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

Viele Schäden kündigen sich nicht zuerst als technische Fehlermeldung an. Betroffene Personen beschreiben unverständliche Entscheidungen, Beschäftigte umgehen Empfehlungen, Fachkräfte führen Schattenlisten und Kunden brechen Prozesse ab. Solche Signale müssen in das Monitoring gelangen, ohne dass jede Beschwerde vorschnell als Modellfehler klassifiziert wird.

Ein Beschwerdeprozess verbindet Kanal, Fallreferenz, Systemversion, Wirkung, betroffene Gruppe, Untersuchung, Antwort und Korrektur. Wiederkehrende Muster werden aggregiert. Beinahe-Vorfälle – Fälle, in denen Aufsicht oder Zufall einen Schaden verhindert – bleiben sichtbar. Wer nur eingetretene Schäden zählt, verliert die wertvollsten Präventionsdaten.

Ein Vorfallprozess beginnt vor dem Vorfall

Artikel 73 enthält für schwerwiegende Vorfälle abgestufte Meldefristen. Grundsätzlich erfolgt die Meldung unmittelbar nach Feststellung eines Kausalzusammenhangs oder seiner vernünftigen Wahrscheinlichkeit und spätestens 15 Tage nach Kenntnis. Für bestimmte besonders gravierende Fälle gelten kürzere Höchstfristen; ein zunächst unvollständiger Bericht kann zur Fristwahrung nachgereicht und später vervollständigt werden.

Diese Fristen sind keine Zielwerte für interne Reaktion. Das Team muss früher erkennen, triagieren, Beweise sichern und zuständige Rollen aktivieren. Der Runbook-Test fragt: Wer kann das System deaktivieren? Wer konserviert Logs, ohne die Untersuchung zu verfälschen? Wer bewertet Auswirkungen auf Personen? Wer informiert Betreiber, Anbieter, Behörden und weitere Stellen? Wer dokumentiert die Entscheidung, wenn ein Signal nicht meldepflichtig ist?

Die Untersuchung darf die spätere Ursachenbewertung nicht durch unkontrollierte Änderungen erschweren. Konfiguration, Versionen und relevante Artefakte werden eingefroren oder reproduzierbar gesichert. Gleichzeitig schützt der Prozess betroffene Personen und verhindert weitere Schäden.

Änderungen brauchen ein eigenes Evidenzgate

KI-Systeme verändern sich häufiger als klassische Softwareprodukte. Ein Anbieter aktualisiert das Basismodell, ein Retrievalbestand wächst, ein Prompt wird optimiert, ein Tool erhält mehr Rechte oder eine neue Datenquelle kommt hinzu. Jede Änderung kann Leistung, Risiko, Transparenz, Aufsicht und Zweck beeinflussen.

Artikel 17 nennt im Qualitätssystem ausdrücklich Verfahren für Änderungen, Tests vor, während und nach der Entwicklung, Post-Market-Monitoring, Vorfallmeldung, Aufzeichnungen und Verantwortlichkeiten. Ein Change Ticket mit „kleine Promptanpassung" genügt nicht. Das Gate bewertet betroffene Behauptungen, neue Fehlerpfade, Datenänderungen, Regressionstests, Dokumentationsbedarf, Rollback und Freigabe.

Änderungen werden nach Wirkung statt nach Dateigröße eingestuft. Eine einzige neue Toolberechtigung kann riskanter sein als ein großes internes Refactoring. Eine neue Modellversion wird erst produktiv, wenn Vergleichsdaten, Grenzfälle, menschliche Aufsicht und Rücknahme getestet sind.

Korrektur ist mehr als ein Patch

Wenn ein Hochrisiko-System nicht konform ist, verlangt Artikel 20 geeignete unmittelbare Korrekturmaßnahmen. Je nach Lage kann dies Anpassung, Rücknahme vom Markt, Deaktivierung oder Rückruf bedeuten. Relevante Vertriebspartner, Betreiber, Vertreter, Importeure, Behörden und gegebenenfalls notifizierte Stellen müssen informiert werden.

Ein Corrective Action Record beschreibt Problem, Umfang, betroffene Versionen und Einsätze, Sofortschutz, Ursachenanalyse, dauerhafte Maßnahme, Validierung, Kommunikation und Abschlusskriterium. Er prüft auch nachgelagerte Folgen: Müssen Entscheidungen erneut angesehen, Betroffene informiert oder Datenprodukte neu erzeugt werden? Ein Softwarepatch heilt keine bereits entstandene Wirkung.

Die kleinste brauchbare Monitoringarchitektur

Auch ein kleiner Anbieter braucht kein gigantisches Kontrollzentrum. Eine tragfähige Minimalarchitektur besteht aus sechs verbundenen Registern:

Baseline: Zweck, Version, Population, Daten, Kontrollen und Restrisiko.

Signalregister: Metriken, Schwellen, Beschwerden, Drift und Beinahe-Vorfälle.

Änderungsregister: Änderung, Auswirkung, Tests, Freigabe und Rollback.

Vorfallregister: Triage, Beweise, Meldung, Untersuchung und Schutzmaßnahmen.

Maßnahmenregister: Korrektur, Verantwortlichkeit, Frist und Wirksamkeitsprüfung.

Reviewkalender: tägliche Alarme, periodische Reviews und ereignisbasierte Neubewertung.

Die Register können technisch einfach sein. Entscheidend sind stabile Kennungen und Beziehungen. Von einer Beschwerde muss zum Systemlauf, von dort zur Version, zur Änderung und zur Korrektur navigiert werden können.

Methode: BASELINE → SIGNAL → TRIAGE → CHANGE → VERIFY

Die Betriebslogik lässt sich auf fünf Schritte verdichten. BASELINE fixiert die gültige Systembehauptung. SIGNAL sammelt technische und menschliche Beobachtungen. TRIAGE bewertet Wirkung, Dringlichkeit und Meldeweg. CHANGE setzt begrenzte Korrektur oder Anpassung um. VERIFY prüft, ob Maßnahme und Dokumentation die Ursache tatsächlich adressieren.

Der letzte Schritt schließt den Kreis. Ohne Wirksamkeitsprüfung wird Monitoring zu einer Ticketmaschine. Mit ihr wird der Betrieb zu einem kontrollierten Lernsystem, das negative Evidenz nicht versteckt, sondern in bessere Grenzen und Entscheidungen übersetzt.

Übungsblatt: Entwirf einen Post-Market-Monitoringplan

1. Definiere Zweck, Systemversion, Population und Entscheidungswirkung.

2. Formuliere fünf Behauptungen, die im Betrieb weiter gelten müssen.

3. Ordne jeder Behauptung technische, menschliche und wirkungsbezogene Signale zu.

4. Definiere Schwellen für Review, Pause, Korrektur und Vorfalltriage.

5. Entwirf den Informationskreis zwischen Anbieter und Betreiber.

6. Lege das Änderungs- und Regressionstest-Gate fest.

7. Verbinde Beschwerden, Beinahe-Vorfälle und Logs mit Maßnahmen.

8. Plane Reviewrhythmus, Verantwortliche und Wirksamkeitsprüfung.

Reflexion: Welche Systembehauptung kann Ihr heutiges Dashboard nicht überprüfen? Welche reale Änderung würde bei Ihnen derzeit unbemerkt produktiv werden?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Der Beitrag beschreibt ein fachliches Betriebs- und Evidenzmodell, keine Rechtsberatung. Die genannten Anforderungen beziehen sich insbesondere auf Hochrisiko-KI-Systeme; für andere Systeme können risikoadäquate Teile freiwillig sinnvoll sein. Sektor-, Datenschutz-, Arbeits-, Produkt- und nationales Recht bleibt gesondert zu prüfen. Stand der redaktionellen Prüfung: 17. Juli 2026.