Vendor-Lock-in bei KI vermeiden.

Vor zwei Jahren war die Welt einfach: Man integrierte die OpenAI-API, zahlte ein paar hundert Euro im Monat, und die Sache lief. Heute zeigen die ersten Mittelständler, was passiert, wenn man eine geschäftskritische Anwendung an einen einzigen Anbieter knüpft — Preiserhöhungen ohne Verhandlungsspielraum, geänderte Nutzungsbedingungen, plötzlich abgeschaltete Modelle, regulatorische Unsicherheit bei US-Cloud-Anbietern. Vendor-Lock-in ist im KI-Umfeld kein theoretisches Risiko, sondern eine Frage der Zeit. Wer heute eine Strategie aufsetzt, ohne über Austauschbarkeit nachzudenken, wird in zwei oder drei Jahren feststellen, dass die Migration teurer wird als die Software selbst. Dabei geht es nicht darum, Bindungen grundsätzlich zu vermeiden — das wäre unwirtschaftlich. Es geht darum, sie bewusst einzugehen und an den richtigen Stellen Wahlfreiheit zu behalten. Dieser Artikel zeigt, wie Sie sich architektonisch, vertraglich und beim Umgang mit Ihren eigenen Daten so aufstellen, dass Sie verhandlungsfähig bleiben — ohne in den Fehler zu verfallen, jede Entscheidung mit dem Gedanken an einen späteren Wechsel zu lähmen.

Warum Vendor-Lock-in bei KI besonders heikel ist.

Bei klassischer Unternehmenssoftware kennen Sie das Problem: Ein ERP-Wechsel kostet sechs- bis siebenstellig, ein CRM-Wechsel bindet Mitarbeitende über Monate. Bei KI ist die Lage in mehreren Punkten anders — und teils gefährlicher.

Erstens entwickeln sich Modelle, Preise und Verfügbarkeiten im Wochen- bis Monatstakt. Was heute das beste Preis-Leistungs-Verhältnis liefert, ist in zwölf Monaten überholt. Zweitens ist die Lieferantenlandschaft konzentriert: Wenige große US-Anbieter (OpenAI, Anthropic, Google) dominieren den Markt für leistungsstarke Modelle. Drittens werden in KI-Anwendungen oft genau die Daten verarbeitet, die Sie nicht verlieren möchten — Vertragsentwürfe, Kundengespräche, interne Dokumente. Und viertens ist die Erfahrung mit Bedienlogik, Prompts und Eigenheiten eines Anbieters ein Asset, das bei einem Wechsel ein gutes Stück weit verloren geht.

Hinzu kommt eine politische Dimension. Der EU-US Data Privacy Framework gilt nicht als rechtssicher dauerhaft. Die Möglichkeit, dass ein US-Anbieter unter dem CLOUD Act auf europäische Daten zugreifen muss, ist real. Wer seine gesamte KI-Architektur auf einen amerikanischen Anbieter stützt, geht ein Klumpenrisiko ein, das sich nicht nur in Euro berechnet. Auch die Frage, ob bestimmte Modelle in Zukunft EU-Anwender ausschließen, ist nicht abwegig — einige Anbieter haben Funktionen schon in der Vergangenheit regional begrenzt.

In Beratungsprojekten zeigt sich regelmäßig: Mittelständler unterschätzen, wie schnell ein Lock-in entsteht. Drei produktive Anwendungen mit eigenen Prompts, ein paar Integrationen ins ERP, ein Schulungsplan für Mitarbeitende — und schon ist der Wechsel nicht mehr trivial. Die Frage ist nicht, ob Sie sich binden, sondern wie tief und an welchen Stellen.

Drei Ebenen, auf denen Sie unabhängig bleiben sollten.

Lock-in entsteht selten an einer einzigen Stelle. Er ist die Summe vieler kleiner Entscheidungen. Sinnvoll ist es, die Frage in drei Ebenen zu zerlegen — und auf jeder Ebene bewusst zu entscheiden, wie viel Bindung Sie akzeptieren.

• Architektonische Ebene: Wie sind Ihre Anwendungen technisch an den Anbieter gebunden? Nutzen Sie proprietäre Schnittstellen oder einen abstrahierten Layer?
• Vertragliche Ebene: Welche Kündigungsfristen, Datenexport-Rechte und Preisanpassungsklauseln haben Sie? Gibt es Mindestabnahmen, die Sie binden?
• Daten- und Wissens-Ebene: Wo liegen die Daten, die Sie für KI nutzen? Wer besitzt die Embeddings, die Fine-Tuning-Datensätze, die Prompt-Bibliotheken?

Die Erfahrung zeigt, dass die meisten Unternehmen sich primär um die vertragliche Ebene kümmern — und die anderen beiden vernachlässigen. Das ist gefährlich. Ein guter Vertrag schützt nicht, wenn Sie technisch nicht in der Lage sind, innerhalb von Wochen auf einen anderen Anbieter zu wechseln. Und Daten, die im Format eines Anbieters liegen, sind oft schwerer migrierbar als die Software selbst.

Der zentrale Gedanke: Unabhängigkeit ist keine Eigenschaft, die man hat oder nicht hat. Sie ist ein Grad, den man bewusst wählt — und der Aufwand kostet. Wer 95 Prozent Unabhängigkeit will, zahlt deutlich mehr als der, der mit 70 Prozent zufrieden ist. Für die meisten Mittelständler ist 70 bis 80 Prozent der pragmatische Zielwert.

Architektur: Der Abstraktions-Layer als Versicherung.

Technisch ist die wichtigste Maßnahme ein Abstraktions-Layer zwischen Ihren Anwendungen und dem KI-Anbieter. Das klingt nach Software-Architektur-Jargon, ist aber im Kern eine einfache Idee: Ihre Anwendung spricht nicht direkt mit OpenAI oder Anthropic, sondern mit einer internen Schicht, die diese Anbieter wiederum ansteuert. Wenn Sie wechseln wollen, ändern Sie nur diese Schicht — nicht jede einzelne Anwendung.

Tools wie LangChain, LiteLLM oder eigene dünne Wrapper machen das einfach. Die Mehrkosten sind gering, der Nutzen erheblich. In einem typischen Projekt bedeutet das vielleicht zwei bis fünf Tage Mehraufwand für eine Architektur, die später bei einer Migration zehn bis dreißig Tage spart. Das Verhältnis spricht für sich — vorausgesetzt, die Disziplin wird durchgehalten und nicht nach dem dritten Sonderfall aufgeweicht.

Achten Sie dabei auf drei Punkte. Erstens sollte die Abstraktion bewusst minimal sein. Wer jedes Feature jedes Anbieters durch den Layer verfügbar macht, schafft selbst wieder Komplexität — und am Ende ist der Layer schwerer wartbar als die direkte Anbindung. Zweitens sollte der Layer in Ihrer eigenen Infrastruktur laufen, nicht beim Anbieter. Sonst tauschen Sie einen Lock-in gegen einen anderen. Drittens sollten Sie regelmäßig — etwa alle sechs Monate — testen, ob ein Modellwechsel tatsächlich funktioniert. Eine Abstraktion, die nie geprüft wird, ist im Ernstfall oft kaputt. Diese Tests müssen nicht produktiv ausgespielt werden, ein Parallelbetrieb mit Vergleich der Ergebnisse reicht.

Ein verwandtes Thema ist die Wahl zwischen Cloud- und Self-Hosting-Modellen. Open-Source-Modelle wie Llama, Mistral oder DeepSeek erreichen für viele Aufgaben inzwischen ausreichende Qualität. Sie auf eigener Hardware oder in einer europäischen Cloud zu betreiben, ist nicht für jeden Anwendungsfall sinnvoll, aber für sensible Daten eine ernste Option. Mehr dazu finden Sie im Artikel Cloud vs. On-Premise.

Vertragliche Absicherung: Was im Kleingedruckten zählt.

Die Standard-Verträge der großen KI-Anbieter sind anbieterfreundlich — was nicht überrascht. Sie haben aber als mittelständisches Unternehmen mit nennenswertem Volumen mehr Verhandlungsspielraum, als Sie vermuten. Ab etwa 30.000 Euro Jahresvolumen lassen sich Anpassungen aushandeln, ab 100.000 Euro sind individuelle Konditionen üblich. Wer sich nicht meldet, bekommt allerdings den Standardvertrag — und der ist selten optimal.

Worauf Sie achten sollten:

• Preisanpassungsklauseln: Standard sind 12-Monats-Preise mit anschließender Anpassung „nach billigem Ermessen“. Verhandeln Sie eine Deckelung — etwa Inflationsrate plus zwei Prozent.
• Datenverarbeitungsverträge (AVV): Selbstverständlich, aber prüfen Sie die Auftragsverarbeiter-Listen. Manche Anbieter nennen mehrere hundert Unterauftragsverarbeiter.
• Datenexport-Recht: Sie müssen das Recht haben, Ihre eingegebenen Daten, Prompts, Embeddings und ggf. Fine-Tuning-Modelle in einem nutzbaren Format zu exportieren.
• Service Level Agreements: Verfügbarkeiten und Reaktionszeiten. Viele KI-Anbieter geben hier deutlich schwächere Zusagen als klassische SaaS-Anbieter — was bei geschäftskritischer Nutzung problematisch ist.
• Kündigungsfristen: Drei Monate sind angemessen, längere binden Sie unnötig.
• Auditrechte: Das Recht, beim Anbieter Sicherheits- und Compliance-Audits durchzuführen, ist selten in Standardverträgen vorgesehen — bei sensiblen Daten lohnt die Nachverhandlung.

Ein oft übersehener Punkt: Modell-Lebenszyklus. Anbieter ziehen ältere Modelle regelmäßig zurück. Wenn Ihre Anwendung auf einem bestimmten Modell aufgebaut ist und Sie monatelang validiert haben, dass es korrekt arbeitet, ist die Abschaltung ein Problem. Verlangen Sie eine Vorlaufzeit von mindestens sechs Monaten und die Möglichkeit, ältere Modellversionen gegen Aufpreis weiter zu nutzen. Manche Anbieter bieten das im Enterprise-Segment an, wenn man danach fragt.

Datenhoheit: Was bleibt bei Ihnen?

Die dritte Ebene ist oft die wichtigste — und am häufigsten unterschätzt. Daten, die in einem KI-System wachsen, sind ein eigenständiges Asset. Wer es nicht aktiv schützt, verliert es bei einem Anbieterwechsel. Im schlimmsten Fall fängt man nach drei Jahren Optimierungsarbeit wieder bei Null an.

Drei Kategorien sind besonders relevant. Erstens Prompts und Prompt-Bibliotheken: Die Sätze und Strukturen, mit denen Sie aus dem Modell die für Sie nützlichen Ausgaben holen. Diese sind in vielen Unternehmen über Monate gewachsen und oft das eigentliche Know-how. Speichern Sie sie systematisch in einem eigenen Repository, nicht nur in der Oberfläche des Anbieters. Eine Versionierung über Git oder ein ähnliches System macht spätere Nachvollziehbarkeit möglich.

Zweitens Embeddings — also die numerischen Repräsentationen Ihrer Dokumente, die für Suchanwendungen und Retrieval-Augmented Generation genutzt werden. Diese sind anbieterspezifisch. Wer von OpenAI auf Anthropic wechselt, muss alle Embeddings neu berechnen. Das ist nicht dramatisch, kostet aber Zeit und Geld — bei einem mittelgroßen Dokumentenbestand schnell ein vierstelliger Betrag und ein Tag Rechenzeit. Wichtig ist, die zugrunde liegenden Quelldokumente lückenlos verfügbar zu haben. Wer nur die Embeddings hat, aber die Originale verloren, kann nicht migrieren.

Drittens Fine-Tuning-Datensätze. Wenn Sie ein Modell auf Ihre Daten angepasst haben, sind die Trainingsdaten Ihr Eigentum. Aber das resultierende, angepasste Modell ist es meist nicht. Klären Sie vertraglich, ob Sie das Fine-Tuning-Modell exportieren oder zumindest auf einem Nachfolgemodell des gleichen Anbieters weiter nutzen können. Für den Fall eines Anbieterwechsels brauchen Sie zumindest die Trainingsdaten in einem Format, das ein anderer Anbieter einlesen kann.

Multi-Modell-Strategie: Mehr als ein Anbieter, weniger als alle.

Eine wirksame Maßnahme gegen Lock-in ist, gar nicht erst exklusiv mit einem Anbieter zu arbeiten. Eine Multi-Modell-Strategie verteilt Ihre Anwendungen bewusst auf zwei oder drei Anbieter — was Verhandlungsmacht schafft und im Ernstfall die Reaktionsfähigkeit erhöht.

Die naive Variante wäre, jede Anwendung an einen anderen Anbieter zu hängen. Das schafft mehr Probleme, als es löst — Administration, Verträge, Datenschutz multiplizieren sich. Sinnvoller ist eine bewusste Zuordnung nach Anwendungstyp:

Die Multi-Modell-Strategie kostet etwas mehr Aufwand in der Wartung und ein paar Prozent mehr in der Lizenz. Sie zahlt sich aus, sobald ein Anbieter die Preise erhöht oder ein Modell zurückzieht. Wer dann sagen kann: „Wir schieben das Volumen innerhalb von zwei Wochen um“, verhandelt aus einer anderen Position.

Wo die Grenzen der Unabhängigkeit liegen.

Ehrlich gesagt: Volle Unabhängigkeit ist eine Illusion. Selbst wer alles richtig macht, hat in der Praxis nie die Wahl zwischen beliebig vielen gleichwertigen Anbietern. Drei Realitäten sind zu akzeptieren.

Erstens unterscheiden sich Modelle in Qualität, Verhalten und Verfügbarkeit. Was bei OpenAI funktioniert, klappt bei einem anderen Anbieter nicht eins zu eins. Prompts müssen oft angepasst, Schwellwerte neu kalibriert werden. Eine Migration ist nie ein reiner Schaltervorgang.

Zweitens haben Open-Source-Modelle ihre eigenen Schattenseiten. Self-Hosting bedeutet Verantwortung für Infrastruktur, Updates, Sicherheit. Für viele Mittelständler ist das die Übernahme einer neuen Disziplin, die intern nicht ohne Weiteres aufgebaut werden kann.

Drittens ist Unabhängigkeit Geld wert — Geld, das in andere Investitionen fließen könnte. Ein Abstraktions-Layer, redundante Verträge, doppelte Schulungen kosten Aufwand. Für unkritische Anwendungen ist das nicht gerechtfertigt. Niemand braucht eine Multi-Anbieter-Strategie für einen FAQ-Bot.

Der pragmatische Weg: Klassifizieren Sie Ihre Anwendungen nach Kritikalität. Für strategische Anwendungen — dort, wo ein Ausfall oder eine Preiserhöhung wirklich weh tut — investieren Sie in Unabhängigkeit. Für die anderen leben Sie mit dem Lock-in und planen explizit ein, dass Sie im Notfall die Anwendung abschalten und in zwei Monaten neu aufbauen.

Was jetzt sinnvoll ist.

Wenn Sie heute keinen Plan gegen Vendor-Lock-in haben, ist das kein Anlass zur Panik — aber zu einer ehrlichen Bestandsaufnahme. Drei Schritte führen weiter.

Erstens: Eine schlichte Liste, welche KI-Anwendungen bei Ihnen produktiv laufen, mit welchem Anbieter, welchem Vertragsstand und welcher Geschäftskritikalität. Diese Liste fehlt in den meisten Unternehmen — und ohne sie lässt sich keine Strategie machen.

Zweitens: Bei den drei oder vier wichtigsten Anwendungen prüfen, was ein Anbieterwechsel kosten würde. Nicht in der Theorie, sondern als grobe Aufwandsschätzung. Wer das einmal durchgerechnet hat, hat ein klares Bild seines aktuellen Risikos.

Drittens: Bei neuen Anwendungen die Architekturentscheidung bewusst treffen. Abstraktions-Layer, Datenformate, Vertragslaufzeiten — das alles wird am Anfang entschieden und ist später schwer zu ändern. Eine halbe Stunde Nachdenken am Tag der Entscheidung spart oft Wochen Migrationsaufwand.

Das Ziel ist nicht maximale Unabhängigkeit, sondern bewusste Bindung. Wer weiß, woran er sich gebunden hat, kann mit dem Anbieter verhandeln, kann mit der Geschäftsführung Risiken ehrlich darstellen, kann reagieren, wenn sich Rahmenbedingungen ändern. Wer es nicht weiß, ist auf das Wohlwollen seiner Lieferanten angewiesen — und das ist im KI-Markt eine wackelige Position.

Sie wollen prüfen, wie tief Ihr Unternehmen bereits an einen KI-Anbieter gebunden ist und welche Schritte sinnvoll sind? Unverbindlich anfragen — wir gehen Ihre aktuellen Anwendungen, Verträge und Architekturentscheidungen gemeinsam durch und entwickeln eine pragmatische Unabhängigkeitsstrategie.