Post-market monitoring reads like a solo obligation. One provider, one system, one plan. Read the sourcing and the picture inverts: the provider owes the duty and holds almost none of the material that discharges it. Operational signal sits with deployers. Logs sit with whoever controls the runtime. Modification history sits with whoever changed the system downstream. Incident reports sit with authorities in whichever Member State the harm occurred.
A monitoring plan is therefore a data custody problem before it is a documentation problem. The useful question is not what the plan should look like. The useful question is who holds each input, which provision compels them to hand it over, and whether that provision is in force yet.
The in-force question is where 2026 gets awkward. The Digital Omnibus moved the high-risk obligations without moving the monitoring duty, which leaves a gap worth understanding before you staff a programme around it. The sections below take the holders one at a time.
Article 72 survived the delay that moved almost everything feeding it
Article 113 sets a general application date of 2 August 2026 and then carves out exceptions by chapter. Reading those carve-outs is the whole exercise. Point (c) defers Chapter III, Sections 1, 2 and 3 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for systems classified under Article 6(1) and Annex I.
Article 72 does not live in Chapter III. Post-market monitoring sits in Chapter IX, which runs from Article 72 to Article 94 and covers monitoring, information sharing and market surveillance. Chapter IX appears nowhere in the Article 113 exceptions apart from Article 78 on confidentiality. On the face of the text, the monitoring duty has applied since 2 August 2026.
Article 72 and Chapter III therefore diverge on timing. Articles 16 to 27 are Chapter III, Section 3, which means the provider obligations and the deployer obligations are deferred to December 2027 at the earliest. The duty to run a post-market monitoring system was not deferred. The duties of the parties who hold the monitoring data were. A provider reading only the headlines about the delay will conclude it has sixteen months of quiet, and will be reading the wrong chapter.
Honesty about the limits of that reading matters. The monitoring duty attaches to high-risk systems, and the provisions that classify a system as high-risk are themselves deferred. Specialists have landed on both sides of whether Article 72 can bite before the category it depends on operates, and no authority has settled it. Treating the duty as live is the defensible position. Treating the delay as covering everything is not.
The provider owes the monitoring system and holds the least of the data
Article 72(1) requires providers to establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the risks of the system. Proportionate is doing real work in that sentence. A recruitment screening tool used by forty employers and a credit model running inside one bank do not owe the same apparatus.
Article 72(2) defines the activity rather than the document. Providers must actively and systematically collect, document and analyse relevant data on performance across the system’s lifetime, in order to assess continuing compliance with Chapter III, Section 2. Two words carry the load. Actively rules out waiting for complaints. Systematically rules out a quarterly glance at a dashboard. Sensitive operational data of law enforcement deployers is excluded from the collection.
Then Article 72(3), which the omnibus rewrote. The post-market monitoring system must be based on a post-market monitoring plan, and the plan is now part of the technical documentation referred to in Annex IV. Placement inside Annex IV is the consequential half of that amendment. A document inside the technical documentation is a document a conformity assessment body reads and a market surveillance authority can demand, which turns the plan from an internal artefact into an exhibit. Teams building that technical file should align it with the per-version record each model already needs rather than running two parallel documents.
Deployers hold the operational signal, and their duty to share it is deferred
Post-market monitoring depends on observation by whoever operates the system in the field. Article 26(5) is the provision that moves that observation upstream. Deployers must monitor the operation of the high-risk system on the basis of the instructions for use. Where they have reason to consider that use in accordance with those instructions may present a risk within the meaning of Article 79(1), they must inform the provider or distributor without undue delay and suspend use. Where they identify a serious incident, they must inform the provider first, then the importer or distributor, then the relevant market surveillance authorities.
Article 26 is in Chapter III, Section 3. The deferral in Article 113 point (c) therefore reaches it. A provider whose monitoring plan assumes a stream of deployer notifications is building on a duty that does not bind the deployer until December 2027 for Annex III systems and August 2028 for systems inside Annex I products.
Contract is the available substitute, and it is better than the statute in one respect. A statutory notification duty fires on a risk threshold. A contractual reporting schedule fires on a calendar, which is what a monitoring programme actually needs. Providers negotiating that clause now should treat it the way they would treat any information right against a supplier or counterparty, with named fields, a frequency, and a route for the data to arrive in a form you can analyse.
Financial institutions get a shortcut. Where a deployer is a financial institution subject to internal governance requirements under Union financial services law, the monitoring obligation is treated as met by complying with those rules.
Downstream providers who altered your system owe documentation and test access
Someone who puts their name on your system, substantially modifies it, or changes its intended purpose so that it becomes high-risk becomes a new provider. The original provider then has duties running the other way, and the omnibus expanded them.
Article 25(2) now spells out what cooperation means. The initial provider must make available technical documentation sufficient to assess compliance with the Article 16 requirements. The initial provider must also disclose known limitations and failure modes. Targeted technical access for testing and validation has to follow. All three sub-obligations are new text, and each one is a monitoring input in disguise: known failure modes are exactly what a post-market monitoring plan is supposed to watch for.
A carve-out runs alongside them. The cooperation duty does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk system, and the omnibus widened that carve-out from handing over documentation to cooperating at all. Specifying that exclusion is now a commercially meaningful act rather than boilerplate.
Article 25(4) keeps the contractual route for third parties supplying models, tools, services, components and processes, and the omnibus added that the AI Office may develop and recommend voluntary model contract terms, published free of charge. Free model terms will not fit every deal. Having a published baseline changes the negotiation anyway, because a supplier refusing the standard clause now has to explain why.
Logs sit wherever control sits, and control is the test in two separate articles
Article 19 obliges providers to keep logs automatically generated by their high-risk systems, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months. Article 26(6) places the same six-month floor and the same control test on deployers for the logs they control. Providers that are financial institutions keep the logs as part of the documentation already required under financial services law.
Control is the operative word in both places, and it rarely sits in one organisation. A model served through a customer’s own cloud tenancy generates logs the provider never sees. A system embedded in a product generates logs the integrator holds. Running the plan against logs you cannot reach is the most common structural failure in this area, and the fix is an access term rather than a technical one.
Worth noting what the six months is not. Six months is the statutory floor for retention, not a judgement about what monitoring needs. A plan assessing continuing compliance across a system’s lifetime against a log window of half a year will struggle to show drift, seasonality or slow degradation. Setting retention from the monitoring question rather than from the floor is the cheaper decision to take early, and it belongs in the same conversation as handling model updates and substantial change.
Other AI systems your system interacts with form the second limb of Article 72(2)
Article 72(2) adds a clause that most summaries skip. Where relevant, post-market monitoring includes analysis of the interaction with other AI systems. Agentic deployments make that clause operational rather than theoretical, because a system whose inputs are another model’s outputs can degrade without anything changing inside it.
Monitoring that boundary means knowing what the boundary is, which in practice means an inventory that records dependencies rather than just systems. Most registers list models and owners. Few record which system consumes which other system’s output, and that edge is the thing Article 72(2) asks about. Extending the register of systems in scope to carry those edges costs little while the estate is small and is painful to retrofit later.
Market surveillance authorities hold what someone else reported about you
Serious incident reports under Article 73 travel to the market surveillance authority of the Member State where the incident occurred. A deployer who cannot reach the provider reports directly. So a provider can be the subject of a report it has not seen, filed by a party it does not control, in a jurisdiction it does not operate in.
Article 73 is a distinct regime with its own clocks and its own unresolved commencement question, and this site covers it separately. The short version is that the reporting periods run to fifteen days by default, ten where a death may have been caused, and two for a widespread infringement or serious and irreversible disruption to critical infrastructure. For the full treatment, including which duties bind today and which wait, see the reporting clocks that attach once an incident is identified.
The monitoring connection is the one worth drawing here. Article 3(49) defines a serious incident across four limbs: death or serious harm to health, serious and irreversible disruption to critical infrastructure, infringement of Union law obligations protecting fundamental rights, and serious harm to property or the environment. Monitoring is how an organisation notices that one of those four has occurred. A reporting process with no monitoring behind it is a process waiting for a journalist.
Scale gives some sense of the base rate. The OECD’s AI Incidents Monitor carried about 18,579 recorded incidents and hazards as at 24 October 2026, drawn from media reporting rather than regulatory filings. Media-sourced counts are not a compliance baseline. Such counts do establish that the population of events a monitoring plan is meant to catch is large and growing, and that most of them surface outside any formal channel first.
The template arrives on 2 September 2027, three months before the duty it describes
Original Article 72(3) directed the Commission to adopt an implementing act establishing a template for the monitoring plan and a list of the elements to be included in it. Regulation (EU) 2026/1744 replaced that paragraph. The replacement reads that the Commission, taking utmost account of the opinion of the Board, shall adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027. The Commission’s own article reference now shows that wording and marks the paragraph as amended.
Article 72(3) bundles two changes into that replacement, and the second is easy to miss. An implementing act is binding and adopted under the examination procedure. Guidance is not binding, and a template inside guidance is a voluntary one. So the specification of what goes in the plan moved from a binding instrument to an optional one.
Now the arithmetic. Guidance is due 2 September 2027. Annex III high-risk obligations apply from 2 December 2027. Three months separate the template from the deadline it serves, and that assumes the Commission hits the date. Precedent argues for caution. The Article 73(7) guidance on serious incident reporting was due 2 August 2025 and remains unfinalised more than fourteen months past that deadline. A draft and a consultation landed on 26 September 2025, with comments closing that November. Practitioner analysis of that draft is currently a better guide to the Commission’s thinking than the finished instrument, because there is no finished instrument.
Planning to the template is therefore planning to a date that has slipped once already, for a document that will not bind you when it arrives. Writing the plan from Article 72 and Annex IV directly is the position that survives either outcome.
Annex I products and financial institutions may fold the plan into what they already run
Article 72(4) is the relief valve, and two populations can use it. For high-risk systems covered by the Union harmonisation legislation in Section A of Annex I, where a post-market monitoring system and plan already exist under that legislation, providers may integrate the Article 72 elements into it, provided the result achieves an equivalent level of protection. The same route is open for Annex III point 5 systems placed on the market by financial institutions subject to governance requirements under Union financial services law.
Equivalent level of protection is the condition that decides whether integration works, and it is an assessment a provider has to document rather than assert. A medical device manufacturer already running post-market surveillance has most of the apparatus. Showing that the apparatus also assesses continuing compliance with Chapter III, Section 2, which is what Article 72(2) asks for, is a mapping exercise with a written conclusion at the end of it. Teams that have done this across frameworks before will recognise the shape from reconciling one control set against several.
| Input | Who holds it | Provision | In force from |
| Monitoring system and plan | Provider | Article 72(1) to (3) | 2 August 2026 |
| Operational observation and risk notification | Deployer | Article 26(5) | 2 December 2027 or 2 August 2028 |
| Documentation, failure modes, test access | Initial provider to new provider | Article 25(2) | 2 December 2027 or 2 August 2028 |
| Provider-side logs, six month floor | Provider | Article 19 | 2 December 2027 or 2 August 2028 |
| Deployer-side logs, six month floor | Deployer | Article 26(6) | 2 December 2027 or 2 August 2028 |
| Serious incident reports | Market surveillance authority | Article 73 | 2 August 2026, contested |
| Plan template and guidance | European Commission | Article 72(3) as replaced | due 2 September 2027 |
What an inspector samples when the template does not exist yet
An authority asking about post-market monitoring in 2028 will not ask whether you used the Commission’s template. Expect the questions Article 72 already contains. The answers are either in a record or they get reconstructed under pressure.
A defensible record answers six questions, and those do most of the work. Which systems in the estate are high-risk, and when was each classified. What data does each system’s plan collect, and on what cadence. Where does that data come from, and what compels the holder to provide it. What analysis was performed, by whom, and what did it conclude. What changed as a result, and when. Which findings crossed into a serious incident assessment, and what happened next.
Notice that five of the six are about provenance and timing rather than content. Provenance is the practical reason post-market monitoring fails inside otherwise competent organisations. The analysis usually happens. The record of who looked, at what, on which date, against which threshold, usually does not, and a record assembled after the question is asked carries no weight. govern365.ai exists to hold those six answers against the system they belong to, with the timestamps attached, so the monitoring plan in the Annex IV file and the evidence behind it stay the same artefact. Where that evidence physically lives matters less than that it is somewhere an auditor can sample it without a reconstruction project.
Sequencing the work is the remaining decision. Classification first, because a plan for a system you have not classified is a plan without a scope, and whether a system lands in Annex III at all determines which date applies to it. Contracts second, because information rights take longer to negotiate than dashboards take to build. Collection third. Teams running this as a continuous process rather than a project can see how govern365.ai operationalises governance workflows end to end.
One habit is worth carrying over from the transparency work, where the duties were also left untouched by the delay. Write the commencement state into the record beside each duty, rather than the duty alone. A register that says Article 26(5) applies, without saying from when and to which Annex, will produce a confident wrong answer the first time somebody relies on it. Carrying commencement state on every duty across every regime in scope is what govern365.ai was built to do.
Questions teams ask about post-market monitoring
Does Article 72 apply now, or was it delayed with the high-risk rules?
Article 72 sits in Chapter IX, and Article 113 defers only Chapter III, Sections 1 to 3, to 2 December 2027 and 2 August 2028. Chapter IX is not named in the exceptions. On the text, the monitoring duty has applied since 2 August 2026. The counter-argument is that the duty attaches to a category the deferred provisions define, so it may have no population to act on yet. No authority has resolved it, and treating the duty as live is the defensible planning assumption.
What has to be in a post-market monitoring plan?
No binding specification exists. The Commission was originally directed to adopt an implementing act setting out a template and a list of elements. Regulation (EU) 2026/1744 replaced that with a duty to adopt guidance, including a template, by 2 September 2027. Until then the content comes from Article 72(1) and (2), from Annex IV, and from the Chapter III, Section 2 requirements the monitoring is meant to assess continuing compliance with.
Is the post-market monitoring plan part of the technical documentation?
Yes, and that is new. The omnibus amendment to Article 72(3) states that the plan shall be part of the technical documentation referred to in Annex IV. A conformity assessment body and a market surveillance authority can therefore both reach it, which raises the bar on how the plan is written.
Do deployers have to send monitoring data to the provider?
Eventually. Article 26(5) requires deployers to monitor operation on the basis of the instructions for use, to inform the provider without undue delay where use may present a risk under Article 79(1), and to inform the provider on identifying a serious incident. Article 26 is in Chapter III, Section 3, so it does not bind until 2 December 2027 for Annex III systems or 2 August 2028 for Annex I systems. Contract is the only reliable route before those dates.
How long do logs have to be kept?
At least six months under both Article 19 for providers and Article 26(6) for deployers, in each case only for logs under that party’s control, and for a period appropriate to the intended purpose. Six months is a floor rather than a target. A programme trying to detect slow performance drift will usually need a longer window than the statutory minimum.
Can a medical device manufacturer reuse its existing post-market surveillance system?
Article 72(4) allows it. Where a post-market monitoring system and plan already exist under the Union harmonisation legislation in Section A of Annex I, the Article 72 elements may be integrated into it provided an equivalent level of protection is achieved. The equivalence has to be assessed and documented rather than assumed, and the mapping should show how the existing system assesses continuing compliance with Chapter III, Section 2.
How does post-market monitoring relate to serious incident reporting?
Monitoring is how an organisation notices that something reportable happened. Article 3(49) defines a serious incident across four limbs, covering death or serious harm to health, serious and irreversible disruption to critical infrastructure, infringement of Union law protecting fundamental rights, and serious harm to property or the environment. The reporting clocks under Article 73 run to fifteen days by default, ten where a death may have been caused, and two for widespread infringement or critical infrastructure disruption.
What should a provider do in the next twelve months?
Classify the estate and record when each classification was made. Negotiate information rights with deployers and integrators, since those take longest. Decide log retention from the monitoring question rather than from the six-month floor. Write the plan against Article 72 and Annex IV now, and treat the September 2027 guidance as a reconciliation exercise rather than a starting point.
