Die KI-Vendor-Landschaft ist unübersichtlich — und sie ist es mit System. Jedes Quartal bringt neue Plattformen, neue Modellanbieter, neue Start-ups, die behaupten, jedes Problem zu lösen, und neue Preismodelle, die jeden seriösen Vergleich erschweren. Für ein Mittelstandsunternehmen, das seine erste signifikante KI-Investition tätigt, ist das Risiko einer Fehlentscheidung nicht abstrakt. Es ist ein sechsstelliger Betrag, der in einer Plattform gebunden wird, die in 18 Monaten technisch überholt oder kommerziell unattraktiv ist — und der Rückstand, den ein erzwungener Re-Plattform-Wechsel mitten im Betrieb erzeugt.
Die gute Nachricht: Sie müssen nicht den perfekten Vendor wählen. Sie müssen einen ausreichend guten Vendor wählen und dabei die Fähigkeit zum Wechsel erhalten. Diese Unterscheidung — gut genug mit erhaltener Optionalität — ist das einzige Prinzip, das jede KI-Vendor-Entscheidung übersteht, die schnell altert. Alles andere in diesem Artikel ist die Operationalisierung dieses einen Satzes.
Warum Vendor-Auswahl bei KI schwieriger ist als bei klassischer Software
Klassische Enterprise-Software ist stabil. Ihr ERP funktioniert dieses Jahr wie letztes Jahr. Die Vendor-Landschaft ist konsolidiert, die Wechselkosten sind hoch, aber vorhersehbar. Sie treffen eine Entscheidung, leben fünf bis zehn Jahre damit und planen Upgrades auf einem bekannten Zeitplan. Die Beschaffungslogik, die der Mittelstand über Jahrzehnte verinnerlicht hat — gründlich evaluieren, einmal entscheiden, lange binden — ist genau auf diese Stabilität optimiert.
KI verhält sich gegenteilig. Modellfähigkeiten verbessern sich sprunghaft zwischen Generationen; was heute State of the Art ist, ist im nächsten Quartal die Baseline. Preisstrukturen verschieben sich, während Anbieter zwischen Per-Token-, Per-Seat- und Per-Outcome-Modellen experimentieren. Open-Source-Modelle haben in zwei Jahren einen großen Teil des Abstands zu proprietären Spitzenmodellen geschlossen und machen für viele Use Cases den teuren API-Aufruf verzichtbar. Und Anbieter pivotieren, fusionieren oder stellen Produkte ein. Eine mehrjährige, schwer kündbare Bindung an eine einzelne KI-Plattform ist in diesem Umfeld kein Stabilitätsanker — sie ist eine Wette darauf, dass sich ein notorisch instabiler Markt ausgerechnet bei Ihrem Vertrag stillhält. Die Regulierung verstärkt das zusätzlich: Mit den ab August 2026 greifenden Transparenzpflichten der EU-KI-Verordnung und dem ohnehin laufenden Pflichtenregime für General-Purpose-KI-Modelle ist der Compliance-Rahmen selbst noch in Bewegung. Wer sich jetzt unflexibel bindet, bindet sich an eine Momentaufnahme.
Das Vier-Ebenen-Evaluierungsframework
Der Fehler, den die meisten machen, ist, „KI-Vendor" als eine Entscheidung zu behandeln. Tatsächlich treffen Sie vier getrennte Entscheidungen, die jeweils ein anderes Lock-in-Profil und andere Wechselkosten haben. Wer sie vermischt, zahlt das Lock-in der klebrigsten Ebene für alle vier.
Ebene 1 — Modellanbieter. Die Foundation Models von OpenAI, Anthropic, Google, Mistral und der Open-Weight-Familie (Llama, Mistral, Qwen). Diese Ebene verändert sich am schnellsten und sollte von Tag eins als austauschbar behandelt werden. Evaluieren Sie hier nicht nach Benchmark-Tabellen — die sind für Ihren Anwendungsfall fast bedeutungslos —, sondern nach der Qualität an Ihren eigenen Daten, den Kosten pro Transaktion bei Ihrem realistischen Volumen und den Datenverarbeitungsbedingungen. Das Lock-in-Risiko ist gering, wenn Sie sauber architektonisch arbeiten: Modelle werden über APIs mit weitgehend ähnlichen Input-/Output-Formaten angesprochen, der Anbieterwechsel ist eine Sache von Tagen, nicht Monaten — vorausgesetzt, Sie haben keine anbieterspezifischen Features tief in Ihren Workflow verdrahtet. Designen Sie deshalb modell-agnostisch und führen Sie eine dünne Abstraktionsschicht ein, die den Modellwechsel erlaubt, ohne den Anwendungscode anzufassen. Das kostet wenig zusätzliche Komplexität und kauft Ihnen die wertvollste Option im gesamten Stack. (Warum kommerzielle Modelle für die meisten Mittelständler der richtige Startpunkt sind, erklärt Build vs. Buy für Enterprise-KI.)
Ebene 2 — Plattform und Orchestrierung. Die Middleware, mit der Workflows gebaut werden: Prompt-Management, Retrieval-Pipelines, Orchestrierung mehrstufiger Prozesse, Agenten-Frameworks. Hier konkurrieren Open-Source-Bausteine mit den Managed Platforms der Hyperscaler — Azure AI Foundry, AWS Bedrock, Google Vertex AI. Entscheidend ist, ob die Plattform Ihre konkreten Muster trägt (Klassifikation, Extraktion, Retrieval, Orchestrierung), welche Hosting-Optionen sie bietet und wie ausgereift Monitoring und Observability sind. Das Lock-in-Risiko ist mittel und unterschätzt: Plattformspezifische Abstraktionen, Workflow-Definitionen und Integrationsmuster erzeugen Wechselkosten, die kein Konfigurationswechsel auflöst, sondern ein Projekt. Bevorzugen Sie offene Orchestrierung, wo die Funktionalität vergleichbar ist, und halten Sie Ihre Kernlogik — Prompts, Validierungsregeln, Geschäftslogik — außerhalb der Plattform, in Ihrem Repository, exportierbar.
Ebene 3 — Dateninfrastruktur. Wo Ihre Daten liegen, wie sie verarbeitet werden und wie sie in die KI-Workflows einfließen: Vektordatenbanken, Datenpipelines, die Integrationsschicht zu ERP, CRM und DMS. Das ist die klebrigste Ebene und der Ort, an dem das meiste reale Lock-in entsteht. Sobald die Pipelines stehen und die Vektorindizes befüllt sind, ist ein Wechsel teuer und riskant — nicht wegen der Technik, sondern wegen der stillschweigend eingebauten Annahmen. Behalten Sie hier die Hoheit: Standardformate, offene Protokolle, jede Pipeline mit einer eingebauten Exportfähigkeit. Lassen Sie nie zu, dass ein Vendor das einzige Repository Ihrer operativen Daten wird.
Ebene 4 — Implementierungs- und Betriebspartner. Die Häuser, die Ihnen beim Bauen, Deployen und Betreiben helfen. Das Lock-in-Risiko ist hier nicht technisch, sondern strukturell: Ein Partner, der opake Systeme baut und das Betriebswissen für sich behält, erzeugt eine Abhängigkeit, die kein Vertrag vollständig auffängt. Wählen Sie Partner, die sich selbst überflüssig machen — deren Engagement damit endet, dass Ihr Team den Workflow eigenständig betreiben und weiterentwickeln kann. Wer Engagements so strukturiert, dass fortlaufende Abhängigkeit entsteht, optimiert seinen eigenen Umsatz, nicht Ihre Fähigkeit.
Datensouveränität: die nicht verhandelbare Anforderung
Für DACH-Unternehmen ist Datensouveränität kein Nice-to-have, sondern ein Filter, der vor der Funktionsdiskussion greift. Unter der DSGVO erfordert die Übermittlung personenbezogener Daten an Verarbeiter außerhalb des EWR geeignete Garantien; in regulierten Sektoren — Finanzdienstleistung, Versicherung, Gesundheit — kommen sektorspezifische Anforderungen an Auslagerung und Datenstandort hinzu, die den Spielraum weiter verengen. Praktisch heißt das: Sie evaluieren nicht „kann der Vendor das?", sondern „bleibt die Verarbeitung — nicht nur die Speicherung — nachweisbar in der EU?".
Auf der Modellebene existieren reale EU-Verarbeitungswege, aber sie sind nicht der Default. Über Azure lässt sich mit den Data-Zone-Deployment-Typen (EU) erreichen, dass Prompts und Antworten innerhalb der EU Data Boundary verarbeitet werden. Anthropics Claude bietet eine echte EU-Residenz nicht über die Standard-API, sondern über die regionalen Inferenzprofile von AWS Bedrock oder die EU-Regionen von Google Vertex AI, wo die Inferenz in der EU-Infrastruktur des Cloud-Anbieters läuft. OpenAI hat für seine API eigene EU-Datenresidenz-Optionen eingeführt. Diese Wege sind dokumentiert und vertraglich fassbar — aber sie sind Konfigurations- und Vertragsfragen, die aktiv gewählt und geprüft werden müssen, nicht Eigenschaften, die ein Verkaufsgespräch automatisch mitliefert. Ein wichtiges Detail aus der Praxis: Cross-Region-Inferenz innerhalb einer Geografie (etwa „EU") kann Anfragen über mehrere EU-Regionen routen, ohne dass Kundendaten in der Zielregion gespeichert werden — das ist DSGVO-konform, aber Sie sollten wissen und dokumentieren, dass es so funktioniert. Auf der Datenebene schließlich eliminieren selbst gehostete Vektordatenbanken (Qdrant, Milvus, Weaviate auf Ihrer Infrastruktur) die Frage vollständig.
Die operative Konsequenz ist simpel und wird trotzdem selten eingehalten: Akzeptieren Sie keine Vendor-Zusicherung ohne Verifizierung. Fragen Sie konkret und schriftlich, wo Daten verarbeitet werden, ob Eingaben für das Modelltraining genutzt werden und ob ein DSGVO-konformer Auftragsverarbeitungsvertrag vorgelegt werden kann. Wo eine dieser Antworten ausweicht, haben Sie Ihre Antwort.
Der Exit-Klausel-Test
Bevor eine Unterschrift unter einen KI-Vertrag kommt, stellen Sie eine einzige Frage: Wenn wir in sechs Monaten wechseln müssten — könnten wir? Dieser Test ist deshalb so wirksam, weil er versteckte Abhängigkeiten zwingt, sichtbar zu werden, solange Sie noch Verhandlungsmacht haben. Können Sie Ihre Daten in einem Standardformat exportieren? Können Sie den Workflow auf einer anderen Plattform nachbilden? Gehören Ihnen Ihre Prompts, Validierungsregeln und Geschäftslogik — oder dem Vendor? Ist das Betriebswissen dokumentiert oder im Kopf eines fremden Teams?
Ein „Nein" auf eine dieser Fragen ist kein Ausschlusskriterium, aber ein identifiziertes Risiko, das in den Vertrag gehört: Datenportabilitäts-Klauseln mit definierten Exportformaten, Dokumentationspflichten, bei kritischer Software ein Source-Code-Escrow — oder eine Architektur, die die Abhängigkeit von vornherein reduziert. Der Punkt ist nicht, jedes Lock-in zu vermeiden; das ist unmöglich und oft teuer erkauft. Der Punkt ist, jedes Lock-in bewusst einzugehen, mit einem Preisschild und einem Ausweg.
Die teuren Fehler — und wie man sie vermeidet
Entscheidung anhand von Demos. Jede Vendor-Demo sieht beeindruckend aus; das ist ihr Zweck. Ihre Beschaffungsentscheidung gehört auf einen Proof of Concept mit Ihren Daten, in Ihrem Maßstab, für Ihren Anwendungsfall — nicht auf eine polierte Präsentation mit handverlesenen Beispielen.
Plattform vor Wertnachweis kaufen. Erwerben Sie keine Enterprise-KI-Plattform, bevor ein einziger Workflow in Produktion läuft. Starten Sie mit leichtgewichtigen Mitteln, beweisen Sie den Business Case, investieren Sie dann in Infrastruktur. Dass die meisten Anbieter das Gegenteil empfehlen, hat einen einfachen Grund: Die meisten Anbieter verkaufen Plattformen.
Total Cost of Ownership ignorieren. Der API-Preis ist die sichtbare Ausgabe; Integration, Monitoring, Storage und Teamschulung sind die unsichtbare. Ein Modell zu 0,01 EUR pro Aufruf, das 50.000 EUR Integrationsentwicklung verlangt, ist nicht günstig — es ist nur günstig etikettiert.
Vendor-Auswahl als einmalige Entscheidung behandeln. Prüfen Sie Ihren Stack jährlich. Die Landschaft verschiebt sich schnell genug, dass die optimale Wahl von letztem Jahr nicht die von diesem Jahr sein muss. Bauen Sie die Optionalität zum Wechsel ein, ohne den Wechsel zum Reflex zu machen — auch Stabilität hat einen Wert, und ständiges Re-Plattformen ist sein eigenes, teures Lock-in.
Die Entscheidung treffen
Vendor-Auswahl-Paralyse ist real: Die Landschaft ist komplex, die Einsätze fühlen sich hoch an, die Optionen sind überwältigend. Der Ausweg ist nicht mehr Analyse, sondern eine kleinere erste Frage. Definieren Sie einen einzigen, spezifischen ersten Anwendungsfall (siehe Process Mining für KI-Kandidaten). Identifizieren Sie den minimalen Vendor-Stack, den genau dieser Fall braucht. Priorisieren Sie Datensouveränität und Exit-Flexibilität vor Feature-Vollständigkeit. Führen Sie einen zeitlich befristeten Proof of Concept von zwei bis vier Wochen durch, bevor Sie sich binden. Dann fangen Sie klein an, lernen und erweitern — auf einem Fundament, das Sie jederzeit verlassen könnten.
Ein Fit Call prüft Ihren konkreten ersten Use Case gegen genau dieses Raster — Modell, Plattform, Daten, Partner und Exit — bevor eine Unterschrift Sie an eine Momentaufnahme bindet.
Wir sind dabei vendor-agnostisch: Wir vertreiben keine Plattformen und nehmen keine Vermittlungsprovisionen. Unsere Empfehlung basiert ausschließlich auf Ihrem Anwendungsfall, Ihren Datensouveränitätsanforderungen und den Fähigkeiten Ihres Teams. Für den breiteren operativen Kontext siehe KI im Betrieb.
References: European Commission, „AI Act — Regulatory framework on AI" (digital-strategy.ec.europa.eu); artificialintelligenceact.eu, „Implementation Timeline"; Microsoft Learn, „Deployment types in Microsoft Foundry Models — EU Data Zones"; AWS, „Geographic cross-Region inference — Amazon Bedrock"; OpenAI, „Data residency for the OpenAI API".