# Vendor Lock-In bei AI vermeiden — Strategien für Mittelstand 2026 > Welche Lock-In-Schichten bei AI-Stacks bestehen, wie Sie sie technisch und vertraglich entschärfen und welcher Aufwand 2026 realistisch ist. Quelle: https://www.krynexlabs.de/wissen/vendor-lock-in-vermeiden/ Stand: 2026-09-30 Anbieter: Krynex Labs UG (haftungsbeschränkt) i. G., Chemnitz · https://www.krynexlabs.de --- Praxis & Mittelstand # 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 Sie an deren Ökosystem **Pragmatisches Ziel:** Anbieter-Wechsel in **2–4 Wochen statt 6 Monaten** machbar machen. 100 % Provider-Unabhängigkeit kostet zu viel — Sie bauen sonst alles selbst, ohne die Vorteile von Anbieter-Stack zu nutzen. ## Modell-Lock-In: das nicht-offensichtliche Problem **Worin liegt es?** Sie haben 200 Prompts für Ihre Customer-Support-Pipeline auf Claude Sonnet 5.5 optimiert. Wenn Sie auf GPT-6 Sol wechseln, 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 Sie die LangChain-Patterns für RAG und Agents sowieso nutzt. **Eigener Adapter** — wenn Sie nur 2–3 Provider brauchen und volle Kontrolle wollen. 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.** Sie haben 50.000 Dokumente mit `text-embedding-3-large` von OpenAI indiziert, in einer Qdrant-Datenbank. Wechseln Sie das Embedding-Modell, sind alle 50.000 Vektoren nicht mehr vergleichbar mit den neuen — Sie müssen **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 Sie nicht alle Funktionen von OpenAI Assistants brauchen, bauen Sie 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 Sie heute nicht tun sollten 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. ## Dazu bei Krynex Labs Leistung Modell-Inventur: was bald abgeschaltet wird → https://www.krynexlabs.de/services/modell-inventur/ Wissen LLM-Preise vergleichen → https://www.krynexlabs.de/wissen/llm-preise-vergleichen/ Workshop Workshop KI im Arbeitsalltag → https://www.krynexlabs.de/workshops/ki-im-arbeitsalltag/ ## Passend dazu Insights RAG-Systeme scheitern an drei Stellen — keine davon ist das Modell → https://www.krynexlabs.de/blog/rag-mistakes/ Wissen KI-Agent oder Automatisierung: was braucht Ihr Prozess? → https://www.krynexlabs.de/wissen/ki-agent-oder-automatisierung/ Wissen KI im Mittelstand einführen: der praktische Leitfaden → https://www.krynexlabs.de/wissen/ki-im-mittelstand-einfuehren/ ## Konkrete Frage zu eurem Setup? Ein 30-Minuten-Erstgespräch klärt meistens schon, ob euer aktueller AI-Stack hält oder wo nachzuarbeiten ist. Kostenlos, ohne Verkaufsdruck. [Erstgespräch buchen](https://www.krynexlabs.de/kontakt/)