Lock-in kündigt sich nie an. Er entsteht in kleinen, vernünftigen Einzelschritten: Das erste Tool war schnell eingeführt, die Prompts wurden auf genau dieses Modell getrimmt, das Firmenwissen wanderte in die Wissensfunktion der Plattform, und die Automatisierungen riefen die API direkt auf. Jeder Schritt für sich war richtig. Zusammen ergeben sie einen Zustand, in dem ein Anbieterwechsel einem Neubau gleichkommt — und genau das weiß auch der Anbieter.
Wo Lock-in im KI-Stack wirklich entsteht
Die Abhängigkeit sitzt selten dort, wo man sie vermutet. Nicht das Abo ist das Problem, sondern das, was sich um das Abo herum ansammelt:
- Prompts und Agenten-Konfigurationen, die auf die Eigenheiten eines Modells getrimmt sind und nirgendwo zentral dokumentiert liegen
- Firmenwissen, das nur in der Wissensbasis der Anbieter-Plattform existiert — ohne sauberen Export der Quelldokumente und Strukturen
- Workflows, die proprietäre APIs direkt aufrufen, sodass jeder Modellwechsel Eingriffe an zwanzig Stellen bedeutet
- Historie und Bewertungen: Korrekturen, Feedback und Qualitätsdaten, die beim Wechsel schlicht verloren gehen
Die Architektur, die Wechselfähigkeit erhält
Die Antwort ist keine Anbieter-Askese, sondern eine klare Trennlinie: Prozesse gehören der Firma, Modelle sind austauschbare Bauteile. Konkret heißt das: Zwischen Geschäftsprozessen und Modell-APIs liegt eine dünne eigene Schicht, die Anfragen entgegennimmt und an das jeweils beste Modell weiterreicht. Firmenwissen lebt in eigenen Datenbanken und Dokumenten, auf die jedes Modell per RAG zugreifen kann — nicht exklusiv in der Plattform eines Anbieters. Prompts, Regeln und Workflows werden wie Quellcode behandelt: versioniert, dokumentiert, im eigenen Repository. Wer so baut, kann Modelle pro Aufgabe wählen und tauschen, statt mit einem Generalisten zu leben, der nur bequem ist.
Die Testfrage für jeden KI-Baustein: Wenn dieser Anbieter morgen seine Bedingungen ändert — wie viele Tage kostet uns der Wechsel? Wer die Antwort nicht kennt, hat den Lock-in schon.
Evals: das Sicherheitsnetz für jeden Modellwechsel
Wechselfähigkeit steht und fällt mit einer unscheinbaren Zutat: automatisierten Testfällen. Wer für jeden wichtigen Prozess eine Sammlung realer Beispiele mit erwarteten Ergebnissen pflegt — zwanzig typische Kundenanfragen, zehn Angebotsszenarien, die kniffligsten Sonderfälle —, kann ein neues Modell in Tagen bewerten statt in Monaten. Ohne diese Evals ist jeder Wechsel ein Blindflug, und aus Angst vor dem Blindflug bleibt man beim alten Anbieter. Mit ihnen wird der Modellmarkt zu dem, was er sein sollte: ein Wettbewerb, von dem der Kunde profitiert.
Wann Lock-in in Ordnung ist
Ehrlich bleiben: Null Abhängigkeit gibt es nicht, und maximale Unabhängigkeit hat ihren eigenen Preis in Komplexität. Es kann rational sein, sich für die Stärken eines Anbieters bewusst zu entscheiden — wenn dessen Ergebnisse messbar besser sind und der Vorsprung den Bindungsnachteil überwiegt. Der Unterschied liegt im Wort „bewusst": Ein dokumentierter Trade-off mit bekanntem Ausstiegspfad ist eine Entscheidung. Ein Zustand, der durch hundert kleine Bequemlichkeiten entstanden ist, ist ein Risiko. Einmal im Jahr gehört deshalb die Frage auf den Tisch: Wo sind wir gebunden, was würde ein Wechsel kosten, und ist uns die Bindung diesen Preis noch wert?
Der Unterschied zwischen Tool-Sammlung und Betriebssystem
Genau hier trennt sich die Tool-Sammlung vom KI-Betriebssystem. Eine Tool-Sammlung ist die Summe fremder Plattformen, in denen die eigene Firma zu Gast ist. Ein Betriebssystem gehört dem Unternehmen: die Daten, die Prozesse, die Prompts, die Qualitätsmaßstäbe — und darunter arbeiten austauschbare Modelle, die man wechselt wie Lieferanten. Wer so denkt, muss keinem Modellrennen hinterherlaufen. Er profitiert von jedem neuen Sieger, weil das eigene System jeden Sieger einspannen kann.