The Post-Market Monitoring Plan Required by Article 72

Article 72 is the provision that makes conformity a continuing state rather than a launch-day event. It requires a provider of a high-risk AI system to keep collecting evidence, for the system’s whole lifetime, that it still meets the requirements it was assessed against. The plan is where that becomes something a team can execute.

What Article 72 actually requires

Article 72 of Regulation (EU) 2024/1689 has three operative ideas and it is worth separating them, because they are often collapsed into one.

• A system, proportionate to the risk. Providers must establish and document a post-market monitoring system proportionate to the nature of the AI technologies and to the risks of the particular high-risk system. Proportionality is explicit in the text, which means a fifteen-page plan for a low-consequence system is not more compliant, it is just longer.
• Active and systematic collection. The system must actively and systematically collect, document and analyse relevant data on performance throughout the system’s lifetime — data that may come from deployers or from other sources — so that the provider can evaluate continuous compliance with the Chapter III Section 2 requirements. “Actively” rules out waiting for complaints. Where relevant, the analysis must cover interaction with other AI systems. The obligation does not extend to sensitive operational data of deployers that are law enforcement authorities.
• A written plan. The monitoring system must be based on a post-market monitoring plan, and that plan is part of the technical documentation in Annex IV.

The date on which the duty binds has moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It moved the application date for stand-alone Annex III high-risk systems from 2 August 2026 to 2 December 2027, and for high-risk AI embedded in the Annex I regulated products from 2 August 2027 to 2 August 2028. That is a change of deadline, not of substance: Article 72 is unchanged, and the monitoring plan still has to exist before the system is placed on the market, because it forms part of the Annex IV technical documentation the conformity assessment is run against. A postponement of the deadline is not a postponement of the design work it depends on.

The plan is part of the technical file

Two consequences follow from Article 72(3) putting the plan inside Annex IV. First, the plan is in scope for the conformity assessment and for any later request from a market surveillance authority — it is not an internal operations document that lives in a wiki. Second, it inherits the technical documentation’s retention and update expectations: the file has to be kept current, so a plan describing a monitoring pipeline that was decommissioned a year ago is a documentation defect.

Article 72(3) also directs the Commission to adopt an implementing act laying down a template for the plan and the list of elements it must contain, with a deadline in the Regulation of 2 February 2026. Whether that act has been adopted, and what the template requires, is the first thing to check before designing a plan from scratch — if the template exists, your plan should be written into it rather than mapped onto it afterwards. Check the Commission’s AI Act policy pages and EUR-Lex for the implementing act rather than relying on any summary, including this one.

A structure that satisfies the duty

The Regulation tells you the purpose of the plan — evaluating continuous compliance with Articles 8 to 15 — which is enough to derive a structure. Organise it by requirement, not by data source, because that is the axis the reader of the plan cares about.

• Scope. Which system, which versions, which intended purpose, and which reasonably foreseeable misuse the plan covers. Reasonably foreseeable misuse is a defined term in Article 3 and it is what the plan looks for evidence of.
• A row per requirement. For accuracy and robustness (Article 15), the metrics declared in the instructions for use and how they are measured in production. For data governance (Article 10), drift in input distributions against the characteristics the training and validation sets were documented to have. For human oversight (Article 14), whether the oversight measures are actually being exercised — override rates, escalation rates, time spent on review. For transparency to deployers (Article 13), whether the reported limitations still match observed behaviour.
• Named sources for each row. Automatically generated logs under Article 12 are the backbone; deployer reports under Article 26 are the second source; complaints, field service reports, published research on the model family, and the provider’s own re-testing fill the rest. Say for each row where the data comes from, at what frequency, and who is accountable for looking at it.
• Analysis method and cadence. Who reviews, how often, against what baseline, and where the output is recorded. A plan with collection but no scheduled analysis fails the “analyse” word in Article 72(2).
• Interfaces. How a monitoring finding becomes a serious incident report under Article 73, a corrective action under Article 20, or an input to the Article 9 risk management system. These are the joins that make the plan operational.

Triggers and corrective action

The most common weakness in a monitoring plan is that it defines collection and analysis but not thresholds. Article 20 requires a provider that considers, or has reason to consider, that a high-risk system it has placed on the market is not in conformity to immediately take the necessary corrective actions — withdraw, disable, or recall as appropriate — and to inform distributors, deployers, the authorised representative and importers. “Has reason to consider” is the phrase your thresholds have to anticipate.

So write the thresholds down in advance, per requirement: the accuracy floor below which the declared performance is no longer supportable, the input-drift measure at which the data governance assumptions stop holding, the override rate at which human oversight is evidently not working as documented. Record what happens at each level — investigate, notify deployers, restrict the intended purpose, withdraw. Deciding the threshold while an incident is running is how a provider ends up defending a judgement call rather than executing a plan.

Note the asymmetry with Article 73. Post-market monitoring is continuous, internal and evidence-gathering; serious incident reporting is event-driven, external and on a clock measured in days. Monitoring is what usually finds the thing that triggers the clock, which is why the two documents should reference each other explicitly rather than being written by different teams.

Reusing a plan you already have

Article 72(4) exists to stop duplicate paperwork. Where a high-risk AI system is covered by the Union harmonisation legislation listed in Section A of Annex I — medical devices, machinery, and the rest — and a post-market monitoring system and plan already exist under that legislation, the provider may integrate the elements required by Article 72 into the existing system and plan, using the Commission’s template, provided that this achieves an equivalent level of protection. The same option is extended to certain financial institutions covered by Annex III point 5, which are already subject to internal governance requirements under Union financial services law.

The condition to watch is “equivalent level of protection”. A medical device post-market surveillance plan under Regulation (EU) 2017/745 is built around clinical safety and performance; it does not natively ask whether an Article 14 human oversight measure is being exercised or whether an Article 10 dataset assumption has drifted. Integration means adding the AI-specific rows to the existing plan, not declaring the existing plan sufficient because it has the right title.