Warum Unternehmen bei AI Vendor Lock-in vermeiden müssen

AI ist kein normales SaaS-Thema mehr

Viele Unternehmen behandeln AI noch wie ein weiteres Cloud-Feature: Modell auswählen, API anbinden, fertig. In der Praxis ist AI aber längst tiefer im Stack verankert. Wer heute produktive AI baut, entscheidet damit oft gleichzeitig über Datenflüsse, Identität, Observability, Deployment-Modelle, FinOps, Governance und teilweise sogar über Hardwarepfade. Genau daraus entsteht Vendor Lock-in.

Das Problem ist nicht, dass Microsoft, AWS, NVIDIA oder SAP schlechte Plattformen wären. Im Gegenteil: Alle vier Anbieter investieren massiv in Flexibilität. Microsofts Foundry-Modellkatalog umfasst Hunderte Modelle verschiedener Anbieter, Amazon Bedrock unterstützt über 100 Foundation Models, SAP betont für AI Core einen hyperscaler-agnostischen Ansatz, und NVIDIA positioniert NIM und Nemotron ausdrücklich als breit deploybare Bausteine. Gerade deshalb ist das Thema so relevant: Selbst wenn Plattformen offener werden, kann der Lock-in an ganz anderen Stellen zuschnappen.

Der moderne Lock-in sitzt nicht nur im Modell

Früher dachte man bei Lock-in vor allem an proprietäre Dateiformate oder geschlossene Datenbanken. In der AI-Welt ist das Bild komplizierter. Ein Unternehmen kann heute formal mehrere Modelle nutzen und trotzdem faktisch an einen Anbieter gefesselt sein, etwa weil Prompt-Management, Sicherheitsrichtlinien, Vektorindizes, Agentenlogik, IAM, Abrechnung und Monitoring tief in eine einzelne Plattform eingebaut wurden. Diese Abhängigkeit ist oft viel schwerer aufzulösen als ein reiner Modellwechsel.

Genau deshalb reicht die Aussage „Wir nutzen doch mehrere Modelle“ nicht aus. Wer verschiedene Modelle nur innerhalb eines einzigen Plattform-Ökosystems konsumiert, hat das Modellrisiko etwas reduziert, aber nicht automatisch das Plattformrisiko.

Microsoft: Multi-Model ja, aber der Stack bleibt mächtig

Microsoft Foundry zeigt gut, wie moderne Plattformen gleichzeitig flexibel und bindend sein können. Laut Microsoft umfasst der Modellkatalog Hunderte Modelle von Azure OpenAI, Mistral, Meta, Cohere, NVIDIA und Hugging Face; zusätzlich gibt es verschiedene Deployment-Optionen wie Managed Compute und serverless beziehungsweise Standard- und Provisioned-Modelle. Microsoft bietet außerdem für einige Foundry-Tools Container an, damit dieselben APIs auch on-premises genutzt werden können.

Das ist stark — aber genau hier liegt die Falle: Wer Sicherheitsrichtlinien, Datenzonen, Azure-spezifische Endpunkte, Deployments, Identitäten und Tooling tief an den Microsoft-Stack koppelt, macht einen späteren Wechsel teuer. Man verlässt dann nicht nur einen Modellanbieter, sondern ein komplettes Betriebsmodell. Besonders deutlich wird das bei Datenverarbeitung und Residency: Foundry unterscheidet zwischen globalen, Data-Zone- und regionalen Deployments, mit teils unterschiedlicher Verarbeitung von Inferencing-Daten. Solche Architekturentscheidungen sind sinnvoll, aber sie prägen die Plattform später massiv.

AWS Bedrock: Weniger Modell-Lock-in, aber möglicher Plattform-Lock-in

Amazon Bedrock ist auf den ersten Blick ein gutes Gegenmittel gegen reinen Modell-Lock-in. AWS dokumentiert, dass Bedrock über 100 Foundation Models verschiedener Anbieter unterstützt. Dazu kommen regionenagnostische Model IDs und Inference Profiles, mit denen Anfragen über mehrere AWS-Regionen verteilt werden können.

Das ist operativ attraktiv: Ein Team kann mehrere Modellfamilien testen, vergleichen und produktiv nutzen, ohne jede Integration separat bauen zu müssen. Aber auch hier gilt: Wer seine Guardrails, Berechtigungen, Kostenlogik, Telemetrie, Knowledge Bases und Agenten-Workflows tief im AWS-Ökosystem verankert, wird nicht durch ein anderes Modell automatisch unabhängig. Dann wurde nur der Modell-Lock-in entschärft, während der Control-Plane-Lock-in bestehen bleibt.

Anders gesagt: Bedrock kann helfen, nicht an einen Modellhersteller zu hängen. Es schützt aber nicht automatisch davor, an AWS als Betriebsumgebung zu hängen.

NVIDIA: Der gefährlichste Lock-in ist oft hardware-nah

Bei NVIDIA ist das Thema noch heikler, weil es nicht nur um APIs, sondern um den darunterliegenden Beschleuniger-Stack geht. NVIDIA beschreibt NIM als vorgefertigte Inference-Microservices für den Einsatz auf „any NVIDIA-accelerated infrastructure“ in Cloud, Rechenzentrum, Workstation und Edge. Gleichzeitig bewirbt NVIDIA Nemotron als offene Modelle, die „anywhere—from edge to cloud“ deploybar sind, inklusive offener Gewichte, Datensätze und Techniken.

Das klingt offen — und teilweise ist es das auch. Aber es zeigt zugleich die Grenze dieser Offenheit: Die operative Flexibilität gilt vor allem innerhalb von NVIDIA-beschleunigter Infrastruktur. Genau hier entsteht ein klassischer AI-Lock-in. Wer seine Inferenz, Optimierungen, Betriebswerkzeuge und Performance-Ziele komplett um NVIDIA-Software und NVIDIA-Hardware herum baut, hat später einen sehr teuren Exit. Denn dann geht es nicht mehr nur um ein API-Mapping, sondern um Performance-Profile, GPU-Verfügbarkeit, Serving-Architektur und teils die komplette Wirtschaftlichkeit des Systems.

Das heißt nicht, dass NVIDIA vermieden werden sollte. Im Gegenteil: Für viele produktive AI-Workloads ist NVIDIA heute de facto Standard. Aber genau deshalb muss man die Abhängigkeit bewusst managen, statt sie aus Bequemlichkeit wachsen zu lassen.

SAP: Der Lock-in sitzt in den Prozessen

SAP ist ein Sonderfall. Hier entsteht Vendor Lock-in oft weniger über das Modell selbst, sondern über die Nähe zu echten Geschäftsprozessen. SAP beschreibt AI Core als standardisierte, skalierbare und hyperscaler-agnostische Plattform, die open-source-basierte AI-Funktionen integrieren kann. Der generative AI hub verspricht zentralen Modellzugang, Governance und die Erweiterung von SAP-Anwendungen über eine einheitliche API.

Das ist für Unternehmen attraktiv, weil AI dort direkt in Finance, HR, Einkauf oder ERP-nahe Prozesse wandert. Genau dadurch wird ein späterer Wechsel aber schwieriger. Wenn AI-Agenten, Prompt-Flows, Dokumentenverarbeitung und Fachlogik tief in SAP-nahe Prozesse eingebettet sind, ist der Lock-in nicht nur technisch, sondern organisatorisch. Dann muss ein Unternehmen nicht bloß eine API austauschen, sondern gewachsene Prozessketten, Berechtigungen und Fachlogiken neu bauen. SAP versucht das mit einem hyperscaler-agnostischen Unterbau abzufedern — die Geschäftsprozess-Nähe bleibt trotzdem ein massiver Bindungsfaktor.

Warum Vendor Lock-in bei AI so teuer wird

Der eigentliche Schaden zeigt sich oft nicht am Anfang, sondern beim Skalieren. Im Pilotprojekt wirkt eine enge Bindung an einen Anbieter bequem. Alles ist integriert, schnell verfügbar und vom Vertrieb gut erklärt. Erst später kommen die harten Fragen:

• Was passiert, wenn ein anderes Modell deutlich besser oder günstiger wird?
• Was passiert, wenn Compliance eine andere Datenverarbeitung verlangt?
• Was passiert, wenn GPU-Kosten oder Tokenpreise kippen?
• Was passiert, wenn ein Unternehmensbereich nicht in denselben Stack passt?
• Was passiert, wenn ein Ausfall, eine Preisänderung oder eine Produktabkündigung die Architektur trifft?

Dann merkt man, ob man eine AI-Strategie gebaut hat oder nur eine komfortable Demo-Plattform.

So vermeidet man Lock-in in der Praxis

Die wichtigste Regel lautet: Modell, Plattform und Geschäftslogik sauber trennen. Unternehmen sollten ihre AI-Anwendungen so bauen, dass das Modell austauschbar bleibt, die Orchestrierung nicht an einen einzigen Dienst gekettet ist und die Kernlogik nicht direkt in proprietären Features verschwindet.

Konkret heißt das:

1. Eine eigene Abstraktionsschicht vor das Modell setzen

Nicht jede Anwendung sollte direkt gegen eine einzelne Vendor-API programmiert werden. Eine interne AI-Gateway- oder Provider-Schicht macht Modellwechsel realistisch, statt nur theoretisch.

2. Prompts, Tools und Policies versionieren

Prompt-Logik, Tool-Definitionen, Guardrails und Evaluierungen gehören in die eigene Delivery-Pipeline — nicht nur in proprietäre Oberflächen.

3. Daten und Embeddings portabel halten

Wer Retrieval, Vektorsuche und Wissensquellen stark an einen Anbieter koppelt, verschiebt den Lock-in nur vom Modell zur Datenebene.

4. Offene Modelle ernsthaft mitdenken

Nicht jeder Workload braucht Closed Models. Gerade für interne Automatisierung, Extraktion, Klassifikation oder Edge-Szenarien können offene Modelle die Exit-Kosten stark senken. NVIDIA selbst betont bei Nemotron den offenen Charakter und die freie Nutzbarkeit der Modelle; SAP und Microsoft bieten parallel Plattformpfade, in denen mehrere Modelle parallel betrieben werden können.

5. GPU- und Inferenzstrategie getrennt betrachten

Viele Unternehmen vermischen Modellwahl und Infrastrukturwahl. Das ist gefährlich. Ein Modellwechsel ist wertlos, wenn die Betriebsrealität komplett an einen bestimmten GPU-Stack gebunden bleibt.

6. Exit-Kosten früh testen

Der beste Schutz gegen Lock-in ist ein geplanter Wechseltest. Wer nie versucht hat, denselben Use Case von Microsoft auf Bedrock, von Bedrock auf Self-Hosting oder von NVIDIA-optimiert auf alternative Inferenzpfade zu verschieben, kennt seine echte Abhängigkeit nicht.

Mein Fazit

Die eigentliche Frage ist nicht, ob Microsoft, AWS Bedrock, NVIDIA oder SAP „gut“ oder „schlecht“ sind. Die wichtigere Frage lautet: Wie viel deiner AI-Wertschöpfung gehört am Ende noch dir?

Microsoft bietet breite Modellvielfalt und Hybridoptionen. AWS Bedrock reduziert reinen Modell-Lock-in. NVIDIA treibt Performance und Produktionsreife. SAP bringt AI nah an reale Geschäftsprozesse. All das ist wertvoll. Aber genau diese Stärke macht die Bindung gefährlich, wenn Unternehmen nicht bewusst gegensteuern.

Wer AI langfristig strategisch nutzen will, darf sich nicht nur fragen, welches Modell heute am besten ist. Er muss fragen, welche Architektur ihm morgen noch Bewegungsfreiheit lässt. Denn in der AI gewinnt am Ende nicht nur der mit dem besten Modell — sondern der, der noch wechseln kann.