EU AI Act post-market monitoring — Article 72 obligations explained

Our Article 9 piece (eu-ai-act-article-9-risk-management) covers the pre-deployment risk management system in full — the six requirements, the evidence each one produces, and how the disposition memo maps to it. This piece deliberately does not repeat that content. What it does is take the one item that piece touches only briefly — post-market monitoring — and treat it as what the regulation actually makes it: a separate article, with a separate obligation, that starts where Article 9's pre-market work ends.

The distinction is not pedantic. Conflating the two produces a specific and common failure: an organisation completes a strong Article 9 risk register before launch, considers the regulatory box checked, and never builds the operational monitoring discipline Article 72 actually requires once the system is live. The risk register was real work. It was also never designed to answer the question Article 72 asks, which is a question about the system's ongoing behaviour, not its design-time analysis.

Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risks of the system. That system must actively and systematically collect, document and analyse relevant data on the performance of the AI system throughout its lifetime — data that may be provided by deployers, or collected through other sources, about how the system is actually performing once it is in real use.

The purpose the article states explicitly is enabling the provider to evaluate the continuing compliance of the AI system with the requirements the regulation sets — meaning the post-market monitoring system is not a passive log, it is the mechanism by which the provider keeps knowing whether the system it certified as meeting the regulation's requirements at launch still meets them once real users, real data, and real edge cases have had time to interact with it.

Article 9 asks whether the analysis was done correctly before the system shipped. Article 72 asks whether the system is still behaving the way that analysis assumed it would, now that it is actually in use — and it keeps asking, for as long as the system is on the market.

The clearest way to hold the two articles apart is by what kind of thing each one produces. Article 9's risk management system is, at its core, a design-time artefact: a risk register, an evaluation methodology, a treatment plan, a residual risk acceptance statement, all of which can be produced, reviewed, and signed off before the system reaches production. It is thorough analysis performed once — or re-performed at defined trigger points — against the system as designed.

Article 72's post-market monitoring system is an operational discipline: it has to actually run, continuously, against the system as deployed, collecting real data from real usage and feeding what it finds back into the organisation's decision-making. It is not something that gets completed once and filed. A monitoring plan that was written and then never operated is not a monitoring system in the sense Article 72 means — it is a document describing a monitoring system that does not exist.

This distinction matters directly for how a design-time security review fits in. A design-time review — the kind this site describes throughout — supports Article 72 by producing the initial risk register and control plan that a post-market monitoring plan then has to track against: what the review flagged as a risk to watch becomes a signal the monitoring plan should actually monitor for. What a design-time review does not do, and cannot substitute for, is the provider's own ongoing operational monitoring once the system is live. That obligation belongs to the provider, running continuously, against production usage a point-in-time design review was never built to observe.

A post-market monitoring plan that actually satisfies Article 72, rather than gesturing at it, defines four things concretely rather than in general terms.

• What performance signals are tracked, and against what baseline. Not “monitor for issues” but named metrics — accuracy or error rate on defined task categories, rate of flagged or overridden outputs, rate of user-reported problems — each compared against a stated baseline established at launch, so a deviation is something the plan can actually detect rather than something someone happens to notice.
• What data sources feed the monitoring system.Deployer-reported incidents, structured user complaints, internal QA sampling, and any telemetry the provider has agreed with deployers it will receive — named specifically, with an owner for collecting each one, not left as an assumption that data will surface on its own.
• How findings feed back into a decision. A monitoring signal that crosses a defined threshold has to trigger something specific — a re-assessment of the risk register, a corrective action, an update to the technical documentation — with the trigger and the decision-maker named in the plan, not left to whoever happens to see the data.
• Review cadence. A stated frequency at which the monitoring data itself gets reviewed as a whole, independent of any single incident — because a slow drift in performance rarely crosses an incident threshold on any single day, and only shows up if someone looks at the trend on a schedule.

The regulation is explicit that the data feeding a post-market monitoring system can come from deployers or be collected through other sources — a deliberately broad framing, because a provider frequently does not have direct visibility into how its system performs inside every deployer's environment. This makes the deployer relationship a first-class part of the monitoring plan, not an afterthought: if the plan's only data source is what the provider can observe directly, and the system is primarily used through deployer integrations the provider does not instrument, the monitoring plan has a structural blind spot regardless of how well-designed the rest of it is.

The feedback loop is what turns collected data into the “evaluate continuous compliance” purpose the article states. A finding that performance has drifted, or that a specific misuse pattern is occurring more often than the original risk assessment anticipated, has to be able to reach the same risk management system Article 9 established — updating the risk register, and where the drift is material, triggering a re-assessment or corrective action rather than sitting in a monitoring dashboard no one is mandated to act on.

Article 73's serious-incident reporting obligation sits next to Article 72 in the regulation's structure and is easy to conflate with it, but the two are distinct requirements. Article 72 is the general, ongoing monitoring system — collecting and analysing performance data as a continuous practice. Article 73 is a specific, triggered obligation to report serious incidents to market surveillance authorities within defined timeframes once one has occurred.

A well-run post-market monitoring system under Article 72 is frequently the mechanism that surfaces the kind of event Article 73 requires reporting on — the two are connected in practice even though they are separate obligations in the text. This piece does not work through Article 73's reporting requirements in detail; it is flagged here only so the two are not mistaken for the same obligation, the way Article 9 and Article 72 themselves are often mistaken for each other.

Across the systems we have seen or reviewed evidence for, the same gap pattern shows up more than any other on the post-market side: an organisation with a genuinely strong pre-deployment risk register — well documented, specific to the system, evaluated with a real methodology — that was never wired to any operational monitoring plan once the system shipped. The register was produced correctly. It was also treated as a launch deliverable rather than a living artefact, and nothing in the organisation's process picks it back up once the system is in production.

The result is a risk register that becomes stale documentation almost immediately — accurate as a description of the system's design-time analysis, and silent on whether any of that analysis still holds true six months into real usage. From the outside, at audit time, this looks like a mature AI governance program: the artefact exists, it is well-written, it covers the required categories. What it does not do is answer the question Article 72 actually asks, because nothing has updated it since launch.

A design-time security review — the kind that produces the risk register, the control plan, and the residual risk acceptance that satisfy Article 9 — is the natural starting point for a post-market monitoring plan, not a substitute for one. The risks the review identified, the controls it required, and the assumptions its residual risk acceptance rested on are exactly the things a monitoring plan should be watching for drift against. A monitoring plan built without reference to the design-time review is reinventing a baseline the review already established.

What the review itself does not do, and what no point-in-time analysis can do, is observe the system continuously once it is live. That obligation — actively and systematically collecting and analysing performance data throughout the system's lifetime — belongs to the provider, as an operational function, running for as long as the system is on the market. The design-time review hands that function a starting baseline and a set of things worth watching. It cannot do the watching itself, and a governance program that treats it as though it can is the exact gap pattern the previous section describes.