Post-Market-Monitoring-Plan für KI-Agenten: Was Artikel 72 des EU AI Act verlangt

Mit der Klassifizierung beginnen, nicht mit Labels

KI-Agenten sind im AI Act keine eigene Rechtskategorie. Ausschlaggebend für Artikel 72 ist nicht das Wort Agent, sondern ob das System als hochriskant eingestuft wird oder Teil eines Hochrisiko-Systems ist.

Ein interner Assistent, der Besprechungsnotizen formuliert, wird nicht genauso behandelt wie ein Agent für Kreditwürdigkeitsprüfung, Schaden-Triage, Recruiting, Identitätsprüfung oder entscheidungsunterstützende Workflows im öffentlichen Sektor. Wenn diese Klassifizierungsarbeit noch nicht erfolgt ist, beginnen Sie mit Hochrisiko-KI unter dem EU AI Act klassifizieren und KI-Agenten-Compliance unter dem EU AI Act. Sobald ein System im Anwendungsbereich liegt, wird Post-Market-Monitoring Teil des Betriebsmodells und nicht bloß eine optionale Best Practice.

Was Artikel 72 tatsächlich verlangt

Artikel 72 verpflichtet Anbieter von Hochrisiko-KI-Systemen, ein Post-Market-Monitoring-System einzurichten und zu dokumentieren, das der Art der KI-Technologie und den Risiken des Systems angemessen ist. Diese Überwachung muss über die gesamte Lebensdauer des Systems aktiv bleiben.

In der Praxis besteht die Pflicht aus fünf Bausteinen: Relevante Daten nach dem Deployment müssen aktiv, systematisch erfasst, dokumentiert und analysiert werden; die fortlaufende Einhaltung der Anforderungen aus Kapitel III Abschnitt 2 muss überprüft werden; Interaktionen mit anderen KI-Systemen müssen einbezogen werden, wenn sie relevant sind; das Monitoring-System muss auf einem Post-Market-Monitoring-Plan beruhen; und dieser Plan muss Teil des Annex-IV-Dokumentationspakets sein. Bestehende sektorspezifische Post-Market-Prozesse können wiederverwendet werden, wenn Unionsrecht bereits gleichwertige Governance verlangt – aber nur dann, wenn das integrierte Ergebnis denselben Schutzstandard erreicht.

• Erheben Sie relevante Daten nach dem Deployment systematisch und nicht nur anlassbezogen.
• Prüfen Sie diese Daten gegen laufende Compliance-Anforderungen und nicht nur gegen Produkt-KPIs.
• Erfassen Sie Interaktionen mit anderen KI-Systemen und externen Tools, sofern diese risikorelevant sind.
• Dokumentieren Sie den Plan in Annex IV so, dass ein Prüfer nachvollziehen kann, wie das Monitoring tatsächlich funktioniert.
• Integrieren Sie bestehende sektorspezifische Prozesse nur dann, wenn das Schutzniveau gleichwertig bleibt.

Ein Dashboard ist noch kein Plan

Der häufigste Fehler besteht darin, Beobachtbarkeit mit Compliance zu verwechseln. Ein Dashboard zeigt Latenz, Erfolgsquote, Kosten oder Token-Verbrauch. Ein Post-Market-Monitoring-Plan muss einem Prüfer dagegen erklären, welche Risiken überwacht werden, welche Signale belegen, dass Kontrollen weiterhin funktionieren, welche Schwellenwerte eine Eskalation auslösen, wer was prüft und wie Korrekturmaßnahmen dokumentiert werden.

Deshalb ist Post-Market-Monitoring eng mit der EU-AI-Act-Artikel-17-Checkliste, Audit-Trails für KI-Agenten: Von Logs zu Nachweisen und dem zugrunde liegenden Evidenzpaket verknüpft. Wenn nicht nachvollziehbar ist, wie aus Telemetrie belastbare Nachweise werden, existiert noch kein belastbares Betriebsmodell nach Artikel 72.

• Welche Risiken überwacht werden: rückgebunden an das Risikoregister nach Artikel 9.
• Welche Signale relevant sind: nicht nur Outputs, sondern auch Tool-Aufrufe, Freigaben, Overrides und nachgelagerte Auswirkungen.
• Welche Schwellenwerte gelten: was informativ ist, was am selben Tag geprüft werden muss und was die Produktion einfriert.
• Welche Unterlagen auditfähig sind: Vorfälle, Prüferbegründungen, Korrekturmaßnahmen und versionsgebundene Evidenz-Exporte.

Warum Artikel 72 für KI-Agenten besonders wichtig ist

Statische Vorhersagesysteme können still scheitern. Agenten scheitern über Systemgrenzen hinweg. Sie rufen Daten ab, benutzen Tools, stoßen Workflows an, delegieren an andere Modelle und arbeiten mit unterschiedlichen Autonomiegraden. Deshalb muss Monitoring für Agenten workflowbezogen sein und darf sich nicht nur auf Modellmetriken beschränken.

Die Logik des Post-Market-Monitorings ist für agentische Systeme besonders relevant, auch wenn das zugrunde liegende Modell nicht kontinuierlich nachtrainiert wird. Neue Risiken können durch Prompt-Änderungen, Policy-Updates, Modellwechsel, erweiterte Tool-Berechtigungen, Retrieval-Änderungen, Integrationsdrift oder Anpassungen im Betreiberkontext entstehen. Das System kann also riskanter werden, ohne dass jemals ein klassischer Trainingszyklus stattfindet.

• Tool-Ausführung: fehlgeschlagene Aktionen, Wiederholungen, Seiteneffekte und unzulässige Zugriffsversuche.
• Policy-Kontrollsignale: Ablehnungen, Beinahe-Ablehnungen, Freigabe-Queues und Override-Gründe.
• Verhalten über Systemgrenzen: was geschieht, wenn der Agent auf andere KI-Dienste oder externe Automatisierungen angewiesen ist.
• Grundrechtsrelevante Auswirkungen: Disparitäten, Beschwerden, Einsprüche und materiell schädliche Downstream-Effekte.

Was in einen belastbaren Artikel-72-Plan gehört

Ein belastbarer Plan ist nicht deshalb lang, weil er wichtig aussehen soll. Er ist so konkret, dass ein Prüfer verstehen kann, wie Sie Degradationen erkennen, wer Auffälligkeiten untersucht und wie Evidenz in Konformität und Change Control zurückfließt.

Für KI-Agenten sollte der Plan in der Regel mindestens die folgenden Bausteine enthalten. Viele Teams kombinieren an dieser Stelle die rechtliche Pflicht mit der Vorlage für den Post-Market-Monitoring-Plan, dem Playbook für menschliche Aufsicht und der Evidence-Pack-Checkliste, damit der Prozess nicht nur für Juristen, sondern auch für Engineering- und Operations-Teams nutzbar ist.

• Systemidentifikation und Zweckbestimmung: exakter Systemname, Version, Anbieter, Release-Scope, Einsatzkontext, betroffene Nutzer, Systemgrenzen und Hochrisiko-Klassifizierungslogik.
• Monitoring-Ziele, die an das Risikoregister gebunden sind: Jedes wesentliche Risiko sollte mindestens ein überwachtetes Signal, einen Verantwortlichen und einen Eskalationspfad haben.
• Datenquellen und Erhebungsmethoden: Ausführungslogs, Tool-Traces, Freigabeereignisse, Override-Aufzeichnungen, Beschwerden, Stichproben von Outputs, Vorfall-Tickets und Integrationsänderungen.
• Metriken, Schwellenwerte und Schweregrade: Aufgabenfehlerrate, Tool-Fehlerrate, Halluzinationsquote oder Quote nicht gedeckter Aktionen, Override-Häufigkeit, Disparitätsindikatoren, Rollback-Ereignisse und folgenbezogene Schwellenlogik.
• Sampling-Policy und Prüfungsrhythmus: kontinuierliche Telemetrie, 100-%-Prüfung kritischer Aktionen, Basissampling für geringere Risiken und verschärfte Prüfung nach Releases, Modellwechseln oder Vorfällen.
• Daten zu menschlicher Aufsicht und Intervention: Was wurde eskaliert, wer hat geprüft, welchen Kontext hat die Person gesehen, was wurde geändert und ob sich derselbe Fehlertyp wiederholt.
• Vorfallbehandlung und Verknüpfung mit Artikel 73: Wer untersucht, was als Vorfall gilt, welche Behördenfristen greifen und wie der Start der Meldefrist identifiziert und belegt wird.
• Korrekturmaßnahmen und Change Control: Wer das System pausieren, deaktivieren, zurückrollen oder zurückziehen darf und wie Erkenntnisse aus dem Monitoring in Artikel 9 Risikomanagement und Artikel 17 Qualitätsmanagement zurückfließen.
• Aufbewahrung von Nachweisen und Audit-Readiness: Wie Logs, Prüfernotizen, Vorfälle und Korrekturmaßnahmen aufbewahrt, geschützt, versionsgebunden verknüpft und für Prüfungen exportiert werden.

Wann Monitoring zur Meldung nach Artikel 73 wird

Im Monitoring-Plan muss klar geregelt sein, wann ein Alert zu einem Vorfall wird, wer die Triage verantwortet und wann eine Meldung nach Artikel 73 auszulösen ist. Diese Frist darf nicht der Improvisation überlassen werden.

Nach dem derzeit geltenden Rahmen des Artikels 73 beträgt die äußerste Frist 15 Tage, nachdem Anbieter oder Betreiber von einem schwerwiegenden Vorfall Kenntnis erlangt haben. Die äußerste Frist beträgt 2 Tage bei weitverbreiteten Verstößen gegen Pflichten zum Schutz von Grundrechten oder bei einer schwerwiegenden und irreversiblen Störung kritischer Infrastruktur sowie 10 Tage, wenn eine Person verstorben ist und Kausalität oder ein hinreichender Verdacht auf Kausalität festgestellt wurde. Operativ bedeutet das: Schwellenwerte und Eskalationsregeln müssen diese Konstellationen schnell genug sichtbar machen, damit eine fristgerechte Meldung überhaupt möglich ist.

• Tod oder schwere Gesundheitsschäden erfordern die schnellste Triage und einen sauber belegten Pfad zur Kausalitätsbewertung.
• Schwerwiegende und irreversible Störungen kritischer Infrastruktur dürfen nicht in langsamen internen Review-Queues hängen bleiben.
• Grundrechtsverletzungen sind keine abstrakten Rechtsfragen, sondern brauchen operative Trigger, die an Beschwerden, Overrides, Einsprüche und schädliche Downstream-Ergebnisse gekoppelt sind.
• Korrekturmaßnahmen nach Artikel 20 sollten in denselben Workflow eingebettet sein, damit Mitigation nicht auf die endgültige Meldebürokratie warten muss.

Artikel 72 ist Anbieterpflicht, aber Betreiber speisen die Daten ein

Artikel 72 ist eine Pflicht des Anbieters, doch der Anbieter kontrolliert häufig nicht den gesamten operativen Kontext. Betreiber halten oft die Beschwerdeakten, Notizen aus menschlicher Prüfung, Vorfall-Tickets aus dem Erstlinien-Support oder Outcome-Daten, die das Monitoring überhaupt erst aussagekräftig machen.

Für agentische Systeme sollten Anbieter-Betreiber-Verträge deshalb festlegen, welche Daten der Betreiber zurückliefern muss, wie schnell schwerwiegende Vorfälle und Beinahe-Vorfälle eskaliert werden, wie Override-Aufzeichnungen aufzubewahren sind und wie Änderungen an Workflows oder Integrationen gemeldet werden. Wird diese Schnittstelle nicht gestaltet, sieht der Plan auf dem Papier vollständig aus und versagt in der Praxis.

• Rückgabepflichten für Daten zu Beschwerden, Overrides, Einsprüchen und Outcome-Metriken.
• Meldekanäle für Vorfälle mit benannten Kontakten und Zuständigkeitszuordnung je Jurisdiktion.
• Änderungsmeldungen, wenn Betreiber Prompts, Tools, Workflows oder umgebende Kontrollen anpassen.
• Aufbewahrungs- und Exportrichtlinien, damit Post-Market-Evidenz nicht über mehrere Systeme zerfällt.

Die Lage zu Vorlage und Fristen im März 2026

Die sicherste Einordnung des geltenden Rechts lautet derzeit: Die Vorlagenfrage ist offen, die Anbieterpflicht nicht. Der aktuelle Wortlaut von Artikel 72 verweist weiterhin auf einen Durchführungsrechtsakt der Kommission für eine Planvorlage. Gleichzeitig hat die Kommission am 19. November 2025 vorgeschlagen, diese Vorgabe durch Leitlinien statt durch ein harmonisiertes Format zu ersetzen. Dieser Vorschlag befindet sich aber noch im Gesetzgebungsverfahren und ändert daher das heute geltende Recht nicht.

Dasselbe gilt für die Fristen. Nach dem derzeit geltenden AI Act greifen die meisten Hochrisiko-Pflichten am 2. August 2026, während bestimmte in Produkte eingebettete Hochrisiko-KI-Systeme eine längere Übergangsfrist bis zum 2. August 2027 haben. Die Kommission hat Änderungen am Zeitplan vorgeschlagen, doch diese sind noch nicht geltendes Recht. Praktisch sinnvoll ist es daher, jetzt einen prüffähigen Plan aufzubauen und das Format später anzupassen, falls die Kommission Leitlinien oder gesetzliche Änderungen finalisiert.

• Aktueller Wortlaut von Artikel 72: Zusammenfassung zu Artikel 72 im AI Act Service Desk
• Aktuelle Fristen für schwerwiegende Vorfälle: Zusammenfassung zu Artikel 73 im AI Act Service Desk
• FAQ der Kommission zum Umsetzungszeitplan: Navigating the AI Act
• FAQ der Kommission zur Standardisierung: Understanding the standardisation of the AI Act
• Vorschlag der Kommission, der noch beraten wird: COM(2025) 811 final

Typische Fehler, an denen Artikel-72-Pläne scheitern

Die meisten Schwächen sind operativ, nicht theoretisch. Teams schreiben den Plan wie ein Memo, während Regulierer und Prüfer ihn als Nachweis einer tatsächlich laufenden Betriebsfähigkeit behandeln werden.

Ein guter Praxistest lautet: Könnte ein Dritter anhand Ihres Plans erkennen, wie das System überwacht wird, wer Auffälligkeiten untersucht, wie Produktionsänderungen das Sampling beeinflussen und was gemeldet oder zurückgerollt wird, wenn Schwellenwerte überschritten werden?

• Post-Market-Monitoring als Dashboard statt als Betriebsverfahren behandeln.
• Nur die Modellqualität überwachen und Tool-Nutzung, Freigaben, Overrides sowie nachgelagerte Auswirkungen ignorieren.
• Metriken ohne Schwellenwerte, Verantwortliche, Schweregradlogik oder Reaktionszeiten auflisten.
• Interaktionen mit anderen KI-Systemen in agentischen Workflows vergessen.
• Rohlogs aufbewahren, aber keine Vorfallentscheidungen, Prüferbegründungen oder Evidenz zu Korrekturmaßnahmen sichern.
• Monitoring von der Change Control entkoppeln, sodass jedes Release das Risiko neu setzt, ohne die Prüfintensität zu erhöhen.
• Annehmen, dass die Dokumentation des Modellanbieters das systembezogene Monitoring des Anbieters ersetzt.