EU AI Act Post-Market Monitoring: What Article 72 Requires from Providers
Article 72 EU AI Act: providers of high-risk AI systems must document a post-market monitoring system. Deadline 2 Dec 2027. Fine up to €15M or 3%.
Article 72 of Regulation (EU) 2024/1689 places a clear obligation on providers of high-risk AI systems: establish, document, and operate a post-market monitoring system that actively and systematically collects, records, and analyses data on the system's performance throughout its lifetime. The purpose is not to satisfy a regulator's checklist once a year. It is to detect, as early as possible, whether a deployed system continues to comply with the requirements of the Act — and to feed what you learn back into your risk management system under Article 9.
This article covers what Article 72 requires, how the monitoring plan fits into your Annex IV technical documentation, where it ends and other obligations (Article 73 serious-incident reporting; Articles 74 and beyond for market surveillance by authorities) begin, and what "proportionate to the risks" means in practice.
What Article 72 actually says
Article 72 imposes the post-market monitoring obligation exclusively on providers — those who develop or place a high-risk AI system on the EU market or into service under their own name or trademark (Article 16). Deployers have a role in supplying data, but designing and running the monitoring system is your job as provider.
The obligation has three operative parts:
- Establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risks the system presents.
- Actively and systematically collect, document, and analyse relevant data on the system's performance throughout its lifetime. That data may come from deployers, users, or other sources.
- Feed findings into the Article 9 risk management system and, where necessary, into updates to your Annex IV technical documentation.
The monitoring system must be based on a post-market monitoring plan that forms part of the technical documentation required under Article 11 and Annex IV. The European Commission is required to provide a template for this plan — a significant practical help, since the plan must be system-specific but must also follow a structure regulators can audit. When the Commission template is available, align your plan to it.
For high-risk AI systems also covered by other Union law (for instance, a diagnostic imaging tool that is also a medical device under the MDR), Article 72 explicitly allows the monitoring obligation to be integrated into that other regulation's post-market surveillance mechanism, provided the requirements are met.
How Article 72 differs from Articles 73 and 74
Three articles sit close together in the Act and cover overlapping-sounding territory. Getting them confused in your documentation is a red flag to any auditor.
Article 72 is your own, proactive monitoring system — internal, continuous, lifecycle-long. You build and operate it.
Article 73 is serious-incident reporting — what you do when monitoring (or any other source) reveals an incident that causes or could cause death, serious harm to health, serious damage to property or the environment, or a serious infringement of fundamental rights. Article 73 sets the reporting timeline to national market surveillance authorities; Article 72 is the mechanism that detects what you then report under Article 73.
Articles 74 and beyond concern market surveillance by national competent authorities — what they do to you, not what you do to yourself.
In the original text of this page, these three were blended together and presented as one surveillance regime. They are not. Article 72 is the provider's own obligation; the others are what flows from it or sits alongside it.
The monitoring plan: what goes in it
The post-market monitoring plan sits in section 9 of the Annex IV technical documentation. It is a living document — you update it when your monitoring reveals that earlier assumptions about risk or performance were wrong.
At minimum, a credible plan addresses:
Scope and objectives. What performance indicators will you track? For an employment-screening system (Annex III, point 4(a)), you might track selection-rate parity across demographic groups, overall accuracy against ground-truth outcomes, and rate of appeals overturning automated recommendations. For a creditworthiness-scoring system (Annex III, point 5(b)), you might track approval-rate disparity by applicant category and loan default rates by approval cohort.
Data sources and collection method. Where does data come from? Directly from your own infrastructure, from deployer reports, from API logs, or from a combination? If you rely on deployers to supply data, your supply contracts should set out that obligation. You cannot build a credible monitoring system on data you have no right or mechanism to collect.
Analysis frequency and methodology. How often will you analyse the data — monthly, quarterly, on an event-triggered basis? What methods will you use to detect performance drift or emerging risks? Spell this out. "We will review data periodically" is not a plan.
Feedback into the Article 9 risk management system. What happens when the data shows something unexpected? The plan must describe the decision path from monitoring finding to risk-assessment update to potential technical-documentation amendment. Regulators will look for evidence that this loop actually closed — not just that it was written down.
Integration with Article 73. Define the internal threshold at which a finding escalates to a potential serious incident requiring external reporting under Article 73. This threshold will vary by system and intended use.
Proportionality. Article 72 explicitly requires that the monitoring system be proportionate to the risks the system presents. A low-volume internal tool that an Article 6(3) self-assessment barely moved into high-risk territory need not carry the same monitoring apparatus as a facial-recognition system used across a national border-control network. Document your proportionality reasoning.
Where monitoring data comes from
Article 72 anticipates that providers will not always have direct visibility into how their system performs once deployed. Data "may come from deployers or other sources." This matters practically.
If you sell a high-risk AI system to fifty deploying organisations, you need to think, before you sign any contract, about how you will obtain performance data from all fifty. That requires contractual obligations on deployers to log, retain, and share relevant data. It requires agreeing on data formats. And it requires navigating GDPR, because the performance data will often relate to natural persons — applicants, borrowers, patients.
Where collecting individual-level data is disproportionate, aggregate data by relevant categories (e.g. demographic group, jurisdiction, use-case scenario) often suffices. The goal is detecting systemic risk, not building a new personal-data processing operation for its own sake.
For systems covered by other EU legislation with their own post-market surveillance requirements — MDR, for instance — Article 72 allows a single integrated monitoring mechanism rather than two parallel systems. Use that integration where it is available; it reduces duplication without reducing the substantive obligation.
The Article 9 feedback loop
The monitoring obligation under Article 72 exists to serve the risk management system under Article 9. Article 9 requires providers to establish, implement, document, and maintain a risk management system throughout the entire lifecycle of a high-risk AI system. That lifecycle obligation has no content without post-market data.
If your Article 9 risk assessment concluded, before launch, that residual risks were acceptable, Article 72 monitoring is how you verify that conclusion held true in production. If monitoring data reveals new failure modes, distributional shift, or disparate performance across demographic groups, Article 9 requires you to update your risk assessment and, where needed, implement additional mitigation. Article 11 and Annex IV require you to update your technical documentation to reflect those changes.
This is a closed loop: monitoring informs risk assessment, risk assessment informs technical documentation, technical documentation is the basis for demonstrating continued conformity. Regulators and notified bodies examining ongoing compliance will trace exactly this chain. If monitoring findings exist but the risk assessment was never updated, that gap is the problem.
Deadline and penalties
The deadline for Article 72 compliance tracks the broader high-risk obligations. Under the Digital Omnibus agreed in May 2026, obligations for stand-alone high-risk AI systems listed in Annex III apply from 2 December 2027 (pushed back from the original 2 August 2026 date). For high-risk AI systems embedded as safety components of Annex I regulated products, the deadline is 2 August 2028.
That extension is useful, but it does not change what you need to build. Designing a monitoring plan, establishing data-collection infrastructure, and integrating findings into your risk management system all take time. For most providers, 2 December 2027 is close enough that design work should begin now, not in 2027.
Non-compliance with Article 72 falls under Article 99(4): a fine of up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For companies meeting the SME definition, Article 99(6) caps the fine at whichever of those two figures is lower — a genuine proportionality protection, but not a reason to skip the obligation.
How Confir helps
Confir's AIGM area (Governance and Post-Market Monitoring) covers the Article 9 and Article 72 cluster. The monitoring controls in AIGM walk you through structuring your plan, defining the metrics appropriate to your system's intended use, and documenting the feedback path from monitoring findings to risk-management updates.
The Annex IV technical-documentation pack that Confir generates includes the post-market monitoring plan section, pre-structured to match the Article 72 requirements and ready for the Commission template once it is issued. Because Confir's assessment logic is deterministic and rule-based — not an LLM generating plausible-sounding text — the output is reproducible and audit-defensible: the same inputs produce the same structured outputs every time.
If you are a provider of a high-risk AI system and your Article 72 monitoring plan does not yet exist, the right place to start is classifying your system, establishing your role, and generating the documentation in a single workflow rather than assembling it by hand.
Frequently Asked Questions
What is the difference between Article 72 post-market monitoring and market surveillance?
Article 72 is your own, provider-operated obligation to monitor your system's performance throughout its lifetime and feed findings back into your risk management system. Market surveillance (Articles 74 and beyond) is what national competent authorities do — they investigate, inspect, and may require corrective action. Your Article 72 monitoring is internal and proactive; market surveillance is external and reactive. Confusing the two is a common error: if an authority shows up to conduct market surveillance, they will examine the records your Article 72 system produced.
Does Article 72 also apply to deployers?
No. Article 72 applies to providers. Deployers have a complementary obligation — they must inform the provider of any serious incidents or malfunctions they identify (Article 26), and they must cooperate with the provider's data-collection requirements. But deployers do not design, operate, or document the monitoring system. If you are both provider and deployer (because you built the system and use it yourself), you carry both sets of obligations.
What does "proportionate to the risks" mean for a small provider?
It means you do not need to build a real-time telemetry pipeline for a narrow-scope system that barely crossed the Article 6 high-risk threshold. A documented schedule of periodic performance reviews, a defined set of metrics tied to the system's intended use, and a clear internal escalation path if a metric exceeds its threshold may be sufficient. The proportionality justification must be written into the plan. "We are small" is not a justification; "our system processes 200 applications per quarter and presents a low probability of harm because human decision-makers review every output" is.
How does the monitoring plan relate to the Annex IV technical documentation?
The post-market monitoring plan is a required component of the Annex IV technical documentation under Article 11. It lives in section 9 of Annex IV. Your technical documentation as a whole must remain current — if monitoring reveals that an earlier risk assessment was wrong, you update the relevant sections of the documentation. The monitoring plan is not a separate standalone document filed once; it is integrated into the living compliance record.
Does Article 72 apply if my system is also covered by MDR or another sector regulation?
Article 72 explicitly permits integration with post-market surveillance requirements under other Union law. If your system is a medical device regulated under MDR, you can use a single integrated monitoring mechanism rather than two parallel systems, provided it meets the requirements of both. In practice, this means your MDR post-market surveillance plan should be extended or cross-referenced to satisfy Article 72, and vice versa. Note that the deadline for high-risk AI as a safety component of an MDR-regulated product is 2 August 2028, not 2 December 2027.
What fine applies if a provider has no Article 72 monitoring system?
The applicable fine is under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, Article 99(6) applies the lower of the two figures. Enforcement is most likely to target providers where a serious incident occurred and monitoring records show either that the incident was not detected systematically or that findings were not fed back into the risk management system.
When must the monitoring plan be in place — and must it be operational before launch?
Yes. The post-market monitoring plan must be part of your Annex IV technical documentation at the point of conformity assessment, which happens before you place the system on the market. You cannot launch first and design the plan later. The deadline for stand-alone Annex III systems is 2 December 2027 (per the Digital Omnibus agreed May 2026), and the monitoring infrastructure needs to be operational from day one of deployment, not retrofitted after the fact.
Related guides
- Article 72 post-market monitoring
- Article 6 high-risk AI classification
- Annex III high-risk use cases
- compliance checklist for providers
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →