KI-Modell wechseln, ohne dass Prozesse brechen

1. Der Wechsel kommt sowieso

Die Entscheidung, das produktive KI-Modell zu wechseln, trifft nicht der Kunde. 41 Prozent der deutschen Unternehmen ab 20 Beschäftigten nutzen bereits Künstliche Intelligenz, weitere 48 Prozent planen oder diskutieren den Einsatz ^[1] — und jedes dieser Unternehmen wird vor diesem Vorgang stehen. Denn der Wechsel ist in die Geschäftsmodelle der Anbieter eingebaut, und zwar dreifach.

Erstens: Abkündigung. Die großen Anbieter dokumentieren Modell-Lebenszyklen, aber Laufzeit und Vorlauf variieren nach Modellklasse. OpenAI gewährt für allgemein verfügbare Modelle mindestens sechs Monate Vorlauf bis zur Abschaltung, für Spezialvarianten etwa drei Monate, für Preview-Modelle teils nur zwei Wochen ^[2]. Anthropic garantiert 60 Tage; real lagen die Fristen zuletzt zwischen zwei und sechs Monaten ^[3]. Google sichert für Gemini-Modelle mindestens 12 Monate ab Veröffentlichung zu und verschiebt Abschalttermine allenfalls nach hinten, nie nach vorn ^[4]; die veröffentlichten Einzeltermine liegen bei etwa 12 bis 16 Monaten. Microsoft setzt das Abschaltdatum in Azure für bestimmte allgemein verfügbare Modelle auf 18 Monate nach Erscheinen und stellt klar: „Retirement dates aren’t extendable“ — in manchen Konstellationen wird das Modell hinter einem Deployment sogar automatisch ausgetauscht ^[5]. Produktive Prozesse haben deshalb ein anbieter- und modellklassenspezifisches Ablaufdatum, keine universelle 12-bis-18-Monats-Regel.

Zweitens: Ökonomie. Öffentliche Listenpreise für benchmarkdefinierte Modellleistung sind stark gefallen; eine Marktanalyse beschreibt Größenordnungen um Faktor zehn pro Jahr ^[6]. Epoch AI misst je nach Aufgabentyp einen Rückgang zwischen Faktor 9 und Faktor 900 jährlich, im Median rund 50 ^[7]. Der Stanford AI Index dokumentiert für GPT-3.5-äquivalente Benchmarkleistung einen Preisverfall von 20 Dollar auf 7 Cent pro Million Token in rund zwei Jahren ^[8]. Diese Werte belegen einen Preis- und Benchmarktrend, nicht automatisch gleiche Prozessleistung oder niedrigere End-to-End-Kosten: Outputlänge, Prüfungen und Integration gehören in den TCO.

Drittens: Qualität. Leistungsfähigere Modelle erscheinen im Quartalsrhythmus. Irgendwann ist der Abstand zwischen dem eigenen Bestand und dem Stand der Technik so groß, dass Wettbewerber mit besseren, schnelleren oder günstigeren Prozessen arbeiten.

Warum sich Ergebnisse ändern, obwohl „alles funktioniert“

Der Trugschluss beim Modellwechsel lautet: Die Schnittstelle bleibt gleich, also bleibt das Verhalten gleich. Technisch ist der Austausch oft eine Zeile Konfiguration. Semantisch ist er ein Eingriff ins Herz des Prozesses — denn API-Kompatibilität garantiert keine semantische Gleichwertigkeit: dass das neue Modell auf dieselben Eingaben fachlich gleichwertige Ausgaben liefert.

Wie groß die Verhaltensunterschiede sind, ist gut belegt. Eine Stanford/Berkeley-Studie verglich dasselbe Produkt „GPT-4″ im Abstand von drei Monaten: Die Genauigkeit bei einer Zahlenklassifikationsaufgabe fiel von 84,0 auf 51,1 Prozent, der Anteil direkt ausführbaren Codes sank von 52 auf 10 Prozent — weil das Modell begann, Code in Formatierungszeichen einzubetten ^[9]. Kein Ausfall, keine Fehlermeldung; nur andere Ergebnisse — und zwar in beide Richtungen: Das Schwestermodell GPT-3.5 verbesserte sich im selben Zeitraum auf derselben Aufgabe deutlich ^[9]. Genau diese Unkalkulierbarkeit vermaßen Apple-Forscher an Updates offener Basismodelle: Zwischen 2 und knapp 12 Prozent aller Testfälle kippten von richtig auf falsch — sogenannte negative Flips —, obwohl die Durchschnittsleistung stieg ^{[10, Tab. 3 und 4]}. Entscheidend ist die Verteilung dahinter: Bei großen Leistungssprüngen blieben die Raten niedrig; bei Updates mit kleinem Leistungsabstand, also dem typischen Nachfolgemodell, lagen sie bei 8 bis 12 Prozent.

Dazu kommt: KI-Modelle sind nicht deterministisch. Auch die als Determinismus-Schalter bekannte Einstellung „temperature = 0″ garantiert keine identischen Antworten auf identische Anfragen ^[11]; in einem Experiment lieferten 1.000 identische Anfragen an dasselbe Modell 80 verschiedene Antworten ^[12]. Und Prompts — die Arbeitsanweisungen an das Modell — sind nicht übertragbar: Rein kosmetische Formatänderungen verschoben die Genauigkeit in Untersuchungen offener Modelle bei Few-Shot-Prompts um bis zu 76 Prozentpunkte, und welches Format gut funktioniert, unterscheidet sich von Modell zu Modell ^[13]. Schon ein zusätzliches Leerzeichen am Ende eines Prompts änderte in einer Studie rund 5 Prozent aller Vorhersagen ^[14].

„Aber das neue Modell ist doch laut Benchmark besser“

Benchmark-Ergebnisse messen Durchschnittsleistung auf fremden Aufgaben — nicht Leistung auf Ihrem Prozess. Welches Modell in einem Vergleich vorn liegt, kippt schon, wenn dieselbe Aufgabe anders formuliert wird ^[15]. Die Stanford-Evaluationsplattform HELM zeigt systematisch, dass Genauigkeitsgewinne mit Verlusten bei Robustheit oder Verlässlichkeit einhergehen können ^[16]. Und ein Teil der veröffentlichten Benchmark-Werte ist aufgebläht: Auf einem neu erstellten Testsatz vergleichbarer Art und Schwierigkeit brachen Modelle um bis zu 8 Prozent ein — ein Teil ihrer Bestwerte beruhte auf auswendig gelernten Testaufgaben ^[17]. Externe Benchmarks bleiben nützlich für Vorauswahl, Robustheitsprofile und Red-Teaming; über den produktiven Go/No-Go-Schritt entscheidet jedoch die eigene Eval-Suite.

2. Praxisbeispiel: Der stille Bruch

Ein mittelständisches Unternehmen verarbeitet Eingangsrechnungen automatisiert: Ein KI-Modell extrahiert Rechnungsnummer, Beträge, Datum und Lieferantendaten und übergibt sie als strukturierte Ausgabe ans ERP-System. Seit einem Jahr läuft das stabil. Dann wechselt die IT auf das Nachfolgemodell — 70 Prozent günstiger, laut Hersteller „deutlich leistungsfähiger“. Der Wechsel dauert einen Nachmittag. Die Stichprobe danach sieht gut aus.

Drei Dinge haben sich trotzdem geändert, und keines davon löst einen Fehler aus. Das neue Modell schreibt Datumsangaben bei ausländischen Rechnungen gelegentlich im US-Format, rundet Skonto-Beträge in Randfällen anders und lässt ein selten benötigtes Feld in Grenzfällen leer, das das alte Modell zuverlässig befüllte. Das ERP-System verarbeitet alles klaglos weiter — es prüft Struktur, nicht Inhalt.

Fünf Wochen später stimmen beim Monatsabschluss Zahlungsziele und Summen einzelner Kreditorenkonten nicht. Die Suche kostet Tage, denn niemand verbindet die Abweichungen mit dem Modellwechsel: Der lief ja „ohne Zwischenfälle“. Gefunden wird die Ursache durch Zufall, beim Vergleich einer alten und einer neuen Extraktion derselben Rechnung.

Genau das ist das Muster der negativen Flips aus der Apple-Studie ^[10]: Das neue Modell ist im Durchschnitt besser und trotzdem an Stellen schlechter, an denen das alte zuverlässig war. Ein sichtbarer Ausfall wäre harmlos gewesen — er wird sofort bemerkt und behoben. Die unsichtbare Veränderung lief fünf Wochen mit. Die Lehre: Nicht der Absturz ist das Risiko des Modellwechsels, sondern die stille Ergebnisänderung. Und die findet man nur, wenn man systematisch vergleicht — nicht, wenn man stichprobenartig schaut, ob es „funktioniert“.

Das Beispiel ist konstruiert; es verdichtet Fehlerbilder, wie sie in der Forschung dokumentiert sind ^[10], ^[14]. Reale Fälle dieser Art werden kaum publiziert — Unternehmen berichten still verlaufene Fehler nicht öffentlich.

3. Wann lohnt der Wechsel?

Nicht jeder Wechsel ist wirtschaftlich sinnvoll. Ein seriöser Business Case stellt der Ersparnis die vollen Wechselkosten gegenüber — und die bestehen fast nie aus Lizenzpreisen, sondern aus Arbeit: Prompts an das neue Modell anpassen und neu validieren, Tests aufsetzen und auswerten, eine Parallelbetriebsphase finanzieren, Restrisiko tragen. Als Faustregel für die Entscheidung:

• Ersparnis quantifizieren: aktuelle Modellkosten pro Jahr × erwarteter Preisvorteil. Bei kleinen Volumina (wenige hundert Euro monatlich) trägt die Ersparnis allein selten einen Wechsel — dann zählen Qualität, Geschwindigkeit oder das Abschaltdatum.
• Kritikalität bewerten: Je näher der Prozess an Buchhaltung, Kundenkommunikation oder rechtlich relevanten Entscheidungen liegt, desto höher der Absicherungsaufwand — und desto wichtiger, ihn nicht unter Zeitdruck leisten zu müssen.
• Eval-Reife prüfen: Existiert bereits eine Testbasis (Kapitel 4, Phase 0), sinken die Wechselkosten drastisch. Ohne sie ist der erste Wechsel am teuersten; jeder weitere kostet einen Bruchteil davon — Prompt-Anpassung und Testphasen fallen allerdings jedes Mal erneut an.
• Das Abschaltdatum kennen: Steht für das aktuelle Modell ein Abschalttermin fest, ist die Frage nicht ob, sondern wann. Die Fristen sind dabei knapper, als sie klingen: Gegen 60 Tage garantierte Vorwarnzeit ^[3] stehen der Aufbau der Eval-Suite (in der Beispielrechnung unten 10 bis 15 Personentage), ein bis zwei Wochen Shadow-Betrieb, ein Canary-Rollout und vier bis sechs Wochen Puffer vor dem Abschalttermin — das geht nicht auf. Wer erst bei der Ankündigung anfängt, migriert ohne Absicherung; wer die Testbasis vorher hat, wählt den Zeitpunkt selbst.

Als Faustregel für den freiwilligen Wechsel: Erst wenn die erwartete Jahresersparnis die einmaligen Wechselkosten um mindestens die Hälfte übersteigt, trägt der Business Case sich selbst. Darunter entscheiden Abschaltdatum, Kritikalität und Qualitätsgewinn — nicht die Rechnung.

Der häufigste Einwand an dieser Stelle: „Eine eigene Testsuite ist für uns zu teuer.“ Für den Einstieg sind 50 bis 100 kuratierte Beispiele oft praktikabel; Anthropics Eval-Beispiele arbeiten mit 100 bis 1.000 Fällen ^[18]. Diese Größenordnung ist aber ein Startpunkt, kein universeller Sicherheitsnachweis. Die Fallzahl folgt aus zulässiger Fehlerrate, erwarteter Regression, Segmentabdeckung und Kritikalität. Bei null beobachteten kritischen Fehlern liegt die einseitige 95-Prozent-Obergrenze näherungsweise bei 5,8 % für 50 Fälle und 3 % für 100 Fälle; für eine Obergrenze von 1 % wären etwa 299 unabhängige Fälle erforderlich. Für den Vergleich zweier Modelle ist die nötige Fallzahl allerdings kleiner, als diese Werte nahelegen: Weil Bestand und Kandidat dieselben Eingaben bearbeiten, zählen nur die Fälle, in denen genau eines von beiden richtig liegt. Erst dieser direkte Vergleich macht eine Regression sichtbar — ein einzelner Fehler ohne ihn ist von der normalen Fehlerquote des Bestandsmodells nicht zu unterscheiden. Kritische Randfallsegmente brauchen deshalb eigene Abdeckung.

4. Das Wechsel-Playbook

Der kontrollierte Modellwechsel ist ein Verfahren in fünf Phasen. Sein Migrationsgegenstand ist nicht nur eine Modell-ID, sondern die versionierte KI-Systemkonfiguration aus Modell, Prompts, Tools, Retrieval, Guardrails, Deployment und Monitoring. Davor steht eine Maßnahme, die unabhängig vom Modell wirkt und in ein bis zwei Personentagen umsetzbar ist: der Output-Vertrag an der Schnittstelle (Phase 0a). Wer nur eine einzige Maßnahme umsetzt, setzt diese um. Die übrigen Bausteine sind Standard im professionellen Software- und ML-Betrieb ^[19], ^[20] und werden von KI-Anbietern selbst eingesetzt ^[21].

Phase 0 — Die Eval-Suite: erst die Messlatte, dann der Kandidat

Eine Eval-Suite ist die Regressionstestbasis für KI-Prozesse: ein Golden Set mit erwarteten Ausgaben plus vorab definierte Metriken, Margen und Stoppregeln. OpenAI betont, dass ohne Evals kaum zu verstehen ist, wie Modellversionen den eigenen Anwendungsfall verändern ^[22]. Die Messlatte umfasst fünf Familien: fachliche Qualität, Format/Schema, Latenz und TCO, Security & Safety sowie Compliance. NIST ordnet GenAI-Risiken über Entwicklung, Nutzung, Evaluation und Betrieb hinweg ein ^[23].

Die Verantwortung wird vor Sichtung des Kandidatenergebnisses in einem schlanken RACI festgelegt: Der Fachbereich definiert Fehlerkosten und Nichtunterlegenheitsmargen, die IT automatisiert die Gates, Informationssicherheit sowie Datenschutz/Legal prüfen ihre Risikodimensionen, und ein benannter Risk Owner trifft die finale Go/No-Go-Entscheidung und darf den Rollout stoppen. Golden Set, Migration Manifest, Schwellenwerte und Definition von „richtig“ bleiben im Haus.

Phase 1 — Der Testlauf: Kandidat gegen Golden Set

Der Kandidat durchläuft das komplette Golden Set gegen das Bestandsmodell ^[19]. Fachbereich und Risk Owner haben vorher kritische Fehlerklassen, Nichtunterlegenheitsmarge, Wiederholungen, Aggregation, Segmente und Stoppregeln festgelegt. Kein Gesamtscore darf einen Einbruch in einem kritischen Segment verdecken. Neben Qualität werden p95-Latenz, Tokenverbrauch und TCO pro Vorgang gemessen. Security/Safety ist ein eigenes Gate mit direkten und indirekten Prompt-Injections, Offenlegung sensibler Informationen, Tool- und Berechtigungsgrenzen, Refusal-/Moderationsregressionen und adversarialen Fällen aus Incidents oder Red-Teams. OWASP empfiehlt Angriffssimulationen, Least Privilege, nachgelagerte Autorisierung und Human Approval bei hochriskanten Aktionen ^[26], ^[27]. Ein neuer kritischer Fehler, eine erfolgreiche neue Angriffs- oder Berechtigungsklasse oder eine nicht abgefangene Schemaverletzung beendet Phase 1. GitHub lässt vor Änderungen an der Copilot-Produktion über 4.000 Offline-Tests laufen ^[21].

Phase 2 — Shadow-Betrieb: mitlaufen, nicht entscheiden

Besteht der Kandidat offline, erhält er echten Produktionsverkehr — aber nur als Kopie. Beim Shadow-Betrieb (auch Traffic Mirroring) beantwortet weiterhin das Bestandsmodell alle Anfragen; der Kandidat bearbeitet dieselben Eingaben parallel, seine Ausgaben werden nur aufgezeichnet und verglichen, nie verwendet ^[28]. Das deckt auf, was kein Golden Set abbildet: das Verhalten auf dem echten, ungefilterten Eingabestrom von heute. Zwei Grenzen gehören dazu: Bei Mehrrunden-Dialogen läuft der Schatten auf Gesprächsverläufen, die er selbst nie erzeugt hätte. Agenten mit Seiteneffekten dürfen keine Live-Aktionen ausführen; Tools werden deaktiviert oder mit minimalen Rechten an eine Trockenprotokollierung gebunden, geplante Aktionen gegen Policy und Berechtigungen geprüft und hochriskante Aktionen unabhängig vom Modell durch ein nachgelagertes System gesperrt.

Phase 3 — Canary-Rollout: klein anfangen, messbar bleiben

Erst jetzt entscheidet der Kandidat real — für einen kleinen Teil des Verkehrs. Bei 5 % Canary-Anteil begrenzt selbst eine 20-Prozent-Fehlerrate die Exposition zunächst auf 1 % der Vorgänge ^[20]; die Schwere eines einzelnen Vorfalls begrenzt das nicht. Deshalb legt das RACI fest, wer bei fachlicher, Security-, Datenschutz- oder TCO-Abweichung stoppt. Für Agenten bleiben Least Privilege, nachgelagerte Autorisierung und Human Approval bei hochriskanten Aktionen modellunabhängige Kontrollen ^[26], ^[27]. Ein unautorisierter Aktionsversuch stoppt den Canary sofort. Parallel wird ein Recovery-Runbook geprobt: Modellrouting zurückschalten, fehlerhafte Daten identifizieren und korrigieren, externe Aktionen kompensieren, Betroffene informieren und den Vorfall dokumentieren. Bei niedrigem Volumen ersetzt eine Pilotgruppe mit täglichem Review den Prozent-Canary; feste Stoppkriterien und Direktvergleich mit der Bestandsgruppe bleiben.

Phase 4 — Vollumstellung: umschalten und absichern

Nach erfolgreichem Canary wird vollständig umgestellt — mit drei Absicherungen. Versioniertes Migration Manifest: Festgeschrieben werden, soweit verfügbar, immutable Modell-/Deployment-ID, Prompt und Systemnachricht, Tool-Schemas, Retriever-/Embedding-Version, Safety-/Guardrail-Konfiguration, Samplingparameter, Parser, Region/Deploymenttyp, Retention und Monitoring. Fehlt eine immutable Version, werden Alias-Semantik, Änderungsprozess und Restrisiko dokumentiert ^[3]. Rollback und Recovery: Das alte Manifest bleibt reaktivierbar; der Rückweg wird vor der Vollumstellung geprobt. Bereits gesendete E-Mails, Buchungen oder Schreibzugriffe erfordern zusätzlich Datenkorrektur, Kompensationsaktionen und Incident-Kommunikation ^[28]. Monitoring: Die Eval-Suite einschließlich Security/Safety läuft weiter ^[21]; Compatibility Gates blockieren Änderungen, sobald ein definierter Verhaltensvertrag verletzt wird ^[29]. Wer den Vergleichsaufbau aus Phase 2 nicht abbaut, sondern dauerhaft auf einem kleinen Verkehrsanteil weiterlaufen lässt, bemerkt auch stille Anbieter-Updates, ohne dass ein Wechsel ansteht. Nach jedem Vorfall gehört zudem eine Frage in die Auswertung: Hätte die Eval-Suite diesen Fall gesehen? Wenn nein, wandert er hinein.

Nicht jeder Prozess braucht alle fünf Phasen. Ein unkritischer interner Assistenzprozess kommt mit einem kleinen Golden Set und dem Testlauf aus; je näher der Prozess an Buchhaltung, Kunden oder rechtlich relevanten Entscheidungen liegt, desto mehr Phasen gehören dazu. Das Verfahren skaliert mit der Kritikalität — wie im klassischen Software-Betrieb ^[20]. Bei kleinen Volumina ersetzt eine fachliche Nachkontrolle von ein bis zwei Prozent der Vorgänge in den ersten Wochen einen Teil der Automatisierung: teurer je Fall, dafür sofort verfügbar. Und für den Fall, dass kein Kandidat besteht, während der Abschalttermin näher rückt, gehört die Entscheidung vorab getroffen — den besten verfügbaren Kandidaten mit zusätzlichen Kontrollen fahren, den Prozess vorübergehend auf manuelle Prüfung zurückstellen oder ihn aussetzen.

Wenn Sie das Modell nicht selbst betreiben

Steckt die KI in Standardsoftware oder betreibt ein Systemhaus die Integration, verschieben sich die Schritte in den Vertrag: Ankündigungsfristen, Test-/Sandbox-Zugang, Abnahmerecht gegen Golden Set und Security-Testpaket, Rollback-/Recovery-Zusage sowie Datenportabilität, Exportformate, Exit-Support, Auditinformationen, Retention und Unterauftragnehmer. Wer diese Rechte nicht bekommt, kann den Systemwechsel nicht eigenständig kontrollieren. Golden Set und Freigaberegeln bleiben die Abnahmeinstanz, die der Lieferant nicht stellen kann.

Die beiden verbleibenden Einwände

„Wir testen ein paar Beispiele manuell.“ Eine Handvoll Stichproben kann systematische Verschiebungen nicht erkennen — dafür streuen die Ergebnisse zu stark: Bei Codeaufgaben lieferte je nach Testsatz die Hälfte bis drei Viertel identischer Anfragen keine zwei gleichen Antworten ^[11], und dokumentierte Regressionen betreffen einen einstelligen bis niedrig zweistelligen Prozentsatz der Fälle ^[10] — also gerade nicht jede Stichprobe. Anekdote ersetzt keine Regression.

„Unsere Abstraktionsschicht löst das.“ Ein API-Adapter macht Modelle technisch austauschbar — semantisch gleichwertig macht er sie nicht. Gewechselt wird praktisch eine Systemkonfiguration: Modell, Prompt, Tool-Schemas, Retrieval/Embeddings, Guardrails, Parser, Deployment und Monitoring ^[30]. Architektur senkt die Wechselkosten; Migration Manifest, Evals und Recovery ersetzt sie nicht.

Und eine ehrliche Grenze: Auch die beste Eval-Suite misst nur, was man antizipiert hat. Sie verwandelt den Blindflug in Sicht auf die bekannten Risiken — Schema-Prüfung, Shadow-Vergleich auf echtem Verkehr und laufendes Monitoring existieren genau deshalb, weil kein Golden Set vollständig ist.

Wer dieses Playbook etabliert hat, verhandelt trotzdem anders. Der glaubwürdige Satz „Wir können in vier bis sechs Wochen kontrolliert wechseln“ wirkt überall dort, wo tatsächlich verhandelt wird: bei Vertragsverlängerungen, Enterprise-Vereinbarungen und Volumenrabatten. Wer als kleiner Kunde Listenpreise zahlt, verhandelt nicht — profitiert aber genauso: Wechselfähigkeit heißt, den fallenden Marktpreis ^[6] jederzeit mitnehmen zu können, statt Kosten von gestern zu tragen.

5. Compliance: Der Wechsel ist auch ein Governance-Ereignis

Ein Modellwechsel berührt Datenschutz- und KI-Regulierung, soweit personenbezogene Daten im Spiel sind. Zwei Gates sind zu unterscheiden. Phase-0-Datengate: Schon Auswahl, Speicherung, Wiederverwendung und Annotation personenbezogener Golden-Set-Fälle sind Verarbeitungen. Bevorzugt werden synthetische oder hinreichend anonymisierte Fälle; bei pseudonymisierten Daten bleiben Zweck, Rechtsgrundlage, Datenminimierung, Zugriff, Aufbewahrung und Löschung zu dokumentieren, denn zuordenbare pseudonymisierte Daten bleiben personenbezogen ^[24]. Kandidaten-Gate: Vor jeder Übermittlung personenbezogener Test- oder Shadow-Daten müssen Vertrags- und Transfergrundlage stehen. Dafür ist Vorlauf einzuplanen: AVV, Garantienprüfung und Transferbewertung dauern in der Praxis Wochen, nicht Tage — das Gate gehört deshalb parallel zu Phase 0 gestartet, nicht erst vor Phase 1. Reale, hinreichend anonymisierte Daten lösen keinen AVV allein wegen ihrer Realitätsnähe aus.

Auftragsverarbeitung und Transfer prüfen — vor dem ersten Kandidatentest mit personenbezogenen Daten. Ein neuer KI-Anbieter ist regelmäßig ein neuer Auftragsverarbeiter: Die DSGVO verlangt eine dokumentierte Prüfung seiner Garantien und einen Auftragsverarbeitungsvertrag mit definierten Pflichtinhalten ^[31]. Ersetzt der bisherige Anbieter einen Unterauftragnehmer, greifen Informationspflicht und Widerspruchsrecht ^[31]; tauscht er intern nur das Modell, ist zu prüfen, ob Vertrag und Leistungsbeschreibung den Wechsel abdecken und eine Änderungsmitteilung zugesagt ist. Das Gate dokumentiert Drittlandtransfer, Datenresidenz, Unterauftragnehmer, Löschfristen sowie No-Training- und Zero-Retention-Zusagen. Die deutschen Aufsichtsbehörden stufen Anwendungen als vorzugswürdig ein, die Ein- und Ausgaben nicht zum Training verwenden ^[32].

Die eigene Kundenseite mitdenken. Wer mit der KI Daten seiner Kunden verarbeitet, ist selbst Auftragsverarbeiter — dann ist der Anbieterwechsel aus Kundensicht ein Unterauftragnehmer-Wechsel mit Anzeigepflicht und Widerspruchsrisiko. Und wo KI-Ausgaben Teil der geschuldeten Leistung sind, können eigene Kundenverträge Qualitäts- oder Änderungszusagen enthalten, die ein stiller Wechsel verletzt.

Die Vorgeschichte des Modells zählt — mit Augenmaß. Der Europäische Datenschutzausschuss hält fest, dass Rechtsverstöße beim Training eines Modells auf die Rechtmäßigkeit seines Einsatzes durchschlagen können ^[33]. In der Praxis heißt das: die verfügbare Dokumentation des Anbieters (Model Cards, Transparenzangaben) einholen und die Prüfung dokumentieren — mehr kann ein Kunde großer Anbieter nicht leisten, weniger sollte er nicht tun.

EU AI Act einordnen — prüfen, nicht fürchten. Für die meisten Mittelstandsanwendungen wie interne Assistenz oder Textverarbeitung gelten keine Hochrisiko-Pflichten — wohl aber allgemeine Pflichten wie KI-Kompetenz (Art. 4, in Kraft seit Februar 2025) und Transparenz (Art. 50) ^[34]. Bei einem Hochrisiko-System kann der Modellaustausch eine „wesentliche Änderung“ darstellen und eine neue Konformitätsbewertung auslösen ^[34]. Nach dem im Juni 2026 beschlossenen Digital-Omnibus-Zeitplan greifen die verschobenen Hochrisiko-Pflichten für eigenständige beziehungsweise Annex-III-Systeme ab dem 2. Dezember 2027 und für in Produkte eingebettete Annex-I-Systeme ab dem 2. August 2028 ^[35], ^[36]. Allgemeine Pflichten gelten unabhängig davon. Die Einstufung des eigenen Systems sollte vor dem Wechsel feststehen; bei Beschäftigtendaten oder Leistungskontrolle gehört auch der Betriebsrat frühzeitig an den Tisch.

Dokumentieren. Wer wann welches Modell mit welchem Testergebnis freigegeben hat, gehört schriftlich festgehalten — rechtlicher Anker ist die Rechenschaftspflicht der DSGVO ^[31]. Aufbewahrt wird diese Dokumentation mindestens für die Dauer der Verarbeitung und die laufenden Verjährungsfristen. Bestehende Datenschutz-Folgenabschätzungen, das Verarbeitungsverzeichnis und die Datenschutzhinweise sind beim Wechsel auf Aktualität zu prüfen. Nebeneffekt: Diese Dokumentation ist das Gedächtnis für den nächsten Wechsel.

6. Sofortmaßnahmen: Was Sie diese Woche tun können

1. Output-Vertrag schärfen: Pflichtfelder, Feldnamen, Datums- und Zahlenformate sowie Wertebereiche an der Schnittstelle hart prüfen und nicht konforme Ausgaben abweisen statt durchreichen. Wirkt sofort, modellunabhängig und ohne Eval-Suite.
2. Systeminventar erstellen: Modell-/Deployment-ID, Prompt, Tools, Retrieval, Guardrails, Region, Retention und Monitoring je Prozess erfassen.
3. Abschaltdaten notieren: Anbieter- und modellklassenspezifische Retirement Dates mit ausreichendem Vorlauf in den Kalender legen.
4. Migration Manifest versionieren: Immutable Versionen nutzen; Alias-Semantik und Restrisiko dokumentieren.
5. Golden Set sicher starten: 50–100 Fälle als Einstieg, bevorzugt synthetisch oder anonymisiert; pseudonymisierte Fälle nur nach Phase-0-Datengate.
6. Abnahmematrix festlegen: Fehlerkosten, Margen, Wiederholungen, kritische Segmente und Stoppregeln vor Sichtung des Kandidaten definieren.
7. Security-Testpaket ergänzen: Prompt Injection, Disclosure, Tool-/Berechtigungsgrenzen und Refusal-/Moderationsregressionen testen.
8. Rollback und Recovery proben: Altes Manifest reaktivieren und Kompensationspfad für irreversible Seiteneffekte durchspielen.
9. RACI und Compliance-Gates benennen: Fach-, IT-, Security-, Datenschutz-/Legal- und Risk-Owner-Rollen samt Stopprecht festlegen; AVV/Transfer vor externer Übermittlung prüfen.

Wer diese neun Punkte umsetzt, hat die Grundlage gelegt. Der nächste Modellwechsel ist dann eine versionierte Systemänderung mit nachvollziehbarer Freigabe, begrenzter Exposition und vorbereitetem Recovery.

Quellen