Post-Market Monitoring Under the EU AI Act: Article 72 Explained
Article 72 of the EU AI Act requires high-risk AI providers to maintain an active post-market monitoring system throughout the system's lifetime. This guide explains what the plan must contain, how it connects to incident reporting under Article 73, and the key deadlines.
Most organisations preparing for EU AI Act compliance focus heavily on pre-market obligations: technical documentation, conformity assessments, CE marking. Article 72 is different. It imposes an ongoing obligation that begins the moment a high-risk AI system is placed on the market and continues for the system's entire commercial lifetime. Yet in most compliance programmes, it receives only a fraction of the attention it deserves.
This guide explains what post-market monitoring (PMM) actually requires, who is obligated, what a compliant plan looks like, and how it connects to the incident reporting obligations in Article 73.
What Is Post-Market Monitoring?
Post-market monitoring is the systematic collection and review of data on a high-risk AI system's performance after it has been deployed. The principle is borrowed directly from medical device regulation (MDR Article 83), and the analogy is intentional: just as a medical device must be monitored for adverse events after patients start using it, a high-risk AI system must be monitored for performance drift, errors, and unanticipated risks after deployers start using it.
Article 72(1) states:
"Providers of high-risk AI systems shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system."
Proportionality matters here. A simple classification model used in a single country has different PMM requirements than a predictive policing tool deployed across fifteen Member States. The obligation scales with actual risk and deployment scope.
Who Is Obligated?
Post-market monitoring is a provider obligation under Article 72. Deployers are not required to operate a PMM system themselves, but they have a critical supporting role.
Under Article 26(5), deployers must inform providers of any serious incidents or malfunctions they observe in the deployed system. This is not optional. Without the data flowing back from deployers, a provider's PMM system cannot function effectively.
Providers of high-risk AI systems embedded in products regulated under other EU harmonisation legislation (for example, medical devices or machinery) must integrate their PMM with the post-market surveillance systems required by those other frameworks. There is no exemption — it is an integration obligation.
What a Compliant PMM Plan Must Contain
Article 72(3) cross-references Annex VII for post-market monitoring content in systems using statistical approaches. More broadly, a compliant PMM plan should cover the following elements:
1. Scope and System Description
The plan must clearly identify the AI system it covers, the intended purpose, the deployment contexts, and the categories of users (deployers) and affected persons. A vague description is not sufficient — the system's operational boundaries need to be defined so that anomalies can be meaningfully detected.
2. Performance Metrics and Thresholds
The plan must specify the KPIs against which the system will be evaluated post-deployment. These should mirror the accuracy and robustness metrics documented in the technical documentation under Article 11 and Annex IV, but they must also include:
- Distribution shift indicators (detecting when input data no longer resembles training data)
- Error rate tracking by deployment context (different deployers, different use cases)
- Performance degradation thresholds that trigger a formal review
Without explicit thresholds, there is no basis for deciding when observed performance warrants intervention.
3. Data Collection Mechanisms
The plan must describe how performance data is collected from deployed systems. This typically involves:
- Structured feedback loops from deployers (incident reports, anomaly logs)
- Automated logging of system outputs and confidence scores where technically feasible
- Sampling protocols if full output logging is not possible
Providers must also address data protection: performance monitoring data may include personal data, which triggers GDPR obligations for data minimisation, purpose limitation, and processing agreements with deployers.
4. Drift Detection and Review Process
Performance drift in AI systems is common — model behaviour shifts as real-world data evolves away from training distributions. The PMM plan must include:
- A defined methodology for detecting drift (statistical tests, monitoring dashboards, or both)
- Review intervals appropriate to the risk profile (quarterly for lower-risk deployments; continuous monitoring with monthly reviews for high-stakes systems)
- Escalation criteria: what level of drift triggers a model update, retraining, or withdrawal?
5. Incident Escalation Procedures
The PMM plan must define the internal process for identifying, documenting, and escalating serious incidents. This is the operational bridge to Article 73 (incident reporting to authorities). The process should specify:
- Who receives incident reports from deployers
- Internal triage criteria (what qualifies as serious vs. minor)
- Timelines for internal investigation
- Decision points for triggering external reporting under Article 73
6. Review Frequency and Governance
The plan must specify how often the PMM system itself is reviewed — not just the AI system's performance, but the adequacy of the monitoring process. This typically means an annual review at minimum, with ad hoc reviews triggered by significant incidents or updates to the system.
Governance documentation should name the responsible function (quality assurance team, AI governance officer, or equivalent) and define the review committee's composition and authority.
Minimum PMM Plan Template
The following structure satisfies the core Article 72 requirements for most high-risk AI systems:
| Section | Content |
|---|---|
| 1. System identification | Name, version, intended purpose, deployment contexts |
| 2. Performance KPIs | Accuracy metrics, error rates, confidence distribution |
| 3. Drift indicators | Input distribution monitoring, output stability metrics |
| 4. Data collection | Sources, sampling methodology, GDPR safeguards |
| 5. Review schedule | Standard intervals (e.g., quarterly) + trigger-based reviews |
| 6. Incident procedure | Receipt, triage, investigation, escalation timeline |
| 7. Corrective actions | Criteria for update, retraining, restriction, or withdrawal |
| 8. Governance | Responsible function, review committee, document control |
This template is a starting point. High-risk systems in sensitive sectors (healthcare, law enforcement, employment) require additional depth, particularly in sections 2 and 6.
The Link to Article 73: Incident Reporting
Article 72 (PMM) and Article 73 (incident reporting) are two sides of the same compliance framework. PMM is the detection mechanism; Article 73 is the reporting obligation triggered when PMM detects a serious incident.
Under Article 73(1), providers must report any serious incident to the market surveillance authorities of the Member States where the incident occurred. A serious incident is defined in Article 3(49) as any incident that directly or indirectly causes or could cause:
- Death or serious harm to health
- Serious and irreversible disruption of critical infrastructure
- Infringement of fundamental rights
- Serious damage to property or the environment
The reporting timeline under Article 73(1) is structured: an initial report as soon as the provider becomes aware, followed by a detailed investigation report within defined timeframes set by the market surveillance authority.
Without a functioning PMM system, providers cannot reliably detect serious incidents before they are reported by third parties or regulators — a significantly worse compliance position.
Compliance Deadline
Following the AI Omnibus provisional agreement (7 May 2026), the deadline for Annex III high-risk AI obligations — including Article 72 PMM — has been extended to 2 December 2027 (Annex III standalone systems) and 2 August 2028 (Annex I embedded products). The original August 2026 date no longer applies.
For systems already on the market before the new deadlines, the transitional provisions of Article 111(2) apply, provided the system remains unchanged. Any substantial update resets the obligation.
The delay is not a reason to wait. Designing a PMM system, establishing data flows with deployers, setting performance baselines, and integrating the plan into technical documentation takes 6–12 months. Organisations that start in late 2026 or 2027 will be building under pressure — exactly the conditions that produce incomplete compliance.
DILAIG's compliance platform includes a post-market monitoring plan builder aligned with Article 72, with templates calibrated to each Annex III category. Generate your PMM plan in minutes and integrate it directly with your technical documentation at dilaig.com.