Monitoring ist mehr als Uptime
AI Monitoring beobachtet technische Gesundheit, Daten- und Modellverhalten, Outputqualität, Security, Nutzerwirkung und Governance Controls. Incident Management steuert Erkennung, Triage, Eindämmung, Behebung, Wiederherstellung, Kommunikation und Lernen.
Warum Go-live nur der Beginn ist
Drift
Daten, Nutzerverhalten, Quellen und Modelle verändern sich.
Missbrauch
Neue Angriffsmuster oder unerlaubte Nutzung entstehen im Betrieb.
Impact
Kleine Fehler können sich unbemerkt über viele Fälle kumulieren.
Lernen
Incidents und Near Misses verbessern Tests, Controls und Schulung.
Typisches Praxisbild
Ein RAG-Assistent antwortet schnell und ohne technische Fehler. Nach einer Inhaltsänderung sinkt jedoch die Quellenabdeckung; Halluzinationen steigen. Das Infrastrukturmonitoring bleibt grün, weil fachliche Qualitätsmetriken und Nutzerbeschwerden nicht mit dem AI-Service verknüpft sind.
Was BAIS für den Betrieb klärt
- Welche technischen, fachlichen, Security- und Impact-Signale sind kritisch?
- Welche Baseline und Schwellenwerte gelten?
- Wie werden Halluzination, Drift, Bias, Abuse und Leakage erkannt?
- Welche Nutzerfeedbacks und Beschwerden fließen ein?
- Wer erhält welchen Alert in welcher Frist?
- Wie werden Events nach Severity klassifiziert?
- Wann wird gedrosselt, isoliert, zurückgerollt oder gestoppt?
- Welche Daten braucht Forensik und Ursachenanalyse?
- Wer informiert Kunden, Betroffene, Management oder Behörden?
- Wie werden Lessons Learned in Tests und Controls zurückgeführt?
Handlungsfähiges Signal statt Dashboard-Dekoration
„Wir überwachen Verfügbarkeit und Antwortzeit.“
- Keine Qualität
- Kein Drift
- Keine Severity
- Keine Reaktion
„Uptime, Latenz und Kosten werden mit Quellenabdeckung, groundedness, Policy-Verstößen, Overrides, Beschwerden und Injection-Signalen überwacht. Kritische Schwellen stoppen Tools automatisch und alarmieren Incident Commander und System Owner.“
Fünf Monitoring-Dimensionen
Severity: 0–2 kontinuierlich getestet · 3–5 zentrale KPI/Alerts vorhanden · 6–8 technische Basis ohne Impact-Sicht · 9–10 keine definierten Betriebs- und Incident Controls.
Was eingerichtet und nachgewiesen wird
Wer handelt im Incident?
Welche Regelwerke berührt R-011?
- ISO/IEC 27001-orientiert: Event Monitoring, Logging, Incident Assessment, Response, Evidence, Learning und Business Continuity.
- ISO/IEC 42001: Monitoring, Messung, Nichtkonformität, Korrekturmaßnahme und kontinuierliche Verbesserung.
- EU AI Act: Je nach Rolle und System können Post-Market Monitoring, Logging, Serious-Incident-Prozesse und Korrekturmaßnahmen relevant sein.
- DSGVO: Datenschutzverletzungen, Risikobewertung, Dokumentation und gegebenenfalls Meldung/Benachrichtigung.
Wie Monitoring und Reaktion gebaut werden
- Technical-, Quality-, Security-, Impact- und Control-Events korrelieren.
- Baseline pro Use Case, Modell, Datenquelle und Nutzersegment führen.
- Golden Sets, Sampling und Human Review für Qualitätsmessung einsetzen.
- Drift-, Injection-, Leakage-, Abuse- und Anomaliesignale erfassen.
- Alerts mit Severity, Owner, Frist und automatischer Aktion verbinden.
- Tool-Nutzung drosseln, isolieren, auf Fallback wechseln oder stoppen.
- Versionierte Decision Records und forensisch geeignete Logs sichern.
- Rollback, Recovery, Kommunikation und Wiederanlauf regelmäßig üben.
- RCA-Maßnahmen in Backlog, Tests, Controls und Training zurückführen.
- Überfällige Incidents, Findings und Retests sichtbar eskalieren.
Was Incident Readiness schwach macht
Betriebsfähigkeit verständlich erklären
„R-011 überwacht nicht nur, ob das AI-System online ist, sondern ob Qualität, Sicherheit, Wirkung und Governance Controls stabil bleiben. Bei Abweichungen greifen definierte Alerts, Stop-/Fallback-Maßnahmen, Incident Runbooks und nachweisbare Verbesserungen.“
„AI kann technisch gesund und fachlich falsch laufen. Deshalb verbinden wir Infrastrukturmetriken mit Groundedness, Quellenabdeckung, Drift, Policy-Verstößen, Missbrauch, Human Overrides und Beschwerden. Jede kritische Schwelle besitzt Owner und Aktion. Incidents werden eingedämmt, untersucht, kommuniziert, behoben und durch RCA und Retest in bessere Controls übersetzt.“
„Der Cloud-Provider überwacht doch alles.“
Der Provider überwacht seinen Service. Kundenspezifische Qualität, Daten, Prompts, Tools, Prozesswirkung und Governance bleiben Aufgabe der einsetzenden Organisation.
„Wir haben noch keine Incidents.“
Ohne definierte Erkennung bleiben Vorfälle möglicherweise unsichtbar. Near Misses, Beschwerden und Override-Muster sind ebenfalls wichtige Signale.
„Ein Kill Switch ist zu drastisch.“
Safe Degradation erlaubt abgestufte Reaktion: Tool sperren, Output nur als Entwurf, manueller Fallback, Traffic drosseln oder vollständig stoppen.
R-011 ist vollständig, wenn …
- Technical-, Quality-, Security-, Impact- und Control-KPI definiert sind.
- Baseline, Schwelle, Datenquelle, Owner und Reaktion je Metrik vorliegen.
- Drift, Halluzination, Abuse, Leakage und Beschwerden erfasst werden.
- Severity, Alert, Eskalation und Kommunikationswege getestet sind.
- Kill Switch, Drosselung, Isolation, Fallback und Rollback funktionieren.
- Decision Records, Logs und forensische Zeitlinie verfügbar sind.
- Runbooks, Bereitschaft, Vertretung und Meldeprüfung funktionieren.
- RCA, Maßnahmen, Retest, Lessons Learned und Review nachweisbar sind.