KI Modellwechsel 2026: Was den Vendor Lock-in überlebt

Constantin Budin, Principal Data & AI bei Pexon Consulting | 11 Min. Lesezeit | 21.09.2026

TL;DR: KI Modellwechsel und Lock-in in fünf Sätzen

Vendor Lock-in bei KI entsteht nicht über den Vertrag, sondern über den KI Modellwechsel, den der Anbieter erzwingt: Anthropic sagt aktuellen Modellen nur zwölf Monate Laufzeit ab Release zu. OpenAI-Kompatibilität, Gateways und MCP lösen das jeweils nur teilweise. Pexon Consulting baut deshalb drei Dinge, die jeden Wechsel überleben: eigene Zugangsschicht, eigene Evals, eigene Datenhaltung inklusive Embeddings.

Das Problem: Die Abschaltmail kommt planmäßig

Im August kommt die Mail. Das Modell, auf das Ihr Team im Januar alles abgestimmt hat, wird in 60 Tagen abgeschaltet. Der Nachfolger hat eine andere Modell-ID, akzeptiert einen Sampling-Parameter nicht mehr, und das Prompt-Caching verhält sich anders.

Das ist kein Pech, sondern der dokumentierte Normalfall. Anthropic hat seit dem 04.09.2024 in neun Wellen Modelle abgekündigt. Wir haben die öffentliche Liste nachgerechnet: Jedes Claude-Modell mit datierter ID lief zwischen 365 und 774 Tagen, der Median liegt bei rund 14,5 Monaten. Seit der Generation 3.5 sind es nur noch 12 bis 13 Monate. Claude Opus 4.1 (claude-opus-4-1-20250805) wurde am 05.08.2026 abgeschaltet, exakt ein Jahr nach seinem ID-Datum.

Architekturentscheidungen und Verträge laufen dagegen drei bis fünf Jahre. Die kurzlebigste Komponente sitzt in der Mitte des Systems. Das ist kein Planungsfehler, sondern die Natur der Sache. Sie müssen nur die richtige Schicht festlegen, und das ist nicht das Modell.

Die Projektleitung KI eines Telekommunikationsdienstleisters sagte es uns im März so: „Wir setzen da tatsächlich nur auf diese eine Plattform, das ist eine Art Abhängigkeit.“

Neun Abkündigungswellen in zwei Jahren: die Datenlage

Wie lange lebt ein KI-Modell? Rund ein Jahr, bei deutlich kürzerer Vorwarnzeit. Unsere Tabelle stammt aus der Anthropic-Seite Model deprecations, Stand September 2026, die Lebensdauer haben wir aus dem Datum in der Modell-ID berechnet.

Drei Befunde. Erstens ist die Vorwarnzeit geschrumpft: Alle fünf letzten Wellen lagen zwischen 60 und 62 Tagen, und genau das ist die Zusage („at least 60 days‘ notice before model retirement for publicly released models“). Zweitens gibt es nach dem Stichtag keinen Übergangsmodus: „Requests to retired models will fail.“ Drittens steht die Laufzeit aktueller Modelle vorab fest: Claude Opus 4.7 wurde am 16.04.2026 veröffentlicht, die Abschaltung erfolgt „Not sooner than April 16, 2027“. Bei Claude Opus 5 (Release 24.07.2026) steht dasselbe Muster: frühestens 24.07.2027.

Dazu kommt das Tempo an der Spitze. Zwischen Opus 4.7 (16.04.2026), Opus 4.8 (28.05.2026) und Opus 5 (24.07.2026) lagen 99 Tage. Opus 4.7 und 4.8 tragen heute beide den Status „Legacy“. Die nächste Frist ist übrigens nah: claude-sonnet-4-5-20250929 ist „Not sooner than September 29, 2026“ gelistet.

Andere Anbieter, andere Fristen, gleiches Prinzip:

• Microsoft Foundry (Azure OpenAI): GA-Modelle werden nach zwölf Monaten für Neukunden gesperrt und nach 18 Monaten abgeschaltet, danach liefert jede Anfrage 410 Gone. Provisionierte Deployments werden ausdrücklich nicht automatisch migriert: „Provisioned deployments are NOT auto-upgraded.“
• OpenAI: mindestens sechs Monate Vorwarnung für GA-Modelle. Die Assistants API wurde am 26.08.2026 abgeschaltet, am 23.10.2026 folgen zwölf datierte Modell-IDs, darunter gpt-4o-2024-05-13 und o1-2024-12-17 (Quelle: OpenAI Deprecations, Stand September 2026).

Sechs Annahmen zum Vendor Lock-in bei KI, sechs Belege dagegen

Keine der sechs verbreiteten Annahmen hält der Dokumentation der Hersteller stand. Wir zitieren nur Primärquellen, keine Gateway-Anbieter und keine Analysten.

Annahme 1: OpenAI-kompatibel heißt austauschbar

Anthropics OpenAI-Kompatibilitätsschicht ist laut Doku „primarily intended to test and compare model capabilities“. In der Feldtabelle stehen 15 Anfragefelder der obersten Ebene als „Ignored“, darunter response_format, seed und reasoning_effort. Wörtlich: „Most unsupported fields are silently ignored rather than producing errors.“ Beim Function Calling wird strict verworfen, „which means the tool use JSON is not guaranteed to follow the supplied schema“. Prompt Caching geht über diesen Weg gar nicht.

Kein Fehler, kein Alarm: Ein ignoriertes response_format fällt erst auf, wenn nachgelagerte Systeme am Output scheitern.

Annahme 2: Ein Gateway löst das Problem

Ein Gateway löst Zugang, Budget, Protokoll und Failover. Es löst nicht das Prompt-Format, nicht die Embeddings, nicht die Evals. Wir sagen das so deutlich, weil wir selbst Gateways bauen: Ein Gateway verschiebt die Bindung, es löst sie nicht auf.

Die Grenzen stehen sogar in der Doku des Microsoft Model Routers. Das nutzbare Kontextfenster ist „the limit of the smallest underlying model“, und Caching wirkt nur, „when the same model handles consecutive requests with overlapping prompt prefixes“. Wer mehrere Modelle hinter einem Endpunkt mischt, verliert also potenziell den Cache-Vorteil. Die Architektur dahinter beschreibt unsere Seite zum LLM-Gateway mit Modell-Routing.

Annahme 3: Offene Gewichte heißen kein Lock-in

Offene Gewichte beseitigen die Abhängigkeit vom Abschaltdatum eines Anbieters. Die Bindung wandert aber nur: in GPU-Betrieb, Updates, Qualitätssicherung und Prompts. Anthropic schreibt es für den Wechsel von OpenAI offen hin: „If you’ve done lots of tweaking to your prompt, it’s likely to be well-tuned to OpenAI specifically.“ Das gilt für jedes Modellpaar, egal unter welcher Lizenz. Wir halten Open-Weight-Modelle für einen wichtigen Baustein, aber für kein Gegenmittel gegen Lock-in.

Annahme 4: MCP ist Standard, also portabel

MCP liegt seit dem 09.12.2025 bei der Agentic AI Foundation unter der Linux Foundation, ausdrücklich für „vendor-neutrality and long-term independence“. Die Pointe steht in der Anthropic-Doku zu Amazon Bedrock und Google Cloud: Beide listen unter „Features not supported“ die „Agent infrastructure (Agent Skills, MCP connector, programmatic tool calling)“. Clientseitig können Sie MCP-Server weiter anbinden. Der serverseitige MCP-Connector der API fehlt aber genau auf den Plattformen, auf denen viele Unternehmen aus Commitment- oder Souveränitätsgründen landen.

Annahme 5: Wir zahlen, also bleibt das Modell

Die Abkündigung ist eine Kapazitätsentscheidung des Anbieters: „Anthropic currently deprecates and retires models to ensure capacity for new model releases.“ Ein Unternehmensvertrag ändert daran nichts.

Annahme 6: Ein Modellwechsel ist ein String in der Config

Ab Claude Opus 4.7 sind temperature, top_p und top_k abgekündigt. Laut Doku liefert ein Nicht-Standardwert einen 400-Fehler, das Python-SDK ab Version 1.0 hat die Parameter entfernt, „so passing them raises a TypeError„. Claude Opus 5 bringt zusätzlich „two breaking changes for code running on Claude Opus 4.8: thinking is on by default, and thinking can be disabled only at effort high or below“.

Der Bruch lässt sich nachstellen:

# Derselbe Request gegen zwei Modelle, Stand September 2026
# Erwartung laut Anthropic-Doku: claude-sonnet-4-6 antwortet mit 200,
# claude-opus-5 mit 400, weil temperature ab Opus 4.7 abgekündigt ist
for MODEL in claude-sonnet-4-6 claude-opus-5; do
  curl -s -o /dev/null -w "$MODEL: HTTP %{http_code}\n" \
    https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    -d "{\"model\": \"$MODEL\", \"max_tokens\": 64, \"temperature\": 0.2, \"messages\": [{\"role\": \"user\", \"content\": \"Test\"}]}"
done

Der beste Beleg kommt vom Anbieter selbst. Die Doku zu Bedrock und Google Cloud empfiehlt, in Claude Code /claude-api migrate auszuführen, „to apply model ID swaps and breaking parameter changes across your codebase“. Ein Migrationswerkzeug baut niemand für einen String-Tausch.

Derselbe Anbieter, drei Clouds, drei Lebenszyklen

„Wir nehmen Claude“ ist noch keine Entscheidung. Dasselbe Modell hat je nach Betriebsweg eine andere ID, einen anderen Funktionsumfang und einen anderen Abschalttermin, wörtlich: „Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model’s lifecycle status and dates can differ.“

Stand September 2026, Quelle: Anthropic-Doku. Microsoft Foundry und Claude Platform on AWS folgen dem Lebenszyklus der Claude API.

Für Häuser mit EU-Anforderung ist Bedrock mit EU-Inferenzprofil trotzdem oft der richtige Weg, wenn klar ist: Der Abschalttermin liegt bei Amazon, einige Funktionen bauen Sie selbst. Die vollständige Plattformtabelle für Claude pflegen wir unter Claude über Bedrock, Vertex und Foundry. Und ob Ihre bestehenden AWS- oder Azure-Commitments den Verbrauch anrechnen: Das klären Sie mit Ihrem Account-Team, nicht mit einem Blogartikel. Den Auftragsverarbeitungsvertrag prüft Ihre Rechtsabteilung.

Der teuerste Lock-in: Embeddings

Der Modellwechsel an der Oberfläche dauert Tage. Der Wechsel des Embedding-Modells darunter zieht den ganzen Korpus neu durch. Vektoren verschiedener Embedding-Modelle liegen in verschiedenen Vektorräumen und sind nicht vergleichbar. Qdrant formuliert es in der Migrationsanleitung trocken: „Switching models requires re-embedding all vectors in your collection, which can take time.“ Die dort beschriebenen Verfahren (zwei parallele Collections oder benannte Vektoren) halten während der Umstellung alte und neue Vektoren nebeneinander vor.

Der Aufwand lässt sich ohne erfundene Zahlen rechnen: Dokumente mal Tokenzahl mal Embedding-Preis, plus Doppelbetrieb, plus Neubewertung der Trefferqualität. Den letzten Posten unterschätzen fast alle.

Unsere Empfehlung: Trennen Sie das Embedding-Modell bewusst vom Antwortmodell. Das Antwortmodell wechseln Sie, ohne den Index anzufassen. Das Embedding-Modell wechseln Sie selten und geplant, und Sie dokumentieren, welches Modell welchen Index erzeugt hat.

Zwei weitere Bindungen stehen im Kleingedruckten. Prompt Caching verlangt „100% identical prompt segments“, und die Mindestlänge unterscheidet sich je Modell: 512 Tokens bei Opus 5, 1.024 bei Sonnet 4.6, 4.096 bei Haiku 4.5. Darunter wird ohne Fehlermeldung nicht gecacht („no error is returned“). Ein Wechsel auf ein kleineres Modell kann also still die Rechnung erhöhen. Und Fine-Tuning hängt am Basismodell: Bei Microsoft endet das Training „no earlier than the base model retirement date“, danach läuft nur noch das bestehende Deployment aus.

Routing spart weniger, als die Folie sagt

Model Routing gilt als Kostenhebel. Das Referenzprojekt RouteLLM wirbt im README mit „reduce costs by up to 85% while maintaining 95% GPT-4 performance“ auf MT Bench. Das zugehörige Paper (arXiv 2406.18665, Tabelle 6) zeigt, wie stark das vom Benchmark abhängt:

Auf Wissens- und Rechenaufgaben bleibt ein Faktor von rund 1,4 bis 1,5, bei spürbarem Qualitätsverlust. Routing lohnt sich trotzdem, aber aus einem anderen Grund: Es lenkt Datenklassen auf das erlaubte Modell und liefert einen zweiten Pfad, wenn der erste abgeschaltet wird.

Was tatsächlich portabel ist: drei Dinge

Bei einem KI-Anbieterwechsel bleiben drei Dinge erhalten: die aufbereiteten Daten, die Evaluationen und die eigene Zugangsschicht. Alles andere wird angepasst oder neu gebaut.

1. Ihre Daten und deren Aufbereitung. Chunking, Metadaten, Berechtigungen. Die teuerste Arbeit und die einzige, die vollständig Ihnen gehört. Die Vektoren nur bedingt, siehe oben.
2. Ihre Evaluationen. Eine Eval-Suite mit Ihren eigenen Fragen und erwarteten Antworten bewertet ein neues Modell in Stunden. Anthropic empfiehlt genau das: „thorough testing of your applications with the new models well before the retirement date“.
3. Ihre Zugangsschicht. Anmeldung, Policy, Protokoll, Budget, Modellkatalog. Sie ändert sich nicht, wenn das Modell wechselt, und sie ist der Ort, an dem der Wechsel stattfindet.

Unabhängigkeit misst man daran, wie lange ein Wechsel dauert. Mit Eval-Suite sind es Tage. Ohne warten Sie auf die Abschaltmail.

Ob diese Schicht in der EU-Cloud, hybrid oder on-premise läuft, ist eine zweite Frage. On-premise löst das Datenthema und schafft eigenen Betriebsaufwand. Pexon Consulting (80 Mitarbeitende in Deutschland, ISO 27001) baut beide Varianten, und wir raten nur dann zu on-premise, wenn Datenklasse oder Regulierung es verlangen.

Welche Kosten ein KI Modellwechsel wirklich auslöst

Eine belastbare öffentliche Zahl in Personentagen gibt es nicht, und wir erfinden keine. Belegbar sind die Posten, die Sie für Ihr System schätzen können:

1. Re-Embedding des Korpus plus Doppelbetrieb während der Umstellung
2. Prompt-Nacharbeit für das neue Modell
3. Code-Anpassung an Breaking Changes wie temperature oder Thinking-Defaults
4. Verlorene Plattform-Funktionen, etwa beim Umzug auf Bedrock oder Google Cloud
5. Neue oder erweiterte Evals
6. Neu aufzubauender Prompt-Cache

Die Posten zwei, drei und sechs fallen bei jedem Upgrade an, auch beim selben Anbieter. Deshalb gehört die Frage in die Architektur, nicht in den Einkauf.

Häufig gestellte Fragen

Was ist Vendor Lock-in bei KI?

Vendor Lock-in bei KI ist die Bindung an einen Modellanbieter, die einen Wechsel teuer macht. Sie entsteht an Prompt-Format, Tool-Schemata, Embeddings, Fine-Tuning, Plattform-Funktionen und Abschaltterminen, selten am Vertrag.

Wie lange lebt ein KI-Modell?

Laut Anthropic-Abkündigungsliste 12 bis 25 Monate ab ID-Datum, seit Generation 3.5 rund 12 bis 13 Monate. Zugesagt sind frühestens zwölf Monate nach Release. Microsoft Foundry schaltet GA-Modelle nach 18 Monaten ab.

Was kostet ein KI Modellwechsel?

Eine belastbare Gesamtzahl gibt es nicht. Die Kosten setzen sich aus Re-Embedding, Prompt-Nacharbeit, Code-Anpassung, Evals und verlorenen Plattform-Funktionen zusammen. Eine vorhandene Eval-Suite senkt den größten Posten: die Unsicherheit.

Schützt eine OpenAI-kompatible API vor Vendor Lock-in?

Nein. Anthropic nennt die eigene Kompatibilitätsschicht nicht produktionsreif, 15 Anfragefelder der obersten Ebene werden stillschweigend ignoriert, strict wird verworfen. Kompatibilität schützt vor Absturz, nicht vor verändertem Verhalten.

Gateway oder Open-Weight-Modell: was hilft mehr gegen Lock-in?

Beides, an unterschiedlichen Stellen. Das Gateway macht den Zugang anbieterneutral, das Open-Weight-Modell entkoppelt vom Abschalttermin. Keines ersetzt eigene Evals und saubere Datenhaltung.

Nächster Schritt

Verwandte Themen