EU AI Act Serious Incident Report Filing Guide

Under the EU AI Act, a serious incident is a malfunction or incident that leads to death or serious health damage, critical infrastructure disruption, fundamental rights infringement, or serious property or environmental damage (Article 3(49)). Providers of high-risk AI systems must report serious incidents to the market surveillance authority of the Member State where the incident occurred, within 2, 10, or 15 days depending on the harm category (Article 73). Deployers carry parallel notification duties under Article 26. A compliant filing process requires severity triage mapped to the four harm categories, a documented escalation path, and technical evidence drawn from Article 12 logging and Article 72 post-market monitoring.

Key Filing Facts

Four structural points shape every serious incident filing under the Act.

Four harm categories

Article 3(49) defines a serious incident across death or health harm, critical infrastructure disruption, fundamental rights infringement, and property or environmental damage.

Tiered deadlines

Article 73 sets 2, 10, or 15 day reporting windows depending on which harm category applies.

Provider and deployer duties

Articles 73 and 26 place parallel but distinct reporting obligations on providers and deployers.

Logging as evidence

Article 12 logging and Article 72 post-market monitoring generate the technical evidence used in filings.

Defining a Serious Incident Under Article 3(49)

Article 3(49) of Regulation (EU) 2024/1689 defines a serious incident narrowly, distinguishing it from routine malfunctions or performance degradation. An incident qualifies as serious only if it directly or indirectly leads to one of four outcomes: death or serious damage to a person's health; serious and irreversible disruption to the management or operation of critical infrastructure; infringement of obligations under Union law intended to protect fundamental rights; or serious damage to property or the environment.

This threshold has direct operational consequences. A model producing an incorrect output, an availability outage, or a measured drop in accuracy does not automatically meet the Article 3(49) bar unless that failure is causally connected to one of the four harm categories above. Governance teams need documented internal criteria that map detected anomalies to these categories, because the classification decision determines whether a report is required at all and, if so, which statutory deadline applies.

Article 73 Reporting Deadlines

Article 73 sets tiered timelines that start when the provider becomes aware of the incident. Map severity to the correct window before the clock runs out.

Scenario	Deadline context
Critical infrastructure disruption or widespread infringement	Applies where the incident falls under the critical infrastructure disruption category in Article 3(49)(b), or involves widespread infringement. The clock starts when the provider becomes aware of the incident.
Incidents involving death	Applies once a causal link, or a reasonably likely causal link, between the AI system and a death has been established. Reporting is triggered by identification of that link, not by the death itself.
General default deadline	Applies to all other serious incidents under Article 3(49) not covered by the shorter timelines. Article 73(2) frames this as reporting immediately, and in any case no later than 15 days after becoming aware.

In practice, organizations should plan operational capacity against the shortest applicable window (including the 2-day scenario) so escalation paths, evidence packs, and authority contacts are already decided when classification is confirmed.

Provider and Deployer Responsibilities

Article 73(1) places the primary reporting obligation on the provider of the high-risk AI system, who must notify the market surveillance authority of the Member State or States where the incident occurred. Article 73(3) then requires the provider to conduct an investigation, an associated risk assessment, and corrective action. Filing the report is the start of a documented remediation cycle, not a one-time notification.

Deployers carry a parallel but distinct obligation under Article 26. When a deployer identifies a serious incident during operation, it must inform the provider, importer, or distributor, as well as the relevant market surveillance authority. Enterprises that deploy third-party high-risk AI systems rather than building them need internal clarity on which duty applies to their role, since both provider and deployer obligations can be active at once depending on the contractual relationship.

Required Evidence for a Compliant Filing

The evidence required to support a filing is grounded in the Act's logging and monitoring provisions. Article 12 requires high-risk AI systems to be designed with logging capabilities enabling traceability of the system's functioning throughout its lifecycle. Article 72 requires providers to maintain a post-market monitoring system that actively and systematically collects and analyzes performance data.

Together these provisions mean a compliant filing should include:

Timestamped system logs that support reconstruction of events
A documented sequence from detection through internal escalation
For death-related incidents, correlation between the incident timeline and system or model version history to establish the causal link required under Article 73(2)(b)

Submission mechanics

Article 73(4)-(5) anticipate a common reporting form and, where appropriate, a centralized reporting mechanism. The exact mechanics were not finalized in the source text reviewed here, so teams should confirm current submission requirements with the relevant national authority before filing.

Internal Process for Detecting, Documenting, and Filing

A durable internal process ties detection signals to classification, authority notification, and remediation follow-through. Keep the path short enough to meet the tightest Article 73 window, and keep records strong enough to defend the “becoming aware” moment if an authority asks for it.

Incident Reporting Readiness Checklist

Use this checklist to confirm your organization can detect, classify, and file before the shortest statutory deadline applies.

Severity classification criteria explicitly mapped to the four Article 3(49) harm categories
Documented escalation path with named roles able to act within the 2-day deadline
Clear delineation of provider versus deployer notification duties for each deployed system
Pre-built internal report template aligned to anticipated Article 73(4)-(5) form fields
Logging and monitoring capability sufficient to timestamp the “becoming aware” moment
Periodic tabletop exercises testing the full detection-to-filing timeline against the 2-day scenario

Common Implementation Questions

How is the “becoming aware” moment determined for calculating the reporting deadline?

The Act does not provide a rigid formula. It depends on when the provider or deployer has sufficient information to recognize an event as a serious incident. Documented escalation records, including detection timestamps and the point severity classification was confirmed, are used to establish and defend this moment if an authority requests it.

Which market surveillance authority should we notify if an incident affects multiple Member States?

Article 73(1) directs reporting to the market surveillance authority of each Member State where the incident occurred. National procedural mechanics, including specific contact points and submission formats, vary by Member State and should be confirmed directly with each relevant authority.

What are our obligations if we deploy a third-party high-risk AI system rather than build it?

As a deployer, Article 26 requires monitoring the system's operation and, upon identifying a serious incident, notifying the provider, importer, or distributor along with the relevant market surveillance authority. The provider retains separate Article 73 duties, so coordination should be defined contractually in advance.