EU AI Act Incident Reporting: What Article 73 Requires When Something Goes Wrong
Article 73 of the EU AI Act imposes strict incident reporting obligations on providers of high-risk AI systems. Learn the legal definition of a "serious incident," who must notify whom, and within what deadlines — including the 2-calendar-day rule for life-threatening situations.
When a high-risk AI system malfunctions in the field, the EU AI Act does not give you time to deliberate. Article 73 establishes a precise, time-sensitive reporting regime. Providers who fail to comply face fines of up to €15 million or 3% of global turnover — whichever is higher. This article breaks down every obligation, deadline, and reporting element you need to have in place before something goes wrong.
What Is a "Serious Incident"? The Legal Definition
The starting point is Article 3(49) of the regulation, which defines a serious incident as:
"any incident or malfunction of an AI system that directly or indirectly leads to any of the following: (a) the death of a person or serious damage to a person's health; (b) a serious and irreversible disruption of the management or operation of critical infrastructure; (c) infringement of obligations under Union law intended to protect fundamental rights; (d) serious damage to property or the environment."
Three elements deserve close attention:
"Directly or indirectly" — The causal chain does not need to be immediate. If an AI system outputs a recommendation that a clinician follows, and that recommendation leads to patient harm, the incident qualifies even though a human decision was interposed.
"Serious damage to health" — The regulation does not define a severity threshold numerically. In practice, regulators and notified bodies treat any damage requiring hospitalization or causing permanent impairment as presumptively serious.
"Fundamental rights infringement" — This extends the definition well beyond physical harm. A biometric categorization system that systematically discriminates against a protected group can trigger Article 73 obligations, even without physical injury.
Serious Incident vs. Near-Miss
Article 73 covers serious incidents and malfunctions that could have led to a serious incident (near-misses) for AI systems intended for safety components. If your post-market monitoring plan (PMM, governed by Article 72) detects a near-miss, the obligation is to log it internally and assess whether it meets the threshold for external reporting. A near-miss that reveals a systemic defect in the AI model likely crosses that threshold; a one-off anomaly that was caught and corrected by human oversight may not.
Who Must Report — and to Whom
The reporting obligation under Article 73(1) falls on providers of high-risk AI systems placed on the Union market. Deployers are not primary reporting parties, but Article 73(6) requires them to inform the provider without delay when they become aware of a serious incident. The provider then triggers the official notification.
The authority to notify is the market surveillance authority (MSA) of the Member State where the incident occurred. If the incident affects users in multiple Member States, the provider notifies the MSA in each affected jurisdiction. The AI Office plays a coordinating role for GPAI models involved in serious incidents, but for high-risk AI under Annex III, the MSA is the primary counterpart.
The Deadlines — Strictly Enforced
Article 73(3) sets tiered deadlines:
| Situation | Deadline |
|---|---|
| Serious incident (standard) | 15 calendar days from awareness |
| Incident involving risk to life or irreversible health damage | 2 calendar days from awareness |
| Death confirmed after initial report | Immediately upon confirmation |
"Awareness" is the moment the provider's internal systems — including the PMM — detect or are informed of the incident. Providers cannot reset the clock by claiming they needed time to investigate before becoming "aware." If the PMM flags an anomaly and a subsequent review confirms it is serious, the 15-day period typically runs from the initial flag, not from the confirmation.
For the 2-day track, you need an escalation path that bypasses normal approval chains. This means a named individual with authority to file the report, 24/7 access to the MSA's notification portal, and a pre-filled template ready to go.
What the Report Must Contain
Article 73(3) and the Commission's draft implementing acts specify the following minimum content:
- Identity of the provider — legal name, registration number, contact details of the designated responsible person under Article 22 or Article 25.
- Description of the AI system — system name, version, registration number in the EU database (Article 71).
- Description of the incident — date, location, affected persons, nature of harm or risk.
- Causal analysis — preliminary assessment of the incident's root cause, even if incomplete at the time of filing.
- Corrective measures taken or planned — including whether the system has been withdrawn from deployment, usage restricted, or a software patch issued.
- Reference to the PMM — Article 72 requires providers to maintain a PMM proportionate to the risk level; the incident report should reference how the monitoring system detected (or failed to detect) the event.
- Third-party involvement — whether a notified body, deployer, or EU-authorized representative was involved.
- Follow-up plan — timeline for a complete root-cause analysis and final report.
The initial report can be preliminary. A complete follow-up report must be submitted when the investigation is concluded — typically within 30 days for standard incidents.
The Link to Post-Market Monitoring (Article 72)
Incident reporting and post-market monitoring are not parallel systems — they are integrated. Article 72 requires providers to collect, document, and analyze data from deployed systems on an ongoing basis. That monitoring infrastructure is what generates the alerts that trigger Article 73 reporting.
Practically, this means your PMM must include:
- Automated anomaly detection thresholds aligned with the serious incident definition
- A documented escalation procedure specifying who reviews alerts and within what timeframe
- Audit logs that capture when an anomaly was first flagged (critical for establishing the "awareness" clock)
- A feedback channel from deployers, since Article 73(6) obligates them to notify you
If your PMM is a spreadsheet updated quarterly, it is not fit for purpose. MSAs reviewing compliance post-incident will examine whether the monitoring infrastructure was adequate to detect the incident in a timely way.
Minimal Incident Report Template
The following structure satisfies the Article 73 content requirements for an initial notification:
SERIOUS INCIDENT NOTIFICATION — [PROVIDER NAME]
Date of notification: [DD/MM/YYYY]
Reference number: [internal tracking ID]
1. PROVIDER
Legal name, address, EU database registration number
2. AI SYSTEM
Name, version, intended purpose, Annex III category
3. INCIDENT DESCRIPTION
Date/time of occurrence:
Location (Member State, sector):
Nature of harm (death / health damage / fundamental rights / property):
Number of affected persons:
4. PRELIMINARY CAUSE
[Brief technical and operational assessment — "unknown" is acceptable at
initial stage but must be updated]
5. IMMEDIATE CORRECTIVE ACTIONS
System suspended: Yes / No
Usage restricted: Yes / No
Patch deployed: Yes / No / Planned [date]
6. PMM REFERENCE
How was the incident detected? [PMM alert / deployer notification / media / other]
Date of first detection signal: [DD/MM/YYYY]
7. FOLLOW-UP TIMELINE
Complete root-cause analysis expected: [date]
Final report submission expected: [date]
8. CONTACT PERSON
Name, title, phone, email (available 24/7 during investigation)
File this template in your quality management system (QMS) and test it in a tabletop exercise before deployment. The two-day deadline for life-risk incidents leaves no room for drafting under pressure.
Common Gaps in Incident Reporting Programs
No awareness protocol. Providers assume the incident will be obvious. In practice, serious incidents often emerge gradually — a pattern of anomalous outputs, a deployer complaint, a field report. Without a defined protocol specifying what triggers the awareness clock, providers systematically miss their deadlines.
Deployer contracts that omit Article 73(6). If your deployer agreement does not explicitly require them to notify you of serious incidents, you are relying on goodwill. Article 73(6) creates a legal obligation for deployers, but your contract should reinforce and specify it.
Reports that describe rather than analyze. MSAs expect a causal analysis, even preliminary. A report that merely describes what happened without any hypothesis about why will prompt follow-up requests and signal an immature QMS.
Conflating incident reporting with product liability. Incident reports filed with the MSA can be requested by plaintiffs in civil litigation. Legal counsel should be involved in drafting, but involvement must not delay filing.
DILAIG's compliance platform includes an incident detection checklist aligned with Article 73 and Article 72, deadline calculators, and a pre-filled notification template validated against the Commission's draft implementing acts. Run your incident readiness audit at dilaig.com.