Serious Incident Under the EU AI Act: Definition and Reporting Obligations

A "serious incident" is a defined term in Regulation (EU) 2024/1689 (the EU AI Act). It covers any incident or malfunctioning of an AI system that leads — directly or indirectly — to death, severe harm to health, irreversible disruption of critical infrastructure, a breach of fundamental-rights obligations under Union law, or serious harm to property or the environment. Providers of high-risk AI systems must report such incidents to national authorities under Article 73.

The EU AI Act definition

Article 3 of Regulation (EU) 2024/1689 contains all the Act's core definitions; the definition of "serious incident" appears at point 49.

A serious incident is an incident or malfunctioning of an AI system that, directly or indirectly, leads to any one of the following:

(a) Death or serious harm to a person's health. The harm can be physical or psychological; "serious" has its ordinary meaning — not a minor adverse effect, but harm of a kind that warrants medical intervention or has lasting consequences.

(b) A serious and irreversible disruption of the management or operation of critical infrastructure. Critical infrastructure includes digital networks, energy grids, water-supply systems, transport infrastructure, and financial systems. The disruption must be both serious in scale and irreversible, or at least practically difficult to reverse quickly.

(c) An infringement of obligations under Union law intended to protect fundamental rights. This limb ties the incident concept directly to the EU Charter of Fundamental Rights and sector-specific instruments — for instance, anti-discrimination law, data-protection rules under the GDPR, or the rights of migrants and asylum seekers. An AI system output that causes or materially contributes to a fundamental-rights violation can constitute a serious incident even if no physical harm occurs.

(d) Serious harm to property or the environment. Material damage of sufficient gravity — destroyed equipment, large-scale data loss with financial consequences, or environmental contamination traceable to an AI malfunction — falls here.

The four limbs are alternatives: satisfying any one triggers the definition. There is no requirement that multiple limbs be met simultaneously.

The reporting duty (Article 73)

Article 73 of Regulation (EU) 2024/1689 lays down the post-incident reporting obligation. The duty sits within the post-market phase and is a provider obligation — it runs from the provider to the market surveillance authority of the Member State in which the incident occurred.

Who reports. Providers of high-risk AI systems are the primary reporting party. Where a deployer becomes aware of a serious incident, it must notify the provider (and may notify the authority directly) under Article 26 — but the formal Article 73 report to the authority belongs to the provider. If the deployer has assumed provider responsibilities under Article 25 (for example, by substantially modifying the system or placing it on the market under its own name), the Article 73 duty transfers to it accordingly.

To whom. The report goes to the market surveillance authority of the Member State where the incident took place — not to a central EU body. Where the incident spans several Member States, the authority of the state where the most significant impact occurred is the addressee; national authorities then cooperate.

The default deadline: 15 days. Under Article 73(2), the provider must report without undue delay — and no later than 15 days after it becomes aware of the incident and establishes a causal link (or a reasonable likelihood of one) between the AI system and the adverse outcome. The 15-day window is the baseline.

Shortened deadline: 10 days for a death. Where the incident results in the death of a person, Article 73(4) cuts the window to no later than 10 days after the provider becomes aware.

Shortened deadline: 2 days for critical infrastructure or widespread infringement. Article 73(3) imposes the sharpest timeline: no later than 2 days where the incident constitutes a widespread infringement — meaning it affects a large number of people across Member States — or a serious and irreversible disruption of critical infrastructure. These are the scenarios with the broadest social impact, and the 2-day window reflects that urgency.

Incomplete initial report. Article 73 explicitly permits an initial report that is incomplete if the provider does not yet have all required information. The provider then files a complete report as soon as the missing information is available. This is not a loophole — the initial report still needs to be submitted within the applicable deadline, and the completeness follow-up is expected promptly.

In summary: the timeline the provider must apply depends on the type of harm. For a death, the window is 10 days. For critical infrastructure disruption or a widespread infringement, it is 2 days. For all other serious incidents, it is 15 days.

Examples

The four statutory limbs each cover distinct real-world scenarios.

Health harm (limb a). A risk-scoring AI deployed by a hospital to triage emergency patients malfunctions and consistently assigns lower priority scores to patients presenting with atypical symptom patterns. A patient who should have received immediate intervention is delayed; the delay contributes to a cardiac event. Even if the connection is indirect — the AI's output influenced a clinician's decision — the health harm originating in the malfunction can qualify as a serious incident.

Critical infrastructure (limb b). An AI system managing load balancing for a regional electricity grid produces erroneous forecasts after a data pipeline failure. The errors cause an unplanned cascade shutdown affecting several provinces for 36 hours. Restoring normal operations requires hardware inspection and re-synchronisation that takes days. The disruption is both serious and practically irreversible within the short term — it meets limb (b).

Fundamental rights (limb c). A high-risk AI system used in asylum-application processing wrongly classifies a cohort of applicants as low-credibility, leading to a series of rejections. An audit later finds the model applied a proxy variable that disproportionately penalised applicants from a particular country of origin. The systematic misclassification constitutes an infringement of EU anti-discrimination obligations and the right to an effective remedy — a fundamental-rights breach under limb (c), even if no immediate physical harm occurred.

Property and environment (limb d). An AI-controlled quality-assurance system in a chemical processing facility fails to detect a batch contamination event, allowing a faulty production run to proceed. The contamination destroys a significant volume of product and equipment, and a small quantity of toxic effluent reaches a nearby waterway before the problem is identified. The combination of property loss and environmental harm qualifies under limb (d).

How it connects to post-market monitoring

Serious incident reporting under Article 73 does not stand alone — it is the reactive face of an ongoing obligation. Article 72 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to establish and operate a post-market monitoring system throughout the lifetime of the system. That system must actively collect and analyse data on the performance of the AI in deployment: error rates, near-misses, unexpected outputs, and user feedback.

Post-market monitoring under Article 72 is the mechanism through which a provider is most likely to detect that something has gone wrong before it escalates into a reportable event — or to establish, after the fact, the causal link that triggers the Article 73 clock. If a provider has no structured monitoring in place, it will struggle to demonstrate when it "became aware" of an incident, and it may find itself unable to file within the applicable deadline.

Documentation is integral to both obligations. A provider that cannot produce records of its monitoring activities, anomaly logs, and the chain of events leading to the incident will face difficulties satisfying the market surveillance authority. The technical documentation required under Article 11 and Annex IV should include the monitoring architecture; the Article 17 quality management system should map the internal escalation path from anomaly detection to incident reporting.

Confir's AIGM compliance area (Governance & Post-Market Monitoring) covers Articles 9, 72, and 73. The module generates rule-based record templates for post-market monitoring activities and maps the Article 73 reporting timelines against each system's risk profile, so the correct deadline — 2 days, 10 days, or 15 days — is flagged deterministically rather than left to manual recall under pressure.

Frequently Asked Questions

Does the 15-day deadline run from the incident itself or from when the provider learns of it?

It runs from awareness — specifically, from the point at which the provider becomes aware of the incident and establishes a causal link (or a reasonable likelihood of one) between the AI system and the harm. If the provider only learns of the incident weeks after it occurred, the 15-day clock starts at that point. This does not excuse slow internal reporting chains, however: a provider is expected to have post-market monitoring under Article 72 in place precisely so that significant events are surfaced quickly.

Does a deployer have to report directly to the market surveillance authority?

The Article 73 duty to report to the authority falls on the provider. A deployer's obligation under Article 26 is to notify the provider and to cooperate with the investigation. Where a deployer has taken on provider responsibilities under Article 25 — for example, by placing a system on the market under its own brand — the Article 73 duty follows that status shift. In practice, a deployer that witnesses a serious incident should treat internal escalation to the provider as time-sensitive.

What is a "widespread infringement" that triggers the 2-day deadline?

The Act does not define "widespread infringement" with a numerical threshold. The concept points to incidents that affect a large number of people simultaneously across Member States — for example, a defective update to a widely deployed high-risk AI system that causes systematic errors in decisions affecting thousands of individuals across several EU countries. The 2-day window also applies, separately, to serious and irreversible disruptions of critical infrastructure.

Can a provider submit an incomplete first report?

Yes. Article 73 explicitly anticipates situations where not all information is available within the reporting window. An initial incomplete report preserves compliance with the deadline; the provider must then follow up with a complete report as the investigation progresses. The initial report should include what is known — the nature of the incident, the AI system involved, the harm identified, and the steps taken so far — and should state what information is still being gathered.

Is a near-miss a serious incident under Article 73?

No. Article 3(49) requires that the incident "leads to" one of the four categories of harm, directly or indirectly. A near-miss — where the malfunction was detected and corrected before any harm materialised — does not satisfy that threshold. However, near-misses are precisely the events that a well-functioning post-market monitoring system under Article 72 should capture, because they signal risks that could escalate to a reportable event if not addressed.

Does Article 73 apply to GPAI model providers?

Article 73 targets providers of high-risk AI systems. GPAI model providers have a separate incident-reporting obligation under Article 55, which applies to providers of systemic-risk GPAI models. The two obligations are distinct. A company that both provides a GPAI model with systemic risk and deploys it in a high-risk application may face obligations under both articles; the applicable authority and the precise reporting mechanics differ.

Related terms

• Incident reporting obligations under the EU AI Act
• Article 73 — serious incident reporting: full guide
• Post-market monitoring (Article 72)
• Article 72 — post-market monitoring by providers
• Notified body
• Substantial modification