Insights

EU AI Act Articles 72 & 73: A Plain-English Guide to Post-Market Monitoring and Serious Incident Reporting

Last updated · July 10, 2026

Your high-risk AI system passed conformity assessment, got its CE mark, and shipped. Congratulations - now the real compliance work begins.

Articles 72 and 73 of Regulation (EU) 2024/1689 (the EU AI Act) govern what happens after your system is on the market: how you watch it, what you do when something goes wrong, and how fast you have to tell a regulator. For Annex III high-risk systems, these obligations apply from 2 August 2026 under current law. A provisional political agreement reached in May 2026 under the Digital Omnibus package would push that date to 2 December 2027 - but that deal still needs formal Parliament and Council adoption plus Official Journal publication. Until it does, 2 August 2026 is your planning anchor.

This guide walks through both articles in plain English, explains the Commission's September 2025 draft guidance on incident reporting, and gives you a practical checklist to build your programme before the clock runs out.

Article 72 in Plain English: Post-Market Monitoring

What the law actually requires

Under Article 72 of the EU AI Act, providers of high-risk AI systems must establish and document a post-market monitoring system that is proportionate to the nature of the AI technologies and the risks of the system. "Proportionate" matters: a CV-screening tool and a medical-imaging classifier both need monitoring plans, but the depth of data collection and analysis should reflect the stakes involved.

The monitoring system must do three things actively and systematically throughout the system's lifetime:

Collect relevant data on performance - which may be provided by deployers or gathered through other sources.
Document that data in a way that is retrievable and auditable.
Analyse it to let you evaluate continuous compliance with the Chapter III, Section 2 requirements (risk management, data governance, technical robustness, transparency, human oversight, accuracy, and cybersecurity).

The post-market monitoring system must also include, where relevant, an analysis of the interaction with other AI systems. If your system feeds into or receives outputs from another AI, that interface is in scope.

The monitoring plan and Annex IV

The post-market monitoring system must be based on a post-market monitoring plan, and that plan must form part of the Annex IV technical documentation. This is not a separate compliance artefact you can bolt on later - it lives inside your technical file from day one.

The Commission was required to adopt an implementing act with a template for the post-market monitoring plan and a list of elements to include by 2 February 2026. As of the time of writing, that implementing act has not been formally published. Don't wait for it: design your data collection architecture now and map it to the template once it arrives.

Integration with existing monitoring regimes

If your system is already covered by Union harmonisation legislation listed in Annex I (for example, medical devices under MDR/IVDR), you can integrate the Article 72 elements into your existing post-market surveillance plan rather than creating a parallel document - provided the integrated approach achieves an equivalent level of protection. The same option is available to financial institutions deploying Annex III point 5 systems (credit-scoring, insurance) that already have internal governance processes under EU financial services law.

Deployers are a data source, not a bystander. Article 26 requires deployers to monitor the operation of high-risk AI systems and inform providers of serious incidents and risks. Build a structured data-sharing channel with your deployers into the monitoring plan — don't rely on ad hoc emails when something goes wrong.

Article 73 in Plain English: Serious Incident Reporting

What counts as a "serious incident"?

Article 3(49) of the EU AI Act defines a "serious incident" as an incident or malfunction of an AI system that directly or indirectly leads to: (a) death or serious harm to a person's health; (b) serious and irreversible disruption of the management or operation of critical infrastructure; (c) infringement of EU-law obligations protecting fundamental rights; or (d) serious harm to property or the environment.

The Commission's draft guidance (published 26 September 2025, consulted until 7 November 2025) puts useful flesh on these bones:

Health harm covers life-threatening illness, temporary or permanent impairment of a body structure or function, conditions requiring or prolonging hospitalisation, or medical intervention to prevent such outcomes.
Critical infrastructure disruption is "serious" if it creates an imminent threat to life or physical safety, and "irreversible" if physical infrastructure must be rebuilt, essential data cannot be restored, or specialised equipment is permanently damaged.
Fundamental rights infringement must significantly interfere with Charter-protected rights at scale - the guidance cites a recruitment tool that systematically discriminates by ethnicity, or a credit-scoring system that categorically rejects applicants from certain neighbourhoods.
Property or environmental harm is assessed by economic impact, cultural significance, and permanence of damage.

The indirect-causation rule

One of the most important clarifications in the draft guidance: in the Commission's view, an indirect causal link between the AI system and the harm is sufficient to trigger the reporting duty. The guidance gives two illustrative examples: an incorrect AI medical analysis that causes harm only after a clinician acts on it, and a flawed AI credit or loan assessment that leads to financial harm downstream. If your system is a step in a chain that ends in serious harm, you may still need to report.

The reporting deadlines - and they are tight

Article 73 establishes a tiered reporting system with deadlines ranging from 2 to 15 days depending on the severity and type of incident. Here is how the tiers work:

Article 73 Reporting Deadlines

Trigger	Deadline	Practical notes
Standard serious incident — causal link established or reasonably suspected	15 days	Clock starts when you become aware. An initial incomplete report is permitted; complete report follows.
Widespread infringement OR serious and irreversible disruption of critical infrastructure	2 days	Fastest tier. Treat any critical-infrastructure-adjacent incident as potentially falling here until assessed otherwise.
Death — causal link established or suspected	10 days	Runs from the date you establish or suspect the causal link, not from the date of death.

Reports go to the market surveillance authority of the member state where the incident occurred - not to the AI Office (that's the GPAI route under Article 55(1)(c)). If you operate across multiple member states and an incident spans borders, map your authority contacts in advance.

After you file: what Article 73 requires next

Filing the initial report is not the end. Article 73(6) requires you to:

Investigate the incident, including a risk assessment.
Take corrective action - and document it.
Cooperate with the competent authority and, where relevant, the notified body.
Not alter the AI system in any way that could affect the evaluation of causes without first informing the authorities. This is the "evidence preservation" rule, and it has teeth.

Authorities may take market-surveillance measures under Regulation (EU) 2019/1020, and those measures can be triggered within 7 days of receiving your notification.

Simplified regime for regulated sectors

The draft guidance proposes a significant carve-out for sectors that already carry equivalent reporting duties. Where a high-risk Annex III system is already covered by another EU law with equivalent incident-reporting obligations - such as NIS-2 for critical infrastructure, CER, DORA, or MDR/IVDR - Article 73 would apply only to incidents involving fundamental-rights infringements (Article 3(49)(c)). In practice, the underlying incident continues to be reported under the sector regime; the AI Act is used only to notify the fundamental-rights dimension of the same event. This is still draft guidance - watch for the final version.

GPAI models with systemic risk: a parallel duty

If you also provide a GPAI model with systemic risk, Article 55(1)(c) imposes a separate obligation to report serious incidents to the AI Office and national competent authorities. The September 2025 draft guidance does not address this obligation, but the Commission's GPAI Code of Practice contains relevant provisions. If you are subject to both regimes, align your reporting workflows now.

Penalties for getting it wrong

Breaching the post-market monitoring or serious incident reporting obligations falls under the Article 99 penalty tier of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, the lower of the two figures applies.

The Incident Triage Widget: Is This a Reportable Serious Incident?

Use this decision tool to quickly assess whether an event involving your high-risk AI system may trigger an Article 73 reporting obligation.

Before the Deadline: Your Practical Checklist

Whether 2 August 2026 holds or the Digital Omnibus pushes it to December 2027, the programme you need to build is the same. Here is what to have in place.

Build and document your post-market monitoring plan

Draft the plan now — don't wait for the Commission's implementing-act template. Include: monitoring objectives, data collection methods (automated telemetry, deployer feedback channels, user complaints), analysis procedures, performance thresholds, review cadence, and the roles responsible. Embed the plan in your Annex IV technical documentation. When the official template arrives, map your existing document to it.

Define your deployer data-collection channel

Article 26 requires deployers to monitor and report to you. Make this concrete: add a contractual obligation in your deployer agreements, provide a structured reporting form or API endpoint, and set a response SLA. Deployer-reported anomalies are often your earliest signal of a developing serious incident.

Set internal thresholds and triggers

Translate the legal definition of 'serious incident' into operational criteria your engineering and support teams can apply without a lawyer in the room. Define what constitutes a 'significant drop in accuracy,' 'unexpected behaviour,' or 'system failure' for your specific system. Document the criteria in writing — regulators will ask.

Build your incident-response runbook

The runbook must cover: (1) how to log and triage an event; (2) how to assess causal link to the AI system; (3) which deadline tier applies (2 / 10 / 15 days); (4) who drafts and approves the notification; (5) which market surveillance authority to contact in each member state where you operate; (6) the evidence-preservation rule — no changes to the AI system that could affect cause evaluation without first informing authorities; and (7) the process for filing an initial incomplete report followed by a complete one.

Map overlaps with other reporting regimes

Identify where Article 73 intersects with GDPR Article 33 (personal data breach, 72-hour clock), NIS-2 (24-hour early warning, 72-hour incident report), DORA, CER, MDR/IVDR, and product-safety legislation. For each overlap, decide whether the simplified Article 73 regime (fundamental-rights only) applies, and document your reasoning. The Commission's draft reporting template includes a field for referencing parallel sectoral reports — use it.

Assign clear internal roles

Name an Article 73 Reporting Owner (typically the CISO, DPO, or AI Compliance Lead), a Legal Reviewer, and a Technical Investigator. Ensure each knows their responsibilities before an incident occurs. Run a tabletop exercise against a realistic scenario — for example, a credit-scoring system producing systematically biased outputs at scale.

How Articles 72 and 73 Fit the Bigger Picture

Post-market monitoring and incident reporting don't exist in isolation. They are the operational tail of a compliance programme that starts much earlier:

Classification - You need to know your system is high-risk before any of this applies. See our high-risk classification guide if you haven't confirmed your status.
Roles - Whether you are a provider, deployer, or both determines which obligations land on you. The provider and deployer roles guide maps this in detail.
Penalties - The €15 million / 3% turnover tier for breaching Articles 72 and 73 is the mid-tier of the AI Act's penalty structure. The Article 99 fines guide explains how enforcement works and what mitigating factors regulators must consider.

Article 72's monitoring plan is also the early-warning system that feeds Article 73. If your monitoring is weak, you may not detect a serious incident in time to meet the 2- or 10-day reporting clocks. The two articles are designed to work together.

help_outlineDoes Article 72 apply to AI systems already on the market before 2 August 2026?expand_more

Yes, with a transitional nuance. Systems already placed on the market or put into service before the applicable date must comply with the AI Act's requirements — including post-market monitoring — from the date those requirements become applicable. If your system is already deployed, you need a monitoring plan in place by the deadline, not just for new deployments.

help_outlineWho do I report a serious incident to if the incident occurred in multiple member states?expand_more

Article 73 requires you to report to the market surveillance authority of the member state where the incident occurred. If an incident spans multiple member states, you may need to notify multiple authorities. The Commission's draft guidance includes a field in the reporting template for cross-border incidents. Map your authority contacts for each member state where your system is deployed before an incident happens.

help_outlineCan a deployer trigger the Article 73 reporting obligation?expand_more

Primarily, the reporting duty falls on the provider. However, deployers have an active role: they must promptly inform the provider when they identify a serious incident. Where the provider cannot be reached, deployers are expected to cooperate directly with the market surveillance authority. Build this escalation path into your deployer agreements.

help_outlineWhat if the Commission's implementing-act template for the monitoring plan hasn't been published by 2 August 2026?expand_more

You are still required to have a post-market monitoring plan in place. The implementing act provides a standardised template, but the obligation to monitor exists independently of it. Draft your plan against the Article 72 requirements now. When the template is published, review and align your existing document — you should not need to start from scratch.

help_outlineDoes the Digital Omnibus change the Article 73 reporting deadlines (2 / 10 / 15 days)?expand_more

No. The provisional Digital Omnibus deal would defer the applicability date for Annex III high-risk obligations — potentially to 2 December 2027 — but it does not change the substance of Articles 72 or 73. The 2 / 10 / 15-day reporting clocks remain unchanged once the obligations apply.

help_outlineIs an 'indirect' causal link really enough to trigger reporting?expand_more

According to the Commission's September 2025 draft guidance, yes. The guidance explicitly states that an indirect causal link between the AI system and the harm is sufficient. The examples given include an incorrect AI medical analysis that causes harm only after a clinician acts on it, and a flawed AI credit assessment that leads to downstream financial harm. This is a broad interpretation — build your incident triage criteria accordingly.

This guide is for informational purposes only and does not constitute legal advice. The EU AI Act is a complex regulation and its application to your specific circumstances will depend on facts that only your legal advisers can assess. The Digital Omnibus provisional agreement referenced above has not been formally adopted as of the date of publication; treat 2 August 2026 as your compliance planning anchor until the position changes.