Template: Post-Market Monitoring Plan nach Art. 72

Wofür

Der Post-Market Monitoring Plan beschreibt, wie ein Hochrisiko-KI-System nach dem Inverkehrbringen systematisch beobachtet wird: welche Daten aus dem realen Betrieb erhoben werden, woran sich eine Verschlechterung der Leistung oder ein neu auftretendes Risiko zeigt, wer die Auswertung verantwortet und was ab welcher Schwelle passiert. Er ist kein Betriebs-Dashboard und kein Reporting an das Management. Er ist der dokumentierte Nachweis, dass die Annahmen aus dem Risk Assessment nach Art. 9 in der Praxis nachgehalten werden — und die Brücke zwischen laufendem Betrieb und den Meldepflichten nach Art. 73. Der Plan wird pro KI-System oder System-Familie geführt, ist Teil der technischen Dokumentation nach Anhang IV und wird nach jeder wesentlichen Änderung fortgeschrieben.

Wann es Pflicht ist

Art. 72 der KI-Verordnung (VO 2024/1689) verpflichtet Provider 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. Das System sammelt, dokumentiert und analysiert relevante Daten über die Leistung des Hochrisiko-KI-Systems während seiner gesamten Lebensdauer — auch Daten, die Deployer bereitstellen — und erlaubt es dem Provider zu prüfen, ob die Anforderungen aus Kapitel III Abschnitt 2 fortlaufend eingehalten werden. Grundlage ist ein Post-Market Monitoring Plan, der Bestandteil der technischen Dokumentation nach Anhang IV ist; die Kommission ist beauftragt, dafür ein Musterformat bereitzustellen. Für Systeme, die bereits anderem Unionsrecht mit vergleichbaren Post-Market-Pflichten unterliegen, sieht Art. 72 die Integration in die dort bestehenden Systeme vor, statt eine zweite Struktur daneben zu bauen.

Die Pflichten für Hochrisiko-KI greifen mit dem Enforcement-Termin 02.12.2027. Ein Monitoring-Plan, der erst dann entsteht, hat zu diesem Zeitpunkt keine Historie — und Historie ist genau das, was er belegen soll.

Das Artefakt selbst

# Post-Market Monitoring Plan — [System-Name], Version [X.Y]

## 1. Geltungsbereich und Rollen
- KI-System / Modell-Version / Einsatzzweck:
- Eigene Rolle: [ ] Provider  [ ] Deployer mit Provider-Pflichten (Art. 25)
- Betroffene Rechtsräume (DE / EU27-Rest / UK / CH):
- Verantwortlich für Auswertung (Rolle, nicht Person):
- Verweis auf technische Dokumentation (Anhang IV, Abschnitt):
- Review-Zyklus / letzte Fortschreibung:

## 2. Was beobachtet wird (Ableitung aus Art. 9)
| Risiko aus Risk Assessment | Beobachtbares Signal | Metrik | Datenquelle |
|---|---|---|---|
| | | | |
| | | | |
| Nicht überwacht — Begründung | | | |

## 3. Metriken und Schwellenwerte
| Metrik | Definition | Zielwert | Warnschwelle | Eskalationsschwelle | Messfrequenz |
|---|---|---|---|---|---|
| Genauigkeit / Fehlerrate | | | | | |
| Verteilungs-Drift (Input) | | | | | |
| Ergebnis-Drift (Output) | | | | | |
| Fairness-/Gruppenkennzahl | | | | | |
| Human-Override-Quote (Art. 14) | | | | | |
| Beschwerden / Widersprüche | | | | | |
| Verfügbarkeit / Robustheit (Art. 15) | | | | | |

## 4. Datenquellen und Zuflüsse
- Systemlogs nach Art. 12 (Umfang, Aufbewahrung):
- Rückmeldungen der Deployer (Kanal, Frequenz, vertragliche Grundlage):
- Beschwerden Betroffener und Ergebnisse aus Art. 14:
- Externe Quellen (Behörden-Leitfäden, Sicherheitsmeldungen, Vendor-Advisories):
- Ausgeschlossene Quellen und Begründung (z. B. Datenschutz):

## 5. Auswertung
- Turnus (z. B. monatlich operativ, quartalsweise Gesamtbewertung):
- Auswertende Rolle / Vier-Augen-Prinzip:
- Bewertungsmaßstab: Abweichung vom Zustand der Konformitätsbewertung
- Dokumentationsort des Auswertungsberichts:

## 6. Reaktionspfade
| Auslöser | Sofortmaßnahme | Verantwortlich | Frist | Nachweis |
|---|---|---|---|---|
| Warnschwelle überschritten | | | | |
| Eskalationsschwelle überschritten | | | | |
| Verdacht auf schwerwiegenden Vorfall | Übergabe an Incident-Prozess (Art. 73) | | unverzüglich | |
| Systemisches Risiko / Rückruf-Prüfung | | | | |

## 7. Rückkopplung in die Governance
- Update Risk Assessment (Art. 9) — Auslöser und Zuständigkeit:
- Update technische Dokumentation (Anhang IV):
- Prüfung: wesentliche Änderung mit erneuter Konformitätsbewertung (Art. 43)?
- Information der Deployer (Kanal, Inhalt):

## 8. Nachweisführung
- Ablage der Auswertungsberichte (Ort, Format, Aufbewahrungsdauer):
- Unveränderbarkeit / Versionierung der Auswertungen:
- Verknüpfung zu Vorfall-Register und AIMS-Kontrollen:

## 9. Freigabe
- Erstellt / geprüft durch (Rolle) / am:
- Nächstes Review:

Ausfüll-Anleitung

1. Abschnitt 2 vor Abschnitt 3 füllen. Metriken ohne Herleitung aus dem Risk Assessment sind Betriebskennzahlen, kein Post-Market Monitoring. Jede Zeile beginnt bei einem konkreten Risiko, nicht bei einer verfügbaren Messgröße.
2. Die Zeile "nicht überwacht" ausfüllen. Bewusst begründete Auslassungen sind belastbar; stillschweigende Lücken sind es nie.
3. Schwellenwerte beziffern. "Auffällige Abweichung" ist kein Schwellenwert. Wo eine belastbare Zahl fehlt, wird eine vorläufige Schwelle mit Begründung und Überprüfungsdatum gesetzt.
4. Referenzpunkt ist die Konformitätsbewertung, nicht der Vormonat. Die Frage lautet: Verhält sich das System noch so wie in dem Zustand, für den die Konformität festgestellt wurde?
5. Deployer-Daten vertraglich absichern. Art. 72 rechnet mit Rückmeldungen aus dem Einsatz. Wer keinen Kanal und keine vertragliche Grundlage hat, überwacht nur die Laborsicht.
6. Human-Override-Quote und Beschwerden nicht auslassen. Beide zeigen Qualitätsprobleme oft früher als technische Metriken.
7. Die Grenze zu Art. 73 sauber ziehen. Der Monitoring-Prozess erkennt und bewertet; sobald der Verdacht auf einen schwerwiegenden Vorfall besteht, übernimmt der Incident-Prozess mit eigenen Fristen.
8. Abschnitt 7 ist der Punkt, an dem der Plan wirkt. Auswertungen, die nie ein Risk Assessment oder eine Doku ändern, sind Ablage, nicht Governance.
9. Bestehende Post-Market-Systeme integrieren. Wo sektorales Unionsrecht bereits Marktbeobachtung verlangt, wird der KI-Teil dort eingebettet — mit klarer Kennzeichnung, welche Elemente Art. 72 abdecken.

Audit-Erwartung

Auditoren prüfen zuerst, ob der Plan gelebt wird: Gibt es Auswertungsberichte über mehrere Perioden, mit Datum, Verantwortlichem und erkennbarer Konsequenz? Ein perfekt formulierter Plan ohne einen einzigen Auswertungszyklus gilt als nicht implementiert. Typische Prüffragen sind die Herleitung der Metriken aus dem Risk Assessment, die Nachvollziehbarkeit einer überschrittenen Schwelle bis zur ergriffenen Maßnahme und der Umgang mit Deployer-Rückmeldungen. Quergelesen wird mit dem Logging-Konzept nach Art. 12 — die im Plan genannten Datenquellen müssen tatsächlich erhoben und aufbewahrt werden — sowie mit der technischen Dokumentation nach Anhang IV, in der der Plan referenziert ist. Rote Flaggen: Metriken ohne Schwellenwerte, Auswertungen ohne Adressaten, und ein Plan, der seit der Konformitätsbewertung unverändert ist, obwohl das Modell mehrfach aktualisiert wurde.

Verwandte Artefakte

• Template: AI Risk Assessment nach Art. 9 — Quelle aller Monitoring-Metriken
• Template: Incident Response Plan für KI-Vorfälle — übernimmt ab Verdacht auf schwerwiegenden Vorfall
• Template: Logging-Konzept nach Art. 12 — liefert die Datenbasis
• Template: Technische Dokumentation nach Anhang IV — enthält den Plan als Bestandteil
• Template: Human Oversight-Konzept nach Art. 14 — Overrides als Frühindikator

Warum kontinuierliche Beobachtung mehr ist als ein Pflichtdokument: Continuous Assurance und Post-Market Monitoring auf eu-ai-verordnung.de.

AEGIRA AI Guardian operationalisiert diese Artefakte als laufende Trust-Infrastructure — aegira.ai.