Beobachtung nach dem Inverkehrbringen – Post-Market-Monitoring nach Art. 72 AI Act umsetzen

Die CE-Kennzeichnung ist gesetzt, die Konformitätsbewertung abgeschlossen, das Hochrisiko-KI-System läuft im Markt – und viele Anbieter atmen auf, als wäre die Compliance-Arbeit erledigt. Ein teurer Irrtum. Denn genau an diesem Punkt beginnt eine Pflicht, die im Alltag regelmäßig übersehen wird: die Beobachtung nach dem Inverkehrbringen, das Post-Market-Monitoring nach dem AI Act. Artikel 72 des AI Act verpflichtet Sie, Ihr System über seinen gesamten Lebenszyklus systematisch zu überwachen. Wer das ignoriert, verliert nicht nur die Kontrolle über die reale Leistung seines Systems, sondern verstößt – sobald die Hochrisiko-Pflichten gelten (Anhang III ab 2. Dezember 2027, Anhang I ab 2. August 2028) – gegen EU-Recht.

Was Art. 72 AI Act verlangt – und warum die Pflicht oft übersehen wird

Die Beobachtung nach dem Inverkehrbringen (englisch: post-market monitoring, kurz PMM) ist kein Häkchen auf einer Checkliste. Sie ist ein aktiver, kontinuierlicher Prozess. Art. 72 verlangt von Anbietern, dass sie systematisch Daten über die Leistung ihres KI-Systems sammeln, dokumentieren und analysieren – während der gesamten Lebensdauer und in einer der Art und den Risiken des Systems angemessenen Weise.

Der entscheidende Denkfehler vieler Unternehmen: Sie behandeln Compliance als Zustand, der mit der Konformitätsbewertung erreicht ist. Tatsächlich ist Compliance ein Prozess über den gesamten Lebenszyklus. Die Konformitätsbewertung nach Art. 43 prüft das System zu einem bestimmten Zeitpunkt unter definierten Bedingungen. Doch KI-Systeme verhalten sich im realen Betrieb anders als im Labor: Eingabedaten verschieben sich, Nutzungskontexte ändern sich, Modelle driften. Ein Kreditscoring-System, das bei der Bewertung fair kalibriert war, kann Monate später systematisch bestimmte Bevölkerungsgruppen benachteiligen, weil sich die zugrunde liegende Datenverteilung verschoben hat.

Die Pflicht trifft primär Anbieter von Hochrisiko-KI-Systemen im Sinne von Anhang III und Anhang I. Wer ein solches System entwickelt und unter eigenem Namen oder eigener Marke in den Verkehr bringt, ist verantwortlich – unabhängig davon, ob das System selbst betrieben oder an Dritte weitergegeben wird. Betreiber (Deployer) sind zwar nicht Adressat des Art. 72, spielen aber, wie später deutlich wird, eine unverzichtbare Rolle als Datenquelle.

Der Post-Market-Monitoring-Plan als Herzstück

Im Zentrum der Pflicht steht der Post-Market-Monitoring-Plan. Und dieser Plan ist kein internes Nice-to-have, sondern verpflichtender Bestandteil der technischen Dokumentation nach Anhang IV. Das bedeutet: Ohne dokumentierten PMM-Plan ist Ihre technische Dokumentation unvollständig – und damit die gesamte Konformität angreifbar. Wie der Plan in die Gesamtstruktur der Nachweise eingebettet ist, zeigt unser Beitrag zur technischen Dokumentation.

Was in den Plan gehört

Der PMM-Plan beschreibt, wie Sie systematisch Leistungsdaten sammeln, dokumentieren und analysieren. Konkret legt er fest:

Welche Daten erhoben werden (Leistungskennzahlen, Fehlerraten, Feedback)
Aus welchen Quellen die Daten stammen (Betrieb, Nutzer, gekoppelte Systeme)
In welchem Turnus ausgewertet wird
Welche Schwellenwerte eine vertiefte Analyse oder Korrekturmaßnahme auslösen
Wer verantwortlich ist und wie die Erkenntnisse zurückfließen

Spätestens hier stellt sich die praktische Frage, womit Sie diese laufende Beobachtung und ihre lückenlose Dokumentation dauerhaft und nachweisbar erfüllen. Denn Monitoring erzeugt über Jahre hinweg eine kontinuierliche Nachweiskette, die manuell kaum revisionssicher zu führen ist. Eine Software für die AI-Act-Dokumentation hilft, Datensammlung, Auswertungsintervalle und Korrekturmaßnahmen strukturiert und versioniert zu verwalten, statt sie in verstreuten Tabellen zu verlieren.

Musterplan der Kommission

Sie müssen den Plan nicht auf der grünen Wiese entwerfen. Ursprünglich sollte die Kommission per Durchführungsrechtsakt eine verbindliche Musterplan-Vorlage erlassen. Seit dem Digital Omnibus (in Kraft seit 27. Juli 2026) sieht Art. 72 Abs. 3 stattdessen Leitlinien der Kommission samt freiwilliger Vorlage bis zum 2. September 2027 vor. Die Pflicht zum PMM-Plan selbst bleibt unverändert. Bis zur Veröffentlichung der Leitlinien sollten Sie sich an den gesetzlichen Vorgaben und etablierten Grundsätzen des Post-Market-Monitoring aus der Produktsicherheit orientieren – die Struktur wird sich daran anlehnen, sodass eine frühzeitig aufgebaute Systematik nicht verloren ist.

Welche Daten Sie für das PMM-System sammeln und auswerten

Die Kernfrage lautet: Was heißt „relevante Daten” konkret? Art. 72 nennt Leistungsdaten aus dem realen Betrieb. In der Praxis umfasst das mindestens drei Kategorien:

Datenkategorie	Beispiele	Zweck
Leistungsdaten	Genauigkeit, Fehlerraten, Latenz, Drift-Indikatoren	Fortdauernde technische Konformität
Nutzerfeedback	Beschwerden, korrigierte Fehlentscheidungen, Support-Tickets	Erkennen realer Fehlwirkungen
Interaktionsdaten	Verhalten im Zusammenspiel mit anderen Systemen	Systemische Risiken erkennen

Der Maßstab der Auswertung ist entscheidend: Sie analysieren die Daten im Hinblick auf die fortdauernde Konformität mit den Anforderungen aus Kapitel III – also den Pflichten für Hochrisiko-KI (Risikomanagement, Daten-Governance, Genauigkeit, Robustheit, menschliche Aufsicht). Es geht nicht darum, ob das System „irgendwie funktioniert”, sondern ob es die spezifischen Anforderungen dauerhaft erfüllt.

Rechenbeispiel

Ein Anbieter eines KI-Systems zur Bewerbervorauswahl definiert im PMM-Plan eine akzeptable Abweichung der Auswahlquote zwischen Geschlechtergruppen von maximal fünf Prozentpunkten. Im ersten Quartal nach Markteinführung liegt die Differenz bei 3 Prozentpunkten – unauffällig. Im dritten Quartal, nach einem Update der Trainingsdaten, steigt sie auf 9 Prozentpunkte. Ohne systematisches Monitoring bliebe diese Verschlechterung unentdeckt, bis Beschwerden eskalieren. Mit definiertem Schwellenwert löst die Überschreitung automatisch eine Untersuchung und eine Korrekturmaßnahme aus.

Betreiberdaten einbeziehen

Ein Großteil der aussagekräftigen Daten entsteht dort, wo das System tatsächlich genutzt wird – beim Betreiber. Der Anbieter hat auf diese Daten aber keinen automatischen Zugriff. Deshalb müssen Sie den Datenfluss zwischen Betreiber und Anbieter vertraglich regeln. Legen Sie in Nutzungs- oder Lieferverträgen fest, welche Leistungs- und Vorfalldaten der Betreiber in welchem Format und in welchem Intervall bereitstellt. Ohne solche Klauseln bleibt Ihr Monitoring blind für die reale Nutzung.

Verzahnung mit Risikomanagement, Logging und Meldepflichten

Art. 72 steht nicht isoliert. Er ist der Motor, der drei zentrale Compliance-Systeme miteinander verbindet.

Rückkopplung in das Risikomanagement (Art. 9)

Das Risikomanagement-System nach Art. 9 ist ausdrücklich als kontinuierlicher, iterativer Prozess ausgestaltet. Erkenntnisse aus dem Monitoring sind der wichtigste Input für dessen Aktualisierung: Zeigt die Beobachtung neue oder verschärfte Risiken, müssen diese bewertet und mit Maßnahmen adressiert werden. Monitoring ohne Rückkopplung ist wertlos – wie diese Schleife funktioniert, erläutert unser Beitrag zum Risikomanagement-System.

Protokolle als Datenbasis (Art. 12)

Woher kommen die technischen Leistungsdaten? Zu einem großen Teil aus den automatischen Protokollen (Logs) nach Art. 12. Die Pflicht zur Aufzeichnung ist damit kein Selbstzweck, sondern liefert die Rohdaten, auf denen Ihr Monitoring aufsetzt. Wer seine Logging-Architektur sauber aufsetzt, spart im Monitoring erheblich Aufwand – die Details zu den Aufzeichnungspflichten finden Sie im Beitrag zu Logging und Aufzeichnungspflichten nach Art. 12.

Schnittstelle zur Vorfallmeldung (Art. 73)

Ergibt das Monitoring einen schwerwiegenden Vorfall, greift die Meldepflicht nach Art. 73. Art. 72 und Art. 73 greifen unmittelbar ineinander: Das Monitoring ist das Frühwarnsystem, die Vorfallmeldung die gesetzlich vorgeschriebene Reaktion bei Überschreiten der Schwelle. Die Meldefristen sind eng – teils wenige Tage –, weshalb der Übergang vom Monitoring zur Meldung im Prozess klar definiert sein muss. Was als schwerwiegender Vorfall gilt und welche Fristen gelten, lesen Sie im Beitrag zur Meldepflicht schwerwiegender Vorfälle.

So setzen Sie das Post-Market-Monitoring praktisch um

Von der Pflicht zur gelebten Praxis führt ein überschaubarer, aber verbindlicher Weg.

Verantwortlichkeiten festlegen und ins QMS integrieren

Benennen Sie eindeutig, wer für Datensammlung, Auswertung und Eskalation zuständig ist. Das Post-Market-Monitoring ist kein Sonderprojekt. Es gehört fest in Ihr Qualitätsmanagementsystem nach Art. 17 verankert – dort, wo Prozesse, Verantwortlichkeiten und Dokumentation ohnehin geregelt sind. Wie Sie das QMS aufbauen und das Monitoring darin einbetten, zeigt der Beitrag zum Qualitätsmanagementsystem nach Art. 17.

Turnus und Trigger definieren

Legen Sie zwei Auslösemechanismen fest:

Zeitbasierter Turnus – regelmäßige Auswertung, z. B. monatlich oder quartalsweise, angemessen zum Risiko des Systems.
Ereignisbasierte Trigger – definierte Schwellenwerte (z. B. Fehlerrate über X %, Drift-Kennzahl über Y), die unabhängig vom Turnus sofort eine Analyse auslösen.

Ein System mit hoher Nutzungsfrequenz und hohem Schadenspotenzial braucht kürzere Intervalle als ein selten genutztes System mit begrenzter Wirkung.

Korrekturmaßnahmen und Dokumentationskette

Ergibt die Auswertung eine Abweichung, greift eine definierte Korrekturmaßnahmen-Kette:

Ursachenanalyse
Bewertung, ob die Konformität mit Kapitel III noch gegeben ist
Festlegung der Maßnahme (Nachjustierung, Update, ggf. Rückruf)
Rückkopplung in das Risikomanagement
Prüfung der Melde- und Informationspflichten
lückenlose Dokumentation jedes Schrittes

Diese Dokumentationskette ist bei einer Marktüberwachungsprüfung Ihr zentraler Nachweis, dass Sie die Beobachtung tatsächlich betreiben – nicht nur behaupten.

Häufige Fehler bei der Überwachung von Hochrisiko-KI und Fristen

Die drei typischen Fehler

Monitoring als Einmal-Aktion. Der häufigste Fehler: Der PMM-Plan wird für die Dokumentation einmal geschrieben und dann nie gelebt. Art. 72 verlangt ausdrücklich einen Dauerprozess über die gesamte Lebensdauer. Ein Plan ohne laufende Auswertung erfüllt die Pflicht nicht.

Fehlende Datenflüsse zwischen Betreiber und Anbieter. Ohne vertragliche und technische Regelung erreichen die relevanten Betriebsdaten den Anbieter nie. Das Monitoring läuft dann formal, aber ohne echte Datenbasis – und übersieht genau die Probleme, die im realen Einsatz entstehen.

Verwechslung von Monitoring und Vorfallmeldung. Beides ist getrennt, aber verbunden. Monitoring ist laufend und intern; die Vorfallmeldung nach Art. 73 ist ein fristgebundenes externes Ereignis. Wer die Abgrenzung nicht kennt, verpasst Meldefristen.

Zeitliche Einordnung

Der AI Act gilt gestaffelt. Die Pflichten für Hochrisiko-KI-Systeme nach Anhang III – und damit auch das Post-Market-Monitoring nach Art. 72 – greifen nach dem Digital Omnibus ab dem 2. Dezember 2027, für Hochrisiko-KI nach Anhang I ab dem 2. August 2028. Das sind feste Termine. Wer heute ein Hochrisiko-System entwickelt, sollte den PMM-Plan bis dahin fertig und den Prozess betriebsbereit haben; die Leitlinien der Kommission samt Vorlage sind bis 2. September 2027 angekündigt. Der Aufbau von Datenflüssen, Verantwortlichkeiten und Auswertungslogik braucht Vorlauf – ein spätes Anfangen rächt sich. Die genaue zeitliche Einordnung aller Hochrisiko-Pflichten finden Sie im Beitrag zu den Fristen für Hochrisiko-KI.

Fazit

Die Beobachtung nach dem Inverkehrbringen ist der Beweis dafür, dass Compliance im AI Act kein Zustand, sondern ein Prozess ist. Art. 72 verpflichtet Anbieter von Hochrisiko-KI-Systemen, die reale Leistung ihrer Systeme über den gesamten Lebenszyklus aktiv und kontinuierlich zu beobachten. Herzstück ist der Post-Market-Monitoring-Plan, der als verpflichtender Bestandteil der technischen Dokumentation festhält, welche Daten aus Betrieb, Nutzerfeedback und Systeminteraktionen gesammelt und im Hinblick auf die fortdauernde Konformität mit Kapitel III ausgewertet werden. Leitlinien der Kommission mit einer freiwilligen Vorlage (bis 2. September 2027) sollen die Struktur zusätzlich vereinheitlichen.

Entscheidend ist die Verzahnung: Das Post-Market-Monitoring speist das Risikomanagement nach Art. 9, nutzt die Protokolle nach Art. 12 als Datenbasis und bildet die Schnittstelle zur Vorfallmeldung nach Art. 73. In der Praxis brauchen Sie klare Verantwortlichkeiten im QMS, einen definierten Turnus samt ereignisbasierten Triggern, eine belastbare Korrekturmaßnahmen-Kette und vertraglich geregelte Datenflüsse mit Ihren Betreibern. Wer diese Elemente rechtzeitig vor der Geltung der Hochrisiko-Pflichten (Anhang III ab 2. Dezember 2027) aufbaut, verwandelt eine leicht übersehene Pflicht in ein funktionierendes Frühwarnsystem für die eigene Konformität.