Was ist Vendor Lock-in?

Vendor Lock-in beschreibt den Zustand, in dem die Migration eines Kunden von einem Anbieter zu einem anderen so kostspielig, aufwendig oder technisch komplex ist, dass ein Wechsel praktisch ausgeschlossen ist. Der Begriff stammt aus der klassischen Cloud- und Software-Beschaffung, hat in der KI-Ära aber neue Dimensionen bekommen. Lock-in ist kein binärer Zustand, sondern ein Spektrum. Wechselbarkeit hängt von technischen, vertraglichen und organisatorischen Faktoren ab — Datenformaten, API-Kompatibilität, Mitarbeiter-Kompetenz, Vertragslaufzeiten und integrierten Workflows. Je tiefer die Integration, desto höher die Wechselkosten und desto schwächer die Verhandlungsposition gegenüber dem Anbieter. In modernen Cloud-Architekturen entsteht Lock-in oft schleichend: Eine API-Anbindung pro Quartal, eine proprietäre Workflow-Komponente pro Halbjahr, ein modell-spezifischer Prompt pro Monat — über drei bis fünf Jahre summieren sich diese Einzelentscheidungen zu einer technischen Bindung, die in einer Krise nicht mehr gelöst werden kann. Der wirtschaftliche Schaden zeigt sich erst, wenn der Anbieter Preise erhöht, Funktionen einstellt oder politisch in Konflikt mit dem Kundenstaat gerät — typischerweise also dann, wenn ein Wechsel besonders dringend wäre.

Klassische Cloud-Lock-in-Mechanismen lassen sich in fünf Schichten gruppieren. Erstens Datenformate: proprietäre Speicher-Layouts, die in keinem anderen System gelesen werden können, oder Schemata, deren Migration umfangreiche Transformationen erfordert. Zweitens APIs: jede proprietäre API-Klausel, die nicht standardisiert ist, schafft Bindung — von Authentifizierungs-Mechanismen über Filter-Sprachen bis zu Streaming-Protokollen. Drittens Kompetenz-Bindung: je mehr Engineers mit anbieter-spezifischen Konzepten vertraut sind, desto höher die organisatorische Trägheit beim Wechsel. Tooling-Ökosysteme um einen Anbieter herum verstärken diesen Effekt. Viertens vertragliche Bindung: Mindestlaufzeiten, Volumen-Rabatte, die nur über Jahre amortisieren, exklusive Lizenz-Klauseln, Beendigungs-Strafen. Fünftens Workflow-Integration: je tiefer ein Anbieter in operative Geschäftsprozesse eingebunden ist, desto kostspieliger der Ausstieg. Webhook-Ketten, automatisierte Reportings, eingebettete Iframe-Komponenten und Single-Sign-On-Konstellationen sind alle Lock-in-verstärkend, wenn sie nicht von Anfang an austauschbar entworfen werden. Gemeinsam erzeugen diese Schichten eine Wechselkostenkurve, die exponentiell wächst — nicht linear.

KI-Anbieter haben das Lock-in-Spektrum um eine spezifische Achse erweitert: das Modell selbst. Closed-API-Modelle wie GPT-4o, Claude oder Gemini sind nicht versionierbar — der Anbieter aktualisiert oder ersetzt das Modell, ohne dass Nutzer Zugriff auf den vorherigen Stand haben. Wer Prompts und Workflows auf eine konkrete Modell-Version optimiert hat, sieht seine Optimierungs-Arbeit bei jedem Update neu kalibriert. Prompt-Bibliotheken sind das zweite KI-spezifische Lock-in-Element. Optimale Prompts unterscheiden sich pro Modell — was bei GPT-4 funktioniert, liefert bei Claude andere Ergebnisse, bei Llama wieder andere. Tool-Calling-Schemata, Function-Definitionen und Output-Formate sind ähnlich modell-spezifisch. Drittens Fine-Tunes: ein auf einem Closed-Modell trainierter Fine-Tune ist nicht portabel. Der Anbieter besitzt die zugrundeliegenden Gewichte und kann den Fine-Tune jederzeit deaktivieren oder migrieren. Auch Vector-Datenbanken können in proprietären Formaten gehalten sein, deren Migration eine vollständige Re-Indexierung erfordert. Viertens schließlich Embeddings: ein Embedding-Modell-Wechsel zwingt zur Re-Indexierung des gesamten Vector-Stores, weil Embeddings nicht zwischen Modellen kompatibel sind. Bei Millionen von Dokumenten ist das ein eigenes Projekt.

Sobald ein Unternehmen in Lock-in gerät, ändert sich die Verhandlungsposition gegenüber dem Anbieter strukturell. Preiserhöhungen lassen sich nicht durch Anbieterwechsel parieren; Service-Level-Verschlechterungen bleiben unbeantwortet; politische oder kommerzielle Vorgaben des Anbieterstaats werden zu Geschäftsrisiken des Kunden. Eine Studie der Forrester Research aus dem Jahr 2024 hat Wechselkosten in Cloud-Setups untersucht: Die Migration von einem führenden Hyperscaler zu einem anderen bei mittelgroßen Unternehmen lag im Median bei 12 bis 18 Monaten Projektlaufzeit und 30 bis 50 Prozent der Jahresgesamtkosten der ersetzten Plattform. Bei tief integrierten KI-Workloads ist der Aufwand erfahrungsgemäß höher, weil Eval-Suiten, Prompt-Bibliotheken und Fine-Tunes anbieter-spezifisch optimiert sind. Hinzu kommt das Compliance-Risiko: Wer in einem CLOUD-Act-anfälligen Stack steckt und dort vertraulichen Workload betreibt, übernimmt das volle Risiko, wenn aufsichtsrechtliche Anforderungen oder politische Eskalationen die Lage ändern. Im Worst Case kommen die Migrationskosten dann mit Zeitdruck — Quartale statt geplanter Jahre. Vendor Lock-in ist deshalb nicht nur eine Kosten-, sondern auch eine Risiko-Achse.

Lock-in vermeiden bedeutet nicht, einen Anbieter zu meiden, sondern Architektur so zu entwerfen, dass Wechsel möglich bleibt. Vier Disziplinen tragen. Erstens offene Modelle: Open-Weight-LLMs (Llama, Mistral, Teuken, Qwen) lassen sich selbst hosten und versionieren. Auch wenn ein Unternehmen dauerhaft auf Closed-API-Modellen bleibt, ist das produktive Vorhandensein einer Open-Weight-Alternative im Stack die Verhandlungsbasis. Zweitens OpenAI-kompatible Inferenz-Fassade: vLLM, SGLang, LiteLLM, TGI und LM Studio bieten alle eine OpenAI-kompatible HTTP-API. Anwendungs-Code, der dieses Schnittstellen-Format spricht, kann mit minimaler Anpassung zwischen verschiedenen Backends wechseln — ein Modell-Tausch wird zur Konfigurations-Änderung statt zum Refactor. Drittens offene Daten-Formate: Vector-Stores wie pgvector und Qdrant verwenden offene Embedding-Formate. Modell-Konfigurationen lassen sich als JSON exportieren. Fine-Tunes — auf Open-Weight-Basis — sind als LoRA-Adapter portabel. Viertens Vertragsklauseln: Audit-Recht, vollständige Subprocessor-Transparenz, No-Training-Zusicherung und ein Vertragsgerichtsstand in der EU sind die Grundklauseln, die einen Wechsel vertraglich tragen. Ein Multi-Provider-Setup mit dokumentierter Migrations-Reihenfolge ergänzt das. Diese Disziplinen sind nicht teurer als ein Lock-in-Stack — sie verlagern Aufwand nur in die Architektur-Phase.