Deployment ist nicht die Ziellinie. Es ist der Punkt, an dem die eigentliche operative Herausforderung beginnt. Die meisten KI-Projekte im Mittelstand werden so geplant, als wäre das Live-Schalten der Abschluss — danach wandert das Modell aus dem Projektbudget in den Betrieb, wo sich niemand mehr explizit dafür zuständig fühlt. Genau dort beginnt das stille Versagen.
KI-Modelle degradieren, und zwar lautlos. Eingabeverteilungen verschieben sich, Geschäftsprozesse ändern sich, vorgelagerte Datenquellen entwickeln sich weiter, und die Welt, auf die das Modell trainiert wurde, driftet weg von der Welt, in der es operiert. Das Tückische daran: Ein degradierendes Modell wirft keine Fehlermeldung. Es liefert weiter plausibel aussehende Outputs — nur sind sie zunehmend falsch. Ohne Monitoring bemerkt das niemand, bis ein Geschäftsergebnis einbricht und die Ursachensuche bei Null beginnt.
Für regulierte und sicherheitskritische Anwendungen ist genau dieses Nachschauen seit dem EU AI Act keine Kür mehr, sondern Pflicht. Artikel 72 verlangt von Anbietern von Hochrisiko-KI-Systemen, Performance-Daten über die gesamte Lebensdauer hinweg „aktiv und systematisch" zu erfassen, zu dokumentieren und zu analysieren — auf Basis eines formalen Post-Market-Monitoring-Plans, der Teil der technischen Dokumentation ist. Die EU-Kommission stellt bis zum 2. Februar 2026 ein Template für diesen Plan bereit; die Kernpflichten für Hochrisiko-Systeme nach Anhang III greifen ab dem 2. August 2026. Compliance wandert damit von einem einmaligen Vor-Markt-Akt zu einer fortlaufenden operativen Disziplin. Wer ohnehin Modelle in Produktion betreibt, sollte das Lifecycle-Management nicht als Regulierungslast verstehen, sondern als das, was es technisch immer schon hätte sein müssen.
Die vier Arten von Drift
Data Drift tritt auf, wenn sich die Verteilung der Eingabedaten ändert. Ein Kundenklassifikationsmodell, das auf historischem Kaufverhalten trainiert wurde, trifft auf eine veränderte Nachfragestruktur nach einem Preisschock. Ein Betrugserkennungsmodell, das auf Transaktionsmuster stabiler Märkte kalibriert wurde, trifft auf volatile Bedingungen. Die Eingaben sehen anders aus als das, was das Modell gelernt hat, und die Vorhersagen verlieren ihre Kalibrierung — obwohl das Modell selbst unverändert ist.
Concept Drift tritt auf, wenn sich die Beziehung zwischen Eingaben und korrekten Ausgaben ändert. Ein Lead-Scoring-Modell, das trainiert wurde, als der Vertriebszyklus 30 Tage dauerte, wird fehlerhaft, wenn sich der Zyklus marktbedingt auf 60 Tage verlängert. Die Eingaben mögen ähnlich aussehen, aber ihre Bedeutung hat sich verschoben. Concept Drift ist die heimtückischste Variante, weil die Daten-Monitoring-Metriken sie nicht zwingend anzeigen — die Verteilung der Eingaben kann stabil bleiben, während die Antwort, die richtig wäre, eine andere geworden ist.
Feature Drift tritt auf, wenn vorgelagerte Datenquellen Format, Verfügbarkeit oder Qualität ändern. Ein Produktionsqualitätsmodell verliert plötzlich den Zugriff auf einen Sensor-Feed. Ein Kundenmodell stellt fest, dass ein zentrales CRM-Feld umdefiniert wurde, weil der Vertrieb es im laufenden Betrieb für etwas anderes nutzt. Die Pipeline liefert andere Daten als das Modell erwartet — und niemand hat es dem Modell gesagt.
Model Drift im LLM-Kontext tritt auf, wenn sich das Verhalten API-basierter Modelle durch Provider-Updates ändert. Diese Form ist für API-Konsumenten die frustrierendste, weil sie außerhalb der eigenen Kontrolle liegt. Sie hat eine konkrete Dimension, die der Mittelstand 2026 hart spürt: Anbieter ziehen Modellversionen aus dem Verkehr. OpenAI etwa hat angekündigt, gpt-4o über die API im Februar 2026 zu retiren — danach laufen ungenutzte Integrationen entweder auf eine Nachfolgeversion mit verändertem Verhalten oder in einen Fehler. Wer Prompts gegen einen undatierten Modell-Alias laufen lässt, hat keine stabile Grundlage. Die einzige belastbare Antwort ist, gegen datierte Modell-Snapshots zu pinnen und jeden Wechsel als bewusstes, getestetes Deployment zu behandeln — nicht als etwas, das über Nacht passiert.
Das Monitoring-System
Effektives Lifecycle-Management erfordert Monitoring auf drei Ebenen. Keine davon allein genügt.
Performance-Monitoring. Verfolgen Sie die Metriken, die für Ihren konkreten Use Case relevant sind — Accuracy, Precision, Recall, Latenz, Kosten pro Aufgabe — gegen die bei Deployment etablierte Baseline. Der entscheidende Fehler, den die meisten Teams machen, ist, nur technische Metriken zu messen. Wenn das Modell Kundentickets klassifiziert, messen Sie Lösungszeit und Eskalationsrate, nicht nur die Klassifikationsgenauigkeit. Ein Modell kann seine technische Accuracy halten und trotzdem das Geschäftsergebnis verschlechtern, wenn sich die Fehlerverteilung in genau die Fälle verschiebt, die teuer sind.
Daten-Monitoring. Verfolgen Sie Eingabeverteilungen mit statistischen Distanzmetriken — Population Stability Index (PSI), Kolmogorov-Smirnov-Test oder Jensen-Shannon-Divergenz. Diese erkennen, wenn sich Eingaben verschieben, bevor die Performance-Auswirkung im Geschäftsergebnis sichtbar wird. Der PSI ist dafür die pragmatische Arbeitsmetrik: interpretierbar und in jeder Data-Stack üblich. Als gängige Faustregel gelten Werte über 0,1 als beobachtungswürdig und Werte über 0,25 als untersuchungsbedürftig. Open-Source-Bibliotheken wie Evidently AI implementieren diese Tests direkt und lassen sich ohne große Plattform in bestehende Pipelines einhängen.
Output-Monitoring. Für generative KI-Systeme greifen klassische Accuracy-Metriken nicht — es gibt keine einzelne richtige Antwort. Verfolgen Sie die Output-Qualität daher über eine Kombination aus stichprobenbasierter menschlicher Bewertung, automatisierten Konsistenzprüfungen und LLM-as-Judge-Mustern gegen ein festes Bewertungsraster. Ein praktikabler Frühindikator ist, die semantische Ähnlichkeit der Outputs zu einem stabilen Referenzlauf über die Zeit zu beobachten: Springt die Verteilung der Antworten plötzlich, ohne dass sich Ihr Prompt oder Ihre Daten geändert haben, ist das ein starkes Signal für eine Modell- oder Provider-Änderung — genau die Form von Model Drift, die sonst niemand bemerkt.
Das Versionierungs-Protokoll
Jede Komponente im KI-System braucht Versionskontrolle — nicht nur das Modell.
Modellversionen. Taggen Sie jede deployte Modellversion mit ihrem Trainingsdaten-Snapshot, Hyperparametern und Evaluierungsmetriken. Bei Performance-Degradation müssen Sie die aktuelle Version mit früheren vergleichen können, um festzustellen, ob das Problem am Modell oder an den Daten liegt.
Prompt-Versionen. Für LLM-basierte Systeme sind Prompts Code. Versionieren Sie sie in Git. Verfolgen Sie, welche Prompt-Version in welcher Umgebung deployed ist. Wenn sich Outputs ändern, spart die Fähigkeit, die Prompt-Historie zu differn, Tage an Debugging.
Pipeline-Versionen. Datenvorverarbeitung, Feature-Engineering, Retrieval-Konfiguration und Nachverarbeitungslogik beeinflussen die Outputs ebenso stark wie das Modell selbst. Eine geänderte Chunking-Strategie oder ein anderer Retrieval-Parameter kann das Systemverhalten spürbarer verschieben als ein Modellwechsel — und wird trotzdem regelmäßig nirgends festgehalten.
Daten-Snapshots. Halten Sie Snapshots von Trainings-, Evaluierungs- und Referenzdaten bei jedem Deployment vor. Wenn Drift erkannt wird, ist der Abgleich aktueller Eingaben mit der Trainingsverteilung der schnellste Weg zur Diagnose. Ohne diesen Referenzpunkt debuggen Sie blind.
Der gemeinsame Nenner: Wenn sich ein Output ändert, müssen Sie in Minuten beantworten können, welche der vier Komponenten sich bewegt hat. Ohne durchgängige Versionierung verbringen Teams Tage mit dieser Frage — meist unter Zeitdruck, weil bereits ein Geschäftsergebnis betroffen ist.
Die Retraining-Entscheidung
Drift-Erkennung ist nur wertvoll, wenn sie Handlung auslöst. Wer Trigger nicht im Voraus definiert, diskutiert sie im Krisenmodus aus — und entscheidet dann schlecht.
Schwellenwert-basierte Trigger. Wenn die Accuracy unter einen definierten Wert fällt — etwa einige Prozentpunkte unter der Baseline —, initiieren Sie einen Retraining-Zyklus. Das setzt kontinuierliche Messung gegen ein aktuelles Golden Test Set voraus; ohne dieses Set ist der Schwellenwert eine Fiktion.
Zeitplan-basierte Trigger. Für Use Cases mit vorhersehbarem Drift — Modelle entlang von Quartalszyklen, Retail mit saisonalen Mustern — planen Sie Retraining in bekannten Intervallen, statt auf das Signal zu warten.
Event-basierte Trigger. Wesentliche Geschäftsveränderungen — Produktlaunches, regulatorische Änderungen, M&A, Marktverschiebungen, aber auch eine angekündigte Modell-Retirement beim Provider — invalidieren Modellannahmen. Diese lösen eine Evaluierung unabhängig vom gemessenen Drift aus.
In der Praxis bewährt sich eine gestufte Reaktion: geringfügiger Drift erhöht die Monitoring-Frequenz, moderater Drift löst eine Evaluierung gegen ein frisches Testset aus, und signifikanter Drift löst Retraining oder Modellersatz aus. Nicht jeder Drift verlangt ein teures Retraining — die Kunst liegt darin, früh genug zu sehen und dann verhältnismäßig zu reagieren.
Das Minimum-Viable-Lifecycle
Der häufigste Einwand im Mittelstand lautet, das sei alles eine Nummer zu groß. Ist es nicht. Für ein Haus, das drei bis zehn KI-Workflows betreibt, reicht ein bewusst schlankes System: wöchentliche Accuracy-Messungen gegen ein Golden Test Set von 50 bis 100 Beispielen, das quartalsweise aktualisiert wird; monatliche Verteilungsprüfungen mit PSI auf den zentralen Eingabefeatures; ein Versionsprotokoll, das Modell-, Prompt- und Pipeline-Versionen mit Deployment-Datum erfasst; und definierte Retraining-Trigger mit klarem Eskalationsweg und benannter Verantwortung.
Das läuft auf der Infrastruktur, die ohnehin im Haus ist — Grafana, Datadog oder ein wöchentlicher Skriptlauf mit benutzerdefinierten Metriken. Eine spezialisierte MLOps-Plattform braucht in dieser Größenordnung niemand. Was es braucht, ist die Entscheidung, dass ein produktives Modell einen Eigentümer hat und ein Modell ohne Monitoring nicht als „in Produktion", sondern als „unbeaufsichtigt" gilt. Diese Unterscheidung ist der eigentliche Reifegrad — und der ist eine Organisationsfrage, keine Toolfrage.
Ein Diagnostic bewertet Ihren Modell-Lifecycle-Reifegrad gegen die vier Drift-Arten — bevor stille Degradation unbemerkt Ihr Geschäftsergebnis erreicht. Wir prüfen Ihre Monitoring-, Versionierungs- und Retraining-Praxis und zeigen, wo ein Modell heute schon unbeaufsichtigt läuft.
Referenzen: EU AI Act, „Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems" (artificialintelligenceact.eu/article/72); Evidently AI, „What is data drift in ML, and how to detect and handle it" (evidentlyai.com/ml-in-production/data-drift); OpenAI, „Deprecations" (developers.openai.com/api/docs/deprecations).