Nach dem Go-live beginnt die Evidenzarbeit

Der Go-live wirkt in vielen Projekten wie eine Ziellinie. Tests sind bestanden, Verantwortliche haben freigegeben, Schnittstellen funktionieren und das System darf in den Alltag. Danach übernimmt „der Betrieb". Genau an dieser Übergabe entsteht eine gefährliche Lücke: Das Projektteam löst sich auf, während die reale Population, die tatsächlichen Daten, Umgehungsstrategien und seltenen Fehler erstmals sichtbar werden.

Ein Labor kann erwartete Fälle simulieren. Der Markt erzeugt dagegen neue Kombinationen. Nutzer formulieren anders als im Test, Datenquellen verändern ihre Struktur, Mitarbeitende entwickeln Abkürzungen, Anbieter aktualisieren Modelle und nachgelagerte Systeme interpretieren Ausgaben neu. Deshalb beginnt nach dem Go-live nicht nur Wartung. Es beginnt eine systematische Evidenzarbeit, die fortlaufend prüft, ob das System noch dasselbe tut, wofür es bewertet und freigegeben wurde.

Post-Market-Monitoring ist kein erweitertes Uptime-Dashboard

Technischer Betrieb misst häufig Verfügbarkeit, Antwortzeit, Tokenkosten und Fehlercodes. Diese Werte sind wichtig, beantworten aber nicht, ob die KI weiterhin geeignet, sicher und regelkonform arbeitet. Ein System kann zu 99,9 Prozent erreichbar sein und dennoch systematisch falsche Prioritäten setzen, bestimmte Gruppen schlechter behandeln oder durch eine geänderte Prozesspraxis außerhalb seines vorgesehenen Zwecks genutzt werden.

Artikel 72 des EU AI Act verlangt für Hochrisiko-KI-Systeme ein dokumentiertes Post-Market-Monitoring, das relevante Daten aktiv und systematisch während der gesamten Lebensdauer sammelt, dokumentiert und analysiert. Das System soll die fortlaufende Konformität bewertbar machen. Der Monitoringplan ist Teil der technischen Dokumentation. Monitoring ist damit eine Messarchitektur mit Fragen, Quellen, Schwellen, Zuständigkeiten und Entscheidungen – nicht bloß eine Sammlung vorhandener Telemetrie.

Ein belastbarer Plan beantwortet mindestens: Welche Behauptungen über das System müssen weiterhin gelten? Welche Signale können diese Behauptungen widerlegen? Wo entstehen diese Signale? Wer prüft sie in welchem Rhythmus? Welche Schwelle löst Untersuchung, Einschränkung, Korrektur oder Stop aus?

Der vorgesehene Zweck bildet die Betriebsbaseline

Monitoring braucht einen Referenzzustand. Dieser besteht nicht nur aus einer Modellnummer. Er umfasst vorgesehenen Zweck, Zielgruppe, Nutzerrollen, Entscheidungswirkung, Datenquellen, Prozessschritte, Integrationen, menschliche Aufsicht, bekannte Fehlermodi und akzeptierte Restrisiken. Ohne diese Baseline ist jede Veränderung nur eine Zahl ohne Bedeutung.

Die zentrale Betriebsfrage lautet: Arbeitet das System noch innerhalb der Annahmen, auf denen seine Bewertung beruht? Wenn ein Assistent ursprünglich Zusammenfassungen erzeugt, später aber seine Ausgaben automatisch über Freigaben entscheiden, hat sich nicht nur die Nutzungshäufigkeit verändert. Der Entscheidungseinfluss ist gewachsen. Eine gute Überwachung erkennt deshalb nicht nur statistische Drift, sondern Zweck- und Prozessdrift.

Jede Baseline erhält eine stabile Kennung und einen Gültigkeitszeitraum. Änderungen werden nicht rückwirkend in dieselbe Beschreibung geschrieben. So bleibt rekonstruierbar, welche Version mit welchem Zweck, welchen Daten und welchen Kontrollen tatsächlich im Einsatz war.

Vier Arten von Drift müssen getrennt werden

Der Sammelbegriff Drift verdeckt unterschiedliche Ursachen und Maßnahmen.

1 · Datendrift: Verteilung, Format, Vollständigkeit oder Herkunft der Eingaben verändert sich. Eine Quelle liefert neue Kategorien oder ein Kundenmix verschiebt sich.

2 · Konzeptdrift: Die Beziehung zwischen Eingabe und gewünschtem Ergebnis verändert sich. Ein früher guter Prädiktor verliert fachliche Bedeutung.

3 · Prozessdrift: Menschen oder Systeme nutzen die Ausgabe anders als vorgesehen. Eine Empfehlung wird faktisch zur automatischen Entscheidung.

4 · Systemdrift: Modell, Prompt, Retrievalbestand, Tool, Schwellenwert oder Anbieterplattform ändert sich – geplant oder unbemerkt.

Diese Formen brauchen unterschiedliche Reaktionen. Datendrift kann eine Qualitätsprüfung oder neue Repräsentativitätsanalyse auslösen. Konzeptdrift verlangt fachliche Neubewertung. Prozessdrift kann Schulung, Rollenänderung oder Funktionsbegrenzung erfordern. Systemdrift gehört in das Änderungsmanagement und gegebenenfalls in eine erneute Konformitäts- oder Risikoprüfung.

Ein einzelner „Drift Score" reicht daher nicht. Das Monitoring verbindet technische Signale mit Prozessbeobachtung, Nutzerfeedback und Wirkung.

Ergebnisse zählen mehr als Modellmetriken

Genauigkeit, Fehlerrate oder Retrievaltreffer sind Zwischenwerte. Entscheidend ist, was nach der Ausgabe geschieht. Wurde eine falsche Empfehlung erkannt? Hat ein Mensch sinnvoll abgewichen? Entstand eine Verzögerung, Benachteiligung oder zusätzliche Arbeitslast? Wurde eine Beschwerde gelöst? Blieb eine Korrektur auf der Oberfläche stecken, während ein nachgelagerter Prozess weiterlief?

Die Evidenzkette verbindet deshalb Systemlauf, Datenstand, Ausgabe, menschliche Entscheidung, nachgelagerte Aktion und beobachtetes Ergebnis. Sie trennt Modellfehler von Integrationsfehlern, Bedienfehlern und ungeeignetem Prozessdesign. Nur dann kann das Team eine passende Maßnahme wählen.

Auch Gruppen- und Szenarioanalysen bleiben notwendig. Ein stabiler Durchschnitt kann verschlechterte Ergebnisse für eine kleine Population verbergen. Monitoring definiert vorab relevante Segmente und prüft sie datensparsam. Wo eine Segmentierung rechtlich oder praktisch nicht zulässig ist, braucht es alternative Prüfverfahren statt einer erfundenen Sicherheit.

Logs werden erst durch Interpretationsregeln zu Evidenz

Artikel 12 fordert bei Hochrisiko-Systemen technische Fähigkeiten zur automatischen Aufzeichnung relevanter Ereignisse. Doch mehr Logs bedeuten nicht automatisch mehr Nachweis. Unstrukturierte Ereignisse ohne Version, Zeitbezug, Identität, Prozessschritt und Ergebnis erzeugen nur teuren Datennebel.

Ein Evidence Event enthält mindestens Ereignistyp, Zeitpunkt, System- und Konfigurationsversion, relevante Datenreferenz, verantwortliche Rolle, Entscheidung, Wirkung und Verknüpfung zum Vorgänger. Sensible Inhalte werden nicht vorsorglich vollständig dupliziert; Referenzen, Hashes, minimierte Merkmale und definierte Aufbewahrungsfristen können den Nachweis mit Datenschutz und Sicherheit verbinden.

Interpretationsregeln legen fest, was ein Signal bedeutet. Drei aufeinanderfolgende Timeouts können ein Verfügbarkeitsproblem sein. Drei manuelle Überstimmungen bei derselben Fallgruppe können dagegen auf eine fachliche Lücke hindeuten. Ohne Hypothese und Schwelle bleibt jedes Dashboard dekorativ.

Betreiber und Anbieter brauchen einen geschlossenen Informationskreis

Der Anbieter sieht Modell- und Produktänderungen, aber oft nicht den vollständigen Einsatzkontext. Der Betreiber sieht reale Fälle, Beschwerden und Umgehungspraktiken, kennt jedoch möglicherweise nicht jede technische Abhängigkeit. Post-Market-Monitoring funktioniert nur, wenn beide Seiten strukturierte Informationen austauschen.

Artikel 26 verpflichtet Betreiber von Hochrisiko-Systemen unter anderem zur Nutzung nach Anleitung, zu kompetenter menschlicher Aufsicht, zur Überwachung des Betriebs und in relevanten Fällen zur Information des Anbieters. Besteht Grund zur Annahme, dass eine regelkonforme Nutzung dennoch ein Risiko erzeugt, ist der Anbieter oder Händler sowie die zuständige Marktüberwachungsbehörde ohne unangemessene Verzögerung zu informieren und die Nutzung auszusetzen. Bei einem schwerwiegenden Vorfall greifen weitere Informationswege.

Der Betriebsvertrag braucht daher nicht nur Service-Level, sondern ein Evidenzprotokoll: gemeinsame Ereignistaxonomie, sichere Übermittlung, Ansprechpartner, Bereitschaft, Fristen, zulässige Daten, Rückfragen und Bestätigung des Abschlusses. Eine Support-E-Mail ist kein geschlossener Informationskreis.

Beschwerden und Beinahe-Vorfälle sind Frühwarnsensoren