Zuletzt aktualisiert am:
KI-Monitoring ist die kontinuierliche Überwachung von KI-Systemen im Produktivbetrieb, um Leistungsabfall, Drift, unsicheres Verhalten und Kontrollfehler zu erkennen. Es umfasst die Modellleistung, Eingabe- und Ausgabeverteilungen, Fairness-Metriken, Kosten und Latenz sowie bei agentischen Systemen die vom System ausgeführten Aktionen.
Was sollte überwacht werden?
Es gibt vier Ebenen, wobei die meisten Programme nur die erste abdecken. Performance erfasst die Genauigkeit, Fehlerraten und das Geschäftsergebnis, für das das System konzipiert wurde. Daten überwacht die Inputs und achtet auf Verteilungsverschiebungen (Distribution Shift), Schemaänderungen sowie vorgelagerte Pipeline-Unterbrechungen, welche mehr Vorfälle verursachen als der Modellverfall selbst. Verhalten verfolgt, was das System erzeugt oder tut – dies umfasst die Ausgabequalität, Ablehnungs- und Halluzinationsraten bei generativen Systemen sowie die tatsächlich ausgeführten Aktionen bei Agenten. Kontrolle prüft, ob die Governance-Kontrollen weiterhin funktionieren: ob menschliche Überprüfungen stattfinden, ob Eskalationen ausgelöst werden und ob die Protokollierung vollständig ist.
Was ist Drift und welche Art davon ist relevant?
Drift ist die Abweichung zwischen den Bedingungen, für die ein Modell entwickelt wurde, und den Bedingungen, unter denen es aktuell betrieben wird. Daten-Drift ist eine Veränderung der Input-Verteilung. Dies ist einfach zu erkennen, da keine Ergebnis-Labels benötigt werden. Konzept-Drift ist eine Veränderung der zugrunde liegenden Beziehung zwischen Inputs und der korrekten Antwort. Dies ist schwieriger zu identifizieren, da es erst bestätigt werden kann, wenn die Ergebnisse vorliegen – und diese treffen in der Kreditvergabe, im Versicherungswesen und im klinischen Umfeld oft erst Monate später ein. Der praxisorientierte Ansatz besteht darin, bei Daten-Drift als Frühindikator Alarm zu schlagen und die Ergebnisse in einem langsameren Zyklus zu validieren.
Wie unterscheidet sich das Monitoring bei generativen und agentenbasierten Systemen?
Genauigkeitsmetriken lassen sich nicht direkt übertragen. Ein generatives System hat nicht die eine korrekte Ausgabe, weshalb die Überwachung hier auf stichprobenartigen Bewertungen anhand von Richtlinien, Fundierungsprüfungen (Groundedness) gegenüber dem Quellmaterial, Ablehnungs- und Sicherheitsraten sowie Nutzersignalen basiert. Bei Agenten ist der relevante Verlauf verhaltensbasiert: Welche Tools wurden aufgerufen, wie oft wurden Eskalationsschwellen überschritten, wie viele Aktionen wurden nachträglich rückgängig gemacht oder korrigiert und ob der Agent versucht hat, Operationen außerhalb seiner zulässigen Befugnisse auszuführen. Eine steigende Rate blockierter Aktionen ist ein wichtiges Governance-Signal, noch bevor es zu einem tatsächlichen Vorfall kommt.
Warum ist das für Regulierungsbehörden wichtig?
Die Überwachung nach der Bereitstellung (Post-Deployment Monitoring) ist eine explizite Verpflichtung und nicht bloß eine Empfehlung. Das EU-KI-Gesetz (EU AI Act) verpflichtet Anbieter von Hochrisiko-Systemen zum Betrieb eines Systems zur Überwachung nach dem Inverkehrbringen sowie zur Meldung schwerwiegender Vorfälle. Das NIST AI Risk Management Framework verankert die kontinuierliche Messung fest in seinen Funktionen „Measure“ und „Manage“. Die Aufsicht über Modellrisiken setzt eine laufende Leistungsüberwachung bereits seit Jahren voraus. In jedem Fall sind bei einer Prüfung Nachweise gefordert: Was wurde überwacht, welche Schwellenwerte galten, was wurde ausgelöst und welche Maßnahmen wurden daraufhin ergriffen?
Was macht ein Monitoring-Programm erfolgreich?
Schwellenwerte, die vor der Bereitstellung definiert und im System hinterlegt werden, sodass ein Alarm eine vordefinierte Bedeutung hat. Eine klare Zuweisung der Verantwortlichkeit an eine namentlich genannte Person statt an wechselnde Dienste. Die Weiterleitung von Alarmen an jemanden, der handlungsfähig ist – da der häufigste Fehler in Dashboards besteht, die niemand öffnet. Eine Abdeckung, die proportional zur Risikoklasse ist, da die gleiche Überwachung für jedes System das Team überfordert und die kritischen Systeme unzureichend beobachtet lässt. Und schließlich die Aufbewahrung der Monitoring-Aufzeichnungen selbst, da Prüfer historische Nachweise verlangen und nicht den aktuellen Zustand des Dashboards.
Praxisbeispiel:
Ein Kreditgeber überwacht ein Kreditentscheidungsmodell in drei Zyklen. Täglich prüft er die Verteilung der Eingangsdaten im Vergleich zur Trainings-Baseline und schlägt Alarm, wenn sich ein Merkmal über einen vereinbarten Schwellenwert hinaus verschiebt. Dadurch wird eine Formatänderung in einer vorgelagerten Auskunftsdatei innerhalb eines Tages erkannt. Monatlich überprüft er die Zustimmungsraten nach geschützten Merkmalen im Vergleich zu den bei der Genehmigung festgelegten Fairness-Schwellenwerten. Vierteljährlich validiert er die Prognosen anhand der tatsächlichen Zahlungsausfälle, sobald die Ergebnisse vorliegen – dies ist der einzige Weg, um ein Concept Drift sichtbar zu machen. Jeder Schwellenwert, jeder Alarm und jede Reaktion wird im Systemverzeichnis protokolliert. Wenn die Aufsichtsbehörde fragt, wie der Kreditgeber sichergestellt hat, dass das Modell noch einsatzfähig war, lautet die Antwort: ein datierter Nachweis und keine bloße Behauptung.
