Why post-market monitoring matters
Conformity assessment is a photograph. It establishes that a high-risk AI system met the requirements of the EU AI Act on the day it was assessed. Everything after that day is governed by Article 72, which requires providers to establish and document a post-market monitoring system that actively and systematically gathers and analyses how the system performs in the field, throughout its life, so the provider can tell whether it still complies. For AI in particular, this matters more than it does for a static product: models drift, input data changes, and the population a system is used on rarely stays the same as the population it was validated against.
Something significant has just happened to this obligation, and it has been almost entirely overlooked. The Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026, removed the European Commission’s power to adopt a binding template for the post-market monitoring plan. Providers had been waiting for that template. It is not coming. What replaces it is non-binding guidance, promised for a date that leaves very little room before the obligations themselves apply.
What Article 72 requires of providers
Article 72 binds providers of high-risk AI systems. It requires a post-market monitoring system proportionate to the nature of the AI technologies involved and to the risks of the particular system, which actively and systematically collects, documents and analyses relevant performance data — data that may come from deployers or from other sources — across the whole lifetime of the system, so that the provider can evaluate its continuing compliance with the requirements in Chapter III, Section 2. Where relevant, that analysis extends to how the system interacts with other AI systems.
The monitoring system has to be based on a written post-market monitoring plan, and that plan forms part of the technical documentation described in Annex IV. This is the point most often missed. The plan is not an internal operations document you can write later; it is part of the file that must exist at conformity assessment, before the system is placed on the market. A provider assessing a system in 2027 will need a plan in 2027.
Post-market monitoring should not be confused with serious incident reporting under Article 73. Article 72 is continuous internal machinery, documentation-facing, and it runs whether or not anything goes wrong. Article 73 is an event-triggered external notification to a market surveillance authority when a serious incident occurs. The two are related — good monitoring is often what surfaces the incident — but they are separate obligations with separate triggers.
What the Digital Omnibus changed
The template that was promised
As adopted in 2024, Article 72(3) obliged the Commission to adopt an implementing act laying down a template for the post-market monitoring plan and the list of elements to be included in it. That was a binding, harmonised format: every provider in the Union would have filled in the same structure, and a plan matching the template would have been, in form at least, unarguable. The deadline for adopting it has passed and it was never adopted.
What the Omnibus recital actually says
Regulation (EU) 2026/1744 removed the empowerment. Recital (41) explains the reasoning, and it is worth reading closely because it is the clearest statement of where this obligation now stands. It records that Article 50(7), Article 56(6) and Article 72(3) “should therefore be amended to remove the empowerments conferred on the Commission to adopt implementing acts”. On post-market monitoring specifically, it says that removing the empowerment to adopt a harmonised template “has the additional benefit of offering more flexibility for providers of high-risk AI systems to put in place a system for post-market monitoring that is tailored to their organisation”.
It then adds the replacement: “recognising the need to offer clarity regarding how providers of high-risk AI systems are required to comply with their obligation set out in Article 72(1) of Regulation (EU) 2024/1689, the Commission should be required to publish guidance, including a voluntary template, on the post-market monitoring plan by 2 September 2027”.
Note the adjective. A voluntary template, not a harmonised one. Much of the commentary that has appeared since July quietly drops the word, and it is the whole point for a business trying to work out what it must do. Note also what did not change: the empowerment was removed, not the obligation. Providers still have to run a post-market monitoring system and still have to base it on a plan that sits in the Annex IV technical documentation.
Flexibility, and what it costs you
The Commission’s framing is that this is deregulatory, and for a sophisticated provider it genuinely is. A tailored monitoring system beats a form-filling exercise, and a company with mature product telemetry can design something that reflects how its system actually fails rather than how a committee imagined it might.
For everyone else it transfers work and risk. Under a binding template, the question “have we done enough?” had a formal answer. Without one, the answer is a judgement call made by the provider and reviewed after the fact by a notified body or a market surveillance authority. That is a harder position to occupy, and it is the reason a documented rationale — why this data, this frequency, these thresholds — now matters as much as the monitoring itself.
The timing problem nobody is discussing
Recital (40) of the Omnibus sets the new application dates: Sections 1, 2 and 3 of Chapter III apply from 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those classified under Article 6(1) and Annex I. The guidance on the post-market monitoring plan is due by 2 September 2027.
That leaves roughly thirteen weeks between the guidance appearing and the Annex III obligations applying. Since the plan has to be in the technical documentation at conformity assessment, and conformity assessment happens before placing on the market, providers working towards December 2027 will in practice be designing and running their plans well before the guidance exists. Waiting for it is not a strategy. For Annex I products the position is easier, with roughly eleven months between the two dates, but those providers face their own scheduling pressure around notified body capacity.
Where the plan sits in the rest of your compliance file
Article 72 is not free-standing, and building it in isolation is the most common structural error. The post-market monitoring system is one of the thirteen aspects that Article 17 requires a provider’s quality management system to cover, so it has to be a governed process with a named owner, not an informal habit. Article 9(2)(c) requires the risk management system to evaluate risks that emerge from the data gathered under Article 72, which makes monitoring an input to risk management rather than a downstream report. Article 12(2)(b) requires the logging capability of a high-risk system to enable the recording of events that facilitate Article 72 monitoring, so design decisions about logging constrain what monitoring is possible later. And Article 19(1) requires providers to keep those logs, to the extent they are under their control, for a period appropriate to the intended purpose and at least six months.
Read together, these say something practical: your monitoring plan should be written after you know what your system logs, what your risk file identifies as worth watching, and who in your quality system owns the result. A plan drafted independently of those three will describe monitoring that your product cannot actually perform.
Practical example
A Swedish company supplies municipalities with an AI system that helps caseworkers assess eligibility for public assistance benefits. Systems used to evaluate eligibility for public assistance benefits and services fall within Annex III, so the company is a provider of a high-risk AI system and its municipal customers are deployers. It has been waiting for the Commission template before writing anything.
That wait has now become indefinite in the form it expected. The productive move is to design the plan from the system’s own failure modes: which eligibility categories the model performs worst on, what caseworker override rates look like by municipality and whether they are drifting, how quickly a change in national benefit rules degrades accuracy, and what a municipality is contractually required to report back. Those are the things that would actually reveal a compliance problem in this system. A generic template would have captured perhaps half of them. The company should also write down why it chose those indicators, because that reasoning is what a supervisory authority will assess in the absence of a prescribed form.
Common mistakes companies make
The first is waiting for the template. It was removed in July 2026, and what is coming in its place is voluntary and late. The second is treating the plan as an operations document rather than part of the Annex IV technical documentation, which means it is needed at conformity assessment rather than after launch. The third is designing monitoring that the product cannot support, because logging decisions were made without reference to what would later need to be observed.
The fourth is collecting data without an analysis obligation attached: Article 72 requires providers to collect, document and analyse, and dashboards nobody reads satisfy none of those verbs. The fifth is relying on deployers to volunteer information. Deployer feedback is one contemplated source among others, and if you want it reliably, the contract has to say so — particularly where the system is delivered as a service and the logs sit with the provider rather than the customer.
Recommended actions
Start the plan now rather than waiting for guidance that arrives roughly three months before the Annex III obligations apply. Build it from your own risk management file and your own logging design, define the indicators you will watch, the sources they come from, how often you will look and what threshold triggers action, and record the reasoning behind each choice. Where you already run post-market surveillance under sectoral legislation, map the AI-specific elements onto it rather than building a second system, and check carefully what your existing surveillance does not cover — model drift and population shift usually fall outside it.
Then close the loop contractually and organisationally. Put the data you need from deployers into your customer agreements, including access to logs where the system is hosted by you, and assign the plan to a named owner inside your quality management system with a review cycle. When the Commission publishes its guidance and voluntary template in 2027, treat it as a check against something you have already built and run, not as the starting point.
Frequently asked questions
Is there still a mandatory format for the post-market monitoring plan?
No. The Digital Omnibus removed the Commission’s power to adopt a binding template by implementing act. The Commission is instead to publish guidance, including a voluntary template, by 2 September 2027. The underlying obligation to run a monitoring system based on a documented plan is unchanged.
Does post-market monitoring apply to us as a deployer?
Article 72 is a provider obligation. Deployers have their own duties, including monitoring operation in accordance with the instructions for use and keeping logs under their control for at least six months, and providers frequently need deployer cooperation to make their own monitoring work. That cooperation should be dealt with in the contract.
When do we actually need the plan in place?
The plan forms part of the Annex IV technical documentation, which must exist when the system undergoes conformity assessment, before it is placed on the market. With the high-risk obligations applying from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, the practical deadline for most providers is earlier than those dates.
Conclusion
The removal of the post-market monitoring template is a small amendment with a large practical effect. It hands providers the freedom to design monitoring that fits their system, and simultaneously hands them the burden of justifying whatever they design. With guidance not due until September 2027 and the Annex III obligations applying that December, the companies that treat this as a design problem to solve now will be in a considerably better position than those still waiting for a form to fill in.
Lawgent helps businesses design AI Act post-market monitoring plans and set the contractual terms that make them work in practice.
