Vendor Lock-in

Geschäfts-Praxis

Vendor Lock-in — Abhängigkeit von einem Anbieter — bei KI durch Datenmenge, individuell trainierte Modelle und integrierte Workflows real. Wer 10.000 Custom-GPTs in OpenAI hat, wechselt nicht trivial zu Claude.

Was Vendor Lock-in im KI-Kontext bedeutet

Vendor Lock-in ist die Situation, in der ein Wechsel weg von einem Anbieter teurer oder umständlicher wird, als bei diesem zu bleiben. Bei klassischer SaaS bekannt — bei KI verschärft durch mehrere Faktoren:

• Personalisierte Prompts und Custom-GPTs
• Eigene RAG-Setups mit Embedding-Vektoren
• Workflow-Integrationen über APIs
• Trainingsdaten, die beim Anbieter liegen
• Mitarbeiter-Gewohnheiten und Tool-Skills

Konkrete Lock-in-Stellen bei KI-Tools

1. Custom GPTs und Projects

ChatGPT erlaubt das Bauen von Custom GPTs mit eigenen Anweisungen, Wissensbasen und Aktionen. Claude hat Projects mit ähnlicher Funktion. Beide sind nicht exportierbar in einem Standard-Format. Wenn Sie 50 Custom GPTs aufgebaut haben und wechseln wollen, müssen Sie sie alle in Claude neu erstellen.

2. Fine-tuned Modelle

Wer mit OpenAI ein fine-tuned Modell trainiert hat, bekommt das Modell nicht heraus — nur API-Zugriff. Wechsel bedeutet: neues Training bei anderem Anbieter, neue Kosten.

3. Embeddings-Datenbanken

Wenn Sie 10.000 Dokumente mit OpenAI-Embeddings indexiert haben, sind diese Vektoren OpenAI-spezifisch. Bei Wechsel zu Claude oder lokalem Modell: alles neu einbetten. Bei großen Datenmengen kann das tausende Euro kosten.

4. Workflow-Integrationen

Make-Workflows, n8n-Knoten, Zapier-Zaps — alle sind plattform-spezifisch. Exportierbar in Plattform-eigenem Format, aber nicht direkt portierbar zwischen Plattformen.

5. API-Pricing-Modelle

Wer 100M Tokens/Monat über OpenAI laufen lässt, bekommt Volumen-Rabatte. Bei einem Wechsel verliert er diese und muss neu verhandeln.

Wie Sie Lock-in von Anfang an reduzieren

Datenexport-fähig aufbauen

• RAG-Dokumente immer im Quellformat (PDF, Markdown) zentral speichern, nicht nur in der Vektor-DB
• Embeddings rekomputierbar machen (Quell-Dokumente + Embedding-Modell dokumentiert)
• Prompts in Versionskontrolle (Git) statt nur in Custom GPTs

Standards bevorzugen

• OpenAI-kompatible APIs nutzen — Ollama, vLLM, viele lokale Modelle sprechen dieses Protokoll
• Model Context Protocol (MCP) für Tool-Anbindungen — anbieter-neutral
• Workflow-Plattformen mit Export-Funktion (n8n exportiert als JSON, das in andere Tools übertragbar ist)

Multi-Provider-Strategie

• Wichtige Workflows parallel auf 2 Modellen testen (z.B. Claude + lokales Llama)
• Bei kritischer Abhängigkeit: ein Backup-Modell warm halten
• Für sensitive Daten ohnehin lokale KI als Fallback

Praxisbeispiel: Anwaltskanzlei mit Custom-GPT-Stack

Eine 12-Personen-Kanzlei hat über 18 Monate 30 Custom GPTs in ChatGPT aufgebaut: Vertragsprüfung, Mandantenkommunikation, Recherche-Assistenten. Kosten allein an Entwicklungszeit: ~25.000 €.

Als 2026 OpenAI die Tarife für Teams um 40% erhöht, will die Kanzlei zu Claude wechseln. Realität: alle 30 Custom GPTs müssen in Claude Projects neu nachgebaut werden. Geschätzter Aufwand: 4 Wochen, ~12.000 € Personalkosten. Die Mehrkosten von OpenAI über 2 Jahre wären ~15.000 € gewesen — Wechsel rechnet sich knapp.

Lesson: Frühzeitig dokumentieren und versionieren. Wer Prompts, Anweisungen, Knowledge Files in Git hatte, kann den Wechsel in 1 Woche durchziehen statt 4.

Lokale KI als Anti-Lock-in-Strategie

Die radikalste Antwort auf Vendor Lock-in: das Modell ist auf eigener Hardware. Open-Weights-Modelle (Llama, Qwen, Mistral) sind portabel zwischen Tools. Ollama heute, llama.cpp morgen — die Modell-Datei (GGUF) bleibt gleich.

Verwandte Begriffe

Souveränität · Lokale KI · TCO · Self-Hosting