Sauber aus dem KI-Anbieter raus die Exit-Strategie vor dem Einstieg.
Die meisten KI-Projekte werden mit Blick auf den Einstieg geplant: Welcher Anbieter, welche Funktionen, welcher Preis. Den Ausstieg denkt kaum jemand mit — und genau das wird teuer, wenn der Anbieter die Preise verdoppelt, die Qualität nachlässt, übernommen wird oder schlicht den Dienst einstellt. Dann zeigt sich, wie tief man eigentlich drinsteckt: Daten in einem proprietären Format, Workflows auf eine bestimmte API geschnitten, ein feinjustiertes Modell, das man nicht mitnehmen kann, und ein Team, das nur dieses eine System kennt. Ein Anbieterwechsel, der auf dem Papier ein Quartal dauern sollte, wird zur Zwölf-Monats-Operation mit sechsstelligen Kosten. Dieser Beitrag zeigt, warum Lock-in bei KI besonders hartnäckig ist, welche Abhängigkeiten einen Wechsel real blockieren, wie eine belastbare Exit-Strategie schon vor dem Einstieg aussieht und was eine echte Exit-Klausel enthalten muss. Ziel ist nicht, jeden Lock-in zu vermeiden — das wäre unwirtschaftlich — sondern ihn bewusst einzugehen und den Notausgang offenzuhalten.
Warum Lock-in bei KI hartnäckiger ist als bei klassischer Software.
Bei klassischer Software ist Lock-in vor allem eine Datenfrage: Bekomme ich meine Daten in einem Format heraus, das ein anderes System lesen kann? Bei KI-Systemen ist die Abhängigkeit vielschichtiger, weil das Verhalten des Systems selbst ein Teil der Investition ist.
Ein konkretes Beispiel: Ein Unternehmen hat über Monate Prompts verfeinert, die auf das spezifische Verhalten eines bestimmten Modells abgestimmt sind. Diese Prompts funktionieren bei einem anderen Modell oft schlechter oder gar nicht — sie sind keine portierbaren Daten, sondern modellspezifisches Tuning. Dazu kommen feinjustierte Modelle, die rechtlich und technisch beim Anbieter liegen, sowie Integrationen, die auf proprietäre API-Eigenheiten gebaut sind.
Die Folge: Der Wechsel kostet nicht nur Migrationsaufwand, sondern auch Requalifizierung. Ein neues Modell verhält sich anders, also muss man Prompts neu schreiben, Qualität neu testen, das Team neu einarbeiten. Dieser unsichtbare Anteil wird systematisch unterschätzt und macht den Großteil der realen Wechselkosten aus.
Die vier Ebenen der Abhängigkeit.
Um einen Ausstieg planbar zu machen, hilft es, die Abhängigkeit in Ebenen zu zerlegen. Jede hat eigene Wechselhürden und eigene Gegenmittel:
| Ebene | Was bindet | Wechselhürde |
|---|---|---|
| Daten | Inhalte, Embeddings, Vektorindizes im proprietären Format | mittel, mit Exportrecht beherrschbar |
| Modell | Feintuning, Gewichte, modellspezifisches Prompt-Tuning | hoch, oft nicht portierbar |
| Integration | API-Aufrufe, SDKs, anbieterspezifische Funktionen | mittel bis hoch, je nach Architektur |
| Prozess & Mensch | eingespielte Workflows, Team-Know-how, Schulung | hoch, schwer zu quantifizieren |
Die Datenebene ist mit einem ordentlichen Exportrecht gut beherrschbar. Die Modellebene ist die kritischste, weil Feintuning-Artefakte oft beim Anbieter bleiben und sich nicht eins zu eins übertragen lassen. Die Integrationsebene hängt stark davon ab, ob man direkt gegen die Anbieter-API gebaut hat oder eine Abstraktionsschicht dazwischengelegt hat. Und die Prozessebene ist die teuerste, weil sie sich nicht exportieren lässt — sie steckt in Köpfen und Gewohnheiten.
Datenexport: notwendig, aber bei weitem nicht hinreichend.
Ein Recht auf Datenexport gehört in jeden Vertrag — aber wer glaubt, damit sei der Ausstieg gesichert, irrt. Die entscheidenden Fragen sind die nach Format und Vollständigkeit. Ein Export, der nur die Rohdaten enthält, aber nicht die abgeleiteten Strukturen — Embeddings, Indizes, Metadaten, Konfigurationen — zwingt Sie, einen erheblichen Teil der Arbeit beim neuen Anbieter zu wiederholen.
Konkret sollten Sie im Vertrag festhalten: Export in einem offenen, dokumentierten Format (nicht nur ein proprietärer Dump), Vollständigkeit inklusive abgeleiteter Artefakte soweit möglich, ein definierter Zeitrahmen für die Bereitstellung und keine Zusatzgebühr, die den Export faktisch verhindert. Manche Anbieter regeln zwar ein Exportrecht, verlangen dafür aber eine Gebühr, die in keinem Verhältnis steht — auch das gehört geklärt.
Bei Embeddings und Vektorindizes gibt es eine technische Feinheit: Embeddings sind modellspezifisch. Ein Vektor, der von Modell A erzeugt wurde, ist für Modell B bedeutungslos. Das heißt, selbst mit perfektem Export müssen Embeddings beim Wechsel meist neu berechnet werden. Das ist kein Vertrags-, sondern ein Architekturthema — und ein Grund, die Rohdaten immer parallel und unabhängig vom Anbieter vorzuhalten.
Das Modell-Problem: Feintuning, das man nicht mitnehmen kann.
Wer ein Modell mit eigenen Daten feinjustieren lässt, schafft Wert — und zugleich eine der härtesten Abhängigkeiten. Die feinjustierten Gewichte liegen technisch und meist auch rechtlich beim Anbieter. Bei vielen großen Anbietern ist der Export der Gewichte schlicht nicht vorgesehen; man mietet die Nutzung, besitzt aber nichts.
Daraus folgen zwei Gegenstrategien. Erstens vertraglich: ein Recht aushandeln, die Feintuning-Daten und, wo möglich, die Artefakte zu exportieren oder zumindest deren Löschung nachzuweisen. Zweitens architektonisch: das wertvolle Asset bleibt der saubere, kuratierte Trainingsdatensatz, nicht das trainierte Modell. Wer den Datensatz versioniert und unabhängig vorhält, kann das Feintuning auf einem anderen Modell wiederholen — mit Aufwand, aber ohne bei null anzufangen.
Eine ehrliche Grenze: Selbst mit demselben Datensatz verhält sich ein anderes Modell anders. Das Feintuning ist also reproduzierbar, aber nicht identisch übertragbar. Wer auf maximale Wechselbarkeit Wert legt, sollte prüfen, ob ein selbst gehostetes Open-Weight-Modell infrage kommt — dann liegt das gesamte Modell im eigenen Zugriff, allerdings um den Preis von Betriebsaufwand und meist etwas geringerer Spitzenqualität.
Architektur als Exit-Versicherung: die Abstraktionsschicht.
Die wirksamste Exit-Versicherung ist nicht juristisch, sondern technisch: eine Abstraktionsschicht zwischen der eigenen Anwendung und dem KI-Anbieter. Statt überall direkt gegen die API eines Anbieters zu programmieren, kapselt man den Zugriff hinter einer eigenen, anbieterneutralen Schnittstelle. Ein Wechsel bedeutet dann, einen Adapter auszutauschen, statt das halbe System umzuschreiben.
Das klingt nach Mehraufwand, und das ist es auch — typischerweise einige Personentage zusätzlich beim Aufbau. Der Nutzen zeigt sich erst beim Wechsel, dann aber massiv: Aus einem Migrationsprojekt von Monaten wird einer von Wochen. Mehrere Frameworks und Bibliotheken bieten solche Abstraktionen heute fertig an, sodass man nicht alles selbst bauen muss.
Die ehrliche Abwägung: Eine Abstraktionsschicht kostet etwas Performance und manchmal Zugriff auf anbieterspezifische Spezialfunktionen, die man bewusst nicht kapselt. Für unkritische Einzelanwendungen ist der Aufwand übertrieben. Für Systeme, die zentral und langfristig sind und auf denen Geschäftsprozesse aufsetzen, ist sie meist die günstigste Versicherung, die man kaufen kann.
Was in eine echte Exit-Klausel gehört.
Eine belastbare Exit-Klausel regelt mehr als nur „Sie dürfen kündigen“. Sie sollte die folgenden Punkte konkret und mit Fristen versehen:
- Datenrückgabe: vollständiger Export in offenem Format, inklusive abgeleiteter Artefakte soweit technisch möglich, kostenfrei oder zu klar gedeckelten Kosten.
- Löschung: Zusage zur vollständigen Löschung aller Daten und Feintuning-Artefakte nach Vertragsende, mit Nachweis (Löschprotokoll).
- Übergangsfrist: ein Weiterbetrieb des Dienstes für eine definierte Zeit (oft 30 bis 90 Tage) nach Kündigung, damit eine Migration ohne Betriebsunterbrechung möglich ist.
- Mitwirkungspflicht: zumutbare Unterstützung beim Export und der Migration, idealerweise mit kalkulierbarem Aufwand und Tagessatz.
- Keine Geiselhaft: Ausschluss, dass der Anbieter die Datenrückgabe von offenen Forderungen oder Zusatzzahlungen abhängig macht.
Diese Punkte sind in den meisten mittelständischen Verträgen verhandelbar, weil sie den Anbieter wenig kosten, solange er kundenfreundlich agiert. Ein Anbieter, der sich bei der Exit-Klausel querstellt, sendet ein deutliches Warnsignal über die spätere Zusammenarbeit.
Wann sich Wechselbarkeit lohnt — und wann bewusster Lock-in klüger ist.
Nicht jede Abhängigkeit muss vermieden werden. Tiefe Integration erzeugt genau die Effizienz, die man sich vom System verspricht — und wer jede mögliche Bindung umgeht, verschenkt diesen Nutzen und zahlt dauerhaft für Flexibilität, die er vielleicht nie braucht.
Eine sinnvolle Faustregel orientiert sich an Kritikalität und Laufzeit. Für ein zentrales System, das Geschäftsprozesse trägt und über Jahre laufen soll, lohnt jede Exit-Vorsorge: Abstraktionsschicht, unabhängige Datenhaltung, harte Vertragsklauseln. Für ein Hilfstool mit überschaubarem Nutzen und leicht ersetzbarer Funktion ist der gleiche Aufwand Verschwendung — hier reicht ein einfaches Exportrecht.
Die Kostenfrage gehört ehrlich auf den Tisch. Exit-Vorsorge ist nicht gratis: Sie kostet beim Aufbau Zeit und manchmal etwas Leistung. Aber die Alternative — ein blockierter Wechsel zur Unzeit — kostet oft ein Vielfaches. Ein realistischer Anbieterwechsel ohne Vorsorge kann im Mittelstand schnell drei bis neun Monate und einen mittleren fünf- bis sechsstelligen Betrag verschlingen. Mit Vorsorge schrumpft beides erheblich. Die Entscheidung ist also keine Glaubensfrage, sondern eine nüchterne Abwägung von Eintrittswahrscheinlichkeit und Schadenshöhe — und die trifft man am besten vor dem Einstieg, nicht im Streitfall.
Sie wollen wissen, wie tief Sie bei einem KI-Anbieter bereits drinstecken und wie ein sauberer Ausstieg aussähe? Unverbindlich anfragen — wir analysieren gemeinsam Ihre Abhängigkeiten über Daten, Modell, Integration und Prozess und entwerfen eine Exit-Strategie, die zum Risiko passt.