Model-Harness statt Modell-Ehe: Wer steuert die KI-Kette?

Der Lock-in wandert vom Einzelmodell zur Orchestrierungsschicht. Wer Routing, Kontext, Eval und Fallback nicht steuert, kauft nur eine neue Ehe – diesmal mit dem Harness der Plattform. Cost-to-Outcome wird die Steuerungsgröße, nicht das nächste Frontier-Modell.

VerwandtToken-OPEX: Inference steuert, nicht das Seat-Budget  /  Wenn ein KI-Modell über Nacht verschwindet: Warum CIOs einen Plan B brauchen

Die Debatte um das „beste“ Modell verfehlt den Punkt. Wer morgen steuern will, fragt nicht zuerst nach der nächsten Frontier-Generation. Er fragt, wer Routing, Kontext und Fallback besitzt. Genau dort wandert der Lock-in hin: von der Modell-Ehe zur Orchestrierungsschicht. Microsoft hat das im Earnings Call zu FY26 Q4 in ungewöhnlich klarer Architektur-Sprache ausgesprochen. Der Markt hört Azure-Wachstum. Entscheider sollten die Trennlinie hören.

Warum die Modell-Ehe den falschen Vertrag schreibt

Viele Organisationen binden Workflows, Prompt-Ketten und Wissenszugriff an ein Flagship-Modell. Das wirkt effizient: eine API, ein Team, eine Mental Map. Bis das Modell teurer wird, deprecatet wird oder die Latenz im Peak kippt. Dann sitzt der Kontext im falschen Ort – im Prompt-Zustand, im Vendor-Memory oder in einer Integration, die nur für eine Modellfamilie gebaut wurde.

Plan B für den Modellausfall ist notwendig. Er reicht nicht, wenn der Harness selbst die Ehe ist. Wer nur das LLM tauschen kann, aber Routing, Memory und Eval beim Plattform-Anbieter belässt, hat Substituierbarkeit auf dem Folien-Slide und Abhängigkeit in der Laufzeit. Die Steuerungsfrage lautet: wer steuert die Kette und wer darf Modelle austauschen.

Was ist ein Model-Harness? Ein Model-Harness ist die Orchestrierungsschicht um Modelle herum: Request-Routing, Policy und Guardrails, externer Kontext und Memory, Evaluation und Qualitätsgates, Fallback-Pfade sowie Cost-Guards. Das Modell liefert Inference. Der Harness entscheidet, welches Modell wann läuft, welcher Kontext mitgeht, wann abgebrochen oder umgeleitet wird und wie Outcome gegen Kosten gemessen wird.

Die Zahlen erklären den Druck auf Kapazität und Effizienz. Die Architekturzeile erklärt den Hebel. Wenn der Plattform-Anbieter Harness und Memory vom Modell löst, optimiert er die eigene Kosten- und Margenkurve. Dieselbe Logik gilt intern: Wer Cost-to-Outcome steuern will, braucht dieselbe Trennung – sonst bleibt jede Modellentscheidung ein Betriebssystem-Wechsel.

„Ein neues Model-System, in dem Harness, Context, Memory und Action Space von jeder einzelnen Modellfamilie getrennt sind – mit dem Ziel, die Cost-to-Outcome-Kurve zu steuern.“

Sinngemäß Satya Nadella, Microsoft Earnings Call FY26 Q4

Trenne Harness vom Modell – und Memory vom Prompt

Architektur-Klarheit beginnt mit einer harten Grenze. Das Modell ist austauschbare Inference. Kontext und Memory liegen außerhalb: in Systemen, die ihr steuert, versioniert und auditiert. Der Action Space – Tools, APIs, Schreibrechte – hängt an Policy, nicht an der Modellfamilie. Routing wählt pro Use Case und Lastprofil, nicht pro Lieblings-Vendor.

Praktisch heißt das: Session- und Unternehmenswissen nicht im Modell-Session-State vergraben. Retrieval, Ticket-Historie, CRM-Kontext und Freigabelogik bleiben eigene Schichten. Eval misst Output-Qualität und Compliance-Gates vor dem Write-back. Fallback ist ein Pfad mit Schwellen: Qualitätsdrop, Latenz, Kosten-Ceiling, Policy-Verletzung.

Microsoft formuliert das als Plattform-Design. Für euch ist es Betriebssystem-Design der KI-Kette. Ohne diese Trennung bleibt Multi-Model Marketing. Mit ihr wird Multi-Model zu einem Steuerungsinstrument – und der Harness zur eigentlichen Assets-Frage.

Entscheide Make or Buy der Orchestrierung

Eigenes Routing und eigene Guards bedeuten Aufwand: Observability, Policy-Engine, Modellkatalog, Eval-Pipelines, FinOps-Tags. Vendor-Harness bedeutet Tempo: schnell angebunden, gut integriert, oft eng mit Cloud-Billing und Identity. Beides ist legitim. Unentschieden ist teuer.

Die Entscheidung hängt an drei Fragen. Erstens: Wie kritisch ist Substituierbarkeit für eure Kern-Workflows – Vertragsprüfung, Support-Automation, Produkt-Copilots, interne Wissensarbeit? Zweitens: Wollt ihr Cost-per-Outcome pro Workflow steuern oder akzeptiert ihr gebündelte Plattform-Pauschalen mit begrenzter Transparenz? Drittens: Wer darf Modelle freischalten und sperren, ohne das Fachteam neu zu integrieren?

Buy eignet sich, wenn der Harness standardisierte Workloads abdeckt und ihr Exit-Klauseln sowie Datenportabilität im Vertrag sitzt. Make oder zumindest ein dünner eigener Control-Plane lohnt, wenn Kontext und Action Space euer Differenzierungsvermögen tragen oder regulatorische Nachweisbarkeit die Vendor-Blackbox sprengt. Hybrid ist der häufige Pfad: Vendor-Runtime, eigener Policy- und Eval-Ring, eigener Memory-Store für Kernkontext.

Was nicht funktioniert: ein „neutraler“ Multi-Model-Layer auf dem Folienbild, während Produktion über einen einzigen Plattform-Harness läuft und der Kontext nur dort lesbar ist. Dann ist der Lock-in nicht das LLM. Es ist die Orchestrierung.

Setze Ownership für Eval, Fallback und Cost-Guards

Ohne Owner driftet der Harness in die IT-Plattform oder in das lauteste Fachteam. Beides skaliert schlecht. Benötigt wird eine klare Rolle – oft Platform/AI Engineering mit Mandat – die Modellkatalog, Qualitätsgates und Fallback-Schwellen freigibt. Fachbereiche definieren Outcome-Metriken. Risk und Legal setzen Guardrails für Datenklassen und Write-Rechte. FinOps taggt Kosten pro Workflow, nicht pro „KI-Topf“.

Eval ist kein einmaliger PoC-Score. Es ist der Dauerbetrieb: goldene Sets, Shadow-Traffic, Regression bei Modell-Updates, menschliche Stichproben an den Stellen, an denen Automatisierung Geld oder Reputation bewegt. Fallback-Schwellen müssen messbar sein: ab welchem Qualitätsabfall wechselt ihr? Ab welcher Kostengrenze pro Case greift ein günstigeres Modell? Ab welcher Latenz eskaliert der Flow an Menschen?

Cost-Guards schließen die Schleife. Token-OPEX steuert ohnehin stärker als Seat-Budgets – das haben wir gesondert ausgeführt. Hier zählt die nächste Stufe: Cost-per-Outcome. Was kostet ein gelöster Ticket-Fall, eine geprüfte Klausel, ein freigegebener Support-Draft? Wer nur Token-Volumen sieht, optimiert den Verbrauch. Wer Outcome sieht, optimiert die Kette.

Schreibe Substituierbarkeit in den Vertrag – und prüfe den SPOF

Einkauf kann Lock-in nicht wegverhandeln, wenn die Architektur ihn zementiert. Aber Einkauf kann ihn begrenzen. Verlangt exportierbaren Kontext und Memory, dokumentierte Routing-APIs und das Recht, Modelle innerhalb der Plattform und wo technisch möglich außerhalb zu wechseln, ohne den gesamten Integrationspfad neu zu kaufen. Koppelt Preisanpassungen an Transparenz: welche Anteile entfallen auf Inference, welche auf Orchestrierung und welche auf gebündelte Features?

Substituierbarkeit heißt: Modellwechsel ohne Re-Integration des Kontexts. Wenn jeder Wechsel bedeutet, Prompt-Graphen, Memory und Tool-Bindings neu zu verdrahten, habt ihr keine Multi-Model-Strategie. Ihr habt Migrationsprojekte im Quartalsrhythmus.

Das Gegenrisiko ist real: Harness-Lock-in als neue Single Point of Failure. Fällt die Orchestrierung aus, fallen alle Modelle mit – egal wie redundant euer LLM-Katalog wirkt. Deshalb gehören Resilience-Tests und Exit-Drills auf Harness-Ebene, nicht nur auf Modell-Ebene. Kapazitätsknappheit und Effizienzdruck am Markt machen das dringlicher: Wenn Supply hinter der Nachfrage bleibt, gewinnen jene, die Last intelligent routen und teure Inference nur dort einsetzen, wo Outcome es rechtfertigt. Microsoft adressiert genau diese Spannung mit Effizienz und getrennten Schichten. Intern braucht ihr dieselbe Disziplin.

Die strategische Lesart der Azure-Zahlen ist deshalb nicht „Cloud gewinnt wieder“. Es ist: die Plattform baut die Steuerungsschicht aus, die über Cost-to-Outcome entscheidet. Wer nur Modelle konsumiert, bleibt Mieter. Wer den Harness steuert – selbst, hybrid oder vertraglich hart geführt – bleibt Entscheider über die KI-Kette.

Drei Moves reichen als Einstieg. Erstens: Kartiert für die fünf teuersten oder kritischsten KI-Workflows, wo Routing, Memory, Eval und Fallback heute sitzen – und wer sie ändern darf. Zweitens: Definiert Cost-per-Outcome und Fallback-Schwellen für diese Workflows, bevor das nächste Modell freigeschaltet wird. Drittens: Prüft den laufenden Cloud- und Modellvertrag auf Kontext-Portabilität und Modellwechsel ohne Re-Build. Was sich nicht messen und nicht umschalten lässt, steuert euch – nicht ihr es.

Häufig gestellte Fragen

Bildquelle: KI-generiert (Juli 2026)