TL;DR: Article 72 of the EU AI Act requires providers of high-risk AI systems to maintain a post-market monitoring system that collects, analyses, and acts on performance data after the system is placed on the market. The monitoring plan must be part of your technical documentation. Serious incidents must be reported to the relevant national market surveillance authority within 72 hours where practicable. Malfunctions that do not reach the serious incident threshold must still be recorded. GPAI providers have parallel obligations under Article 55.
Deploying a high-risk AI system and then stepping back is not an option under the EU AI Act. The regulation treats AI governance as a continuous obligation that runs through the entire product lifecycle, not just a pre-market conformity check. Article 72 is the central provision that makes this concrete.
Post-market monitoring is already familiar territory for companies selling medical devices or safety-critical hardware under other EU product regulations. The EU AI Act imports the same logic: once a product is in the hands of users, the provider remains responsible for tracking how it performs, catching problems early, and taking corrective action.
This guide explains what Article 72 requires, how serious incident reporting works, what a compliant post-market monitoring plan looks like, and how the obligation interacts with other regulatory frameworks.
What Article 72 actually requires
Article 72(1) sets the core requirement: providers of high-risk AI systems must establish and maintain a post-market monitoring system that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.
The word "system" matters. Article 72 does not ask for a one-time review or an annual audit. It requires an ongoing, systematic process that:
- Proactively collects data on the performance of the AI system after it is placed on the market or put into service
- Analyses that data against the expected performance defined in the technical documentation
- Identifies patterns that suggest the system is not performing as intended
- Feeds findings into the risk management system under Article 9
The monitoring system must be documented as part of the technical file under Article 11 and Annex IV. Auditors and market surveillance authorities can request the post-market monitoring plan as part of any conformity assessment or investigation.
The post-market monitoring plan: what it must contain
The plan is the written document that defines how your monitoring system works. It should be structured enough to be reviewed by a third party but practical enough to actually operate.
A compliant post-market monitoring plan typically includes:
Scope and system description. Identify which AI system the plan covers, its version, intended purpose, and the high-risk category under Annex III that applies.
Performance baselines. State the accuracy rates, error rates, or other metrics the system was validated against before deployment. Post-market monitoring compares real-world performance against these baselines.
Data collection methods. Specify what data will be collected (system logs, user feedback forms, operator incident reports, model output samples), how it will be collected, and from which sources. If you rely on deployers to provide data, document the contractual mechanism that requires them to do so.
Review frequency. Define how often the monitoring data is reviewed, who reviews it, and what thresholds trigger escalation to corrective action. Monthly review is a common baseline, with real-time alerting for critical metrics.
Incident classification criteria. Define what constitutes a serious incident under Article 3(49) in the context of your specific system, what constitutes a non-serious malfunction, and what constitutes normal variance. This classification directly determines your reporting obligations.
Corrective action procedures. Describe what happens when monitoring reveals a problem: who is notified internally, what the authority notification process is, and how corrective actions are documented and tracked.
Plan review schedule. State how often the monitoring plan itself will be reviewed and updated, and what triggers an out-of-cycle review (such as a significant update to the AI model or a change in deployment context).
Serious incident reporting: the 72-hour rule
When a serious incident occurs, Article 73 sets out the reporting obligation. The 72-hour timeline applies to the initial notification to the relevant national market surveillance authority.
What counts as a serious incident. Article 3(49) defines a serious incident as an incident or malfunction leading directly or indirectly to: death or serious harm to a person's health; damage to property; serious disruption to critical infrastructure; or breach of fundamental rights protections. The framing is broad. If your hiring AI wrongly excludes a candidate from consideration in a way that may constitute discrimination, that could fall within the fundamental rights prong.
The 72-hour clock. The clock starts when the provider becomes aware of the incident. This is an important detail: awareness, not occurrence. If a deployer reports an incident to you three days after it happened, your 72-hour obligation runs from the time you received the report. This is why your contracts with deployers should require rapid incident notification to you.
What the initial notification must include. The initial report is not expected to be a complete investigation. It should identify the system involved, the nature of the incident, the population affected, the immediate steps taken, and the point of contact for follow-up. A more detailed report is expected within 15 days.
Multiple jurisdictions. If your system is deployed across several member states and an incident affects users in more than one country, you may need to notify multiple national market surveillance authorities. Coordinate with each; there is no single EU-wide reporting portal for incidents as of 2026.
Malfunctions below the serious incident threshold
Not every problem with an AI system is a serious incident. A malfunction is any departure from expected performance that does not reach the harm thresholds in Article 3(49). Malfunctions do not require immediate authority notification, but they must be tracked.
Your post-market monitoring plan should include a log for recording malfunctions, including the date, description, the system behaviour observed versus expected, and any corrective steps taken. This log is part of your technical file and can be requested by auditors.
A pattern of malfunctions is itself a signal. If the same type of error recurs frequently, it may indicate a deeper performance problem that will eventually cross the serious incident threshold. Monitoring plans should include escalation criteria that flag recurring malfunctions for risk management review.
Data sources for effective post-market monitoring
The regulation leaves data source selection to the provider. Good post-market monitoring draws on multiple input streams:
System logs. Automated logging of inputs, outputs, confidence scores, and error events. For large-scale systems, statistical sampling rather than full population review is acceptable if documented.
User and operator feedback. Structured mechanisms for deployers and end users to report unexpected behaviour. This requires building feedback channels into your product and into your deployer contracts.
Accuracy and drift metrics. Scheduled evaluations of model accuracy against held-out test sets, and monitoring for concept drift where the real-world distribution of inputs diverges from training data.
Anomaly detection. Automated flagging of outputs that fall outside expected parameters. This is especially relevant for systems where individual outputs are not reviewed by humans before acting on them.
Regulatory and media signals. External reports of incidents involving similar AI systems can be relevant to your own risk assessment, even if your system is not directly implicated.
See the high-risk AI documentation templates for a post-market monitoring plan template that incorporates these data sources.
GPAI post-market monitoring: Article 55 obligations
Providers of general-purpose AI models with systemic risk face separate post-market monitoring obligations under Article 55. These are overseen by the EU AI Office rather than national MSAs.
Article 55 requires GPAI providers to: conduct adversarial testing (red-teaming) at regular intervals, track and report serious incidents to the AI Office, put in place post-training measures to address identified risks, and maintain technical documentation of the evaluation process.
The GPAI monitoring obligations are model-level rather than deployment-level. If you are a GPAI provider whose model is used in hundreds of downstream applications, your monitoring system must be designed to aggregate information about how those applications perform without requiring you to monitor each deployment individually.
For companies that are both GPAI providers and deployers using their own models in high-risk applications, both Article 55 and Article 72 apply. The documentation should address each set of obligations, though much of the underlying data collection infrastructure can serve both.
Interaction with MDR post-market surveillance
AI systems that are medical devices or safety components of medical devices under the Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR) face overlapping obligations. MDR Article 83 requires a post-market surveillance (PMS) system and Article 87 requires incident reporting to national competent authorities.
The MDR incident reporting timelines are different from the EU AI Act's 72-hour rule. Under MDR, serious incidents must be reported within 15 days (or 2 days for incidents that caused or could have caused serious public health threats). Where an AI medical device causes a serious incident, both the AI Act and MDR reporting obligations may apply simultaneously.
The practical approach for dual-regulated AI medical devices is a single integrated technical file that addresses both frameworks, with a combined post-market monitoring plan and a clear internal procedure that determines which authority gets notified first for any given incident.
Corrective action obligations: what to do when monitoring reveals a problem
Article 20 sets out the corrective action obligations that are triggered by post-market monitoring findings. When monitoring indicates that a high-risk AI system no longer conforms to requirements, the provider must:
- Take immediate corrective action to bring the system into conformity
- Inform the relevant national market surveillance authority and any deployers of the problem and the corrective action taken
- Withdraw or recall the system if it poses an unacceptable risk
- Keep records of the corrective action and update the technical documentation
The threshold for mandatory notification to authorities is not limited to serious incidents. If monitoring reveals a conformity problem even without a specific incident, the provider should assess whether the risk level requires immediate notification or whether an internal corrective action plan is sufficient.
For companies that want to understand how to structure the full documentation set, see one documentation set for EU AI Act, NIST AI RMF, and Texas TRAIGA for an approach to managing multiple framework obligations efficiently.
Connecting monitoring to your risk management system
Article 72 explicitly requires that post-market monitoring feeds into the risk management system under Article 9. This means your monitoring plan should not operate in isolation.
When monitoring reveals a new risk, or evidence that an existing risk is materialising more frequently than expected, that information flows into your risk register. The risk management system is then responsible for assessing whether existing controls are adequate or whether the risk management plan needs to be updated.
This feedback loop is what distinguishes a genuinely active post-market monitoring system from a compliance checkbox. Authorities reviewing your technical documentation will look for evidence that monitoring data has actually influenced your risk management decisions, not just that a monitoring plan exists on paper.
The EU AI Act August 2026 compliance checklist summarises the full documentation set that connects risk management, technical documentation, and post-market monitoring.
Deployer obligations: feeding information back to providers
The post-market monitoring obligation falls on providers, but deployers are a key source of the data providers need. Article 26 requires deployers to:
- Monitor the operation of the high-risk AI system for the purposes and period specified by the provider
- Inform the provider when they identify a risk, a serious incident, or behaviour not described in the instructions for use
- Keep logs of their use of the system for periods specified in the instructions for use
In practice, many providers underestimate how much their monitoring systems depend on deployer cooperation. If a deployer does not have a clear channel to report incidents back to the provider, the provider will not meet the 72-hour reporting obligation because they will be the last to know.
Your deployer contracts should require deployers to:
- Notify you within 24 hours of identifying a potential serious incident (giving you time to assess and report within 72 hours)
- Retain system logs for the periods you specify
- Participate in your monitoring data collection process, including responding to periodic performance surveys or providing access to aggregate usage data
Without these contractual mechanisms, your post-market monitoring system has a structural gap that national market surveillance authorities will identify during any inspection.
What a market surveillance authority will check
When a national MSA reviews post-market monitoring compliance, either as part of a routine audit or following a specific complaint, they typically check:
Does the post-market monitoring plan exist? The plan must be part of the technical file. Its absence is itself a violation.
Is the plan operational? A plan that exists but has never been acted on, with no review records, data collection logs, or findings documented, is treated the same as no plan. Authorities look for evidence that monitoring is actually happening.
Are monitoring outputs feeding into risk management? The authority will trace a path from monitoring data to the risk register. If the plan mentions reviewing accuracy data monthly but the risk register has never been updated based on that data, the monitoring is not functioning as required.
Were serious incidents reported? If the authority is investigating a specific incident, they will check whether the provider classified it correctly and whether the 72-hour notification was met.
Were corrective actions completed? Any corrective actions that were committed to in prior notifications to the authority should be complete and documented.
Preparing for this kind of review is the most practical reason to invest in a well-documented monitoring system from the outset, rather than retrofitting one after enforcement pressure begins. See the EU AI Act deployer evidence gaps guide for the documentation gaps most commonly identified when enforcement begins.
Related Reading
- High-risk AI documentation templates for August 2026
- Annex III high-risk AI systems explained
- EU AI Act August 2026 compliance checklist
- Deployer evidence gaps for SMEs
- AI incident response plan template 2026
- GPAI provider self-test 2026
- One documentation set for EU AI Act, NIST AI RMF, and Texas TRAIGA
- AI incident reporting obligations: when you must notify regulators in 20
- EU AI Act Article 13 transparency: what deployers must tell users of hig
- EU AI Act Article 9 risk management system: step-by-step implementation
- EU AI Act Compliance for Small Teams: The Complete Guide (2026)
- EU AI Act August 2026: 6-week compliance sprint checklist
- AI incident response plan: what regulators expect when your AI system fails
