EU AI Act Article 72: Post-Market Monitoring by Providers (2026)

Article 72 of Regulation (EU) 2024/1689 imposes a standing obligation on every provider of a high-risk AI system: establish, document, and maintain a post-market monitoring system that runs for the entire lifetime of the system. This is not a one-off audit or a checkbox to tick at launch. It is an active data-collection and analysis programme, carried out by the provider, designed to detect whether the system continues to meet the requirements of Chapter III Section 2 once it is operating in the real world.

The old framing of Article 72 as "market surveillance" is wrong. Market surveillance — the powers of national authorities to inspect, test, and sanction — sits in Articles 74 and following. Article 72 is the provider's own monitoring obligation, distinct from but connected to the authorities' oversight regime. Getting that distinction right shapes every practical decision about who builds the monitoring system, what it covers, and when findings must escalate.

Under the Digital Omnibus agreed in May 2026, the high-risk obligations (including Article 72) apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for high-risk AI embedded in Annex I regulated products. The original 2 August 2026 date no longer applies. That is still roughly 18 months away — long enough to build a proper monitoring programme, short enough that waiting is a mistake.

---

What Article 72 Actually Requires

Article 72(1): A System Proportionate to the Risk

Providers must establish, implement, document, and maintain a post-market monitoring system appropriate to the nature of the AI technology and the risks of the particular high-risk system. The word "proportionate" matters: a recruitment screening tool deployed across thousands of candidates each month warrants more intensive monitoring than a low-volume, narrowly scoped document-classification system that also happens to fall in an Annex III area. The regulation does not mandate a single template — it mandates a system calibrated to what could go wrong and how often.

The obligation runs through the system's entire lifecycle. There is no point at which post-market monitoring becomes optional because the system has been running for a year without incident. New data, new deployer contexts, and changes in the population of users all create new risk signals.

Article 72(2): Active Collection, Documentation, and Analysis of Relevant Data

The monitoring system must actively and systematically collect, document, and analyse data relevant to evaluating continuous compliance with Chapter III Section 2 — the core high-risk requirements covering risk management (Article 9), data governance (Article 10), technical documentation (Article 11), logging (Article 12), transparency to deployers (Article 13), human oversight (Article 14), and accuracy, robustness, and cybersecurity (Article 15).

Several points deserve emphasis:

Deployers are a data source. Article 72(2) explicitly contemplates that relevant data may come from deployers. Providers need to build feedback channels — contractually and technically — that allow deployers to report performance anomalies, unexpected outputs, and near-miss incidents. A provider that releases a system and has no mechanism to hear from the organisations actually running it is not complying with Article 72(2).

Other sources count too. Monitoring is not limited to what deployers report. Providers should draw on their own telemetry, user feedback, academic literature on the model type, and sector-specific regulatory guidance.

Interaction with other AI systems. Where relevant, the monitoring system must cover how the high-risk system behaves in combination with other AI systems it is integrated with. A credit-scoring module embedded in a broader lending platform may perform differently depending on upstream data pre-processing. That interaction is within scope.

Law enforcement exception. Article 72(2) carves out one category: deployers' sensitive operational data used for law-enforcement purposes. Providers building systems for law-enforcement deployers cannot be required to receive and process that data as part of their monitoring programme. In practice, this means providers in the law-enforcement segment need to design monitoring architectures that draw on aggregate, anonymised, or de-identified signals rather than case-level operational data.

Article 72(3): The Post-Market Monitoring Plan

Monitoring must follow a documented post-market monitoring plan. The plan is a required component of the Annex IV technical documentation — the same documentation package that providers must assemble to support conformity assessment under Article 43. A plan filed separately from the technical documentation, or kept only in an internal wiki, does not satisfy Article 72(3).

The European Commission will adopt an implementing act establishing a template for the plan. That template does not yet exist as of June 2026, but the regulation is clear about the plan's purpose: it must describe the methodology, data sources, review frequency, roles responsible for analysis, and escalation procedures when monitoring findings indicate the system may no longer meet a Chapter III Section 2 requirement.

Drafting the plan now, even before the Commission template is published, is sensible. The structural requirements — what data, from where, reviewed how often, by whom, with what escalation triggers — are already apparent from the regulation. A provider that waits for the template will be left constructing a plan under time pressure close to the December 2027 deadline.

Article 72(4): Integration with Sector-Specific Union Law

Where a high-risk AI system is already subject to another piece of Union law that includes equivalent post-market monitoring or post-market surveillance obligations (medical devices and machinery are the clearest examples), providers may integrate the Article 72 monitoring into that existing regime rather than running a parallel process. This matters for companies already operating under the Medical Device Regulation or similar frameworks: if their Article 72 obligations are substantively covered by an existing vigilance or post-market surveillance system, they can consolidate rather than duplicate.

---

How Article 72 Connects to the Wider Compliance Architecture

Article 9: Risk Management System

Article 72 is not a standalone obligation. It feeds directly into the Article 9 risk management system, which providers must establish, implement, document, and maintain throughout the AI system's lifecycle. Article 9 requires providers to identify risks, adopt risk management measures, and evaluate residual risk after mitigation. Post-market monitoring is the mechanism by which providers learn whether those measures are actually working in production — and whether new risks have emerged that were not apparent during development or testing.

If monitoring reveals that a recruitment tool's outputs are consistently less accurate for candidates from certain demographic groups than the pre-launch testing suggested, Article 9 requires the provider to evaluate that finding, update the risk assessment, and take remedial action. Article 72 is the source of that signal; Article 9 is the framework for acting on it.

Article 73: Serious-Incident Reporting

When post-market monitoring surfaces a serious incident — one that causes or could cause death, serious injury, serious damage to property or the environment, or breach of fundamental rights obligations — the provider must report to the relevant national competent authority without undue delay under Article 73.

Article 72 and Article 73 have a clear division of labour: Article 72 is the continuous monitoring infrastructure; Article 73 is the incident-triggered reporting mechanism that activates when monitoring findings cross the serious-incident threshold. A provider that has no Article 72 monitoring system is also likely to miss incidents that would trigger Article 73 reporting, compounding the compliance failure.

Article 73 reporting deadlines are strict: 15 calendar days for standard serious incidents from the date the provider becomes aware, and immediate notification (with a formal report to follow) for life-threatening incidents. These timelines make it clear why monitoring must be active and continuous rather than periodic or reactive.

Articles 74 and Following: Market Surveillance by Authorities

National market surveillance authorities — designated by member states under Article 74 — have powers to request documentation, conduct testing, issue corrective actions, and ultimately require recall or withdrawal of non-compliant systems. Their work is not Article 72's subject matter, but it is the enforcement context within which Article 72 operates. A provider with a well-documented, genuinely active post-market monitoring system is in a fundamentally different position during an authority inspection than one that has filed a nominal plan and done nothing since deployment.

---

The Post-Market Monitoring Plan: What to Include

Article 72(3) places the plan inside the Annex IV technical documentation. The Commission template has not been published yet, but the regulation and the logic of the obligation point clearly to the following structure:

1. System description and risk profile. Which high-risk AI system does this plan cover? What are its Annex III classification grounds? What risk scenarios were identified during pre-launch assessment? This links the monitoring programme to the Article 9 risk register.

2. Data sources. Where will monitoring data come from? Deployer feedback channels, system telemetry, user-accessible reporting mechanisms, third-party testing, sector regulatory sources. For law-enforcement deployers, describe the anonymisation or aggregation approach that avoids the Article 72(2) exception.

3. Performance indicators. What metrics indicate whether the system continues to meet the Chapter III Section 2 requirements? Accuracy and error rates by subgroup (Article 15); human override frequency and patterns (Article 14); incidents logged (Article 12). Choose indicators that would actually detect the failure modes identified in the Article 9 risk assessment.

4. Review frequency. How often is collected data reviewed? Monthly automated dashboards supplemented by quarterly substantive reviews is a common baseline. The frequency should be proportionate to the volume of use and the severity of potential harm.

5. Roles and responsibilities. Who within the organisation is responsible for running the monitoring system, reviewing findings, and escalating to leadership or legal? Document names or roles, not just a generic "compliance function."

6. Escalation thresholds and procedures. At what point does a monitoring finding trigger an update to the Article 9 risk register? At what point does it trigger a preliminary Article 73 investigation? Define the thresholds in advance — making that judgment under pressure after an incident is a worse position to be in.

7. Interaction with other AI systems. If the system is integrated with upstream or downstream AI tools, describe how the monitoring programme accounts for their influence on the high-risk system's performance.

8. Integration with sector law (if applicable). If the provider is relying on Article 72(4) to integrate with an existing Union law monitoring regime, describe that integration explicitly.

---

Worked Example: A 35-Person HR-Tech Provider

A 35-person company sells a CV-screening tool to HR departments across the EU. The tool ranks candidates for shortlisting, which places it in Annex III category 4 (employment and workers management). The provider has completed conformity assessment under Article 43 and placed the system on the market.

Under Article 72, the provider must run a post-market monitoring programme. In practice this means:

Deployer feedback channel. The provider builds a structured reporting form into the product's admin panel. HR managers can flag cases where the tool's ranking appears inconsistent with the job requirements or where candidates they expected to rank highly scored unexpectedly low. Reports are logged automatically with timestamps.

Telemetry on model performance. The system logs prediction confidence scores for each ranking. The provider reviews distributions monthly — a shift in confidence score patterns across applicant cohorts signals potential model drift.

Demographic performance checks. Quarterly, the provider runs the model against a synthetic benchmark dataset representative of EU workforce demographics. Results are compared against pre-launch validation benchmarks. Any gap above a defined threshold triggers an escalation review.

Article 9 linkage. If the quarterly review reveals a material accuracy gap — say, the model's precision rate for candidates with non-EU educational backgrounds has dropped 8 percentage points since launch — the provider updates the Article 9 risk register, assesses whether the system still meets the Chapter III Section 2 requirements, and determines whether a corrective action (retraining, updated data governance) is required.

Article 73 trigger. If a deployer reports that the system's shortlisting contributed to a discriminatory outcome that led to a formal employment tribunal complaint, the provider investigates whether this constitutes a serious incident under Article 73. If it does, they notify the relevant national competent authority within 15 days.

Plan documentation. All of the above is written into a post-market monitoring plan that sits in the Annex IV technical documentation pack. It names the product manager responsible, specifies review cadences, and defines the escalation thresholds.

This is not a huge operation. For a 35-person company, it amounts to one person spending a day each month on monitoring reviews and a quarterly two-hour session for the more substantive checks. What it is not is optional.

---

Penalties for Non-Compliance

Failure to establish a post-market monitoring system, or failure to document it as required by Article 72(3), is non-compliance with a high-risk provider obligation. Under Article 99(4), this falls in the Tier 2 penalty band: up to €15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher.

For SMEs and start-ups, Article 99(6) provides a proportionality protection: the applicable fine is the lower of the two amounts. A company with €3 million annual revenue faces a maximum of €90,000 (3% of turnover) rather than €15 million. That is still material. And it does not include the operational consequences of an authority investigation, which may include suspension of the system's distribution or mandatory recall while enforcement proceedings continue.

Do not confuse this tier with the Tier 1 penalties (€35 million or 7%) that apply only to Article 5 prohibited practices. Missing a post-market monitoring requirement is serious; it is not in the same category as deploying a banned AI technique.

One more penalty figure to be aware of: supplying incorrect or incomplete information to a notified body or competent authority — including incomplete monitoring documentation — carries a Tier 3 fine of €7.5 million or 1% of worldwide annual turnover. Providing a nominal plan that does not reflect actual practice is a risk in both the Tier 2 and Tier 3 directions.

---

How Confir Helps

Confir's AIGM area (Governance and Post-Market Monitoring) maps directly to Articles 9 and 72. The AIGM-02 control structures the post-market monitoring plan as part of the Annex IV technical documentation pack — covering data sources, performance indicators, review cadences, and escalation thresholds. The plan auto-populates from the risk profile and Article 9 findings already captured during intake, so providers are not starting from a blank page.

When a monitoring review surfaces a finding that could cross the Article 73 serious-incident threshold, Confir's incident tracking workflow captures the detection timestamp, investigation steps, and reporting decisions in the immutable audit log. That log is the evidence a provider needs during an authority inspection to show timely, good-faith compliance with Article 73's reporting deadlines.

The risk register links monitoring findings back to the Article 9 risk management system. If a quarterly performance review reveals model drift, the finding is created directly against the affected risk entry — keeping the technical documentation and the live monitoring record in sync, which is exactly what Article 72's feedback loop into Article 9 requires.

---

Key Distinctions Worth Fixing in Your Documentation

Article 72 is a provider obligation; market surveillance is an authority power. If your internal compliance documentation mixes these up — treating Article 72 as the authority's surveillance mandate — your monitoring plan will be scoped incorrectly. Article 72 is about what you, as the provider, do proactively. What authorities can do to you is a separate question.

Article 72 is not Article 26. Article 26 imposes obligations on deployers — to use the system according to the instructions, maintain logs, ensure human oversight competence, and feed serious incidents back to the provider. Deployers are an important data source for the provider's Article 72 programme, but they are not the ones running that programme. If you are a deployer, Article 26 is your primary obligation. If you are a provider, Article 72 is yours.

The post-market monitoring plan is not the risk management system. Article 9 and Article 72 are related but separate instruments. The Article 9 risk management system is established before launch, identifies risks, and defines mitigations. The Article 72 monitoring plan describes how performance data will be collected and reviewed after launch to evaluate whether those mitigations are working. One feeds the other; they are not the same document.

Pre-market conformity assessment (Article 43) does not satisfy Article 72. Conformity assessment is the before-launch process. Article 72 begins at launch and runs indefinitely. Some providers conflate the two, treating a passing conformity assessment as evidence of ongoing compliance. It is not. A system that passes conformity assessment in 2027 may be non-compliant with Chapter III Section 2 by 2028 if performance has degraded and no monitoring programme detected it.

---

What to Do Before 2 December 2027

The deadline is fixed enough to plan against. The Commission's implementing act establishing the monitoring plan template has not been published, but waiting for it before drafting anything is the wrong posture. The template will set form; the substance — what data, from what sources, reviewed how often, by whom, with what escalation triggers — is already determined by the regulation.

A reasonable timeline for a provider of a stand-alone Annex III system:

• Now through Q3 2026: Draft the post-market monitoring plan structure. Identify data sources, define performance indicators, assign roles, set review cadences. Validate the escalation thresholds against the Article 9 risk scenarios.
• Q4 2026: Integrate the plan into the Annex IV technical documentation pack. Build or procure the technical infrastructure (telemetry, deployer feedback channels, testing datasets).
• 2027: Run a dry-run monitoring cycle — at least two full review cycles — before the deadline. Identify gaps in data collection or escalation procedures and fix them. Document the dry-run results.
• 2 December 2027: Obligations apply. The monitoring system must be live, documented, and demonstrably active.

The documentation alone — the plan, the integration with Annex IV, the Article 9 linkage — takes meaningful time to assemble correctly. Starting in the second half of 2026 is not early; it is approximately on time.

---

Related guides

• provider obligations under Article 26
• market surveillance authority enforcement timeline
• Article 72 compliance checklist
• SMB compliance requirements for Article 72
• startup compliance guide for Article 72