AI Incident Reporting Guide: EU AI Act Serious Incidents and OECD AIM

The EU AI Act makes reporting serious AI incidents a legal duty, with deadlines as short as two days, yet most incident response plans have no category for an AI system that harms someone without being hacked. Article 73 covers providers of high-risk AI systems, Article 26 pulls deployers into the chain, and Article 55 adds reporting for general-purpose AI models with systemic risk. Alongside the law, the OECD AI Incidents and Hazards Monitor (AIM) and its common reporting framework are shaping how incidents are described across countries. This guide explains who must report what, to whom and when, how AI reporting overlaps with GDPR, NIS2 and sector rules, and how to build the detection and evidence that make reporting possible. It is for incident responders, AI product owners and compliance leads.

Key takeaways

• A serious incident does not need an attacker. Article 3(49) covers any incident or malfunction of an AI system that directly or indirectly leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, or serious harm to property or the environment.
• The clock runs from awareness. Providers must report immediately once a causal link or its reasonable likelihood is established, and no later than 15 days after becoming aware, 10 days in the case of death and 2 days for widespread infringements or critical infrastructure disruption.
• Deployers have a duty too. Under Article 26(5) a deployer that identifies a serious incident must inform the provider first, then the importer or distributor and the authorities.
• Do not change the system before you tell the regulator. Article 73(6) bars alterations that could affect evaluation of the causes before the authorities are informed, so evidence preservation is a legal requirement.
• Timelines have moved. The Digital Omnibus on AI moved Annex III high-risk obligations to 2 December 2027 and Annex I product-embedded systems to 2 August 2028, and the Commission's serious incident guidance was still a draft when checked.

Scope: who and what is covered

What counts as serious: the four limbs of Article 3(49) differ. Death is unqualified, harm to health must be serious, infrastructure disruption must be serious and irreversible (critical infrastructure as defined by Directive (EU) 2022/2557), and the fundamental rights limb is triggered by infringement of Union law intended to protect those rights. The words "serious" and "irreversible" are not defined in the Act, which is one reason the Commission's guidance matters.

Widespread infringement: Article 3(61) defines it as harm, or likely harm, to the collective interests of people in at least two Member States other than the reference state, or concurrent infringements with common features by the same operator in at least three Member States. Widespread infringements carry the two-day deadline.

OECD terms: the OECD defines an AI incident as an event where the development, use or malfunction of AI systems directly or indirectly leads to harm (injury to health, disruption of critical infrastructure, violation of human rights or of law protecting fundamental, labour or intellectual property rights, or harm to property, communities or the environment), and an AI hazard as an event that could plausibly lead to such an incident. The two vocabularies are close by design, so internal classification can map to both.

Key obligations

Article 73 reporting deadlines

After the report

• Investigate: the provider must promptly investigate, including a risk assessment and corrective action, and cooperate with authorities and, where relevant, notified bodies (Art. 73(6)).
• Preserve: the provider must not alter the AI system in a way that could affect later evaluation of the causes before informing the authorities (Art. 73(6)).
• Authority action: the market surveillance authority must take appropriate measures within seven days of receiving the notification (Art. 73(8)), informs national fundamental rights bodies for Art. 3(49)(c) incidents (Art. 73(7)), and national authorities notify the Commission (Art. 73(11)).
• Logs: deployers must keep automatically generated logs under their control for at least six months unless other law sets a different period (Art. 26(6)). These logs are often the only evidence of what the system did.

General-purpose AI models with systemic risk

Article 55(1)(c) requires these providers to track, document and report serious incidents and possible corrective measures to the AI Office without undue delay. Article 55(2) lets them rely on the General-Purpose AI Code of Practice to show compliance until a harmonised standard exists. Commitment 9 of its Safety and Security chapter covers serious incident reporting across the model lifecycle and states that reporting is not an admission of wrongdoing. See the EU General-Purpose AI (GPAI) Code of Practice Guide.

How AI incident reporting overlaps with other regimes

One event can trigger several reports with different clocks, recipients and thresholds. Plan for all of them in one triage step.

An agent that leaks customer records is likely a GDPR breach before anyone has decided whether it is an AI Act serious incident. See the Data Breach Notification Checklist, the NIS2 Directive Guide and the DORA Guide.

The OECD AI Incidents and Hazards Monitor

AIM is an automated monitor, still labelled beta, that builds a record of AI incidents and hazards from news coverage, using Event Registry data with AI-generated summaries for each entry. It separates incidents (realised harm), hazards (plausible harm) and complementary information about earlier events, and it held about 18,579 incidents and hazards when checked. It is not a reporting channel: organisations do not file to it. Its value is as a shared vocabulary and a source of precedents for threat modelling and severity calibration. The OECD's common reporting framework proposes 29 criteria for describing an AI incident, and the Commission says its draft Article 73 guidance aims to align with both.

Timeline and current status

The Commission's consultation page described the reporting rules as applying from August 2026; that predates the Digital Omnibus. Because Article 73 attaches to high-risk systems, check the final guidance and the consolidated text for the date that applies to each system before setting internal deadlines.

Enforcement and penalties

• Penalty tiers: Article 99 sets fines of up to EUR 35 million or 7% of worldwide turnover for prohibited practices, up to EUR 15 million or 3% for breaches of operator obligations listed in Article 99(4), and up to EUR 7.5 million or 1% for supplying incorrect, incomplete or misleading information to authorities. Article 99(4) lists provider obligations under Article 16 and deployer obligations under Article 26, among others; Article 73 is not named there directly, so how authorities penalise late reporting should be confirmed against national implementing law.
• Misleading reports: an inaccurate or incomplete report that is not corrected risks the information tier, which is why an incomplete initial report should be labelled as such under Article 73(5).
• GPAI providers: fines for GPAI model providers are set by the Commission under Article 101.
• Market measures: authorities can require corrective action, restrict or withdraw a system, which can cost more than a fine.

What it means for AI agents and non-human identities

Agents turn model errors into actions, and actions are what cause reportable harm. The Replit AI agent database deletion is a clear example of a malfunction without an attacker: an agent with direct write access to production deleted live records during a code freeze that existed only as a natural-language instruction, then misreported that rollback was impossible. The agent's own account of events could not be trusted, which is why independent logs matter.

• Attribute every action: give each agent its own identity and credentials so logs show which agent, acting for which user, called which tool. Without that, establishing the causal link that starts the Article 73 clock is guesswork. See the Identity Governance for AI Agents Guide.
• Contain without destroying evidence: revoke the agent's tokens and disable its tools rather than redeploying or retraining it, to respect Article 73(6). See the AI Agent Kill Switch and Containment Guide.
• Detect behaviour, not just intrusion: an agent acting outside its baseline is a candidate incident even if no alert fires. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.
• Compromised agents are both: the Spain AEPD AI agent breach, where an attacker's agent logged in and changed personal data, was notified as a GDPR breach; if the system had been high-risk, the same facts could also need an AI Act assessment.

Compliance steps

1. Map your role: list each AI system and model, whether it is high-risk or a GPAI model with systemic risk, and whether you are provider, deployer or both. Record the applicable date for each.
2. Extend the severity matrix: add the four Article 3(49) limbs and the widespread infringement test to your incident classification so triage can flag AI cases in the first hour. See the Incident Severity Classification Matrix Template.
3. Set up feeds: route complaints, contested decisions, override spikes, safety reports and agent anomaly alerts into the incident queue, not only security alerts. Article 72 post-market monitoring data belongs here.
4. Agree the deployer-provider channel: put contacts, timelines and evidence sharing for serious incidents into contracts, because deployers must notify providers first.
5. Build the report pack: prepare a template based on the Commission's draft form and the OECD criteria: system identity and version, what happened, harm and people affected, Member States, causal assessment, immediate measures, and contact point.
6. Preserve evidence by default: snapshot model version, configuration, prompts, retrieved context, tool calls and outputs, and freeze changes until the authority is told.
7. Run a combined triage: in one decision step, assess AI Act, GDPR, NIS2, DORA and sector duties, assign an owner and the earliest deadline.
8. Exercise it: run a tabletop with a non-malicious malfunction (biased decisions in a hiring tool, an agent deleting records) and time each stage. Feed lessons into the plan.

Measuring it

• Time from first signal to classification decision on AI incidents.
• Time from awareness to report, against the 2, 10 and 15 day limits.
• Percentage of high-risk systems with a tested reporting runbook and named contacts.
• Percentage of agent actions attributable to a specific agent identity and user.
• Share of AI incidents where evidence was preserved before remediation.

Common failure patterns

• Security-only triggers: plans that open an incident only on a security alert miss harmful malfunctions such as discriminatory outputs.
• Fixing first: retraining or patching the model before notification, which conflicts with Article 73(6) and destroys the evidence.
• Waiting for certainty: holding the report until the investigation ends instead of filing an incomplete initial report.
• Single-regime thinking: filing the GDPR breach and forgetting the AI Act or NIS2 report, or the reverse.
• Shared agent credentials: agents that run under one service account, so nobody can say which one acted.

Framework mapping

Practitioner checklist

• Record your AI Act role and the applicable date for each AI system and model.
• Add Article 3(49) and 3(61) criteria to the incident severity matrix.
• Route complaints, override spikes and agent anomalies into the incident queue.
• Agree serious incident contacts and timelines with providers in contracts.
• Prepare a report template aligned to the Commission draft and OECD criteria.
• Keep deployer logs for at least six months and freeze system changes until notification.
• Assess GDPR, NIS2, DORA and sector duties in the same triage step.
• Give each agent its own identity so actions can be attributed.
• Run a yearly tabletop on a non-malicious AI malfunction.

Standards and references

• EU AI Act Explorer: Article 73, Reporting of serious incidents (Regulation (EU) 2024/1689)
• EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
• European Commission: Draft guidance and reporting template on serious AI incidents
• OECD.AI: AI Incidents and Hazards Monitor
• OECD: Towards a common reporting framework for AI incidents
• OECD.AI: Defining AI incidents and related terms
• General-Purpose AI Code of Practice: Safety and Security chapter
• NIST: SP 800-53 Rev. 5

This guide summarises AI incident reporting under the EU AI Act and related frameworks and is not legal advice. Related NHI Mgmt Group resources: EU AI Act Compliance Guide · AI Agent Observability and Incident Response Guide · Incident Response Guide · Global AI Regulation Map · MITRE ATLAS Guide