Post-Market Monitoring Plan (PMMP)

gemäss Art. 72 der Verordnung (EU) 2024/1689 (EU AI Act)

Feld	Wert
Provider	[Beispiel-Unternehmen GmbH]
KI-System	EnterpriseAssistant-GPAI
Annex-Pfad	annexiii4employment
Klassifikation	highrisk
Monitoring-Frequenz (engine-empfohlen)	quartalsweise + bei Trigger-Ereignissen
Plan gültig ab	〔Markteintritts-Datum YYYY-MM-DD〕
Erstellt am	2026-05-13
Engine-Version	AI-ACT-2024-1689-v5.12.0

> Rechtsgrundlage: Art. 72 EU AI Act + Recital 156-158. Dieser Plan ist Bestandteil der Technischen Dokumentation (Annex IV §11) und muss vor dem Markteintritt vorliegen. > > Aufnahme in QMS: Nach Art. 72(2)(c) muss dieses Monitoring-System in das Qualitätsmanagement-System (Art. 17) integriert sein. > > Verbindlich: Diese Vorlage ist ein automatisch erstellter Entwurf. Die Commission wird bis 2. Februar 2026 einen detaillierten Template-Implementing-Act veröffentlichen (Art. 72(3)) — bei Verfügbarkeit ist die Vorlage entsprechend anzupassen.

---

1. Monitoring-Ziele und -Scope (Art. 72(1))

1.1 Übergeordnete Ziele

Das Post-Market Monitoring System hat folgende Ziele:

1. Performance-Tracking: Sicherstellen, dass das System im Produktionsbetrieb die in der Technischen Dokumentation deklarierten Performance-Werte erreicht. 2. Compliance-Sicherung: Kontinuierliche Konformität mit Title III, Chapter II EU AI Act gewährleisten. 3. Risiko-Erkennung: Frühzeitige Erkennung neuer oder veränderter Risiken (insbesondere Art. 79-Risiken). 4. Kontinuierliche Verbesserung: Daten-getriebene Optimierung des Systems über den gesamten Lebenszyklus.

1.2 Scope

Aspekt	Wert
Systeme im Scope	EnterpriseAssistant-GPAI (alle Versionen, alle Deployments)
Geographische Abdeckung	EU + EWR
Lebenszyklus-Phase	Markteintritt bis End-of-Life
Daten-Quellen	Telemetrie / Logs / Deployer-Reports / User-Feedback / Incident-Reports

1.3 Engine-detected Risiko-Indikatoren

Folgende Engine-Flags definieren spezifische Monitoring-Schwerpunkte:

• USESGPAI: uses gpai
• GPAIINHIGHRISK: gpai in high risk
• DEADLINEANNEXIII_2026: deadline annex iii 2026

---

2. Monitoring-Architektur (Art. 72(1)(a))

2.1 Daten-Sammlung

Daten-Typ	Quelle	Frequenz	Aufbewahrung
Inferenz-Telemetrie (Latenz, Throughput)	System-Logs (Art. 12)	kontinuierlich	mind. 6 Monate, empfohlen 10 Jahre
Genauigkeits-Metriken (rolling)	Production-Validation-Set	täglich	Lifecycle
Confidence-Distribution	Inference-Pipeline	kontinuierlich	mind. 6 Monate
Drift-Indikatoren (PSI / KS-Test)	Daten-Pipeline	wöchentlich	Lifecycle
Bias-Metriken	Demographic-Slicing	monatlich	Lifecycle
User-Feedback / Beschwerden	Beschwerde-Kanal	bei Eingang	10 Jahre
Override-Events (durch Operator)	Audit-Log	kontinuierlich	mind. 6 Monate
Cybersecurity-Events	SIEM	kontinuierlich	mind. 12 Monate
Deployer-Reports (Art. 26(5))	Deployer-Reporting-Channel	bei Eingang	10 Jahre

2.2 Monitoring-Tool-Stack

〔Welche Tools sind eingesetzt? z.B. Datadog für Telemetrie, Evidently/Fiddler für Drift, eigenes Compliance-Dashboard〕

2.3 Daten-Eigentum + Zugriff

Rolle	Zugriff	Lese-/Schreib-Recht
Provider Compliance-Officer	Vollzugriff	r/w
Provider Tech-Lead	Vollzugriff	r/w
Deployer (eigenes Deployment)	Eigene Telemetrie	r
Aufsichtsbehörde	Auf Anfrage (Art. 21)	r

---

3. Performance-Schwellenwerte und Alarme (Art. 72(1)(b))

3.1 Performance-Schwellenwerte

Metrik	Soll-Wert (Tech-Doc)	Alarm-Schwelle	Eskalations-Schwelle	Aktion
〔Hauptmetrik z.B. Accuracy〕	〔z.B. ≥ 0.92〕	〔< 0.90〕	〔< 0.85〕	〔Re-Training trigger〕
Inferenz-Latenz P95	〔z.B. < 500 ms〕	〔> 800 ms〕	〔> 1500 ms〕	〔Capacity-Scaling〕
Error-Rate	〔z.B. < 0.5 %〕	〔> 1.0 %〕	〔> 2.0 %〕	〔Investigation〕
PSI (Population Stability Index)	〔< 0.1〕	〔0.1 - 0.2〕	〔> 0.2〕	〔Drift-Investigation〕
Disparate Impact (Bias)	〔> 0.8〕	〔0.7 - 0.8〕	〔< 0.7〕	〔Bias-Correction〕

3.2 Drift-Detection

⚠️ GPAI-Integration: Drift kann durch Provider-seitige Modell-Updates des GPAI-Anbieters entstehen. Monitor GPAI-Modell-Versions-Strings im API-Response und triggere Re-Validation bei Änderung.

3.3 Alarmierungs-Kanäle

Schweregrad	Kanal	Reaktions-SLA
INFO	Dashboard	n/a
WARNING	E-Mail + Dashboard	24h
ALERT	Slack/Teams + E-Mail	4h
CRITICAL	PagerDuty + Telefon	30 min
INCIDENT	Compliance-Officer + Geschäftsleitung	sofort

---

4. Inzident-Management (Art. 73 + Art. 72(1)(c))

4.1 Schwerwiegende Vorfälle (Art. 3 Nr. 49 + Art. 73)

Ein schwerwiegender Vorfall liegt nach Art. 3 Nr. 49 vor bei:

• (a) Tod oder schwere Gesundheits-Schädigung einer Person
• (b) Schwere und unwiderrufliche Störung der Verwaltung kritischer Infrastruktur
• (c) Verletzung von Unionsrecht zum Schutz von Grundrechten
• (d) Schwere Sach- oder Umwelt-Schäden

4.2 Meldepflicht-Workflow

Phase	Aktion	Frist
1. Erkennung	Incident-Detection (auto via Monitoring + manuell via Deployer-Reports)	< 24h
2. Sofort-Massnahme	System-Pausierung / Quarantäne / Roll-Back	< 4h
3. Initial-Meldung	Meldung an BNetzA (zentrale Marktaufsichtsbehörde für AI Act in Deutschland)	innerhalb 15 Tagen ab Bekanntwerden
4. Ursachen-Analyse	Root-Cause-Analyse durch Tech + Compliance	< 30 Tage
5. Korrektur-Massnahmen	Implementierung + Validation	sektor-abhängig
6. Final-Bericht	Ausführlicher Bericht an Behörde	〔per Behörde-Anforderung〕

4.3 Spezielle Fristen

Vorfall-Typ	Meldefrist
Tod oder weit verbreiteter Schaden (Art. 73(3))	2 Tage
Verstoss gegen EU-Grundrechte (Art. 73(4))	2 Tage
Kritische-Infrastruktur-Störung (Art. 73(5))	2 Tage
Andere schwerwiegende Vorfälle	15 Tage

4.4 Meldekanäle

Land	Behörde	Meldekanal
DE	BNetzA (zentrale Marktaufsichtsbehörde für AI Act in Deutschland)	〔Online-Portal / E-Mail〕

---

5. Deployer-Feedback-Loop (Art. 26(5) + Art. 72(1)(d))

5.1 Reporting-Pflichten der Deployer

Nach Art. 26(5) müssen Deployer dem Provider folgende Informationen weitergeben:

• Beobachtete Risiken nach Art. 79(1)
• Schwerwiegende Vorfälle (Art. 73)
• Performance-Beobachtungen, die die Konformität betreffen

5.2 Reporting-Kanal für Deployer

Aspekt	Wert
Reporting-URL / Portal	〔z.B. [beispiel-unternehmengmbh].com/deployer-feedback〕
E-Mail	〔z.B. ai-risk@[beispiel-unternehmengmbh].com〕
Hotline (24/7 für CRITICAL)	〔Telefon〕
Standardisierte Reporting-Templates	〔URL zu Templates / Web-Formular〕

5.3 SLA für Deployer-Reports

Severity	Provider-Reaktion
CRITICAL (Art. 73 Vorfall)	< 4h Acknowledgment + Sofort-Untersuchung
ALERT (Konformitäts-Risiko)	< 24h Triage
INFO (Performance-Beobachtung)	< 5 Werktage

---

6. Bewertung der kontinuierlichen Konformität (Art. 72(1)(b))

6.1 Quartalsweise Compliance-Review

Mindestens quartalsweise wird folgendes überprüft:

Anforderung (EU AI Act)	Methode der Überprüfung	Verantwortliche/r
Art. 9 — Risk Management noch aktuell?	Risk-Register-Review	Compliance-Officer
Art. 10 — Trainings-Daten noch repräsentativ?	Drift-Analyse + Re-Validation	Data-Lead
Art. 11 — Tech-Doc auf aktuellem Stand?	Document-Diff vs. System-Stand	Tech-Lead
Art. 12 — Logs vollständig und auditierbar?	Log-Integrity-Check	DevOps-Lead
Art. 13 — Instructions noch korrekt?	UI-Diff + Update-Notwendigkeit	Product-Owner
Art. 14 — Human Oversight effektiv?	Override-Rate-Analyse	Compliance-Officer
Art. 15 — Genauigkeit + Robustheit + Cybersecurity OK?	Pen-Test + Performance-Audit	Security-Lead

6.2 Substantial-Modification-Trigger

Folgende Beobachtungen lösen eine Re-Klassifikation nach Art. 25(1) aus:

• Performance-Drift > Eskalations-Schwelle für > 30 Tage
• Bias-Metriken über Eskalations-Schwelle
• Erweiterung der Zweckbestimmung (auch durch Deployer-Praxis)
• Wesentliche Modell-Updates (Modell-Logik, nicht nur Re-Training)
• Neue Modalitäten (z.B. Vision hinzugefügt)

---

7. Integration in das Qualitätsmanagement-System (Art. 72(2)(c) + Art. 17)

7.1 QMS-Schnittstellen

QMS-Element	PMMP-Integration
Document Control	PMMP-Dokumente folgen QMS-Versions-Kontrolle
Internal Audits	PMMP wird mindestens jährlich auditiert
Management Review	PMMP-KPIs sind Tagesordnungs-Punkt im quarterly Management-Review
Corrective + Preventive Actions (CAPA)	Inzidenten triggern CAPA-Prozess
Training	Training für PMMP-Operatoren ist Pflicht-Modul

7.2 Verantwortlichkeiten (RACI)

Aktivität	Responsible	Accountable	Consulted	Informed
Daten-Sammlung	DevOps	CTO	Compliance	Geschäftsleitung
Drift-Analyse	Data-Science	CTO	Compliance	—
Inzident-Erkennung	Operations	CTO	Compliance	Geschäftsleitung
Behörden-Meldungen	Compliance-Officer	CEO	Legal	Geschäftsleitung
Quartals-Review	Compliance-Officer	CTO	Tech-Lead	Geschäftsleitung

7.3 KPIs für Geschäftsleitung

KPI	Definition	Target
Compliance-Score	% erfüllte Quartals-Compliance-Items	≥ 95 %
Inzident-Rate	Inzidente / Monat	〔Target〕
Mean-Time-to-Detection (MTTD)	Median Zeit Vorfall → Erkennung	〔Target〕
Mean-Time-to-Resolution (MTTR)	Median Zeit Erkennung → Behebung	〔Target〕
Meldepflicht-Compliance	% rechtzeitiger Behörden-Meldungen	100 %

---

8. Plan-Review und -Update

8.1 Plan-Review-Frequenz

Trigger	Review-Tiefe
Substantial Modification (Art. 25)	Vollständiger Review
Schwerwiegender Vorfall	Sektions-spezifischer Review
Jährlich	Vollständiger Review als Teil der QMS-Audit
Behörden-Anfrage	Wie angefordert
EU AI Act Update / Implementing Act	Vollständiger Review

8.2 Versions-Historie

Version	Datum	Änderung	Autor
〔v1.0〕	2026-05-13	Initial-Version	〔Name〕

8.3 Plan-Genehmigung

Rolle	Name	Datum	Unterschrift
Compliance-Officer	〔Name〕	〔YYYY-MM-DD〕	〔...〕
Tech-Lead	〔Name〕	〔YYYY-MM-DD〕	〔...〕
Quality-Manager	〔Name〕	〔YYYY-MM-DD〕	〔...〕
CEO / Geschäftsleitung	〔Name〕	〔YYYY-MM-DD〕	〔...〕

---

> Dieser Post-Market Monitoring Plan wurde am 2026-05-13 mit ai-risk-check.com (Engine AI-ACT-2024-1689-v5.12.0) als Vorlage erstellt. Die Commission wird bis Q1 2026 ein detaillierteres Template via Implementing Act veröffentlichen — bei Verfügbarkeit ist die Vorlage entsprechend anzupassen. Die finale Validität liegt beim Provider. > > Audit-Trail-Hash: 〔Hash aus Audit-Package einfügen〕