KI-Anbieter wechseln: Wie vermeiden Unternehmen Vendor Lock-in?

1. Was bedeutet Vendor Lock-in bei KI?

Von Vendor Lock-in spricht man, wenn der Wechsel von einem Anbieter zu einer Alternative mit hohem technischem, organisatorischem oder wirtschaftlichem Aufwand verbunden ist.

Bei KI-Anwendungen kann diese Abhängigkeit an unterschiedlichen Stellen entstehen.

Beispielsweise:

• eine Anwendung verwendet ausschließlich proprietäre Funktionen eines bestimmten Modells,
• Unternehmenswissen liegt nur in einer anbieterspezifischen Datenstruktur vor,
• Prompts und Workflows sind nicht dokumentiert,
• Geschäftssysteme sind direkt mit einer einzelnen KI-Plattform verbunden,
• Auswertungen und Qualitätsmessung funktionieren nur innerhalb eines Anbieters,
• Vertrags- oder Exportbedingungen erschweren eine Migration.

Ein Lock-in ist dabei nicht automatisch schlecht.

Viele Unternehmen verwenden bewusst spezialisierte Software, weil deren Funktionen einen konkreten Nutzen bieten.

Problematisch wird eine Abhängigkeit vor allem dann, wenn sie erst sichtbar wird, nachdem ein Wechsel notwendig geworden ist.

Technische Abhängigkeit und wirtschaftliche Abhängigkeit unterscheiden

Eine technische Migration kann einfach sein und trotzdem wirtschaftlich unattraktiv.

Beispielsweise wenn:

• ein neuer Anbieter umfangreiche Schulung benötigt,
• bestehende Verträge lange Restlaufzeiten haben,
• Mitarbeiter ihre Arbeitsweise stark an ein Produkt angepasst haben,
• ein Wechsel vorübergehend parallele Systeme erfordert.

Umgekehrt kann ein Anbieterwechsel vertraglich problemlos möglich sein, technisch aber große Umbauten verursachen.

Vendor Lock-in sollte deshalb nicht nur als IT-Problem bewertet werden, sondern als Gesamtkosten eines möglichen Wechsels.

2. Wo entsteht Abhängigkeit in einem KI-Prozess?

Ein KI-Prozess besteht häufig aus deutlich mehr als einem Sprachmodell.

Eine vereinfachte Architektur kann so aussehen:

Geschäftsvorgang → Daten → Prozesslogik → KI-Modell → Prüfung → Aktion im Geschäftssystem.

An jeder dieser Stellen können Anbieterabhängigkeiten entstehen.

Diese Abhängigkeiten sollten nicht alle automatisch beseitigt werden.

Wichtig ist zunächst, sie sichtbar zu machen.

Erst dann kann das Unternehmen entscheiden, welche Bindung akzeptabel und welche geschäftskritisch ist.

3. Wie austauschbar sollte das KI-Modell sein?

KI-Modelle entwickeln sich schnell.

Ein Modell, das heute für eine Aufgabe besonders geeignet ist, kann später durch ein anderes Modell bei Qualität, Geschwindigkeit oder Kosten überholt werden.

Zusätzlich können Anbieter Modelle verändern oder aus dem Angebot nehmen.

Deshalb ist es sinnvoll, Modellwahl nicht als endgültige Entscheidung zu behandeln.

Geschäftslogik nicht vollständig an einen Modellnamen binden

Eine Anwendung sollte möglichst nicht überall im Code oder Workflow voraussetzen, dass genau ein bestimmtes Modell verwendet wird.

Hilfreich kann eine klar definierte Modellschicht sein:

Geschäftsprozess → definierte KI-Aufgabe → Modellzugriff.

Der Geschäftsprozess beschreibt beispielsweise:

„Ordne diese Anfrage einer von fünf vorgesehenen Kategorien zu und gib Kategorie sowie Begründung strukturiert zurück.“

Welche Modellversion diese Aufgabe erfüllt, kann anschließend separat entschieden werden.

Modelle sind trotzdem nicht beliebig austauschbar

Ein häufiger Fehler ist die Annahme:

„Wir ändern einfach den API-Namen und alles funktioniert weiter.“

Modelle unterscheiden sich unter anderem bei:

• Qualität für bestimmte Aufgaben,
• Geschwindigkeit,
• Kontextlänge,
• strukturierten Ausgaben,
• Tool- oder Function-Calling,
• Multimodalität,
• Fehlerverhalten,
• Kosten.

Auch identische Prompts können bei verschiedenen Modellen unterschiedliche Ergebnisse liefern.

Deshalb gehört zu einem Anbieterwechsel immer ein erneuter fachlicher Test.

Unser Vergleich ChatGPT, Gemini oder Claude im Unternehmen? zeigt deshalb bewusst keine dauerhafte Rangliste, sondern bewertet die Auswahl nach Aufgabe und Arbeitsumgebung.

4. Wem gehören Daten und Wissensbasis?

Der wichtigste portable Bestandteil eines KI-Systems ist häufig nicht das Modell, sondern die zugrunde liegende Unternehmensinformation.

Wenn ein Assistent beispielsweise interne Dokumente durchsucht, sollten die Originalquellen möglichst unabhängig von der verwendeten KI-Plattform erhalten bleiben.

Originaldokumente getrennt kontrollieren

Ein Unternehmen sollte wissen:

• wo die maßgeblichen Originaldokumente liegen,
• wer ihre Aktualität verantwortet,
• welche Version gültig ist,
• welche Metadaten für die Suche benötigt werden,
• wie die Inhalte exportiert werden können.

Eine KI-Plattform sollte nicht zur einzigen Stelle werden, an der relevantes Unternehmenswissen noch vollständig vorhanden ist.

Embeddings sind nicht dasselbe wie Originalwissen

Bei RAG-Systemen werden Inhalte häufig technisch aufbereitet, segmentiert und in Vektorrepräsentationen überführt.

Diese Strukturen können abhängig vom verwendeten Embedding-Modell oder Datenbanksystem sein.

Bei einem Wechsel kann deshalb eine Neuerstellung sinnvoll oder erforderlich werden.

Das ist weniger problematisch, wenn:

• die Originaldokumente erhalten sind,
• Chunking- und Metadatenlogik dokumentiert sind,
• Quellenzuordnungen nachvollziehbar bleiben.

Wie Unternehmenswissen für KI-Systeme strukturiert werden kann, erläutert unser Beitrag KI mit Unternehmenswissen verbinden: RAG und Wissensdatenbanken.

5. Prompts, Workflows und Agentenlogik dokumentieren

Ein großer Teil des praktischen Wertes einer KI-Anwendung steckt nicht im Modell selbst.

Er steckt in der Frage, wie das Unternehmen den Prozess aufgebaut hat.

Dazu gehören beispielsweise:

• Systemanweisungen,
• fachliche Regeln,
• Beispiele für gewünschte Ergebnisse,
• Entscheidungslogik,
• Freigaben,
• Ausnahmebehandlung,
• Tool-Aufrufe,
• Qualitätskriterien.

Geschäftsregel und Prompt nicht verwechseln

Angenommen, eine Kundenanfrage darf nur automatisch weitergeleitet werden, wenn Region und Leistungsbereich eindeutig erkannt wurden.

Diese Anforderung ist eine Geschäftsregel.

Der konkrete Prompt ist lediglich eine mögliche technische Umsetzung.

Wenn die Regel ausschließlich in einem schwer auffindbaren Prompt innerhalb eines Anbieter-Tools existiert, wird ein späterer Wechsel unnötig schwierig.

Besser ist eine getrennte Dokumentation:

Geschäftsregel → gewünschtes Ergebnis → technische Umsetzung im aktuellen System.

Proprietäre Agent-Funktionen bewusst einsetzen

Ein Anbieter kann besonders leistungsfähige Agenten-, Memory- oder Workflow-Funktionen bereitstellen.

Diese Funktionen können einen realen Vorteil bieten.

Sie sollten nicht allein deshalb vermieden werden, weil sie proprietär sind.

Vor der Nutzung sollte aber klar sein:

• welcher Nutzen dadurch entsteht,
• welcher Teil des Prozesses an die Funktion gebunden wird,
• wie aufwendig ein späterer Ersatz wäre.

Portabilität ist ein Entscheidungskriterium, aber nicht das einzige.

6. Wie abhängig sind Integrationen von einem KI-Anbieter?

Ein KI-Assistent wird geschäftlich interessant, wenn er mit vorhandenen Systemen zusammenarbeitet.

Genau dadurch kann jedoch zusätzliche Anbieterabhängigkeit entstehen.

Direkte Punkt-zu-Punkt-Verbindungen

Ein Agent wird direkt mit CRM, E-Mail, Kalender und Dokumentenspeicher verbunden.

Wenn jede Integration speziell für die KI-Plattform gebaut wurde, müssen bei einem Anbieterwechsel möglicherweise alle Verbindungen neu eingerichtet werden.

Geschäftssysteme als eigenständige Ebene behandeln

Wo sinnvoll, kann eine klarere Trennung helfen:

KI → definierte interne Funktion oder API → Geschäftssystem.

Die KI darf beispielsweise nicht beliebig das CRM verändern.

Sie kann lediglich eine definierte Funktion aufrufen:

„Interne Aufgabe für vorhandenen Vorgang anlegen.“

Damit bleiben Berechtigungen und Geschäftslogik stärker vom verwendeten Modell getrennt.

Das ist gleichzeitig ein Sicherheitsvorteil.

Wie entsprechende Rechte begrenzt werden können, zeigt unser Beitrag KI-Agenten im Unternehmen: Welche Berechtigungen brauchen sie wirklich?.

Nicht für jede kleine Lösung eine Abstraktionsplattform bauen

Auch hier gilt: Architektur verursacht Aufwand.

Wenn fünf Mitarbeiter einen KI-Assistenten ausschließlich für interne Textentwürfe verwenden, benötigt das Unternehmen möglicherweise keine zusätzliche Integrationsschicht.

Je geschäftskritischer und stärker integriert die Anwendung wird, desto relevanter wird dagegen die Frage, wie teuer ein späterer Austausch wäre.

7. Welche Vertrags- und Betriebsfragen beeinflussen den Anbieterwechsel?

Vendor Lock-in entsteht nicht nur im Code.

Verträge und Betriebsbedingungen können einen Wechsel ebenfalls erleichtern oder erschweren.

Vor einer größeren Einführung sollten Unternehmen unter anderem prüfen:

• Wie lange läuft der Vertrag?
• Welche Kündigungsfristen gelten?
• Welche Mindestabnahmen oder Nutzungspakete bestehen?
• Wie lassen sich eigene Daten exportieren?
• Was passiert nach Vertragsende mit gespeicherten Daten?
• Welche Logs oder Qualitätsdaten können exportiert werden?
• Wie werden Änderungen an Modellen oder Funktionen angekündigt?
• Was geschieht, wenn eine verwendete Modellversion eingestellt wird?
• Welche Schnittstellen und Funktionen gehören zum gewählten Tarif?

Model Lifecycle berücksichtigen

KI-Modelle sind keine unveränderliche Infrastruktur.

Ein Anbieter kann Modelle aktualisieren, neue Versionen einführen oder ältere Versionen außer Betrieb nehmen.

Für produktive Anwendungen sollte deshalb bekannt sein, wie Modelländerungen getestet und übernommen werden.

Datenschutz und Auftragsverarbeitung bleiben separat zu prüfen

Ein einfacher Anbieterwechsel ist noch kein Beweis für eine geeignete Datenschutzarchitektur.

Wenn personenbezogene Daten verarbeitet werden, müssen unter anderem der konkrete Anbieter, die Verarbeitung, vertragliche Rollen und gegebenenfalls Anforderungen an eine Auftragsverarbeitung geprüft werden.

Ein Multi-Provider-Ansatz kann den Datenschutz sogar komplexer machen, wenn dadurch mehr Anbieter personenbezogene Daten erhalten.

8. Wie testen Unternehmen, ob ein KI-Anbieter wirklich austauschbar ist?

Die beste Antwort liefert kein Architekturdiagramm, sondern ein begrenzter Wechseltest.

Dafür muss die bestehende produktive Lösung nicht sofort umgestellt werden.

Schritt 1: Einen repräsentativen Testsatz festlegen

Wählen Sie reale oder ausreichend realistische Fälle aus dem bestehenden Prozess.

Der Testsatz sollte nicht nur einfache Beispiele enthalten.

Berücksichtigen Sie insbesondere:

• typische Standardfälle,
• schwierige Eingaben,
• fehlende Informationen,
• Fälle mit erwarteter menschlicher Übergabe,
• fachlich kritische Aussagen.

Schritt 2: Das gleiche gewünschte Ergebnis definieren

Vergleichen Sie nicht einfach zwei Chat-Antworten.

Definieren Sie vorher, was der Geschäftsprozess benötigt.

Beispielsweise:

• richtige Kategorie,
• korrekt extrahierte Felder,
• keine erfundenen Informationen,
• korrekte Übergabe bei Unsicherheit,
• vorgesehenes strukturiertes Ausgabeformat.

Schritt 3: Alternative technisch anbinden

Prüfen Sie, welche Änderungen tatsächlich notwendig sind.

Müssen lediglich Modellzugang und Prompt angepasst werden?

Oder betreffen Änderungen zusätzlich:

• Datenaufbereitung,
• Tool-Aufrufe,
• Authentifizierung,
• Logging,
• RAG-System,
• Fehlerbehandlung?

Schritt 4: Qualität, Kosten und Betrieb vergleichen

Schritt 5: Migration dokumentieren

Auch wenn der Wechsel aktuell nicht durchgeführt wird, liefert der Test wichtige Informationen.

Das Unternehmen weiß danach beispielsweise:

• welche Komponenten einfach austauschbar sind,
• wo echte technische Bindungen bestehen,
• welcher Migrationsaufwand realistisch wäre,
• welche Abhängigkeiten bewusst akzeptiert werden.

Damit wird Vendor Lock-in messbarer und weniger abstrakt.

9. Wann ist Vendor Lock-in akzeptabel?

Vollständige Anbieterunabhängigkeit ist weder immer möglich noch automatisch wirtschaftlich sinnvoll.

Eine proprietäre Funktion kann erheblichen Nutzen schaffen.

Ein Unternehmen kann deshalb bewusst eine stärkere Bindung akzeptieren.

Beispielsweise wenn:

• die Funktion einen klaren geschäftlichen Vorteil bietet,
• ein Wechsel aktuell sehr unwahrscheinlich ist,
• der gebundene Prozess nicht geschäftskritisch ist,
• die Daten weiterhin exportierbar und kontrollierbar bleiben,
• der mögliche Wechselaufwand bekannt und vertretbar ist.

Lock-in bewusst bepreisen

Eine praktische Frage lautet:

Was würde es ungefähr kosten, diese Funktion später zu ersetzen?

Wenn diese Größenordnung bekannt ist, kann sie gegen den heutigen Nutzen abgewogen werden.

Unbekannte Abhängigkeit ist riskanter als bewusst akzeptierte Abhängigkeit.

Bei geschäftskritischen Prozessen strengere Anforderungen

Wenn ein KI-System für einen wesentlichen Geschäftsprozess benötigt wird, sollte das Unternehmen stärker darauf achten:

• Daten außerhalb der Plattform verfügbar zu halten,
• Geschäftsregeln zu dokumentieren,
• Fallback-Prozesse vorzusehen,
• Modelländerungen testen zu können,
• Exit- und Migrationsbedingungen zu kennen.

Das bedeutet nicht, bereits dauerhaft einen zweiten Anbieter parallel zu betreiben.

Eine dokumentierte und getestete Wechselmöglichkeit kann ausreichend sein.

10. Checkliste: Wie abhängig ist Ihr KI-Prozess von einem Anbieter?

1. Geschäftsprozess: Ist dokumentiert, welche Aufgabe die KI tatsächlich erfüllt?
2. Modell: Ist klar, welche Anforderungen wirklich modellspezifisch sind?
3. Originaldaten: Bleiben Unternehmensdaten unabhängig vom KI-Anbieter verfügbar?
4. Wissensbasis: Können Originaldokumente, Metadaten und Zuordnungen exportiert werden?
5. Prompts: Sind wichtige Systemanweisungen und Beispiele dokumentiert?
6. Geschäftsregeln: Sind fachliche Regeln getrennt von der aktuellen technischen Umsetzung beschrieben?
7. Workflow: Lässt sich der Ablauf auch außerhalb des aktuellen Tools nachvollziehen?
8. Integrationen: Wissen wir, welche Schnittstellen bei einem Wechsel angepasst werden müssten?
9. Berechtigungen: Sind Zugriffsregeln unabhängig vom Sprachmodell kontrollierbar?
10. Tests: Gibt es einen repräsentativen Testsatz für einen Modellvergleich?
11. Qualität: Sind Kriterien definiert, mit denen Alternativen vergleichbar bewertet werden können?
12. Logging: Können relevante Betriebs- und Qualitätsdaten exportiert werden?
13. Vertrag: Kennen wir Kündigung, Datenexport und Exit-Bedingungen?
14. Model Lifecycle: Ist geregelt, was bei einer Modelländerung oder Abschaltung passiert?
15. Datenschutz: Wissen wir, welche zusätzliche Prüfung ein Anbieterwechsel erfordern würde?
16. Migrationsaufwand: Können wir grob beziffern, was ein Wechsel technisch und organisatorisch kosten würde?

Nicht jede Anbieterbindung ist ein Problem – unbekannte Abhängigkeit schon

Unternehmen müssen KI-Systeme nicht vollständig anbieterneutral bauen.

Eine solche Architektur kann selbst unnötige Kosten und Komplexität verursachen.

Wichtiger ist, geschäftskritische Bestandteile bewusst voneinander zu trennen.

Unternehmensdaten und fachliche Regeln sollten nachvollziehbar bleiben. Modelle sollten anhand klarer Anforderungen getestet werden können. Integrationen und Berechtigungen sollten nicht unnötig an eine einzelne Plattform gekoppelt sein.

Proprietäre Funktionen können trotzdem sinnvoll sein, wenn ihr Nutzen größer ist als der bewusst akzeptierte Wechselaufwand.

Die richtige Frage lautet deshalb nicht: Wie vermeiden wir jeden Vendor Lock-in? Sondern: Welche Abhängigkeiten akzeptieren wir bewusst – und welche würden uns später unnötig die Entscheidungsfreiheit nehmen?