EU AI Act Article 73: Serious Incident Reporting for High-Risk AI Providers
EU AI Act Article 73: high-risk AI providers must report serious incidents within 15 days (general), 10 days (death), or 2 days (critical disruption).
If your high-risk AI system causes — or contributes to — a death, you have ten days to tell the market surveillance authority. Two days if it triggers widespread disruption to critical infrastructure or a serious and irreversible breakdown. Fifteen days for everything else that meets the serious-incident threshold. Those clocks start from the moment you establish a causal link, not from when the harm happened and not from when the investigation concludes.
Article 73 of Regulation (EU) 2024/1689 is the reactive arm of the EU AI Act's post-market regime. Article 72 requires providers to collect performance data continuously; Article 73 requires them to report when that monitoring — or any other channel — reveals a serious incident. This guide sets out who must report, what qualifies as a serious incident, what the timelines mean in practice, and how providers and deployers divide the responsibility.
What Counts as a Serious Incident
The Act defines "serious incident" in Article 3(49). An incident qualifies if it directly or indirectly leads to any of the following:
- the death of a person, or serious harm to a person's health;
- a serious and irreversible disruption of critical infrastructure;
- an infringement of obligations under Union law designed to protect fundamental rights; or
- serious damage to property or the environment.
Two things are worth unpacking. First, the definition covers indirect causation — an AI system that produces a flawed output which a clinician acts on, leading to patient harm, is in scope even if a human stood in the causal chain. Second, the threshold is "serious" harm, not merely negative output. A recruitment AI that produces a suboptimal ranking is not a serious incident. The same system that systematically excludes applicants from protected groups in a way that infringes EU non-discrimination law is.
The definition does not cover every malfunction in a high-risk AI system — only malfunctions whose consequences reach this severity. Providers should document their assessment of why an event did or did not meet the Art 3(49) threshold, because that reasoning will be scrutinised if the authority later disagrees.
The Three Reporting Timelines Under Article 73
Article 73 sets differentiated deadlines based on severity. All run from the moment the provider establishes a causal link — or a reasonable likelihood of one — between the AI system and the incident. An incomplete initial report is explicitly permitted; the provider then completes it once further information is available (Art 73(5)).
| Trigger | Deadline |
|---|---|
| General serious incident (Art 73(2)) | No later than 15 days after becoming aware |
| Widespread infringement of fundamental rights, or serious-and-irreversible critical-infrastructure disruption (Art 73(3)) | No later than 2 days after becoming aware |
| A person has died (Art 73(4)) | No later than 10 days after becoming aware |
| Incomplete initial report (Art 73(5)) | Submit what you have within the applicable window; complete it promptly |
"Becoming aware" is the trigger, not the incident date. The moment a provider's internal monitoring, a deployer notification, or any other source puts the provider on notice that an incident meeting Art 3(49) may have occurred, the clock starts. Waiting for a completed root-cause analysis before filing does not extend the window.
Who Must Report — and Who Does Not
Article 73 is a provider obligation. Only the entity that placed the high-risk AI system on the market or put it into service under its own name bears the duty to notify market surveillance authorities. Importers and distributors do not report under Art 73; they pass incident information up the chain to the provider.
Deployers sit in a distinct position. Under Article 26, a deployer that identifies what it believes is a serious incident must inform the provider first. The deployer should also notify the importer or distributor where the provider is outside the EU. Where the deployer has reason to believe the provider has not filed with the authority — or where circumstances demand it — the deployer may also contact the market surveillance authority directly. But the primary reporting duty, with its hard timelines, sits with the provider.
This matters practically. A 20-person company using a third-party recruitment AI does not file an Art 73 report when a bias event is discovered — it notifies the AI system's provider immediately and documents that notification. The provider then owns the regulatory clock. If the provider is outside the EU, the EU-based importer or authorised representative under Art 22 steps into that role.
Where to Report
The report goes to the market surveillance authority of the member state where the incident occurred — not necessarily where the provider is established. If a bias event in a German hiring process harms applicants in Germany, the provider reports to the German authority. Multi-state incidents may require parallel notifications; providers should maintain a jurisdiction matrix rather than discovering this under pressure.
What the Report Must Contain
The Act does not prescribe a standardised form at EU level; member states are still finalising reporting portals as of mid-2026. Whatever the channel, the substance the authority needs is consistent:
- Identification of the AI system (name, version, intended purpose, Annex III category).
- Description of what happened, when, where, and who was affected.
- The nature of the harm caused or the harm risked, cross-referenced to the Art 3(49) categories.
- Actions already taken or planned — containment, user notification, corrective steps.
- A preliminary causal assessment, even if incomplete. The authority needs enough to triage, not a finished investigation.
- Contact details for the responsible person at the provider.
An incomplete preliminary report filed on time is better than a complete report filed late. Art 73(5) explicitly permits the initial notification to be followed by supplementary information. The constraint is not completeness — it is timeliness.
One practical constraint: the regulation prohibits providers from altering the AI system in ways that would affect a subsequent evaluation by authorities before they have informed the authority of the incident. If a corrective update is urgent for safety, notify first, then deploy the fix, and document the sequence.
The Provider's Obligations Around an Incident
Reporting is not the only duty that activates. Once a serious incident is established, the provider should:
Investigate and conduct a risk assessment. Determine the technical or operational cause. Assess whether the same failure mode could affect other deployments of the same system — including in other member states or sectors. This feeds both the supplementary report and the Art 72 post-market monitoring record.
Take corrective action. The Act expects providers to act, not merely document. Corrective action may mean halting deployment, issuing an updated model, revising the instructions for use, or strengthening the human oversight layer required under Art 14.
Cooperate with the authority. Provide additional information as requested. Do not amend the system in ways that could obscure what happened before the authority has assessed it.
Update technical documentation. Changes made in response to an incident must be reflected in the Art 11 / Annex IV technical file. If the changes are substantial enough to constitute a substantial modification under Art 3(23), the conformity assessment under Art 43 restarts.
How This Fits the Broader Post-Market Framework
Article 72 and Article 73 are two sides of the same obligation. Article 72 requires providers to proactively collect and review data throughout an AI system's operational life — performance metrics, deployer feedback, user reports. Article 73 is what happens when that monitoring (or any other source) reveals something serious enough to require authority notification.
The risk management system under Article 9 should be designed so that serious incidents are caught before they happen — through ongoing hazard identification, testing, and mitigation. An Art 73 report is in some sense an Article 9 failure reaching the surface. Authorities will examine whether the provider's RMS should have identified and controlled the risk that eventually materialised.
Relationship to Other Reporting Regimes
Many high-risk AI deployments sit inside regulated sectors with their own incident-reporting requirements. The Act encourages coordination rather than duplication.
GDPR personal data breaches must be reported to the supervisory authority within 72 hours of awareness (GDPR Art 33). If a serious AI incident also involves a personal data breach, both reports are required — but providers and deployers should coordinate them so the facts are consistent and the authority is not receiving contradictory accounts.
NIS2 significant incidents affecting essential entities must be reported within 24 hours (early warning) then 72 hours (incident notification) under NIS2 Art 23. If an AI-related disruption to critical infrastructure also triggers NIS2, file both. Where member states allow consolidated reporting, use it.
Medical device vigilance under MDR 2017/745 / IVDR 2017/746 has its own serious-incident timelines (generally 15 days, 2 days for death or serious deterioration in public health). A medical-imaging AI embedded as a safety component of a regulated device operates under both regimes. The MDR/IVDR report and the Art 73 report serve different authorities; they may need to be filed in parallel.
The general principle: report once where the regimes allow coordination; when they don't, file all required notifications and be transparent with each authority that parallel reporting is happening.
GPAI Systemic-Risk Incident Reporting
Providers of general-purpose AI models with systemic risk have a separate incident-reporting obligation under Article 55. That obligation runs to the AI Office, not to a member-state market surveillance authority. The Art 73 and Art 55 regimes are distinct: Art 73 applies to the provider of a high-risk AI system when that system causes a serious incident; Art 55 applies to GPAI model providers when the model itself is involved in a systemic-risk incident. A company that both provides a GPAI model and builds high-risk applications on top of it may owe both reports in the same event.
Penalties
Non-compliance with Art 73 attracts the €15,000,000 or 3% of total worldwide annual turnover tier under Article 99(4) — whichever is higher. For companies with limited turnover, the fixed cap of €15M applies; for large multinationals, the 3% figure will typically be larger.
Providing incorrect, incomplete, or misleading information to the market surveillance authority in connection with an Art 73 report is a separate violation under Article 99(5): up to €7,500,000 or 1% of worldwide turnover. Filing a preliminary report in good faith that is later corrected is not misinformation — but a knowingly incomplete submission designed to conceal facts is.
For companies that qualify as SMEs or start-ups under Art 99(6), the fine is capped at the lower of the percentage or the fixed amount — a meaningful protection. However, this cap applies to the fine, not to the obligation to report. The timelines are the same regardless of company size.
How Confir Supports Incident Reporting
Confir's AIGM (Governance & Post-Market Monitoring) assessment area covers Articles 9, 72, and 73. The AIGM controls include a structured incident log that captures the date of awareness, the applicable timeline, the Art 3(49) harm category, draft report contents, and submission confirmation. Because the logic is rule-based and deterministic — same intake produces the same finding — the scoping decision (does this event meet the Art 73 threshold?) is reproducible and audit-defensible.
The immutable audit log records every entry and amendment, which is what an authority examining your incident-handling history will ask to see. Providers can generate an incident summary aligned with the mandatory report contents without the compliance team rebuilding the information from scratch under a 10-day or 2-day deadline.
Frequently Asked Questions
What exactly is the definition of a "serious incident" under Article 73?
"Serious incident" is defined in Article 3(49) of Regulation (EU) 2024/1689. An incident qualifies if it directly or indirectly causes death, serious harm to a person's health, a serious and irreversible disruption of critical infrastructure, an infringement of EU law protecting fundamental rights, or serious damage to property or the environment. The definition covers indirect causation, so an AI output that a clinician acts on — causing patient harm — is in scope even though a human decision stood between the output and the harm.
What are the exact reporting timelines under Article 73?
Three timelines apply, all measured from when the provider becomes aware (or establishes reasonable likelihood of a causal link): no later than 15 days for a general serious incident (Art 73(2)); no later than 2 days where the incident constitutes a widespread infringement of fundamental rights or a serious-and-irreversible disruption of critical infrastructure (Art 73(3)); no later than 10 days where a person has died (Art 73(4)). An incomplete preliminary report may be filed on time and completed later under Art 73(5).
Does Article 73 apply to deployers?
No. Article 73 is a provider obligation. A deployer that identifies a serious incident must notify the provider — and where appropriate, the importer, distributor, and market surveillance authority — under Article 26. But the hard-deadline regulatory report belongs to the provider. The deployer's duty is to flag the incident promptly so the provider's clock does not run down undetected.
Which market surveillance authority do we report to?
The authority of the member state where the incident occurred — not necessarily where the provider is established. If an incident affects users in multiple member states, parallel notifications to each relevant authority may be required. Providers operating across the EU should map the national competent authorities before an incident happens; the relevant designations are made under Article 70.
Can we file a preliminary report and supplement it later?
Yes. Article 73(5) explicitly permits this. File what you have within the applicable window — incident date, system identification, preliminary harm description, and any corrective steps already taken. Follow up with the full investigation findings as soon as they are available. Do not treat the preliminary-report permission as licence to delay meaningful disclosure; the initial submission must be substantive enough for the authority to triage.
How does Art 73 interact with GDPR breach reporting and NIS2?
The obligations run in parallel — not in place of one another. A GDPR personal data breach requires a supervisory authority notification within 72 hours under GDPR Art 33. A NIS2 significant incident requires an early warning within 24 hours and a full notification within 72 hours. Where a single event triggers all three regimes, file all three reports and note in each that parallel reporting is occurring. Where member states offer coordinated reporting channels, use them to avoid contradictory filings.
What are the penalties for missing the reporting window?
Non-compliance with Art 73 falls under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. Knowingly supplying incorrect or misleading information to the authority is a separate offence under Art 99(5): up to €7,500,000 or 1% of turnover. For SMEs and start-ups, Art 99(6) caps the fine at the lower of the percentage or the fixed amount — but the reporting obligation and its timelines are unchanged.
Related guides
- provider obligations checklist
- implementation roadmap for 2026
- critical infrastructure safety requirements
- EU AI Act compliance checklist
- startup compliance guide
- risk classification decision tree
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →