Purpose
The skill creates a monitoring concept for the ongoing monitoring of an AI system after deployment: which metrics, at what frequency, with which thresholds, by whom, with which escalation. Methodologically, the skill follows ISO/IEC 42001 (Ch. 8 Operation, Ch. 9 Performance Evaluation) and NIST AI RMF (MEASURE / MANAGE function). Statutory logging and oversight obligations of the AI Act (Art. 12 record-keeping obligations, Art. 14 human oversight, Art. 72 post-market monitoring) are referenced as points of reference; the assessment of obligations itself belongs in ki-vo-compliance.
Inputs
- System ID and risk class (from the risk assessment)
- Model type (classic ML / LLM / hybrid) and training data sources
- Deployment context (critical / non-critical process; high-risk indications Annex III AI Act)
- Existing telemetry and logging infrastructure
- Affected protected interests (personal rights, trade secrets, professional secrecy)
Sub-agent architecture
Researcher provides AI Act anchors (Art. 12, 14, 72), GDPR anchors (Art. 32), standards (ISO/IEC 42001 Ch. 8/9, NIST AI RMF MEASURE/MANAGE, BSI AIC4 requirements on monitoring), BaFin BDAI / MaRisk AT 7.2. Drafter creates the monitoring concept with a KPI table, escalation matrix and audit plan. Reviewer checks for completeness of the metrics, clear thresholds, logging compliance and human-in-the-loop.
Process
1. Monitoring dimensions
| Dimension | Example metrics | Reference |
|---|---|---|
| Performance | Accuracy, precision, recall, F1, AUC; LLM: task success rate, hallucination rate | NIST AI RMF MEASURE 2.3 |
| Data drift | Kolmogorov-Smirnov test, Population Stability Index (PSI), embedding drift | ISO/IEC 5338, NIST MEASURE 2.4 |
| Concept drift | Performance degradation over time, label distribution shift | NIST MEASURE 2.4 |
| Fairness / bias | Demographic parity, equal opportunity, disparate impact, group-specific error rates | NIST MEASURE 2.11; AGG protected categories |
| Robustness / security | Adversarial resistance, prompt injection tests, red-teaming results | NIST MEASURE 2.7; BSI AIC4 |
| Availability | Uptime, latency, error rate | classic SLO |
| Compliance / logging | Completeness of logs pursuant to Art. 12 AI Act (for high-risk), retention period | Art. 12 AI Act reference point |
| Human oversight | Override rate, escalation rates, training evidence | Art. 14 AI Act reference point; Art. 22 GDPR |
2. Frequency per risk class
| Risk class (AI Act trigger) | Performance check | Drift check | Fairness audit | Full audit |
|---|---|---|---|---|
| High risk (Annex I/III) | daily / continuous | weekly | quarterly | semi-annually |
| Limited risk (Art. 50) | weekly | monthly | semi-annually | annually |
| Minimal risk | monthly | quarterly | annually | annually |
In the case of sector-specific supervision (BaFin, BAFA, BfArM, BNetzA), their frequency requirements take precedence.
3. Thresholds and escalation
Per KPI:
- Green range: tolerance, no intervention
- Yellow (warning): increased monitoring, root cause analysis, ticket
- Red (alarm): escalation to AI owner + risk owner, if necessary decommissioning, incident report
Escalation matrix with roles and availability details. For high-risk systems: documented emergency plan.
4. Logging and records
- For high-risk systems (reference point Art. 12 AI Act): automatic recording of lifecycle events; retention period in accordance with Art. 19 AI Act – detailed review in
ki-vo-compliance. - Under data protection law (Art. 32 GDPR + § 9 BDSG considerations): logs themselves may contain personal data; access and deletion concept (necessity, purpose limitation, retention period).
- Under professional law: review logs as a data flow involving “contributing persons” (§ 203 (4) StGB).
5. Human oversight (human-in-the-loop)
Concrete requirements (reference Art. 14 AI Act + Art. 22 GDPR):
- Clear override option for the supervising person
- Training of the supervising persons (Art. 4 AI Act)
- Documentation of override decisions
- Limit “automation bias”: no mere confirmation routine
6. Incident management
- Incident definition: serious incident within the meaning of Art. 3 No. 49 AI Act (reference point) ↔ internal incident (below the reporting obligation)
- Reporting channels: internal (Data Protection Officer, IT security, compliance); external (supervisory authorities – detailed review in
ki-vo-complianceanddatenschutzrecht) - Lessons learned: documented follow-up, risk register update
7. Audits
- Internal audit in accordance with ISO/IEC 42001 Chap. 9 (at least annually)
- For third-party providers: contractual audit right under Art. 28 III lit. h GDPR; BSI AIC4 as assessment standard
- For sector-specific supervision: schedule their audits
Sources and citation style
Binding: ../../../references/zitierweise.md.
Union and national law
- Regulation (EU) 2024/1689 (AI Act) – Reference points Art. 12 (record-keeping obligations), Art. 13 (transparency towards deployers), Art. 14 (human oversight), Art. 17 (quality management system for providers), Art. 26 (obligations of deployers), Art. 72 (post-market monitoring), Art. 73 (serious incidents). Obligation review in the plugin
ki-vo-compliance. - Art. 22 GDPR
- Art. 32 GDPR (security of processing)
- § 1 AGG
Industry standards
- ISO/IEC 42001:2023 – AIMS, in particular Ch. 8 (Operation), Ch. 9 (Performance Evaluation), Ch. 10 (Improvement)
- ISO/IEC 5338:2023 – AI system life cycle processes
- NIST AI RMF 1.0 (01/2023) – MEASURE and MANAGE functions
- BSI AIC4 – requirement groups for monitoring, incident management, audit
Supervisory practice
- BaFin "Supervisory requirements for the use of big data and artificial intelligence" (BDAI) (June 2018)
[unverifiziert – prüfen auf bafin.de] - BaFin MaRisk AT 4.3 (outsourcing), AT 7.2 (technical and organizational equipment)
- DSK resolutions on AI and automated decision-making
[unverifiziert – prüfen auf datenschutzkonferenz-online.de]
Commentaries
- Selmayr, in: Ehmann/Selmayr, DSGVO, 3rd ed. 2024, Art. 22 marginal no. 1 et seq.
[unverifiziert – prüfen] - Jandt, in: Kühling/Buchner, DSGVO/BDSG, 4th ed. 2024, Art. 32 marginal no. 1 et seq.
[unverifiziert – prüfen] - Spindler, in: Hartmann/Hilgendorf, KI-Recht, 2024, Ch. Monitoring and Post-Market Surveillance
[unverifiziert – prüfen]
Case law ([unverifiziert – prüfen in Beck-Online / juris / curia.europa.eu])
- CJEU, judgment of 07.12.2023 – C-634/21, ECLI:EU:C:2023:957 (SCHUFA, Art. 22 GDPR)
- BAG on co-determination for monitoring devices § 87 I No. 6 BetrVG
Output format
KI-MONITORING-KONZEPT
System: <System-ID> | Risikoklasse: <KI-VO-Trigger> | Stand: <Datum>
I. Geltungsbereich und Schutzgüter
II. Monitoring-Dimensionen und KPIs
<Tabelle: Dimension | Metrik | Schwellenwert Grün/Gelb/Rot | Frequenz | Verantwortlich>
III. Logging (Art. 12 KI-VO als Bezugspunkt)
– Aufbewahrung, Zugriff, Löschkonzept
IV. Menschliche Aufsicht (Art. 14 KI-VO / Art. 22 DSGVO)
– Override-Mechanik, Schulung Art. 4 KI-VO, Bias-Schutz
V. Eskalationsmatrix
<Rolle | Erreichbarkeit | Auslöser | Reaktionszeit>
VI. Vorfallsmanagement
– interner / externer Meldepfad (Detailprüfung /ki-vo-compliance)
VII. Audit-Plan
– intern jährlich; Drittanbieter (Art. 28 III lit. h DSGVO, BSI AIC4)
VIII. Wiedervorlage und Konzept-Review
IX. Quellenverzeichnis
Risks / typical errors
- No thresholds – monitoring without a trigger is theater.
- Missing drift check – the model deteriorates silently.
- Fairness audit on an overall view – group-specific error rates are overlooked.
- Override mechanism only formal – automation bias remains unaddressed.
- Framing logging data as "technical" – they are generally personal data, observe Art. 32 GDPR and retention periods.
- Build AI Act obligations into the monitoring concept instead of referring to
ki-vo-compliance– maintenance effort and inconsistency. - Ignoring sector-specific supervision (BaFin, BfArM).