Research Home Topics EU AI Act Countries Sources Calendar Methodology Authors

Reporting Serious Incidents Under the EU AI Act

When a high-risk AI system is involved in a serious incident, providers must report to market surveillance authorities in the Member State where the incident occurred. Three timelines apply depending on severity. Providers must also investigate, conduct a risk assessment, and take corrective action without delay. Article 73 carries no Digital Omnibus disclaimer — confirmed clean.

Key context
"A serious incident is not defined by severity of harm alone. An AI system that malfunctions in ways that create a reasonably foreseeable risk of harm — even where harm has not yet occurred — triggers reporting obligations."
EU AI Act, Article 73
The reporting clock starts when the provider or deployer becomes aware of the incident — not when an investigation concludes. Timeliness is the primary compliance variable.

Builds on AR-000240 (Provider Obligations) and AR-000370 (Post-Market Monitoring) — none of their content is re-derived here. Article 73 is the reporting obligation that activates when post-market monitoring or deployer feedback identifies a serious incident as defined in Article 3(49) (AR-000340).

Executive summary

The three reporting timelines

15 days
General serious incident
After the provider or deployer becomes aware. Clock starts at awareness, not causal confirmation. Severity may allow a shorter period.
2 days
Widespread infringement or critical infrastructure disruption
Article 3(49)(b) incident: serious and irreversible disruption of critical infrastructure management/operation. Or a widespread infringement.
10 days
Death
After awareness. Report immediately upon suspecting a causal relationship between the AI system and the death — not after confirming it.

What this means

Who this applies to

Regulatory context

The investigation obligation after reporting

The narrowed reporting scope for certain system categories

Commission guidance

Requirements

What organizations must do

  • Build an internal serious-incident triage process that can assess Article 3(49) classification and determine the applicable timeline within hours of becoming aware of an incident — the 2-day timeline for critical infrastructure and widespread infringement incidents leaves little room for deliberation.
  • Report immediately on the applicable timeline even if the investigation is incomplete — Article 73(5) allows an initial incomplete report followed by a full report.
  • After reporting, begin investigation, risk assessment, and corrective action without delay — and notify competent authorities before making any system changes that could affect the investigation.
  • Establish a deployer feedback channel that surfaces serious incidents to the provider quickly — the reporting clock can start at deployer awareness, so deployer-to-provider notification speed affects provider compliance.
  • For medical device / IVD AI systems and systems with equivalent sectoral reporting: confirm which Article 3(49) categories still require Article 73 reporting (only (c)) and confirm the correct national authority to report to.

Common mistakes

Waiting for investigation results before reporting is a common mistake — the reporting obligation activates at reasonable likelihood of a causal link, not at confirmed causation, and Article 73(5) explicitly accommodates incomplete initial reports.

Applying the 15-day timeline to all incidents is a second mistake — critical infrastructure disruption and widespread infringement incidents have a 2-day timeline; deaths have a 10-day timeline with an immediate reporting obligation on suspicion.

Applying corrective patches or system changes before notifying competent authorities is a third mistake — Article 73(6) prohibits changes affecting investigation evaluation without prior notification, even when Article 20 requires corrective action.

Treating deployer incident reports as the sole input to the Article 73 awareness clock is a fourth mistake — providers should also have independent monitoring through the Article 72 post-market monitoring system, which may identify serious incidents before deployers report them.

Open questions

  • Whether the Commission issued the Article 73(7) compliance guidance by the 2 August 2025 deadline — not confirmed against a primary source on this research pass.
  • How “widespread infringement” under Article 3(61) is assessed in practice for the 2-day timeline — Article 3(61) provides the definition (harm to collective interests in at least two Member States, or same conduct by same operator in at least three Member States), but the evidentiary standard for triggering the accelerated timeline is not elaborated in Article 73.
  • Whether Article 73 has been amended by the Digital Omnibus — no disclaimer found on the Service Desk as of this verification pass; treated as clean pre-amendment text, not as confirmed unamended.

Frequently asked

FAQ
When does the reporting clock start — when the provider is aware, or when the deployer is aware?
Article 73(2) references “the provider or, where applicable, the deployer.” If the deployer becomes aware before the provider, the deployer’s awareness date starts the clock for the provider’s reporting obligation. This is why Article 26(6) deployer-to-provider notification speed matters for provider compliance.
FAQ
Can a provider apply a software fix to stop an AI system causing further harm before reporting to authorities?
Article 73(6) prohibits any investigation-affecting system alteration without first informing competent authorities. A corrective fix that changes system behaviour in ways that prevent root-cause determination must be preceded by notification. Providers should contact the market surveillance authority before applying such fixes, not after.
FAQ
Does Article 73 apply to open-source AI systems?
Open-source AI systems are out of scope under Article 2(12) unless they are high-risk, prohibited, or subject to Article 50 transparency obligations. A high-risk open-source AI system falls within Article 73’s scope; a non-high-risk open-source system does not.

Go deeper

Apply this in practice

AGNUS Academy turns AI governance research into hands-on skills — exercises, case studies, and frameworks built on the research you just read.

Explore the Academy →