Klassischer Programmcode verhält sich vorhersehbar: Wer den Quellcode nicht ändert, bekommt dasselbe Ergebnis. Bei KI-Systemen gilt das nicht. Sprachmodelle werden von Anbietern regelmäßig im Hintergrund aktualisiert. Dasselbe Modell kann nach einem Update andere Antworten liefern — ohne dass eine Fehlermeldung erscheint.
Dieses Phänomen nennt sich Modelldrift. Dieser Beitrag erklärt, wie es entsteht und wie Unternehmen es erkennen können, bevor es Schaden anrichtet.
Das Problem: Unsichtbare Veränderungen
„Klassischer Code verhält sich stabil, solange niemand ihn ändert. KI-Systeme können sich verändern, ohne dass jemand die Pipeline anfasst."
Ein KI-Agent produziert strukturierte Ausgaben — zum Beispiel eine Anweisung wie „Lieferung freigeben" oder „Eskalation erforderlich". Das nachfolgende System, das diese Ausgabe verarbeitet, erwartet ein bestimmtes Format. Liefert das Modell nach einem Update statt eines klaren Status einen erklärenden Fließtext, schlägt die Weiterverarbeitung fehl.
Besonders tückisch: Es gibt oft keine Fehlermeldung. Das System empfängt eine Antwort, kann sie nur nicht auswerten. Der betroffene Geschäftsfall bleibt unbearbeitet — und niemand bemerkt es sofort.
Die Lösung: Qualitätssicherung für KI-Pipelines
Das Gegenmittel kommt aus der Softwareentwicklung: systematische Tests vor jeder Änderung. Auf KI-Systeme übertragen bedeutet das drei Bestandteile:
Testdatensatz: Eine Sammlung von 100 bis 200 repräsentativen, anonymisierten Fällen mit bekanntem Ergebnis. Für einen Garantieprozess wären das: dieser Eingang, diese erwartete Entscheidung.
Automatisierte Prüfung: Bei jeder Änderung — neuem Modell, geändertem Prompt, neuer Konfiguration — durchläuft der Testdatensatz automatisch die Pipeline. Ergebnisse werden mit den erwarteten Ausgaben verglichen.
Zwei Prüfebenen: Zuerst wird geprüft, ob die Ausgabe das richtige Format hat. Dann wird inhaltlich geprüft, ob die Entscheidung korrekt ist. Erst wenn beide Prüfungen bestanden sind, geht eine Änderung in Produktion.
Praxis: Der Smart-Hub-Fall nach einem Modellupdate
In Blog 04 hat der Agent den Garantiefall Markus Meier korrekt beendet: Er erkannte, dass eine Geschäftsregel greift — die Freigabe des Regionalleiters steht aus — und eskalierte entsprechend. Das funktionierte, weil das Modell eine klar strukturierte, eindeutige Statusmeldung lieferte.
Nach einem Modellupdate verändert sich das Verhalten: Das Modell liefert dieselbe Information nun als freundlich formulierten Erklärungstext statt als strukturierten Status. Die Überwachungsschicht des Agenten erwartet den klaren Status — und findet ihn nicht. Der Fall Markus Meier bleibt unbearbeitet. Kein Fehler erscheint, keine Meldung — der Prozess kommt still zum Stillstand.
Ein automatisierter Test mit dem Testdatensatz hätte diese Abweichung vor dem Produktivgang erkannt.
Zwischenfazit
Fünf der sieben Konzepte dieser Serie sind beschrieben: Strukturierte Ausgaben (Blog 02), gezielte Informationsauswahl (Blog 03), Kontrolle autonomer Ausführung (Blog 04), Datenschutz durch Architektur (Blog 05) und systematische Qualitätssicherung (Blog 06).
Blog 07 behandelt die organisatorische Seite: Wer hat welche Berechtigungen — und wer trägt die Verantwortung, wenn ein Agent handelt?
Der Prompt ist erst der Anfang. Die Architektur ist das Ziel.