KI sollte Unternehmen einen Vorteil verschaffen. Sie kann auch eine neue Abhängigkeit schaffen
Noch vor einigen Jahren bezog sich die Diskussion um Vendor Lock-in vor allem auf Cloud, ERP-Systeme, Datenbanken oder zentrale Technologieplattformen.
Unternehmen stellten Fragen: Kann ich die Anwendung zu einem anderen Cloud-Provider migrieren? Kann ich die Datenbank wechseln? Können wir uns von einem bestimmten System lösen?
Heute kommt zu dieser Liste ein weiterer Punkt hinzu – künstliche Intelligenz.
Organisationen bauen zunehmend Systeme mit Sprachmodellen, generativer KI, RAG-Lösungen, Prozessautomatisierung und KI-Agenten. Modelle werden Teil von Anwendungen, Vertriebsprozessen, Kundensupport, Dokumentenanalyse, Entscheidungsystemen und der täglichen Arbeit von Teams.
In der Praxis bedeutet das, dass ein Unternehmen nicht nur von einer bestimmten Software, sondern auch von einem bestimmten Anbieter der „Intelligenz“, die seine Systeme antreibt, abhängig werden kann.
Und hier entsteht das Problem. Denn etwas zu nutzen ist nicht dasselbe wie davon abhängig zu sein.
Das ist genau der Unterschied zwischen bewusster technologischer Abhängigkeit und Vendor Lock-in.
Was ist eigentlich AI Vendor Lock-in?
Vendor Lock-in bezeichnet eine Situation, in der eine Organisation so stark an einen Technologieanbieter gebunden ist, dass ein Wechsel zu einer Konkurrenzlösung schwierig, teuer, zeitaufwändig oder riskant wird.
In der KI-Welt kann das weit mehr Formen annehmen als die klassische Abhängigkeit von einer API.
Ein Unternehmen kann abhängig sein von:
- einem konkreten KI-Modell,
- einem bestimmten API-Anbieter,
- einem spezifischen Kommunikationsformat,
- Funktionen, die ausschließlich bei einem Anbieter verfügbar sind,
- einem Agentensystem,
- der Cloud-Infrastruktur,
- der Art der Datenspeicherung,
- einem spezifischen Embedding-Mechanismus,
- einem bestimmten RAG-System,
- der Art, wie Agenten Tools aufrufen,
- Prompts, die auf ein bestimmtes Modell optimiert sind,
- Kompetenzen des Teams, die an ein Ökosystem gebunden sind.
Deshalb ist die Frage: „Nutzen wir OpenAI?“
viel zu einfach.
Besser wäre die Frage: „Wie schwer wäre es für uns, den KI-Anbieter in sechs Monaten zu wechseln?“
Wenn die Antwort lautet: „Wir wissen es nicht.“ – dann kann das das erste Warnsignal sein.
OpenAI, Anthropic, Google – spielt die Anbieterauswahl eine Rolle?
Auf dem Markt existieren heute mehrere starke Ökosysteme für Modelle und KI-Dienste, unter anderem Angebote von OpenAI, Anthropic und Google.
Jeder dieser Anbieter entwickelt eigene Modelle, APIs, Tools und Zusatzdienste.
Das Problem ist nicht, dass einer von ihnen „schlecht“ ist. Im Gegenteil.
Die Nutzung fertiger, hochwertiger Modelle ist oft die beste geschäftliche Lösung. Nicht jedes Unternehmen sollte ein eigenes Modell trainieren. Nicht jedes braucht eigene GPU-Infrastruktur. Nicht jede Organisation sollte den gesamten KI-Stack von Grund auf bauen.
Ein externer Anbieter ermöglicht schnelleren Markteintritt, reduziert Anfangskosten und bietet Technologie, deren Eigenentwicklung für die meisten Organisationen unerreichbar wäre.
Das Problem entsteht, wenn ein Unternehmen den Anbieter nicht mehr als austauschbaren Baustein betrachtet, sondern das gesamte Produkt so entwirft, als würde der gewählte Anbieter in unveränderter Form die nächsten zehn Jahre bestehen.
Und das lässt sich nicht garantieren…
Modelle werden aktualisiert, ältere Versionen werden eingestellt, Preise und Limits ändern sich, APIs verändern sich, neue Modelle erscheinen, Lizenzbedingungen ändern sich, Wettbewerbsfähigkeit verändert sich.
Das ist ein normaler Teil des Technologiemarktes.
Deshalb sollte eine KI-Architektur nicht nur fragen: „Welches Modell ist heute am besten?“
sondern auch: „Welchen Preis zahlen wir, wenn wir in einem Jahr ein anderes Modell verwenden wollen?“
Die größte Falle – „wir tauschen einfach die API“
Auf den ersten Blick scheint eine Migration trivial.
Wir haben eine Anwendung. Die Anwendung sendet eine Anfrage ans Modell. Das Modell antwortet. Wir wechseln den Anbieter. Fertig…
In Wirklichkeit kann es ganz anders aussehen.
Stellen Sie sich eine Anwendung vor, die zwei Jahre lang um ein bestimmtes Modell herum entwickelt wurde.
In dieser Zeit hat das Team:
- Hunderte von Prompts erstellt,
- deren Inhalte optimiert,
- das Antwortformat angepasst,
- ein RAG-System aufgebaut,
- Tool-Calling konfiguriert,
- Agenten entwickelt,
- Workflows entworfen,
- Tests vorbereitet,
- Benutzer in der Arbeit mit dem System geschult.
Nach zwei Jahren stellt sich heraus, dass das Modell in der bisherigen Version nicht mehr verfügbar ist.
Oder die Preise steigen, oder ein Konkurrenzmodell ist deutlich besser, oder das Unternehmen möchte Teile der Daten in eine andere Umgebung verschieben.
Theoretisch genügt ein API-Wechsel – praktisch kann es nötig werden, die gesamte Systemlogik neu zu testen.
Warum?
Weil Modelle nicht identisch sind:
- Sie unterscheiden sich in der Interpretation von Anweisungen.
- Sie unterscheiden sich in der Antwortqualität.
- Sie verhalten sich unterschiedlich im Langzeitkontext.
- Sie verwenden Tools unterschiedlich.
- Sie unterstützen strukturierte Ausgaben verschieden.
- Sie unterscheiden sich in der Multimodalität.
- Sie differieren in der Geschwindigkeit.
- Sie unterscheiden sich im Preis.
- Und sie verhalten sich unterschiedlich in Randfällen.
Deshalb kann eine Migration zwischen Modellen eher einer Migration eines ganzen Geschäftskomponenten gleichen als einem simplen URL-Tausch.
Fünf Ebenen des AI Vendor Lock-in
Es lohnt sich, Lock-in breiter zu betrachten.
1. Modell-Lock-in
Die einfachste Ebene.
Die Anwendung wurde für ein bestimmtes Modell optimiert.
Ein Prompt funktioniert mit einem Modell hervorragend, mit einem anderen schlechter.
Das System basiert auf spezifischen Fähigkeiten dieses Modells.
Ein Wechsel erfordert erneutes Feinjustieren.
2. API-Lock-in
Das System nutzt direkt Funktionen eines bestimmten Anbieters.
Je mehr spezifische Funktionen verwendet werden, desto schwieriger kann die Migration werden.
Es geht nicht nur um reine Texterzeugung.
Wichtig sind auch:
- strukturierte Ausgaben,
- Function-Calling,
- Tool-Calling,
- Multimodalität,
- Kontextmanagement,
- Sicherheitsmechanismen,
- Agentensysteme.
3. Daten-Lock-in
Daten können so gespeichert sein, dass sie stark an ein Ökosystem gebunden sind.
Das betrifft zum Beispiel:
- Embeddings,
- Vektorindices,
- Metadaten,
- Interaktionshistorien,
- RAG-Konfigurationen.
Migration kann nicht nur Datenverschiebung, sondern auch deren Neuprozessierung erfordern.
4. Architektur-Lock-in
Das ist eine deutlich schwerwiegendere Ebene.
Die gesamte Anwendung ist um einen einzelnen Anbieter herum entworfen.
Seine Mechanismen sind an vielen Stellen des Systems verankert.
Dann tauscht man nicht nur ein Bauteil aus – man rekonstruiert Teile der Architektur.
5. Organisationaler Lock-in
Das ist oft das am meisten unterschätzte Problem.
Das Team kennt nur ein Ökosystem.
Alle Kompetenzen konzentrieren sich auf eine Lösung.
Dokumentation, Prozesse, Tests und Know-how sind an einen Anbieter gebunden.
Selbst wenn ein technischer Wechsel möglich wäre, fehlen die Menschen, die ihn durchführen können.
Dann wird Vendor Lock-in nicht mehr nur zu einem technischen Problem – es wird ein geschäftliches Problem.
Löst Multi-Model das Problem?
Die natürliche Antwort lautet: „Wenn ein Anbieter ein Risiko ist, nutzen wir mehrere.“
Das ist jedoch nicht immer die beste Strategie.
Eine Multi-Model-Architektur hat Kosten.
Man muss managen:
- mehrere APIs,
- verschiedene Limits,
- unterschiedliche Preismodelle,
- verschiedene Qualitätsstufen,
- unterschiedliche Antwortformate,
- Tests,
- Monitoring,
- Sicherheit.
Das System wird komplexer.
Deshalb sollte das Ziel nicht lauten: „Wir müssen fünf Anbieter nutzen.“
Sondern: „Wir müssen die Möglichkeit haben, den Anbieter zu wechseln, falls das Geschäft es erfordert.“
Das ist der wesentliche Unterschied.
Nicht jedes Unternehmen braucht Multi-Model.
Jedes Unternehmen sollte jedoch wissen, wie eine Migration zu einem anderen Modell aussehen würde.
AI Gateway und Model Gateway – eine Schicht, die die Anwendung vom Anbieter trennt
Eine Möglichkeit, Abhängigkeit zu mindern, ist die Einführung einer Zwischenschicht.
Sie kann als AI Gateway oder Model Gateway fungieren.
Vereinfacht könnte die Architektur so aussehen:
Business-Anwendung
↓
AI-Abstraktionsschicht
↓
Model-Routing
↓
Provider-Adapter
↓
OpenAI / Anthropic / Google / Open-Weight-Modell / lokales Modell
So muss die Business-Logik der Anwendung nicht die Details jedes Anbieters kennen.
Wir können eine Schicht haben, die verantwortlich ist für:
- Modellauswahl,
- Routing,
- Fallback,
- Kostenkontrolle,
- Monitoring,
- Logging,
- Sicherheitsrichtlinien,
- Limit-Management.
Bei einem Ausfall eines Anbieters kann das System versuchen, ein anderes Modell zu nutzen.
Bei Preiserhöhungen kann das Routing angepasst werden.
Erscheint ein besseres Modell, können Tests gefahren und eine Migration geplant werden.
Das bedeutet nicht, dass ein Wechsel immer schmerzfrei ist.
Es bedeutet jedoch, dass der Wechsel als reale Möglichkeit entworfen wurde.
Model Router – die KI muss nicht immer dasselbe Modell wählen
Noch interessanter ist das Modell-Routing.
Stellen Sie sich ein System vor, das unterschiedliche Aufgaben erhält.
Eine einfache Aufgabe: „Fasse diesen Text zusammen.“
Diese kann an ein schnelles, günstiges Modell geschickt werden.
Eine komplexere Aufgabe: „Analysiere das Dokument und erstelle eine detaillierte Empfehlung.“
Diese kann an ein stärkeres Modell gehen.
Eine Aufgabe mit Bildanalyse kann an ein multimodales Modell routen.
Das System wählt also dynamisch das Modell passend zur Aufgabe.
Das erlaubt Optimierung von:
- Kosten,
- Qualität,
- Antwortzeit,
- Verfügbarkeit.
In diesem Ansatz wird der KI-Anbieter nicht zur integralen Business-Logik – er ist ein Teil der Infrastruktur.
Und das ist eine wichtige architektonische Veränderung.
Abstraktion bedeutet nicht, dass alle Modelle gleich sind
Hier muss vor einer Falle gewarnt werden.
Man kann eine eigene Funktion schreiben: generateText() und denken, damit sei das Problem gelöst.
Ist es nicht.
Modelle sind keine austauschbaren LEGO-Steine.
Wenn eine Anwendung spezifische Fähigkeiten eines Modells nutzt, kann eine einfache Abstraktion das Problem nur verschleiern.
Gute Architektur abstrahiert vom Anbieter, steuert aber bewusst die Unterschiede zwischen Modellen.
In der Praxis sollte die AI-Schicht wissen, dass Modelle verschiedene haben können:
- Fähigkeiten,
- Limits,
- Kosten,
- Qualitätsniveaus,
- Funktionen,
- Kontexte,
- Parameter.
Provider-Agnostisch zu sein sollte nicht bedeuten, so zu tun, als seien alle Modelle gleich.
Sondern, dass das System bewusst mit den Unterschieden zwischen Modellen umgehen kann.
Evals – ohne sie ist Migration Raten
Einer der wichtigsten Bausteine einer change-resistenten Architektur sind Evals, also systematische Tests der Modellqualität.
Angenommen, wir haben 1000 reale Use-Cases. Wir führen sie auf dem aktuellen Modell aus. Dann auf dem neuen. Wir vergleichen die Ergebnisse.
Wir prüfen:
- Qualität,
- Korrektheit,
- Vollständigkeit,
- Halluzinationen,
- Konformität mit Anforderungen,
- Antwortzeit,
- Kosten.
Nur dann können wir sagen: „Das neue Modell ist gut genug.“
Ohne Evals ist eine Migration ein Experiment. Mit Evals wird sie ein ingenieurmäßiger Prozess.
Deshalb sollte ein KI-nutzendes Unternehmen eigene Testsuites aufbauen. Nicht nur das API testen, sondern den eigenen Business-Use-Case. Das ist ein enormer Unterschied.
Prompts können ebenfalls Quelle des Vendor Lock-in sein
Prompts behandeln wir oft als Texte. In der Praxis können sie Teil der Business-Logik werden.
Wenn ein Team über Monate Anweisungen für ein bestimmtes Modell optimiert, können Prompts anfangen wie Code zu wirken.
Deshalb sollten sie:
- versioniert,
- getestet,
- dokumentiert,
- überwacht sein.
Es ist zudem wichtig zu wissen, welche Prompts kritisch für das System sind. Wenn ein Modellwechsel ihre Wirksamkeit verschlechtert, muss klar sein, wo man suchen muss.
In reifen KI-Systemen sollte Prompt-Engineering zunehmend wie Teil der Software-Engineering-Praxis behandelt werden.
Open-Weight und eigene Modelle – sind sie die Flucht vor Vendor Lock-in?
Open-Weight-Modelle und die Möglichkeit, Modelle in eigener Infrastruktur zu betreiben, erhöhen die Kontrolle über Technologie.
Das bedeutet aber nicht automatisch vollständige Unabhängigkeit.
Wenn wir ein Modell in eigene Infrastruktur bringen, brauchen wir weiterhin:
- GPUs,
- Infrastruktur,
- MLOps,
- Monitoring,
- Sicherheit,
- Updates,
- Kompetenzen.
Wir können also die Abhängigkeit vom Modellanbieter reduzieren, gleichzeitig aber die Abhängigkeit von einem Infrastruktur-Anbieter erhöhen. Oder wir nutzen die Cloud, um Open-Weight-Modelle zu betreiben – dann verlagert sich das Problem auf eine andere Ebene.
Ein komplett abhängigkeitfreies System gibt es nicht.
Es gibt jedoch Systeme, bei denen Abhängigkeiten:
- bekannt,
- kontrolliert,
- messbar,
- ersetzbar sind.
Die gefährlichste Form des Vendor Lock-in sitzt im Kopf des Teams
Stellen Sie sich ein Unternehmen vor, das einen einzigen KI-Anbieter nutzt.
Technisch könnte es das Modell wechseln. Aber niemand weiß, wie.
Das Team kennt keine Alternativen.
Es gibt keine Benchmarks.
Keine Evals.
Keine Tests.
Keine Erfahrung mit anderen Modellen.
Alle Lösungen wurden um ein Ökosystem herum gebaut.
Das ist organisatorischer Lock-in.
Daher erfordert Resilienz gegen Vendor Lock-in auch Investitionen in Kompetenzen.
Das Team sollte verstehen:
- wie Modelle funktionieren,
- welche Unterschiede zwischen Anbietern bestehen,
- wie man eine Abstraktionsschicht baut,
- wie man Modelle testet,
- wie man Qualität misst,
- wie man Kosten managt,
- wie man eine Migration durchführt.
Es geht nicht darum, dass jeder Entwickler jedes API kennen muss.
Sondern darum, dass die Organisation technologisch nicht blind an ein einziges Ökosystem gebunden ist.
Wann kann Vendor Lock-in akzeptabel sein?
Vendor Lock-in ist nicht immer schlecht.
Manchmal ist eine bewusste Bindung eine vernünftige geschäftliche Entscheidung.
Wenn:
- der Anbieter eine herausragende Funktion bietet,
- die Lösung die Time-to-Market deutlich verkürzt,
- die Migrationskosten bekannt sind,
- das Risiko akzeptabel ist,
- Alternativen schwächer sind,
- das Geschäft Geschwindigkeit braucht,
kann eine stärkere Bindung an einen Anbieter gerechtfertigt sein.
Das Problem ist nicht der Lock-in an sich – das Problem ist unbewusster Lock-in.
Ein Unternehmen sollte wissen:
- wovon es abhängig ist,
- warum es abhängig ist,
- wie viel ein Wechsel kosten würde,
- wie lange eine Migration dauern würde,
- welche Alternativen existieren.
Nur dann ist eine bewusste architektonische Entscheidung möglich.
Wie bewertet man AI Vendor Lock-in im eigenen Unternehmen?
Ein einfacher Audit ist hilfreich.
Stellen Sie sich Fragen:
Können wir das Modell wechseln, ohne die ganze Anwendung umzubauen?
Ist die Business-Logik unabhängig vom KI-Anbieter?
Sind Prompts versioniert?
Haben wir eigene Evals?
Gibt es Regressionstests für die wichtigsten Use-Cases?
Können wir Daten exportieren und migrieren?
Können wir Embeddings-Anbieter wechseln, ohne Datenverlust?
Nutzen Agenten eine Orchestrationsschicht oder sind sie direkt an ein Ökosystem gebunden?
Haben wir die Möglichkeit, ein alternatives Modell einzusetzen?
Gibt es einen Fallback?
Wissen wir, wie viel eine Migration kosten würde?
Wissen wir, wie lange eine Migration dauern würde?
Haben wir Leute, die sie durchführen können?
Je mehr „Nein“-Antworten, desto größer die Abhängigkeit.
Sie können auch einen eigenen AI Portability Score entwickeln. Beispielsweise die Organisation in fünf Bereichen bewerten:
Architektur – ist der Anbieter austauschbar?
Daten – können wir sie migrieren?
Modelle – haben wir Alternativen?
Evaluation – können wir Modelle vergleichen?
Kompetenzen – kann das Team die Migration durchführen?
So ein Ergebnis muss kein formaler Standard sein, kann aber ein wertvolles Management-Tool sein.
Denn manchmal ist das größte Problem nicht der Lock-in selbst – sondern dass das Unternehmen nicht weiß, dass es ihn hat.
Wie entwirft man eine KI-Architektur, die resilient gegenüber Veränderungen ist?
Es gibt keine universelle Architektur. Aber einige praktische Prinzipien helfen.
Prinzip 1 – Trennen Sie Business-Logik vom KI-Anbieter
Bauen Sie das System nicht unmittelbar um eine einzelne API herum.
Prinzip 2 – Nutzen Sie Abstraktionsschichten, wo sinnvoll
Ein AI Gateway oder Model Gateway kann die Abhängigkeit der Anwendung vom Anbieter reduzieren.
Prinzip 3 – Versionieren Sie Prompts
Behandeln Sie sie als Systembestandteil, nicht als lockere Texte.
Prinzip 4 – Bauen Sie Evals
Gehen Sie nicht davon aus, dass „ein neues Modell funktioniert“. Testen Sie es.
Prinzip 5 – Testen Sie Alternativen
Sie müssen sie nicht produktiv verwenden. Es ist jedoch sinnvoll zu wissen, wie sie mit Ihren Use-Cases umgehen.
Prinzip 6 – Kontrollieren Sie Ihre Daten
Lassen Sie nicht zu, dass Ihre Geschäftsdaten zum Geisel einer Plattform werden.
Prinzip 7 – Dokumentieren Sie Abhängigkeiten
Wissen, wo das System an einen Anbieter gebunden ist, gehört zur Architektur-Dokumentation.
Prinzip 8 – Abstrahieren Sie nicht um jeden Preis
Verstecken Sie Unterschiede zwischen Modellen nicht nur, um eine scheinbare Portabilität zu erreichen.
Prinzip 9 – Messen Sie die Migrationskosten
Es reicht nicht zu sagen: „Irgendwann können wir wechseln.“
Sie müssen wissen:
„Wir brauchen dafür drei Monate und fünf Personen.“
Oder:
„Wir können das nicht ohne Architekturumbau.“
Prinzip 10 – Treffen Sie bewusste Entscheidungen
Manchmal ist die Bindung an einen Anbieter die beste Wahl.
Aber es sollte ein bewusstes Risiko sein.
Kein Zufall.
Die Frage, die jeder CTO stellen sollte
Stellen Sie sich vor, morgen würde der KI-Anbieter:
- die Preise verdoppeln,
- das von uns genutzte Modell zurückziehen,
- Limits ändern,
- eine für unser Produkt kritische Funktion einschränken,
- nicht mehr unsere Compliance-Anforderungen erfüllen.
Was tun wir?
Wenn die Antwort lautet: „Wir wechseln den Anbieter.“
dann sollte die nächste Frage lauten: „Wie lange würde das dauern?“
Ein Tag?
Eine Woche?
Ein Monat?
Ein halbes Jahr?
Oder wissen wir es nicht?
Das ist das Maß für unsere technologische Resilienz.
Zusammenfassung – es geht nicht darum, keinen Anbieter zu haben
Ein vollständig unabhängiges System von externen KI-Anbietern zu bauen, kann unrentabel, unnötig oder schlicht unmöglich sein.
Darum geht es nicht.
Ziel ist nicht Abwesenheit von Abhängigkeiten. Ziel ist bewusstes Management von Abhängigkeiten.
Wir können OpenAI nutzen. Wir können Anthropic nutzen. Wir können Google nutzen. Wir können Open-Weight-Modelle verwenden. Wir können verschiedene Lösungen kombinieren.
Wichtig ist, zu wissen, wo die Grenze verläuft zwischen: „wir nutzen Technologie“ und „wir sind von ihr abhängig“.
In der KI-Welt ist diese Grenze oft schwer zu erkennen. Vendor Lock-in entsteht nicht über Nacht. Er entsteht schrittweise. Zuerst integrieren wir eine API. Dann bauen wir eine Funktion. Dann fügen wir RAG hinzu. Dann Agenten. Dann automatisieren wir Prozesse. Schließlich beginnt das ganze Team, nach diesem System zu arbeiten. Und plötzlich ist ein Modellwechsel nicht mehr nur ein Wechsel des Modells – er ist eine Veränderung eines Teils der Organisation.
Deshalb sollte KI-Architektur nicht nur auf was heute funktioniert ausgelegt sein, sondern auch auf was passiert, wenn sich die Technologie von morgen verändert.
Sie müssen kein System bauen, das ohne OpenAI, Anthropic oder Google funktioniert. Sie sollten jedoch ein System bauen, das auch dann arbeiten kann, wenn einer dieser Anbieter ausfällt.
Das ist der Unterschied zwischen dem Nutzen von KI und dem bewussten Entwurf von KI-Technologie.
