Vendor Lock-In bei AI — wie unabhängig bleiben?

Die ehrliche Kurzantwort

Vendor Lock-In bei AI hat vier Schichten, die sich addieren:

1. Modell-Lock-In — Prompts sind auf ein Modell optimiert, Wechsel bedeutet Re-Engineering und Re-Eval
2. API-Format-Lock-In — jeder Anbieter hat eigene Funktions-Schemas, Tool-Calling-Formate, Streaming-Protokolle
3. Embeddings-Lock-In — wer mit OpenAI-Embeddings indiziert hat, muss bei Anbieter-Wechsel die gesamte Vector-DB neu aufbauen
4. Framework-/Tool-Lock-In — Microsoft Copilot in M365, Anthropic Workbench, OpenAI Assistants API binden dich an deren Ökosystem

Pragmatisches Ziel: Anbieter-Wechsel in 2–4 Wochen statt 6 Monaten machbar machen. 100 % Provider-Unabhängigkeit kostet zu viel — du baust sonst alles selbst, ohne die Vorteile von Anbieter-Stack zu nutzen.

Modell-Lock-In: das nicht-offensichtliche Problem

Worin liegt es?

Du hast 200 Prompts für deine Customer-Support-Pipeline auf Claude Sonnet 4.6 optimiert. Wenn du auf GPT-5.5 wechselst, ist nicht garantiert, dass diese Prompts gleich gut funktionieren. Modelle haben unterschiedliche Stärken, unterschiedliche Format-Erwartungen, unterschiedliche Tool-Calling-Konventionen. Realität: 20–40 % der Prompts müssen angepasst werden, weitere 40–60 % re-evaluiert.

Schutz:

• Eval-Set mit 100–300 Test-Cases. Bei jedem Modell-Wechsel laufen lassen. Vorher/Nachher messen.
• Modell-Agnostische Prompts. Vermeidung von Anbieter-spezifischen Spezial-Tags ("" bei Claude, “function_call”-Schemas bei OpenAI).
• Provider-Routing pro Use-Case. Wenn ein bestimmter Use-Case auf Claude besser läuft, dort bleiben — aber auch GPT als Backup eval’en.
• Regelmäßige Re-Eval mit anderem Modell. Quartalsweise: laufende Anwendung gegen Konkurrenzmodell laufen lassen, Qualitätsdrift früh erkennen.

API-Format-Lock-In: lösbar mit Abstraktionsschicht

Was unterscheidet sich zwischen Anbietern:

• Message-Format: OpenAI nutzt messages: [{role: "user", content: ...}], Anthropic nutzt eigenes System-Prompt-Feld, Google Gemini hat anderes Schema
• Tool-Calling / Function-Calling: OpenAI hat tools mit JSON-Schema, Anthropic hat tools mit ähnlichem aber nicht identischem Format, Google hat eigenes
• Streaming: SSE-Format unterscheidet sich, Stop-Sequenzen, Token-Counts
• Caching: OpenAI hat automatisches Caching, Anthropic hat explizite Cache-Control, Google noch in Beta

Schutz: Provider-Abstraktion.

Drei Optionen:

LiteLLM (Open Source) — leichtgewichtige Bibliothek, die >100 Provider unter einem einheitlichen OpenAI-kompatiblen Interface abstrahiert. Auch Streaming, Tool-Calling, Costs. Unsere Standard-Empfehlung für Mittelstand 2026.

LangChain LCEL — verbreitet, viele Provider-Integrationen, aber tieferer Framework-Lock-In als LiteLLM. Lohnt sich nur wenn ihr die LangChain-Patterns für RAG und Agents sowieso nutzt.

Eigener Adapter — wenn ihr nur 2–3 Provider braucht und volle Kontrolle wollt. Eigener Code, 1–2 Tage Arbeit für die Basis-Funktionalität. Vorteil: keine Framework-Abhängigkeit, klare Versionierung.

Anti-Pattern: Direkter import openai-Aufruf an 50 Stellen im Code. Wechsel wird dann archäologisches Projekt.

Embeddings-Lock-In: die unterschätzte Falle

Was passiert.

Du hast 50.000 Dokumente mit text-embedding-3-large von OpenAI indiziert, in einer Qdrant-Datenbank. Wechselst du das Embedding-Modell, sind alle 50.000 Vektoren nicht mehr vergleichbar mit den neuen — du musst alles neu embedden und die DB neu indizieren.

Bei großen Datenbeständen (1 Mio Dokumente, 10 Mio Chunks) ist das ein substantielles Projekt: Compute-Kosten für neue Embeddings, Downtime oder Doppel-Indexing, Re-Eval der Retrieval-Qualität.

Schutz:

• Embedding-Modell mit Versionierung pinnen. Pro Vector-DB-Eintrag speichern, mit welchem Embedding-Modell-Version er erstellt wurde. Bei Migration: alte und neue Indizes parallel betreiben, schrittweise umstellen.
• Open-Source-Embedding-Modelle als Default prüfen. bge-m3, nomic-embed-text, multilingual-e5 — alle on-prem nutzbar, kein Anbieter-Lock-In. Qualität reicht für die meisten Use-Cases.
• Embedding-Stack vom Generation-Stack trennen. Embedding läuft mit Anbieter X, Generation mit Anbieter Y — das geht, weil keine Embedding-Generation-Kopplung besteht.
• Vector-DB Anbieter-neutral wählen. Qdrant, pgvector, Weaviate sind Open Source und on-prem-fähig. Pinecone und andere SaaS bringen zusätzliches Anbieter-Risiko.

Framework- und Tool-Lock-In

Wo Lock-In besonders eng ist:

• OpenAI Assistants API — proprietäres Konzept, schwer auf andere Anbieter zu migrieren
• Microsoft Copilot for Microsoft 365 — Daten und Logik in M365-Welt eingebunden
• Anthropic Workbench und Anthropic-spezifische Features (Computer Use)
• Vendor-spezifische Vector-Stores (Pinecone, Weaviate Cloud) und ihre Specialty-Features

Schutz:

• Vendor-Features sparsam nutzen. Wenn du nicht alle Funktionen von OpenAI Assistants brauchst, baue mit Standard-Chat-Completion-API. Migrierbar ist besser als bequem.
• Anbieter-spezifische Tools nur für unkritische Use-Cases. Microsoft Copilot für interne Recherche: ok. Für die zentrale Customer-Support-Pipeline: vermeiden.
• Eigenen Memory-Layer. Statt OpenAI Assistants-Threads ein eigener Postgres-basierter Memory-Stack — funktioniert mit jedem LLM.

Vertragliche Schutzmaßnahmen

Im AVV regeln:

• Daten-Export in standardisiertem Format am Vertragsende
• Aufbewahrungsfristen klar definiert
• Sub-Prozessor-Liste mit Widerspruchsrecht
• Modell-Lifecycle-Information (Deprecation-Notices mit Vorlaufzeit)
• SLA für Modell-Verfügbarkeit während angekündigter Migrationszeiten

Multi-Vendor-Strategie:

• Mit mindestens zwei Anbietern AVV abschließen, auch wenn einer der Hauptanbieter ist
• Test-Workloads regelmäßig beim Zweit-Anbieter laufen lassen, damit Quoten und Setup im Notfall verfügbar sind
• Bei kritischen Workloads: parallel betreiben, primärer und sekundärer Pfad

Was wir bei Mittelstandskunden 2026 typisch bauen

Tier 1: Standard-Schutz (5–10 Tage Aufwand)

• LiteLLM oder eigener leichtgewichtiger Adapter
• Eval-Set mit 100 Test-Cases
• Embedding-Modell auf bge-m3 oder text-embedding-3-large (mit Versionierung)
• Provider-neutrale Vector-DB (Qdrant on-prem oder pgvector)
• AVV mit primärem und sekundärem Anbieter

Tier 2: Erweiterter Schutz (10–20 Tage zusätzlich)

• Aktive Multi-Vendor-Routing-Logik basierend auf Use-Case, Daten-Klassifizierung und Verfügbarkeit
• Quartalsweise Cross-Vendor-Eval
• Eigener Memory-Layer in Postgres
• Vector-DB-Versionierung mit Migrationsskripten

Tier 3: Vollabstraktion (großes Projekt)

• On-prem-Open-Source-Stack als parallele Architektur
• Daten-Klassifizierungs-Router (grün/gelb/rot)
• Failover-Tests in CI/CD-Pipeline

Was du heute nicht tun solltest

Keine direkten import openai-Aufrufe an mehr als drei Stellen im Code. Keine Vector-DB-Indexierung ohne Embedding-Modell-Versionsstempel. Und keine “wir bleiben für immer bei Anbieter X”-Strategie — Anbieter ändern Preise, AVVs, AGB, Deprecation-Policies. Wer keine Migration vorbereitet hat, zahlt drauf.

Pragmatischer Einstieg: LiteLLM in den Stack einziehen, Eval-Set aufbauen, Embedding-Modell mit Versionsstempel speichern. Drei Wochen Aufwand für einen Mittelstandskunden — danach läuft das im Hintergrund und der Wechsel ist machbar, wenn er nötig wird.