Die kurze AntwortKI Monitoring überwacht nach dem Go-live nicht nur Genauigkeit, sondern auch Drift, Robustheit, Cybersicherheit, Gruppenunterschiede, menschliche Übersteuerung, Beschwerden, Vorfälle und Nutzung außerhalb des freigegebenen Zwecks. Für jede Kennzahl braucht es Baseline, Datenquelle, Frequenz, Warn- und Stoppschwelle, Owner und dokumentierte Reaktion. Anbieterliches Post-Market-Monitoring nach Artikel 72 und Betreiberüberwachung nach Artikel 26 sind zu unterscheiden und durch vertraglichen Datenaustausch miteinander zu verbinden.

Monitoring beginnt mit Zweck und Risikobild

Ein universelles Dashboard für alle KI Systeme gibt es nicht. Monitoring-Ziele werden aus Zweck, betroffenen Personengruppen, Risikoregister, Anbieteranleitung und Freigabebedingungen abgeleitet. Bei einem Textassistenten können Halluzinationen, vertrauliche Eingaben und unzulässige Veröffentlichungen zentral sein; bei einer Priorisierung natürlicher Personen sind Fehlentscheidungen, Gruppenunterschiede, Übersteuerung und Beschwerden wichtiger. Die Kennzahl folgt dem Risiko und darf nicht lediglich gewählt werden, weil sie technisch leicht verfügbar ist.

Vor dem Produktivstart wird eine Baseline unter repräsentativen Bedingungen festgehalten. Sie beschreibt erwartete Leistung, Datenqualität, Nutzerverhalten und bekannte Grenzen. Ohne Baseline bleibt ein späterer Wert schwer interpretierbar. Monitoring umfasst technische und organisatorische Signale: Logs und Modellmetriken werden mit fachlichen Stichproben, Nutzerfeedback, Beschwerden, Vorfällen und Änderungen des Einsatzkontexts verbunden. Die verantwortliche Stelle prüft regelmäßig, ob die ursprünglichen Annahmen noch tragen.

  • Monitoring-Ziele aus konkretem Zweck, Risiko und betroffenen Gruppen ableiten.
  • Vor dem Go-live eine dokumentierte und nachvollziehbare Baseline festlegen.
  • Technische Messwerte mit fachlichen und menschlichen Signalen verbinden.

Quellen: [1] [2]

Die richtigen Leistungs- und Risikosignale auswählen

Technische Leistung kann je nach System über Fehlerquote, Präzision, Vollständigkeit, Kalibrierung, Robustheit oder Ausfallzeit beobachtet werden. Drift betrifft nicht nur Modellparameter, sondern auch Eingabedaten, Population, Prozess und Zweck. Cybersicherheitssignale umfassen missbräuchliche Zugriffe, ungewöhnliche Eingaben, Manipulationsversuche und Schwachstellen. Für generative Systeme kommen faktische Fehler, problematische Inhalte und das Umgehen von Schutzmaßnahmen hinzu. Metriken müssen für fachliche Entscheider verständlich erklärt werden.

Grundrechts- und Compliance-Risiken benötigen zusätzliche Perspektiven. Gruppenunterschiede können ein Warnsignal sein, sind aber kontextabhängig zu interpretieren und erfordern geeignete Daten sowie rechtliche Prüfung. Hohe menschliche Übersteuerung kann auf schlechte Leistung oder unpraktische Anweisungen hindeuten; ungewöhnlich niedrige Übersteuerung auf Automatisierungsbias. Beschwerden, Rechtsbehelfe, zurückgenommene Entscheidungen und Zweckabweichungen liefern Informationen, die ein rein technisches Monitoring nicht erkennen würde.

  • Leistungsmetriken passend zur konkreten fachlichen Aufgabe wählen.
  • Daten-, Populations-, Prozess- und Zweckdrift getrennt beobachten.
  • Beschwerden und menschliche Übersteuerung als Governance-Signale auswerten.

Quellen: [1] [2]

Schwellen, Frequenz und Datenqualität festlegen

Jede Kennzahl braucht eine Warnschwelle und, wo erhebliche Folgen möglich sind, eine Stoppschwelle. Warnwerte lösen Untersuchung, engere Stichproben oder zusätzliche menschliche Prüfung aus. Stoppschwellen führen zur Aussetzung oder kontrollierten Einschränkung. Schwellen sollten fachlich begründet, vorab genehmigt und nach realen Erfahrungen angepasst werden. Eine nachträgliche Umdeutung, nur um eine Eskalation zu vermeiden, untergräbt das Kontrollsystem und muss als Ausnahme dokumentiert werden.

Die Messfrequenz richtet sich nach Schadenspotenzial, Nutzungsvolumen und Veränderungsgeschwindigkeit. Kontinuierliche technische Erfassung kann mit täglichen, monatlichen oder ereignisbezogenen Reviews kombiniert werden. Ebenso wichtig ist die Qualität der Monitoringdaten: Vollständigkeit, Aktualität, Repräsentativität, Messfehler und fehlende Werte sind zu kontrollieren. Werden sensible oder personenbezogene Daten ausgewertet, bleiben Datenschutz, Zweckbindung, Zugriffsbegrenzung und Speicherfristen zu beachten.

  • Warn- und Stoppschwellen vor dem Betrieb fachlich begründen und genehmigen.
  • Messfrequenz nach Risiko, Volumen und Veränderungsdynamik staffeln.
  • Qualität und rechtmäßige Verarbeitung der Monitoringdaten selbst kontrollieren.

Quellen: [1] [2]

Anbieter und Betreiber haben unterschiedliche Aufgaben

Artikel 72 verlangt für Anbieter von Hochrisiko-Systemen künftig ein dokumentiertes Post-Market-Monitoring-System, das Art und Risiken des Systems angemessen ist. Es sammelt und analysiert aktiv und systematisch relevante Daten über die Leistung während des Lebenszyklus. Ergebnisse fließen in Risikomanagement, technische Dokumentation und erforderliche Korrekturmaßnahmen zurück. Der Anbieter benötigt dafür Informationen aus dem Markt und von Betreibern, darf sich aber nicht auf zufällige Beschwerden als einziges Signal beschränken.

Betreiber überwachen das System im Rahmen von Artikel 26 entsprechend der Gebrauchsanweisung und informieren bei erkannten Risiken oder schwerwiegenden Vorfällen die vorgesehenen Stellen. Sie sehen die reale Nutzung, lokale Daten und Auswirkungen auf Personen. Vertrag und technische Schnittstelle müssen daher festlegen, welche Monitoringdaten ausgetauscht werden, wie Änderungen gemeldet und kritische Signale eskaliert werden. Die Anbieterpflicht ersetzt die eigene Betreiberüberwachung nicht; umgekehrt muss der Betreiber keine vollständige Anbieterfunktion übernehmen.

  • Post-Market-Monitoring des Anbieters und lokale Betreiberüberwachung unterscheiden.
  • Datenaustausch, Änderungsmitteilungen und Eskalation vertraglich regeln.
  • Monitoringresultate in Risikoakte und technische Dokumentation zurückführen.

Quellen: [1] [2]

Reaktion, Incident Prozess und Re-Freigabe verzahnen

Monitoring ist nur wirksam, wenn ein Signal eine definierte Handlung auslöst. Der Owner bestätigt den Alarm, prüft Datenqualität und Auswirkungen und dokumentiert die Entscheidung. Bei erhöhtem Risiko werden Nutzung begrenzt, zusätzliche menschliche Kontrollen aktiviert oder der Incident Prozess gestartet. Systemzustand und relevante Logs sind zu sichern. Zuständige Funktionen bewerten mögliche Meldungen, Betroffenenschutz und Kommunikation. Verantwortlichkeit und Frist dürfen nicht erst nach Überschreiten der Schwelle ausgehandelt werden.

Nach einer Korrektur zeigt eine Wirksamkeitsprüfung, ob der Wert dauerhaft in den akzeptierten Bereich zurückkehrt und keine neuen Risiken entstanden sind. Wesentliche Änderungen an Zweck, Modell, Daten oder Schnittstellen lösen eine Re-Freigabe aus. Auch Interaktionen mit anderen KI Systemen und manuellen Prozessen gehören in die Analyse: Ein lokaler Leistungswert kann stabil bleiben, während die Gesamtkette fehlerhafte Entscheidungen erzeugt. Erkenntnisse aktualisieren Inventar, Risikoregister, Kontrollen, Schulung und Lieferantenbewertung.

  • Jeder Schwelle einen Owner, eine Frist und eine konkrete Reaktion zuordnen.
  • Kritische Signale ohne Medienbruch in den Incident Prozess überführen.
  • Wesentliche Änderungen und Korrekturen an eine dokumentierte Re-Freigabe binden.

Quellen: [1] [2]

Management Reporting und aktueller Zeitplan

Ein Management-Dashboard sollte keine Sammlung sämtlicher Modellmetriken sein. Es zeigt wenige entscheidungsrelevante Indikatoren, Trend und Schwellenstatus, offene Maßnahmen, wesentliche Vorfälle, Anbieteränderungen und akzeptierte Restrisiken. Zu jedem roten Wert gehören Ursache, Sofortmaßnahme, Owner und Zieltermin. Die Geschäftsleitung muss erkennen können, ob der Einsatz innerhalb der genehmigten Bedingungen bleibt und wo eine Einschränkung, zusätzliche Ressource oder strategische Entscheidung erforderlich ist.

Nach der Verordnung (EU) 2026/1744 gelten Artikel 72 und die einschlägigen Hochrisikoregeln für Anhang-III-Systeme grundsätzlich ab 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 grundsätzlich ab 2. August 2028. Für Produkte nach Anhang I Abschnitt B begrenzt Artikel 2 Absatz 2 die unmittelbare Geltung; sektorale Monitoringregeln sind deshalb gesondert zu prüfen. Der Termin für Kommissionsleitlinien samt freiwilliger Vorlage zum Monitoringplan wurde auf 2. September 2027 verlegt. Bis dahin ist der endgültige Stand zu beobachten. Bereits geltendes Datenschutz-, Sicherheits-, Produkt- und Vertragsrecht kann Monitoring früher verlangen. Ein Dashboard garantiert keine Konformität oder Fehlerfreiheit.

  • Managementberichte auf Schwellen, Trends, Maßnahmen und Restrisiken konzentrieren.
  • Hochrisikofristen von bereits geltenden fachrechtlichen Pflichten trennen.
  • Kommissionsleitlinien und freiwillige Monitoringvorlage vor Umsetzung erneut prüfen.

Quellen: [2] [1]

Entscheidungsbox: Ist der Monitoringplan einsatzbereit?

  • Ziele und Kennzahlen sind aus Zweck, Risiken und betroffenen Gruppen abgeleitet.
  • Baseline, Datenquelle, Frequenz sowie Warn- und Stoppschwellen sind dokumentiert.
  • Für jedes Signal stehen Owner, Reaktionsfrist, Eskalation und Evidenz fest.
  • Anbieter- und Betreiberaufgaben sowie der erforderliche Datenaustausch sind geregelt.
  • Ergebnisse fließen in Risikomanagement, Dokumentation, Incident Prozess und Re-Freigabe zurück.

Konkreten Fall besprechen

Häufige Fragen

Welche Kennzahlen muss jedes Unternehmen überwachen?

Es gibt keine identische Kennzahlenliste für alle Systeme. Auswahl und Frequenz richten sich nach Zweck, Rolle, Risiko, betroffenen Personen und Anbieteranleitung. Typische Kategorien sind Leistung, Fehler, Robustheit, Sicherheit, Drift, Gruppenunterschiede, menschliche Übersteuerung, Beschwerden, Vorfälle und Nutzung außerhalb der Freigabe. Jede Kennzahl braucht eine konkrete Reaktionsregel.

Ist Drift Monitoring immer technisch möglich?

Nicht in derselben Tiefe. Bei externen Systemen fehlen Betreibern mitunter Modellzugriff oder geeignete Vergleichsdaten. Dann sind vertragliche Informationsrechte, Anbieterberichte, fachliche Stichproben, Beschwerdesignale und andere Ersatzkontrollen wichtig. Bleibt eine wesentliche Risikodimension unbeobachtbar, muss dies in Freigabe und Restrisikobewertung sichtbar sein und kann eine Nutzungseinschränkung erfordern.

Wann muss das System nach einem Monitoringalarm gestoppt werden?

Das hängt von der vorab definierten Stoppschwelle und der konkreten Gefahr ab. Bei erheblicher Personenwirkung, unkontrollierbaren Fehlentscheidungen, Sicherheitsproblemen oder rechtswidriger Nutzung kann eine sofortige Aussetzung erforderlich sein. Niedrigere Abweichungen können zusätzliche Prüfung oder Einschränkung auslösen. Der Owner dokumentiert Datenlage, Entscheidung, Sofortmaßnahme und Zeitpunkt der Re-Freigabe.

Primärquellen

  1. EUR-Lex: Konsolidierte Fassung der Verordnung (EU) 2024/1689
  2. EUR-Lex: Verordnung (EU) 2026/1744
  3. EU AI Act Service Desk: Artikel 9
  4. EU AI Act Service Desk: Artikel 26
  5. EU AI Act Service Desk: Artikel 72

Rechtsstand: 16. September 2026. Artikel 72 und Artikel 26 gehören zum verschobenen Hochrisikoregime. Anwendungstermine, Kommissionsleitlinien und die angekündigte freiwillige Vorlage zum Monitoringplan sind vor Veröffentlichung erneut zu prüfen. Monitoring unterstützt laufende Steuerung und Nachweisführung, garantiert aber weder Fehlerfreiheit noch Konformität oder Haftungsfreiheit.