Was passiert, wenn der KI-Dienstleister wegfällt

Lock-in bei KI-Systemen ist keine Frage der Technologie, sondern eine Entscheidung beim Kauf.
Drei Fragen entscheiden, ob der Ausfall eines Anbieters eine Migration ist oder ein Neuanfang bei null: Läuft der Stack im eigenen Cloud-Account oder in dem des Anbieters? Gehört der Quellcode dem Unternehmen mit unbefristeter Lizenz, oder wird nur Zugang lizenziert? Lässt sich das zugrunde liegende KI-Modell austauschen, oder ist der Workflow fest an einen Anbieter verdrahtet? Wer diese drei Fragen vor dem Kauf beantwortet, kauft Unabhängigkeit mit.

Am 20. Mai 2025 meldete Builder.ai Insolvenz an. Auf dem Höhepunkt, zwei Jahre zuvor, war das Unternehmen mit weit über einer Milliarde Dollar bewertet. Microsoft zählte zu den Investoren, und das Kernversprechen hieß: eine KI namens Natasha entwickelt Software fast ohne menschliche Programmierer. Tatsächlich schrieben Menschen den größten Teil des Codes von Hand: angestellte Entwickler und externe Dienstleister, unter anderem in Indien und der Ukraine. Das Wall Street Journal hatte darüber schon 2019 berichtet. In den Monaten vor der Insolvenz hatte das Unternehmen rund 270 Stellen gestrichen.

Für jedes Unternehmen, das über Builder.ai eine Anwendung entwickeln ließ, wurde an diesem Tag eine bis dahin theoretische Frage konkret: Läuft das System weiter? Wer betreut es jetzt? Und gehört uns überhaupt etwas davon?

Builder.ai ist der bislang prominenteste Fall, weil ein Weltkonzern investiert war und die Bewertung so hoch lag. Kleinere KI-Anbieter verschwinden regelmäßiger, nur ohne die Schlagzeilen. Die Frage stellt sich bei jedem externen KI-System, bei einer fertigen Plattform genauso wie bei einer eigens entwickelten Individuallösung.

Was Lock-in bei KI-Systemen bedeutet

Lock-in heißt: Ein Unternehmen kann ein System nicht ohne größeren Aufwand wechseln, mitnehmen oder selbst weiterbetreiben, weil es technisch oder vertraglich an einen einzelnen Anbieter gebunden ist. Bei klassischer Software ist das ein altbekanntes Problem. Bei KI-Systemen kommt eine zusätzliche Ebene dazu: Neben der Anwendung selbst hängt oft auch das verwendete Modell an genau einem Anbieter, mit einer eigenen, meist proprietären Schnittstelle.

Lock-in ist dabei kein Naturgesetz der Technologie. Es ist die Folge von drei Entscheidungen, die beim Kauf oder bei der Beauftragung fallen, meistens ohne dass sie überhaupt als Entscheidungen auffallen.

Frage 1: Wo läuft der Stack?

Läuft die Anwendung in der Infrastruktur des Anbieters, gehört der Betrieb dem Anbieter, ganz gleich, was im Vertrag zum Code steht. Fällt der Anbieter aus, fällt der Server mit aus. Läuft dieselbe Anwendung dagegen im eigenen Cloud-Account, mit eigenen Zugängen und eigener Abrechnung, bleibt sie erreichbar, selbst wenn der Anbieter, der sie entwickelt hat, morgen nicht mehr existiert. Der Unterschied liegt nicht im Code, sondern darin, wer die Rechnung für den Server bekommt und wer die Zugangsdaten hält.

Frage 2: Wem gehört der Code?

Ein Lizenzvertrag für Software-as-a-Service räumt Zugang ein, kein Eigentum. Läuft der Vertrag aus oder der Anbieter ab, endet der Zugang, meist ohne dass etwas physisch übergeben wird. Ein Werkvertrag mit Quellcode als Liefergegenstand und einer unbefristeten, unwiderruflichen Lizenz überträgt dagegen etwas Bleibendes: eine Kopie, die im eigenen Repository liegt, unabhängig davon, was mit dem Anbieter passiert. Der Unterschied entscheidet sich vor der Unterschrift, in einer Zeile des Vertrags, die selten verhandelt wird, weil im Projektalltag niemand mit dem Ausfall des Anbieters rechnet.

Frage 3: Lässt sich das Modell austauschen?

Die dritte Ebene betrifft nicht die Anwendung, sondern das KI-Modell dahinter. Ruft der Code eine Modell-API fest verdrahtet auf, mit anbieterspezifischen Parametern mitten in der Anwendungslogik verteilt, wird ein Modellwechsel zum Umbau. Läuft derselbe Aufruf dagegen über eine eigene, stabile Schnittstelle, hinter der sich das tatsächlich genutzte Modell austauschen lässt, wird derselbe Wechsel zu einer Konfigurationsänderung. Der Unterschied zeigt sich meist erst, wenn ein Wechsel tatsächlich ansteht, zu spät, um ihn dann noch günstig nachzurüsten.

Für die Technik-Tiefe

Alle drei Fragen laufen auf dieselbe Antwort hinaus: eine Abstraktionsschicht zwischen der Anwendung und allem, was einem Anbieter gehört. Infrastruktur als Code (Terraform, CloudFormation oder vergleichbar) im eigenen Cloud-Account macht den Betrieb reproduzierbar, unabhängig davon, wer ihn ursprünglich aufgesetzt hat. Ein Gateway oder Router vor den Modell-Aufrufen zeigt nach außen eine eigene, stabile Schnittstelle und spricht dahinter beliebige Modelle über deren jeweilige API an. Der Modellwechsel wird damit zu einer einzelnen Endpoint-URL, die man ändert, statt zu einer Suche-und-Ersetzen-Aktion durch die gesamte Codebasis. Beides ist Konstruktionsarbeit, die am Anfang eines Projekts entschieden wird. Eine solche Schicht nachträglich einzuziehen ist fast immer möglich, aber teurer, als sie von Anfang an mitzuplanen.

Eigener Code ist nicht automatisch Unabhängigkeit

Quellcode-Eigentum allein löst das Problem nicht. Ein Unternehmen, das den vollständigen Code besitzt, aber niemanden hat, der ihn versteht, hat eine Abhängigkeit gegen eine andere getauscht: den externen Anbieter gegen eine einzelne Person oder ein einzelnes internes Team. Dessen Weggang schmerzt genauso wie eine Insolvenz. Dokumentation, ein zweiter Ansprechpartner und ein realistischer Übergabeplan gehören deshalb ebenso zur Unabhängigkeit wie die Vertragsklausel. Und selbst mit eigenem Stack, eigenem Code und austauschbarem Modell bleibt ein Rest an Wechselkosten: Ein neues Team muss sich einarbeiten, ein neues Modell verhält sich nie exakt wie das alte, und jede Migration kostet Zeit. Der Unterschied ist nicht null gegen Totalschaden, sondern Wochen gegen Monate, und ein Neustart mit den eigenen Daten statt ganz ohne.

Was das für die Anbieterauswahl bedeutet

Die drei Fragen lassen sich vor jeder Beauftragung stellen, bei einer fertigen Plattform genauso wie bei einer Individuallösung oder einem internen Projekt mit externer Unterstützung. Wo läuft der Betrieb, wem gehört am Ende der Code, und wie viel Arbeit wäre ein Modellwechsel. Wer bei einem Angebot auf konkrete Antworten drängt statt auf allgemeine Zusicherungen, sieht meist schon am Zögern, welche der drei Fragen dort nicht mitgedacht wurde.

Sie können jetzt bei jedem KI-Angebot, das ins Haus kommt, dieselben drei Fragen stellen, die auch nach der Unterschrift noch zählen. Wer schon beim Lizenzmodell genau hinschaut, wie im vorigen Beitrag dieser Reihe zur Lücke zwischen bezahlten und genutzten Copilot-Lizenzen, sollte beim Anbieter selbst genauso genau hinschauen. Wie groß der Qualitätsunterschied zwischen austauschbaren offenen Modellen und den großen, bekannten Anbietern tatsächlich ist, ehrlich beziffert, ist Thema des nächsten Beitrags.

Häufige Fragen

Was bedeutet Lock-in bei KI-Systemen? Lock-in bedeutet, dass ein Unternehmen ein KI-System nicht ohne größeren Aufwand wechseln, mitnehmen oder selbst weiterbetreiben kann, weil es technisch oder vertraglich an einen einzelnen Anbieter gebunden ist. Es entsteht aus drei Entscheidungen: wo der Stack läuft, wem der Code gehört, und ob sich das zugrunde liegende Modell austauschen lässt.

Wie schützt man sich vertraglich gegen den Ausfall eines KI-Anbieters? Der Kern ist Eigentum statt Zugang: Quellcode als Liefergegenstand mit unbefristeter, unwiderruflicher Lizenz, Betrieb im eigenen Cloud-Account statt in dem des Anbieters, und eine Architektur, die das KI-Modell austauschbar hält statt es fest zu verdrahten. Diese drei Punkte gehören vor die Unterschrift, nicht danach.

Reicht der Besitz des Quellcodes, um Lock-in zu vermeiden? Nicht allein. Ohne eigenes Know-how, wie das System betrieben und gewartet wird, bleibt eine Abhängigkeit bestehen, nur von einer Person oder einem internen Team statt von einem externen Anbieter. Quellcode-Eigentum senkt das Risiko eines Totalausfalls, ersetzt aber keine Betriebsfähigkeit.

Quellen

Builder.ai meldet Insolvenz an (20. Mai 2025): The Register, mlq.ai.
Bewertung über eine Milliarde Dollar, Microsoft als Investor: TechCrunch, Tech Startups.
Menschliche Entwickler statt der beworbenen KI (Wall Street Journal 2019); rund 270 Stellen im März 2025 gestrichen: Rest of World, The Register.
Die nach der Insolvenz kursierende Zahl von 700 Entwicklern, die die KI nur vorgetäuscht hätten, hielt einer technischen Nachprüfung nicht stand: The Pragmatic Engineer.