EU AI Act Post-Market Monitoring (Art. 72): Obligations for High-Risk AI Providers

Compliance does not end at market entry. Art. 72 requires providers of high-risk AI systems to maintain an active post-market monitoring system, collect performance data, and report serious incidents. Here is what you must do — and when.

What Is Post-Market Monitoring?

Conformity assessment and CE marking are the entry ticket to the EU market for a high-risk AI system — not the finish line. Article 72 of the EU AI Act imposes a continuing obligation: providers must establish and operate a post-market monitoring (PMM) system that actively collects, analyses, and acts on real-world performance data throughout the operational lifetime of the system.

The rationale is straightforward. An AI system validated on a fixed dataset may drift as real-world inputs shift, as the user population changes, or as the environment in which it operates evolves. Static compliance snapshots cannot capture this. PMM is the mechanism that turns compliance into a continuous process rather than a one-time event.

The PMM system must be proportionate to the nature and risks of the high-risk AI system concerned. A credit-scoring model deployed at scale across millions of consumers will require more intensive monitoring than a narrow document-classification tool used internally by a regulated firm.

Who Must Establish a PMM System?

Mandatory for:

• Providers of Annex III standalone high-risk AI systems — systems listed in Annex III that are not safety components of a product (e.g., AI used in employment decisions, access to education, law enforcement, creditworthiness assessment, critical infrastructure management)
• Providers of Annex I product-embedded AI systems — AI safety components integrated into products covered by existing EU harmonisation legislation (medical devices, machinery, vehicles)

Not required for:

• Providers of minimal-risk AI systems (no formal PMM obligation, though good practice applies)
• Providers of transparency-only AI systems (Art. 50 obligations do not extend to PMM)
• GPAI model providers — these are subject to a separate regime under Art. 61–62, which includes incident reporting for systemic-risk models but is structured differently from Art. 72 PMM

The deployer's role is supporting but not optional. Deployers must operate the AI system in accordance with the provider's instructions, activate and retain the logging functionality built into the system, and — critically — report any serious incidents they become aware of to the provider without undue delay. A deployer who observes a serious incident and fails to notify the provider is not compliant.

The Post-Market Monitoring Plan (Annex IV, Point 12)

The PMM plan is a mandatory component of the technical documentation (Annex IV). It cannot be a generic document: it must be specific to the system, its deployment context, and its identified risks. At minimum, it must define:

1. Data collection — what performance metrics are captured (accuracy, error rates, decision outcomes), how data is collected (automated telemetry, deployer reports, user feedback), and at what frequency
2. Feedback loops — the mechanism by which deployers can report performance issues, anomalies, or incidents back to the provider in a structured and timely way
3. Accuracy monitoring — how the system's performance is tracked against the validated benchmark used during conformity assessment, including any drift-detection methodology
4. Bias monitoring — for systems where demographic outcomes are material (hiring, credit, law enforcement), ongoing monitoring of statistical disparities across protected groups, with defined methodology and thresholds
5. Update triggers — the specific quantitative or qualitative thresholds that prompt corrective action, including model retraining, parameter adjustment, or deployment suspension
6. Review schedule — how often the PMM plan itself is reviewed and updated, ensuring it remains fit for purpose as the deployment context evolves

The PMM plan must be kept up to date. An outdated plan that no longer reflects the actual monitoring methodology does not satisfy Art. 72.

Serious Incident Reporting (Art. 73)

What constitutes a serious incident?

Article 73 defines a serious incident as any incident or malfunction of a high-risk AI system that directly or indirectly leads to:

• Death or serious harm to health (physical or psychological)
• A serious and irreversible disruption to the management or operation of critical infrastructure
• A serious breach of fundamental rights (privacy, non-discrimination, due process)
• A situation in which a person narrowly avoided any of the above

Importantly, the AI Act does not require that a causal link to the AI system be established before reporting. A reasonable suspicion that the AI system contributed to or failed to prevent the harm is sufficient to trigger the obligation. Providers who wait for certainty before reporting risk non-compliance.

Reporting timelines

The 15-day clock starts when the provider becomes aware of the incident — which, in practice, means when the deployer notifies them. Providers should design their deployer notification procedures so that information reaches them quickly enough to meet the downstream reporting deadline.

What an incident report must contain

A compliant incident report to the national market surveillance authority should include:

• System identification: name, version, EU database registration number
• Description of the incident: what happened, what harm occurred or was narrowly avoided, date and location
• Affected persons: number and categories of affected users or third parties (anonymised where required under GDPR)
• Preliminary causal analysis: the provider's current understanding of how the incident arose, clearly labelled as preliminary
• Immediate corrective or safety measures taken: any steps already taken to limit further harm or risk (e.g., suspension of affected functionality, deployer notifications)
• Contact point: the person or team responsible for follow-up correspondence with the authority

The report should be factual and proportionate. Preliminary reports may be supplemented by follow-up reports as the investigation progresses.

Mandatory Logging (Art. 12)

Article 12 requires that high-risk AI systems be designed and built with the capability to automatically generate logs at a level of granularity sufficient to enable:

• Post-market monitoring in accordance with Art. 72
• Tracing of events leading to a serious incident
• Investigation by national authorities

This is a design requirement imposed on the provider. The provider must build the logging capability into the system before it is placed on the market.

The obligation to activate and retain those logs falls on the deployer. Deployers must not disable logging functionality and must retain logs for the period specified in the provider's instructions and technical documentation. Where no specific retention period is defined, logs should be retained for a period commensurate with the operational lifecycle of the system and any applicable sector-specific requirements (e.g., financial services record-keeping rules under DORA or MiFID II).

Substantial Modifications and Re-Assessment

Not every change to a deployed AI system triggers a new conformity assessment. The Act distinguishes between minor updates and substantial modifications.

A modification is substantial — and requires a new conformity assessment and updated technical documentation — when it:

• Changes the intended purpose of the system (even partially)
• Involves a significant change to the architecture or training methodology
• Uses new training data that materially affects the system's performance in ways that could affect compliance-relevant behaviour
• Degrades performance beyond thresholds defined in the risk management documentation in ways that affect safety or fundamental rights

Minor updates — security patches, bug fixes that correct clearly identified defects without altering compliance-relevant behaviour, cosmetic interface changes — do not require a full re-assessment. However, they must be documented, and the provider must retain a written assessment confirming that the modification does not constitute a substantial modification. That record is subject to inspection by market surveillance authorities.

Practical Implementation Checklist

The following checklist reflects the minimum operational requirements under Art. 72, Art. 73, and Art. 12. It is not a substitute for legal advice but provides a starting point for gap analysis.

• [ ] PMM plan documented in the technical file (Annex IV, point 12), specific to the system and its deployment context
• [ ] Automated logging capability designed and built into the system prior to market placement
• [ ] Deployer instructions include a clear, written incident reporting procedure with escalation contact
• [ ] Incident reporting contact point established internally and notified to the relevant national market surveillance authority
• [ ] Bias and accuracy monitoring processes or dashboards defined, with documented methodology and thresholds
• [ ] Escalation thresholds for corrective action documented and linked to the risk management system
• [ ] Substantial modification assessment procedure in place, with a decision record template for each update
• [ ] Log retention policy defined, communicated to deployers, and aligned with sector-specific retention rules

Cross-references: Technical Documentation — Annex III High-Risk AI Systems — Providers vs. Deployers