TL;DR — die 90-Sekunden-Zusammenfassung
KI-Abhängigkeiten entstehen nicht nur über Infrastruktur — sie entstehen über proprietäre APIs, nicht-portable Embeddings und modellspezifische Prompting-Techniken. Wer AI-Features so baut, dass sie nur mit einem einzigen Anbieter funktionieren, wiederholt den Cloud-Lock-in-Fehler auf einer neuen Ebene. Portable KI-Architektur ist lösbar — wenn man die Weichen früh richtig stellt.
Das neue Lock-in-Muster
Cloud-Lock-in ist bekannt: proprietäre Dienste, keine Exportpfade, prohibitive Migrationskosten. Die Branche hat daraus gelernt — zumindest teilweise.
KI-Lock-in folgt demselben Muster, nur auf einer neuen Ebene. Und diesmal geht es schneller, weil die Integration tiefer ist: Eure Applikationslogik spricht direkt mit der OpenAI-API. Eure Embeddings wurden mit dem Ada-002-Modell erzeugt — nicht portierbar zu anderen Embedding-Modellen ohne vollständige Re-Indexierung. Eure Prompts nutzen modellspezifische Besonderheiten von GPT-5.5. Eure Nutzerdaten fließen durch die Infrastruktur eines US-amerikanischen Unternehmens, das seine Nutzungsbedingungen einseitig ändern kann.
Das sind reale Abhängigkeiten — und sie wachsen mit jeder Feature-Integration.
Wo KI-Abhängigkeiten entstehen
Ebene 1: API-Abhängigkeit — Der direkteste Lock-in: Applikationscode, der hart gegen einen proprietären API-Endpoint kodiert ist. Jeder Anbieterwechsel erfordert Code-Änderungen.
Ebene 2: Modell-Prompting-Abhängigkeit — Manche Prompting-Techniken funktionieren gut mit einem bestimmten Modell, schlecht mit anderen. Wer tief in modellspezifische Eigenheiten investiert, hat impliziten Lock-in aufgebaut.
Ebene 3: Embedding-Abhängigkeit — Embeddings sind Vektoren, die ein spezifisches Modell erzeugt hat. Sie sind nicht direkt portierbar zwischen verschiedenen Embedding-Modellen.
Ebene 4: Datenfluss-Abhängigkeit — Jede Anfrage, die über einen externen KI-Anbieter läuft, überträgt Daten an dessen Infrastruktur. Bei sensiblen Inhalten ist das eine Compliance-Frage, nicht nur eine Kostenfrage.
Portable KI-Architektur: Die vier Ebenen
Ebene 1: API-Abstraktion — Kein Applikationscode spricht direkt mit einem KI-Anbieter. Stattdessen gibt es eine interne Abstraktion — ein Interface, das Modell-spezifische Details kapselt. Der Wechsel von OpenAI auf einen anderen Anbieter ist dann eine Konfigurationsänderung, keine Code-Änderung: Application → KI-Interface → [OpenAI | Anthropic | Ollama | vLLM]
Ebene 2: Modell-agnostisches Prompting — Prompts, die auf Konzepten basieren, nicht auf modellspezifischen Tricks. Klare Anweisungen in natürlicher Sprache funktionieren mit jedem leistungsfähigen Modell besser als modellspezifische Formatierungsmagie.
Ebene 3: Portable Embeddings — Embedding-Strategie so wählen, dass Re-Indexierung möglich und planbar ist. Praktisch: Embedding-Modell und Version explizit in den Metadaten der Vektordatenbank speichern. Migration ist dann ein Batch-Job, kein Notfall. Alternativ: Embedding-Modelle wählen, die über mehrere Anbieter verfügbar sind (z. B. text-embedding-3-small ist auch über Azure verfügbar, viele Open-Weights-Modelle wie nomic-embed-text laufen lokal).
Ebene 4: Datensouveränität — Für Anwendungsfälle mit sensiblen Daten: lokale Inferenz. Ollama, vLLM, llama.cpp — Open-Weights-Modelle (Llama 4, Mistral Large 3, Qwen 3) laufen on-premise und sind DSGVO-kompatibel ohne zusätzliche Auflagen.
OpenAI-kompatible APIs als Abstraktionslayer
Der de-facto-Standard für LLM-APIs ist die OpenAI-API. Das ist hilfreich: Die meisten Alternativen implementieren dieselbe API. Ollama (lokale Inferenz, OpenAI-kompatibel), vLLM (hochperformante lokale Inferenz, OpenAI-kompatibel), Mistral AI, Together AI, Fireworks AI (Cloud-Alternativen mit OpenAI-kompatibler API) und Azure OpenAI (Microsoft-gehostet, EU-Datenspeicherung möglich).
Wer gegen die OpenAI-API baut, kann in den meisten Fällen mit minimalen Konfigurationsveränderungen wechseln — wenn die Abstraktion sauber ist. Das ist kein vollständiger Schutz (Modell-Verhalten unterscheidet sich), aber es eliminiert den Schicht-1-Lock-in.
Datenhoheit im KI-Kontext
Jede Anfrage an eine externe KI-API überträgt Daten. Für öffentliche Inhalte ist das oft akzeptabel. Für Kundendaten, interne Dokumente, personenbezogene Informationen oder strategische Analysen ist es eine Abwägung, die explizit getroffen werden muss.
Die Lösung ist nicht zwingend vollständige Lokalisierung. Es ist klare Datenklassifikation: Welche Daten dürfen externe KI-APIs erreichen? Welche Daten bleiben on-premise? Welche Anwendungsfälle erfordern lokale Inferenz?
Wann On-Premise-Inferenz Sinn ergibt
Nicht jeder Anwendungsfall braucht lokale Inferenz. Aber es gibt klare Szenarien: Verarbeitung sensibler Dokumente (Verträge, HR-Daten, interne Finanzdaten), Latenz-kritische Anwendungen, Kostenoptimierung bei hohem Volumen und Compliance-Anforderungen mit strikten Datenlokalisierungsanforderungen. Open-Weights-Modelle sind heute für die meisten Mittelstands-Anwendungsfälle performant genug. Llama 4, Mistral Large 3, Qwen 3 — die Qualitätslücke zu proprietären Frontier-Modellen schließt sich kontinuierlich.
Häufige Fragen zu AI-Architektur und Lock-in
Wie viel Aufwand bedeutet eine saubere API-Abstraktion?+
Bei Neuentwicklungen: wenige Stunden, wenn von Anfang an eingeplant. Bei bestehenden Integrationen: hängt von der Tiefe der proprietären API-Nutzung ab. Je früher, desto günstiger.
Reicht es, die OpenAI-API durch Azure OpenAI zu ersetzen?+
Das löst die Datenflusskontrolle (EU-Hosting möglich), nicht aber den Modell-Lock-in. Es ist ein erster Schritt, keine vollständige Strategie.
Was ist mit Fine-Tuning?+
Fine-Tuning erzeugt den tiefsten Lock-in, weil das trainierte Modell proprietär ist. Open-Weights-Modelle ermöglichen Fine-Tuning, das ihr besitzt und portieren könnt. Wenn Fine-Tuning nötig ist, bevorzugt Open-Weights.
Muss ich für Lock-in-Freiheit auf Leistung verzichten?+
Nein. OpenAI-kompatible Alternativen und Open-Weights-Modelle sind für die meisten Business-Anwendungsfälle performant genug. Die Qualitätslücke zu Frontier-Modellen schrumpft jedes Quartal.
Fazit
KI-Lock-in ist das Cloud-Lock-in der 2020er — nur schneller, weil die Integrationen tiefer gehen und die Abhängigkeiten schwerer sichtbar sind. Wer jetzt AI-Features baut, hat die Wahl: portable Architektur mit etwas Mehraufwand oder proprietäre Abhängigkeit mit wachsenden Reparaturkosten.
Die Entscheidung fällt nicht beim ersten Feature. Sie fällt bei der Frage, ob es ein Interface gibt.
Wir schauen, wo Lock-in entsteht — bevor er teuer wird.