Article 72: Post-Market Monitoring
Article 72 of the EU AI Act requires providers of high-risk AI systems to establish, document, and implement a post-market monitoring system. The obligation does not end at market placement — it begins there. Providers must actively collect data on their deployed systems, monitor performance against documented standards, and report serious incidents to national market surveillance authorities.
What Article 72 Actually Requires
Article 72(1) requires providers to proactively collect, document, and analyse relevant data on the performance of high-risk AI systems throughout their lifetime. The word “proactively” is significant — providers cannot wait for problems to be reported. The monitoring system must actively seek out performance data.
Article 72(3) requires the post-market monitoring plan to be part of the technical documentation prepared under Article 11. This means the monitoring plan must exist before the system is deployed — it cannot be a retrospective document.
What the Post-Market Monitoring Plan Must Cover
The monitoring plan must be proportionate to the risk and complexity of the system, but must address at minimum the following areas:
Data collection methodology
Describe what data will be collected from the deployed system, how it will be collected, and at what frequency. This includes both automated telemetry and structured feedback from deployers and end users.
Performance indicators and thresholds
Define the metrics used to assess whether the system continues to perform as documented — accuracy degradation, error rate changes, distributional shift indicators. Include the thresholds that trigger corrective action.
Analysis procedures
Describe how collected data will be analysed, who is responsible for analysis, and how findings will be reviewed. This should include a schedule of periodic reviews and a process for investigating anomalies.
Corrective action procedures
Document what actions will be taken if monitoring reveals performance degradation, new risks, or changed deployment contexts — including when the risk management system and technical documentation must be updated.
Serious incident reporting
Define what constitutes a serious incident for your system, the procedure for identifying and escalating incidents internally, and the process for notifying national market surveillance authorities within the required timeframes.
Feedback loop to risk management
Specify how post-market findings feed back into the Article 9 risk management system. New risks identified through monitoring must trigger reassessment, not just be logged.
Serious Incidents and Reporting
Article 73 (which works alongside Article 72) requires providers to report serious incidents to the national market surveillance authority of the member state where the incident occurred. Reporting must happen without undue delay and within 15 days of the provider becoming aware of the incident.
Serious incidents are defined as those that lead to or could lead to the death of a person, serious harm to health, significant damage to property, disruption of essential services, or serious violations of fundamental rights. Where there is doubt about whether an incident crosses the threshold, providers should report and request guidance rather than withhold.
- Document the internal escalation path for potential serious incidents
- Identify the national market surveillance authority for each EU member state where the system is deployed
- Prepare notification templates in advance so the 15-day clock does not expire during drafting
- Log all incidents — including those below the serious incident threshold — for trend analysis
The Feedback Loop to Risk Management
Article 9(2)(c) explicitly links the risk management system to post-market monitoring: the risk management process must take into account data gathered from the monitoring system. This makes post-market monitoring not merely an observation exercise but an active input into the ongoing risk assessment.
In practice, this means any significant finding from monitoring — accuracy degradation, demographic performance gaps, new misuse patterns, or unexpected failure modes — must trigger a reassessment under Article 9. If the reassessment identifies new or changed risks, the technical documentation and instructions of use may need to be updated.
Common Mistakes
Treating post-market monitoring as post-launch documentation
The monitoring plan must be in the technical documentation before market placement. A plan written after deployment — even if retrospectively accurate — does not satisfy Article 72(3).
Relying on deployer-reported incidents only
Article 72(1) requires proactive data collection. Waiting for deployers to report problems is not sufficient. Providers must build monitoring mechanisms that actively collect performance data, not just a feedback form.
No defined serious incident threshold
The monitoring plan must define what constitutes a serious incident for the specific system. A generic description that defers the threshold to subjective judgment creates a reporting gap that regulators will identify.
No feedback loop to Article 9
Monitoring data that is collected but not integrated into the risk management system satisfies the letter but not the spirit of Articles 72 and 9. Monitoring findings must trigger explicit risk reassessment.
Build your post-market monitoring plan
Nytivo helps you document your Article 72 post-market monitoring system as part of your Annex IV technical documentation pack — structured, linked to your risk management system, and ready for regulatory review.
Start free trialArticle 72 — Frequently Asked Questions
When does the post-market monitoring obligation begin?
The obligation begins when the system is placed on the EU market or put into service — not at the compliance deadline of 2 August 2026. Providers who deploy high-risk AI systems before the deadline must have monitoring in place from deployment. The monitoring plan must be part of the technical documentation prepared before market placement.
What counts as a 'serious incident' requiring reporting to authorities?
Article 3(49) defines a serious incident as any incident or malfunction of a high-risk AI system that directly or indirectly leads to the death of a person, serious harm to a person's health, significant damage to property or the environment, serious damage to fundamental rights, serious disruption of services essential to the protection of public safety, or the death, injury, or damage caused by the AI system. Where there is uncertainty about whether an incident meets the threshold, providers should err on the side of reporting.
How quickly must serious incidents be reported?
Serious incidents must be reported to the national market surveillance authority without undue delay — and in any event no later than 15 days after the provider becomes aware of the incident. Where the incident poses an imminent risk to health, safety, or fundamental rights, reporting must occur immediately. Providers should have pre-prepared incident notification templates and a clear internal escalation chain to ensure this timeline is met.
Does Article 72 require deployers to provide monitoring data to providers?
Yes, indirectly. Providers must include in their instructions of use a requirement for deployers to implement monitoring in their deployment context and to share relevant data with the provider. Deployers who detect serious incidents are obliged to inform the provider. In practice, providers should build data sharing requirements into their commercial agreements with deployers and provide technical mechanisms for deployers to submit performance data and incident reports.
How does post-market monitoring relate to Article 9 (risk management)?
They are explicitly linked. Article 9(2)(c) requires that the risk management system take into account data from the post-market monitoring system. New risks identified through monitoring — degraded accuracy in a particular demographic group, unexpected use patterns, or new misuse scenarios — must feed back into the risk assessment and be mitigated or documented. Post-market monitoring is the mechanism by which the risk management system stays current after deployment.