Den gesamten KI-Stack eines Unternehmens auf einen einzigen Modellanbieter zu setzen, war 2023 sinnvoll. 2026 ist es ein unnötiger Fehler: Die Modellschicht ist der schnelllebigste, am stärksten kommodifizierte und am leichtesten ersetzbare Teil des Stacks – und wer so baut, als wäre sie von Dauer, überlässt einem Anbieter stillschweigend seine Roadmap.

Vor drei Jahren gab es faktisch ein einziges Frontier-Modell, auf dem sich zu bauen lohnte, also war eine enge Kopplung daran vernünftig. Diese Welt gibt es nicht mehr. Heute gibt es mehrere Anbieter mit vergleichbarer Leistungsfähigkeit, die Preise sinken alle paar Monate, und das beste Modell für eine bestimmte Aufgabe wechselt von Quartal zu Quartal. Trotzdem sind die meisten KI-Codebasen in Unternehmen noch immer so geschrieben, als wäre ihr Anbieter eine feste Grösse – anbieterspezifische SDKs ziehen sich durch die Geschäftslogik, Prompts sind auf die Eigenheiten eines Modells abgestimmt, und es gibt keine Möglichkeit, eine Alternative ohne Neuschreiben zu evaluieren.

Das ist kein hypothetisches Risiko. Wir haben Unternehmen von Modellen wegmigriert, die abgekündigt, neu bepreist oder schlicht von der Konkurrenz überholt wurden – und die Kosten dieser Migration wurden vollständig davon bestimmt, wie der Stack vorher aufgebaut war.

Das eigentliche Problem: Die am leichtesten ersetzbare Schicht ist verdrahtet, als wäre sie von Dauer

Stellen Sie sich den KI-Stack in Schichten vor: Ihre Daten und Ihr Retrieval, Ihre Geschäftslogik und Workflows, Ihr Evaluation Harness – und zuunterst das Modell. Das Modell ist die Schicht, die sich am schnellsten ändert und Sie am wenigsten differenziert. Gleichzeitig ist es jene, an die Teams am engsten koppeln: Anbieterspezifische Aufrufe, Annahmen über Antwortformate und Prompt-Eigenheiten sind über die ganze Applikation verstreut.

Das Resultat ist eine Umkehrung guter Architektur: Ihre beständigsten Assets (Daten, Workflows, Evals) hängen von Ihrer unbeständigsten Komponente ab (einer bestimmten Modellversion) – und zwar so, dass die beständigen Teile zu Geiseln der volatilen werden. Wenn sich das Modell ändert – und das wird es –, ist der Wirkungsradius Ihre gesamte Applikation statt einer einzelnen Schicht.

Ein Rahmen: Das Modell hinter Ihrer eigenen Grenze isolieren

Die Lösung ist klassisches Software Engineering, angewendet auf eine Schicht, die Teams als etwas Besonderes behandeln: Setzen Sie eine Abstraktion zwischen Ihre Applikation und den Modellanbieter, sodass der Anbieter zu einem austauschbaren Implementierungsdetail wird statt zu einer strukturellen Abhängigkeit. Konkret:

1. Ein internes Interface für Modellaufrufe. Ihre Applikation spricht mit Ihrem eigenen «Completion»-, «Extraction»- oder «Classification»-Interface, nie direkt mit einem Anbieter-SDK. Anbieterspezifisches liegt hinter dieser Grenze, an einem einzigen Ort, den Sie ändern können.
2. Inputs und Outputs normalisieren. Definieren Sie Ihre eigenen Request- und Response-Strukturen. Adapter übersetzen zu und von jedem Anbieter. Ihre Geschäftslogik sieht nie das Rohformat eines Anbieters – eine Formatänderung ist also eine Adapteränderung, keine Applikationsänderung.
3. Prompts als versionierte Assets führen, nicht als Inline-Strings. Speichern Sie Prompts so, dass sie pro Modell abgestimmt und ausgetauscht werden können, denn derselbe Prompt verhält sich über Anbieter hinweg selten identisch.
4. Das Evaluation Harness anbieterunabhängig machen. Das Harness, das die Qualität belegt, ist genau das, was Ihnen erlaubt, ein neues Modell an einem Nachmittag zu testen. Es muss über dasselbe Interface gegen jeden Anbieter laufen.

Das ist nicht gratis – eine Abstraktion ist echter Code, der gewartet werden muss. Das Ziel ist deshalb die minimale Grenze, die das Modell austauschbar macht, nicht ein ausufernder Framework, der jede erdenkliche Anbieterfunktion unterstützt. Abstrahieren Sie die 90 %, die Sie gemeinsam nutzen; sehen Sie eine dokumentierte Ausnahme für die seltene anbieterspezifische Funktion vor, die Sie wirklich brauchen.

Die Multi-Model-Dividende

Sobald das Modell austauschbar ist, ergeben sich drei Vorteile, die Unternehmen mit nur einem Anbieter nicht haben:

• Aufgabengerechtes Routing. Verschiedene Modelle sind bei verschiedenen Aufgaben besser und günstiger; leiten Sie jeden Workload an das passendste Modell, statt ein Modell zu zwingen, alles zu erledigen.
• Verhandlungsmacht und Resilienz. Eine glaubwürdige Wechselmöglichkeit verändert Ihre kommerzielle Position, und ein Ausfall oder eine Abkündigung beim Anbieter wird zu einer Konfigurationsänderung statt zu einer Krise.
• Verbesserungen sofort übernehmen. Wenn ein besseres oder günstigeres Modell erscheint, testen Sie es gegen Ihre Evals und übernehmen es innert Tagen – und profitieren so von der sinkenden Preiskurve, statt auf dem Modell vom letzten Jahr festzusitzen.

Praxisbeispiel: Eine erzwungene Migration, zwei Verläufe

Zwei Unternehmen, mit denen wir gearbeitet haben, mussten innert weniger Monate von einem Modell wegmigrieren, das ihr Anbieter abkündigte.

Unternehmen A hatte Aufrufe des Anbieter-SDKs und Annahmen über das Antwortformat in rund 40 Codepfaden verteilt, Inline-Prompts, die auf dieses Modell abgestimmt waren, und kein Eval-Set. Die Migration wurde zu einem Projekt von rund 14 Wochen: jeden Aufrufort finden, neu schreiben, Prompts nach dem Prinzip Versuch und Irrtum neu abstimmen und von Hand Regressionstests durchführen – ohne Ground Truth. Hohes Risiko, hohe Kosten, am Ende ungewisse Qualität.

Unternehmen B hatte eine Modellgrenze und ein anbieterunabhängiges Evaluation Harness. Seine Migration: einen neuen Adapter implementieren, das Eval-Set über drei Kandidatenmodelle laufen lassen, das beste auswählen, zwei Prompts hinter dem Interface neu abstimmen. Rund vier Tage – mit dem Nachweis, dass das neue Modell dem alten ebenbürtig oder überlegen war. Dasselbe externe Ereignis, zwei völlig verschiedene Ergebnisse – vollständig entschieden durch eine Architekturentscheidung, die lange vor der Abkündigung getroffen worden war.

Unternehmen B machte aus der erzwungenen Migration sogar ein Upgrade, weil das Evaluation Harness ihm erlaubte, mit Zuversicht ein Modell zu wählen, das zugleich günstiger und etwas besser war. Dieselbe Abstraktion, die es vor dem Nachteil schützte, holte auch den Vorteil ab.

Lock-in versteckt sich auch über und unter dem Modell

Die Modellschicht zu bereinigen ist der offensichtliche Gewinn, aber dieselbe Falle existiert auf zwei weiteren Schichten, die Teams übersehen. Unterhalb des Modells können Ihre Vektordatenbank und Ihre Wahl des Embedding-Modells genauso klebrig sein: Embeddings sind modellspezifisch – ein Wechsel des Embedding-Modells bedeutet also, dass Sie Ihren gesamten Korpus neu einbetten müssen –, und manche Managed Vector Stores machen den Export Ihrer Vektoren bewusst umständlich. Oberhalb des Modells kann das Agenten- oder Orchestrierungs-Framework, das Sie einsetzen, Ihre Geschäftslogik so eng an die Abstraktionen eines Anbieters binden, dass zwar der «Modellwechsel» einfach ist, der «Framework-Wechsel» aber das Neuschreiben Ihrer Workflows erfordert. Eine Multi-Model-Strategie, die das ignoriert, löst nur das sichtbarste Drittel des Problems.

Das Prinzip lässt sich verallgemeinern: Identifizieren Sie jede Schicht des KI-Stacks, auf der das Format eines Anbieters in Ihrer Applikation tragend wird, und ziehen Sie dort eine Grenze. Behalten Sie beim Vector Store Ihre Quelldokumente und Ihre Chunking-Pipeline, damit Sie ohne Datenverlust neu einbetten und in einen anderen Store neu indexieren können. Halten Sie bei der Orchestrierung die eigentliche Geschäftslogik in Ihrem eigenen Code und nutzen Sie den Framework als dünne Bequemlichkeitsschicht, nicht als den Ort, an dem Ihre Workflows leben. Der Test ist auf jeder Schicht derselbe: Wenn dieser Anbieter morgen seine Preise verdoppelt oder den Betrieb einstellt – ist der Wechsel eine Konfigurationsänderung, ein Projekt oder ein Neuschreiben? Überall, wo die Antwort «Neuschreiben» lautet, haben Sie einen undiagnostizierten Lock-in.

Nichts davon bedeutet, auf Managed Services zu verzichten – alles selbst zu bauen, um Lock-in zu vermeiden, ist ein eigener teurer Fehler und nach der Build-vs.-Buy-Logik meist die falsche Entscheidung. Es bedeutet, Managed Services hinter Grenzen zu nutzen, die Sie selbst kontrollieren, sodass der Komfort echt und die Abhängigkeit auflösbar ist. Das Ziel ist nicht Anbieterunabhängigkeit als Ideologie, sondern die Kosten eines Meinungswechsels in jenen Teilen des Stacks tief zu halten, die sich am schnellsten ändern. 2026 bewegt sich der gesamte KI-Stack schnell, darum sind diese Grenzen mehr wert als bei einer stabilen Technologie – die Option zu wechseln ist ein realer, wertvoller Vermögenswert, auch in den Quartalen, in denen Sie sie nicht ausüben.

Stolperfallen

• Überabstraktion. Eine Grenze, die so generisch ist, dass sie jede Anbieterfunktion unterstützt, ist ihr eigener Lock-in – an Ihren Framework. Abstrahieren Sie den Normalfall, sehen Sie für den Rest Ausnahmen vor.
• Abstraktion ohne Evals. Austauschbarkeit nützt nur, wenn Sie belegen können, dass ein Wechsel die Qualität erhält. Das Evaluation Harness ist die andere Hälfte der Strategie.
• An ein Modell gekoppelte Prompts. Prompts als permanente Inline-Strings zu behandeln, führt den Lock-in oberhalb der Grenze wieder ein.
• Verfrühte Multi-Model-Komplexität. Sie müssen nicht vom ersten Tag an fünf Modelle betreiben. Sie brauchen die Architektur, die es Ihnen erlaubt, sobald es sich lohnt.
• Lock-in auf der Datenschicht ignorieren. Das Modell ist die am leichtesten ersetzbare Schicht, aber prüfen Sie Ihren Vector Store und Ihre Datenverträge auf dieselbe Falle.

Checkliste für die Entscheidung

1. Ruft unsere Applikation Anbieter direkt auf oder über ein einziges internes Interface?
2. Sind Request- und Response-Strukturen normalisiert, sodass die Geschäftslogik anbieterunabhängig ist?
3. Sind Prompts versionierte, austauschbare Assets statt Inline-Strings?
4. Kann unser Evaluation Harness über dasselbe Interface gegen jeden Anbieter laufen?
5. Wie lange würde uns heute eine erzwungene Modellmigration kosten – Tage oder ein Quartal?
6. Leiten wir Aufgaben an das jeweils passendste Modell, oder zwingen wir eines, alles zu erledigen?
7. Haben wir die Datenschicht auf denselben Lock-in geprüft, den wir auf der Modellschicht behoben haben?

Die gridz-Sicht

Die Modellschicht ist die Komponente in Ihrem KI-Stack, die am schnellsten an Wert verliert, und eine enge Kopplung daran kehrt gute Architektur um – sie macht Ihre beständigen Assets zu Geiseln Ihrer volatilsten Komponente. Eine dünne Modellgrenze plus ein anbieterunabhängiges Evaluation Harness verwandeln eine erzwungene Migration von einer quartalslangen Krise in ein viertägiges Upgrade – und eine sinkende Preiskurve von etwas, dem Sie zuschauen, in etwas, von dem Sie profitieren. Wir gestalten KI-Architekturen für Unternehmen so, dass das Modell ein austauschbares Detail ist und keine strukturelle Wette – denn 2026 ist die einzige sichere Annahme über das beste Modell, dass es sich ändern wird. Wenn Sie wissen wollen, wie schnell Sie heute wechseln könnten, sprechen Sie uns an.