Niemand hat etwas geändert, außer dem Anbieter

Unternehmens-KI läuft auf Modellen, die ihre Anbieter ohne Vorwarnung austauschen. Wer keine eigene Prüfsuite betreibt, bemerkt die Verschiebung erst an den Beschwerden aus der Fachabteilung.

Eine Betrachtung des laufenden Betriebs, also der Phase, in der die meisten KI-Projektpläne bereits enden.

Von Silvio Kleesattel, AI Collaboration Architect bei Skaylink und Absolvent der MIT AI Executive Academy, und Helmut Weiss, Cloud Architect bei Skaylink.

Ein Fertigungsbetrieb lässt eingehende Auftragsbestätigungen von einem Sprachmodell auslesen und in ein strukturiertes Format übergeben, das die Warenwirtschaft weiterverarbeitet. Elf Monate läuft das unauffällig. Dann bricht die Weiterverarbeitung ab, weil das Modell seiner Ausgabe plötzlich einen erklärenden Satz voranstellt. Im Unternehmen hatte niemand etwas geändert, die Prompts und Konfigurationen sind die gleichen wie vorher. Verändert hatte sich das Modell hinter der Schnittstelle. Ausgerechnet in diesem Fall trifft der Verdacht gegen das Modell zur Abwechslung zu, und ausgerechnet auf diesen Fall sind die wenigsten Unternehmen vorbereitet.

Der Zulieferer ändert das Bauteil

Wer ein gehostetes Modell nutzt, bezieht eine Komponente, deren Innenleben der Lieferant jederzeit anpassen darf. Aus der klassischen Softwarebeschaffung ist dieser Gedanke vertraut, dort regeln Versionsnummern und Release Notes, was sich wann geändert hat. Bei Sprachmodell-Diensten fällt beides dünner aus. Ein unveränderter Modellname garantiert nicht, dass darunter dieselben Gewichte (sog. Model Weights) liegen.

Wie deutlich solche Verschiebungen ausfallen können, hat ein Team um Lingjiao Chen in der Harvard Data Science Review dokumentiert. Zwischen der März- und der Junifassung von GPT-4 aus dem Jahr 2023 fiel die Trefferquote bei einer Aufgabe zur Primzahlerkennung von 84 auf 51 Prozent, während andere Fähigkeiten im selben Zeitraum zulegten. Die Deutung dieser Zahl war in der Fachdiskussion umstritten, weil der Einbruch teilweise auf ein verändertes Antwortverhalten und auf die Konstruktion der Testfälle zurückgeführt wurde statt auf verlorene Rechenfähigkeit. Für den Betrieb ist dieser Einwand ein schwacher Trost. Ob eine Anwendung an schlechteren oder an anders formatierten Antworten scheitert, spielt für die Kollegin in der Fachabteilung keine Rolle. Aus unserer Projektarbeit ist das Muster jedenfalls nicht verschwunden, es zeigt sich heute nur seltener an Rechenaufgaben und häufiger im Hinblick auf Ausführlichkeit und Verweigerungsverhalten.

Von der bekannten Streuung einzelner Antworten ist das zu unterscheiden. Die entsteht bei jedem Aufruf neu und lässt sich statistisch einhegen. Ein Versionswechsel dagegen verschiebt das Verhalten dauerhaft und in eine Richtung, was ihn zwar unangenehmer, gleichzeitig aber erheblich leichter messbar macht.

Versionsbindung kauft Zeit

Der Griff zur festen, datierten Modellversion drängt sich auf. Doch diese Sicherheit stellt sich nicht von allein ein, und sie hält nicht lange. Wer bei Azure OpenAI ein Standard-Deployment anlegt und nichts weiter einstellt, erhält eine Upgrade-Regel, die die Version früher oder später automatisch weiterzieht. Eingefroren ist sie erst, wenn die Upgrade-Option ausdrücklich auf NoAutoUpgrade steht. Weil datierte Snapshots nach einer Ankündigungsfrist von mindestens 60 Tagen bei allgemein verfügbaren Modellen unweigerlich wieder aus dem Angebot verschwinden, unterliegt die Entscheidung für ein Modell faktisch den Bedingungen eines Mietvertrags mit einseitigem Kündigungsrecht auf Seiten des Anbieters. Damit erfordert der unausweichliche Modellwechsel als wiederkehrende Konstante in der IT-Planung kontinuierlich eigene Ressourcen.

Im eigenen Haus stellt sich die Lage anders dar. Die Gewichtsdatei ändert sich nicht, solange man sie nicht selbst ersetzt. Bit-identische Antworten garantiert das noch nicht, denn Sampling und Batching wirken ebenso weiter mit wie die Version des Inferenz-Stacks. Gewonnen ist damit die Hoheit über den Zeitpunkt jeder Änderung.
Bezahlt wird diese Gewissheit mit Hardware, Betriebsaufwand und dem Verzicht auf die cutting edge der KI-Entwicklung. Für einen abgegrenzten, unternehmenskritischen Ablauf mit klarer Aufgabe kann sich die Rechnung lohnen, für einen Assistenten in der Breite meist nicht. Beide Wege lassen sich kombinieren, und in der Praxis ist die Mischform gelebte Realität.

Was ein eigenes Testset leistet

Eine Prüfsuite entsteht nicht aus öffentlichen Benchmarks, sondern aus dem eigenen Verkehr. 50 bis 150 echte Fälle, jeder mit einer vom Fachbereich bestätigten Soll-Antwort, genügen für den Anfang und sind in wenigen Tagen zusammengetragen. Prüfbar ist dabei mehr, als viele annehmen. Enthält eine Antwort eine Zahl oder eine Kennung, lässt sie sich exakt vergleichen. Wird ein bestimmtes Format erwartet, prüft ein Schema-Test es maschinell und ohne Ermessensspielraum. Nur wo es auf Bedeutung statt auf Wortlaut ankommt, braucht es eine weichere Bewertung, etwa ein zweites Modell als Prüfer, dessen Urteil stichprobenweise von Menschen kontrolliert wird.

Sinnvoll ist der Durchlauf vor jeder Änderung auf der eigenen Seite und zusätzlich in festem Takt, auch wenn niemand etwas angefasst hat. Der zweite Fall ist der wichtigere. Er ist der einzige, der eine stille Änderung beim Anbieter überhaupt sichtbar macht, und er kostet als nächtlicher Lauf gegen hundert Fälle so wenig, dass die Diskussion darüber teurer ist als die eigentliche Umsetzung. Beim späteren Wechsel zahlt sich dieselbe Suite ein zweites Mal aus, weil ein Kandidatenmodell gegen dieselben Fälle läuft und die Entscheidungsgrundlage aus harten Fakten und Tabellen besteht. Den Ausschlag gibt in der Praxis allerdings ein zweiter Schritt. Das Kandidatenmodell läuft einige Tage parallel auf echtem Verkehr mit, ohne dass seine Antworten nach außen wirken. Erst dieser Schattenbetrieb bringt die Fälle ans Licht, an die bei der Zusammenstellung der Prüfsuite niemand gedacht hat.

Beschwerden sind ein spätes Signal

Neben der Prüfsuite braucht der Betrieb wenige laufende Kennzahlen, die auf Verhaltensänderungen reagieren, bevor Nutzer sich melden. Die Quote formal gültiger Antworten gehört dazu, ebenso der Anteil der Fälle, in denen das Modell eine Auskunft verweigert. Die Verteilung der Antwortlängen ist ein unscheinbarer, aber brauchbarer Frühindikator. Verschiebt sich ihr Mittel über Nacht deutlich, ohne dass sich die Fragen geändert hätten, hat sich mit hoher Wahrscheinlichkeit unter der Schnittstelle etwas bewegt. Noch früher schlagen Latenz und Ausgabe-Tokens pro Anfrage aus. Beide Werte fallen im Betrieb ohnehin an und verschieben sich bei einem stillen Modelltausch häufig, bevor eine inhaltliche Kennzahl überhaupt reagiert. Diese Unterscheidung muss sofort vollzogen werden, sonst hat die Fachabteilung sehr schnell das Vertrauen in ihr Werkzeug verloren; ein solcher Schaden wiegt deutlich schwerer als eine kurzfristige Downtime während eines Modellwechsels.

Die Frist ist verschoben, das Problem nicht

Regulatorisch hat sich der Zeitplan im Sommer verändert. Mit der Verordnung (EU) 2026/1744, seit dem 27. Juli 2026 in Kraft, verschieben sich die Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III auf den 2. Dezember 2027. Andere Teile der KI-Verordnung, darunter die Transparenzpflichten nach Artikel 50, sind wie geplant am 2. August 2026 wirksam geworden. Der Aufschub verschafft Zeit für den Aufbau von Risikomanagement und Konformitätsbewertung samt der zugehörigen Dokumentation. Weg ist keine dieser Pflichten.

Dabei greift der eigentliche Zusammenhang unabhängig von jeder Frist. Wer später darlegen muss, wie eine Auskunft oder eine Vorsortierung zustande kam, braucht eine Protokollierung, die zu jeder Antwort festhält, welches Modell tatsächlich geantwortet hat. Der Modellname allein genügt dafür nicht, weil er bei einer stillen Verschiebung gerade unverändert bleibt. Aussagekraft hat erst die vom Anbieter zurückgegebene konkrete Version, bei OpenAI und Azure OpenAI der system_fingerprint. Fehlt dieses Feld, endet die Rekonstruktion an der Stelle, an der der Anbieter im Hintergrund gewechselt hat, und niemand kann mehr sagen, ob eine strittige Entscheidung aus dem März überhaupt vom selben System stammt wie die Vergleichsfälle aus dem Juni. Nachträglich lässt sich das nicht herstellen. Ein Feld in der Protokollzeile kostet dagegen eine Stunde Entwicklungszeit. Als Prüfraster für die Anbindung externer Modelle taugt im Übrigen der Kriterienkatalog, den das BSI im Juni 2025 vorgelegt hat, ausdrücklich als unverbindliche Vorstufe zu einem künftigen Mindeststandard. Geschrieben ist er für die Bundesverwaltung, verwendbar auch von jedem Mittelständler, der seinem Dienstleister präzisere Fragen stellen will.

In unseren Projekten gehört die Prüfsuite deshalb zur Abnahme, gemeinsam mit der Versionsprotokollierung, und zwar vor dem Produktivstart und nicht als Nachtrag im zweiten Quartal des Folgejahres. Im Budget steht außerdem ein Posten für einen Modellwechsel pro Jahr, obwohl bei der Planung noch keinerlei Prognosen über Spezifika gemacht werden können. Gebraucht wurde er bisher trotzdem jedes Mal.