Modelldrift erkennen: warum KI-Modelle nachlassen und was dagegen hilft
Modelldrift erkennen heißt, rechtzeitig zu bemerken, dass ein KI-Modell schlechter wird, weil sich die Eingangsdaten oder die Zusammenhänge dahinter verändert haben. Erkennbar ist das an sinkender Trefferquote, häufigeren Korrekturen durch Fachleute und verschobenen Datenmustern. Dagegen helfen laufende Überwachung, geplantes Nachtraining und eine benannte Betriebsverantwortung.
Für Entscheider in Kürze
- Risiko: Modelle verschlechtern sich über die Zeit. Wer keine Betriebsverantwortung definiert, verliert den Nutzen nach etwa zwölf Monaten wieder (Branchenreport, Kapitel 08 und 12).
- Aufwand: Überwachung, regelmäßiges Nachschärfen, eine Entscheidung über Abschaltung und eine saubere Dokumentation. Das ist laufende Arbeit, kein einmaliger Projektschritt.
- Kosten: Der Betrieb gehört als eigener Posten in den Business Case, bevor der Pilot startet. Fehlende Zeit nennen 66 % der Unternehmen als Hemmnis für KI und Digitalisierung (Bitkom 2026).
- Zuständigkeit: In unserer Auswertung von 52 veröffentlichten Praktikergesprächen (September 2025 bis August 2026) wird fast nie darüber gesprochen, wer ein Modell betreibt und wie der Betrieb abgesichert wird.
Was Modelldrift ist
Ein KI-Modell lernt Muster aus historischen Daten. Es geht stillschweigend davon aus, dass die Welt, in der es später arbeitet, dieser Vergangenheit ähnelt. Genau diese Annahme hält in der Fertigung selten lange. Maschinen werden umgerüstet, Sortimente wechseln, Lieferanten ändern sich, Prüfvorschriften werden angepasst. Modelldrift ist der Oberbegriff für den schleichenden Qualitätsverlust, der daraus entsteht. Fachlich werden zwei Formen unterschieden.
| Form | Was sich verändert | Beispiel aus der Fertigung |
|---|---|---|
| Datendrift (data drift) | Die Verteilung der Eingangsdaten | Ein neuer Sensor misst mit anderem Nullpunkt, eine neue Produktvariante läuft über die Linie |
| Konzeptdrift (concept drift) | Der Zusammenhang zwischen Eingangsdaten und Ergebnis | Nach einem Umbau bedeutet dasselbe Schwingungsmuster etwas anderes, Nachfrage reagiert anders auf Saison |
| Technischer Bruch | Die Datenzufuhr selbst | Ein Feld im ERP wird umbenannt, eine Schnittstelle liefert leere Werte |
Datendrift ist oft messbar, bevor die Ergebnisse leiden, weil sich die Eingangsdaten statistisch vergleichen lassen. Konzeptdrift zeigt sich meist erst an den Ergebnissen, denn die Eingangsdaten sehen unauffällig aus. Der technische Bruch ist streng genommen keine Drift, erzeugt aber dieselben Symptome und gehört deshalb in dieselbe Überwachung.
Warum Modelle über die Zeit nachlassen
Der Branchenreport, den wir gemeinsam mit Alic.ai herausgegeben haben, nennt den Mechanismus bei mehreren Anwendungsfeldern. Bei Predictive Maintenance führt er fehlende Zeit für die Modellnachschärfung ausdrücklich als Fallstrick auf: Precision und Recall verschlechtern sich sonst über die Zeit. Precision beschreibt, wie viele Alarme tatsächlich berechtigt sind. Recall beschreibt, wie viele echte Ausfälle das Modell überhaupt erkennt. Sinkt die erste Größe, ertrinkt die Instandhaltung in Fehlalarmen. Sinkt die zweite, fällt die Anlage trotz Modell ungeplant aus. Wie wir Prognosemodelle für Stillstände und Ersatzteilbedarf betreiben, zeigt die Seite zur Prognoseplattform Orpheon.
Auch in den anderen Feldern taucht das Muster auf. In der Qualitätsprüfung muss zurückfließen, was die Endkontrolle korrigiert, sonst lernt das Modell nie dazu. Bei Wissensassistenten braucht es eine Pflegeroutine, damit veraltete Dokumente nicht dauerhaft mitantworten. In der Bedarfsplanung verzeiht kein anderes Feld schlechte Stammdaten so wenig, und gepflegte Wunschwerte bei Wiederbeschaffungszeiten verzerren jede Prognose.
Hinzu kommt ein organisatorischer Grund. Nach Projektabschluss wird das Projektteam aufgelöst, die Verantwortung wandert formal in die IT, die das Modell nicht im Detail kennt. Drift kann am ersten Tag beginnen, bemerkt wird sie oft erst Monate später.
Woran Sie Modelldrift erkennen
Modelldrift erkennen Sie selten an einem einzelnen Ereignis, sondern an Trends. Die folgende Tabelle ordnet typische Signale ihren häufigsten Ursachen und passenden Gegenmaßnahmen zu.
| Signal | Mögliche Ursache | Gegenmaßnahme |
|---|---|---|
| Mehr Fehlalarme in der Instandhaltung | Neue Betriebsweise, Retrofit, getauschter Sensor | Eingangsdaten prüfen, mit aktuellen Daten nachtrainieren |
| Echte Ausfälle werden übersehen | Neue Fehlerbilder, verändertes Verschleißverhalten | Ausfälle nachträglich erfassen, Modell nachschärfen |
| Endkontrolle korrigiert die KI-Prüfung häufiger | Neue Produktvariante, veränderte Beleuchtung oder Optik | Korrekturen ins Training zurückführen, Prüfstation prüfen |
| Prognose weicht wiederholt in dieselbe Richtung ab | Sortimentswechsel, Aktionen, veränderte Wiederbeschaffungszeiten | Ursache klären, erklärende Größen ergänzen, nachtrainieren |
| Assistent antwortet mit veralteten Angaben | Dokumente nicht gepflegt, alte Fassungen im Bestand | Pflegeroutine einführen, veraltete Dokumente entfernen |
| Mehr Vorgänge gehen an Menschen zurück | Veränderte Eingangsdokumente oder Formate | Teilschritt vorübergehend zurück in den betreuten Modus |
| Werte fehlen oder springen plötzlich | Geändertes Datenfeld, gestörte Schnittstelle | Plausibilitätsprüfung in der Datenzufuhr, Alarm an den Betrieb |
Damit diese Signale überhaupt auffallen, braucht es einen Vergleichsmaßstab. Der Branchenreport empfiehlt, den Referenzwert vor dem Pilot zu fixieren, also etwa ungeplante Stillstandsminuten, Bearbeitungszeit je Vorgang oder Ausschussquote. Ohne diese Baseline lässt sich später weder der Erfolg belegen noch ein Qualitätsverlust nachweisen.
Praktisch bewährt hat sich eine Überwachung der Modellgüte auf drei Ebenen. Auf der Datenebene wird geprüft, ob sich die Verteilung der Eingangsdaten verschiebt. Auf der Ergebnisebene wird die Trefferquote regelmäßig gegen die tatsächliche Entwicklung gemessen. Auf der Nutzungsebene zählt, wie oft Fachleute Ergebnisse korrigieren oder übergehen. Die dritte Ebene ist die günstigste und wird am häufigsten vergessen.
Was ein geregelter Betrieb dagegen tut
Der Fahrplan im Branchenreport fasst die Betriebsfrage in drei Teilfragen: Wer überwacht die Modellgüte, wer trainiert nach, wer entscheidet über die Abschaltung. Dazu kommt die Dokumentation, die alle drei Schritte nachvollziehbar macht.
- Überwachung: Qualität und Verfügbarkeit werden laufend beobachtet und regelmäßig berichtet, nicht erst bei einer Auffälligkeit.
- Nachtraining: Ein Modell wird nachgeschärft oder ausgetauscht, wenn neue Daten oder veränderte Muster das erfordern. Ein neues Modell geht erst nach einer Testphase in Betrieb, gemessen an Ihren eigenen Anforderungen.
- Abschaltentscheidung: Liegt die Qualität unter dem Referenzwert, übernimmt wieder der manuelle Prozess. Dieser Rückfall wird vorab festgelegt, nicht im Ernstfall improvisiert.
- Dokumentation: Modellstände, Trainingsdaten und Änderungen werden festgehalten, sodass sich später prüfen lässt, welcher Stand zu welchem Ergebnis geführt hat.
So arbeiten wir auch selbst: Weicht eine Prognose wiederholt von der tatsächlichen Entwicklung ab, prüfen wir die Ursache und passen Modell oder Daten an, statt eine einmal trainierte Version unverändert weiterlaufen zu lassen. Wie wir Überwachung, Modellpflege, Kostenkontrolle und Regulatorik im Alltag übernehmen, beschreibt die Seite zu KI-Betrieb als Managed Service.
Verfügbarkeit ist nicht Modellgüte
Ein häufiges Missverständnis betrifft die Verfügbarkeit. Wir arbeiten mit einem generellen Betriebsziel von 99,9 % Verfügbarkeit über unsere betreuten Systeme hinweg. Diese Zahl sagt aus, dass ein System erreichbar ist. Sie sagt nichts darüber, ob seine Ergebnisse noch stimmen. Ein Modell mit starker Drift kann rund um die Uhr verfügbar sein und trotzdem falsche Empfehlungen geben.
Klären Sie deshalb in jedem Betriebsvertrag zwei getrennte Fragen: wie schnell auf einen Ausfall reagiert wird und wie ein Qualitätsverlust eingestuft und behandelt wird. Wie Schweregrade, Reaktionszeiten und Eskalationswege bei uns geregelt sind, zeigt die Seite zum SLA für KI-Systeme.
Modelldrift und der Weg aus dem Pilot
Nur 20 % der KI-Anwendungsfälle in der Fertigung sind unternehmensweit skaliert (Deloitte 2026, Beratungsstudie). Ein Grund dafür ist, dass Piloten auf einen Zeitpunkt hin gebaut werden, Betrieb aber auf Dauer angelegt ist. Wer Modelldrift nicht von Anfang an einplant, erlebt nach einigen Monaten eine sinkende Qualität, verliert das Vertrauen der Fachabteilung und damit das Argument für die Skalierung. Warum so viele Vorhaben an dieser Stelle hängen bleiben, beschreibt unser Beitrag KI-Piloten skalieren.
Für Systeme, die unter die Hochrisiko-Regeln des AI Act fallen, kommen nach unserer Lesart zusätzliche Pflichten hinzu, für eigenständige Systeme ab 02.12.2027 (Annex III), für KI in regulierten Produkten wie Maschinen ab 02.08.2028 (Annex I). Eine lückenlose Dokumentation von Modellständen und Trainingsläufen erleichtert diese Nachweise. Die konkrete Einstufung eines Systems gehört juristisch geprüft.
Häufige Fragen
Wie oft muss ein Modell nachtrainiert werden?
Ein festes Intervall gibt es nicht. Sinnvoll ist ein erneutes Training, sobald die Überwachung eine Verschiebung der Daten oder eine sinkende Trefferquote zeigt, ergänzt um eine regelmäßige Überprüfung. Stabile Prozesse brauchen es seltener als Bereiche mit häufigen Produktwechseln.
Ist Modelldrift ein Fehler des Anbieters?
Nein, Drift ist bei jedem lernenden System zu erwarten. Ein Mangel ist es erst, wenn niemand sie überwacht und niemand für das erneute Training zuständig ist. Diese Zuständigkeit sollte vor dem Rollout vertraglich geregelt sein.
Betrifft Modelldrift auch Sprachmodelle?
Ja, allerdings anders. Die Gewichte eines Sprachmodells ändern sich im eigenen Betrieb nicht von selbst, wohl aber die Dokumente, auf die es zugreift, und die Fragen, die gestellt werden. Hinzu kommt: Wird ein extern bereitgestelltes Modell vom Anbieter aktualisiert, kann sich sein Verhalten ändern, ohne dass Sie es beeinflussen.
Wann sollte ein Modell abgeschaltet werden?
Wenn seine Ergebnisse dauerhaft schlechter sind als der Referenzwert oder als der manuelle Prozess. Legen Sie diese Grenze und den Rückfall auf den manuellen Ablauf vor dem Rollout fest.
