Post-market monitoring and serious-incident reporting

Compliance doesn’t end when you place an AI system on the market. Articles 72 and 73 of the EU AI Act set ongoing obligations: continuously monitor the system in production (Art. 72) and report serious incidents to supervisory authorities on a tight clock (Art. 73). Both are expected to apply from 2 December 2027 (postponed from 2 August 2026 to 2 December 2027 under the Digital Omnibus, agreed May 2026 and pending formal adoption). This guide is the practical operational playbook.

Article 72 — post-market monitoring

Article 72(1) requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the nature of the system and the risks involved.

The post-market monitoring system must:

• Actively and systematically collect, document, and analyse relevant data on the performance of the AI system throughout its lifetime
• Allow the provider to evaluate continued compliance with the Chapter III Section 2 requirements
• Be based on a written post-market monitoring plan (Article 72(3))

The post-market monitoring plan is part of your technical documentation (Annex IV section 4). It’s not a side document — it’s a binding commitment to operational practice.

What goes in the monitoring plan

A defensible monitoring plan covers four areas:

1. Performance metrics

• Accuracy (or relevant precision/recall metrics)
• Fairness across protected groups
• Calibration (confidence vs actual outcomes)
• Robustness against edge cases

How often you measure each, and the thresholds at which intervention is required.

2. Drift detection

• Data drift — the input distribution moving away from training distribution
• Concept drift — the underlying relationship shifting (e.g., what constitutes “good” or “bad” changes)
• Model drift — performance degrading over time

What signals you watch and how you respond.

3. Feedback channels

• Deployer feedback — how the people using the system report issues
• Affected-person feedback — how end users complain
• Internal observability — what your logs and metrics show

4. Update cadence

• How often the model is retrained
• How often the monitoring plan itself is reviewed
• How changes trigger re-assessment (see Substantial modification)

Article 73 — serious-incident reporting

Article 73 sets the reporting obligation when something goes wrong. Two definitions to understand first:

“Incident” — any malfunction or failure of a high-risk AI system, or the use of the system in a way that may cause harm.

“Serious incident” — Article 3(49) defines it as one of:

• Death of a person or serious harm to health
• Serious and irreversible disruption of critical infrastructure
• Infringement of obligations under EU law protecting fundamental rights
• Serious harm to property or the environment

Most operational AI failures aren’t serious incidents under this definition. But discrimination against a protected group, a credit-decisioning system causing widespread denials affecting fundamental rights, or a healthcare AI contributing to a misdiagnosis — those would qualify.

The reporting clock

Article 73(2)-(5) sets the timeline:

| Severity | Reporting clock | |---|---| | Most serious incidents | Immediately, no later than 15 days after becoming aware | | Widespread infringement of fundamental rights | No later than 2 days | | Death of a person | No later than 10 days (and any further information ASAP) |

For supplier or component vendors, “becoming aware” includes notification from deployers.

The report goes to the market surveillance authority of the Member State where the incident occurred. For multi-country incidents, to all affected authorities.

What the report must contain

Article 73(4):

• Description of the incident
• Information on the AI system involved (identifier, version)
• Date and place of occurrence
• Persons or property affected
• The provider’s preliminary assessment of cause
• Any corrective or preventive measures taken or planned
• Information on the deployer (where reporting flows through them)

Subsequent reports update the initial submission with new findings as the investigation progresses.

Coordination with other regulations

Serious-incident reporting under the AI Act often overlaps with:

• GDPR Article 33 — 72-hour personal-data breach notification
• NIS2 Article 23 — 24/72-hour cybersecurity incident reporting
• CRA Article 14 — vulnerability and incident reporting from September 2026
• DORA Article 19 — ICT incident reporting in financial services
• MDR Article 87 — medical-device vigilance reporting

For most operational events you’ll trigger multiple regimes simultaneously. Build one incident-response runbook that handles all of them. Don’t run parallel processes — that’s where reports get lost in the cracks.

Operationalising — a practical playbook

What a working post-market monitoring + incident-response setup looks like for a high-risk AI provider:

Daily

• Automated metric collection from production traffic
• Alert thresholds on accuracy, fairness, error rates
• Anomaly detection on input data distribution

Weekly

• Review of monitoring dashboards by the engineering team
• Review of deployer-reported issues
• Triage of customer-flagged anomalies

Monthly

• Formal monitoring report to internal compliance owner
• Drift evaluation against original training distribution
• Fairness re-evaluation across protected groups

On detected serious incident

• Hour 0: incident logged, owner assigned
• Hour 24–48: preliminary assessment, deployers informed, supervisory authority pre-notification if applicable
• Day 2–15: full investigation, corrective action, formal Article 73 report submitted
• Day 30+: follow-up reports as investigation progresses, root cause analysis published

Quarterly

• Monitoring plan review and update
• Substantial modification review (did any changes cross the line?)
• Conformity assessment refresh check

What deployers owe — Article 26(5)

Deployers have parallel monitoring obligations (lighter). They must monitor the system per the provider’s instructions and inform the provider of incidents. If the provider can’t be reached, the deployer notifies the market surveillance authority directly (Art. 73(6)).

Deployers should:

• Keep the provider’s contact details current
• Train staff to recognise potential incidents
• Have an internal escalation path for AI-related complaints
• Retain logs for the minimum 6 months (Art. 26(6)) — longer if national law requires

What good operational monitoring looks like

The cheapest insurance against an enforcement action is a working monitoring programme that catches anomalies before they become incidents. A provider that can say to a supervisory authority “yes, we observed degraded performance on demographic X in Q2, we re-evaluated the bias profile, we corrected the model in Q3, here’s the evidence” is in a vastly better position than one that didn’t notice until customers complained.

Build the monitoring before you ship. Don’t bolt it on afterward.