Definition, and why it needs one

The working definitions most regimes now borrow come from the OECD, which published common definitions in May 2024 so that incidents could be counted and compared across countries. An AI incident is an event where the development, use or malfunction of one or more AI systems directly or indirectly leads to harm: injury or harm to health, disruption of critical infrastructure, violation of human rights or of legal obligations that protect fundamental, labour or intellectual property rights, or harm to property, communities or the environment. An AI hazard is an event that could plausibly lead to an incident. A near miss is a hazard.

The definition matters because organisations routinely file AI failures as ordinary IT incidents, counted by downtime rather than by harm. A model that is up and running and quietly discriminating is not an outage. It is an AI incident.

How it differs from an IT incident and a serious incident

  • An IT incident is defined by service disruption. Many AI incidents involve no disruption at all.
  • An AI incident is defined by harm, actual or, for a hazard, plausible.
  • A serious incident is the EU AI Act's legal subset (Article 3(49)): an incident or malfunction that leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of obligations that protect fundamental rights, or serious harm to property or the environment.
  • A critical safety incident is the term in California's frontier AI law, SB 53, for events such as unauthorised access to a frontier model's weights or a loss of control causing death or injury.

An internal taxonomy needs all four levels, because the reporting obligation depends on which one an event is.

Who has to report what, and when

  • EU AI Act, high-risk systems. The provider reports a serious incident to the market surveillance authority where it occurred, immediately after establishing a causal link or its reasonable likelihood and no later than 15 days after becoming aware of it. The deadline is 2 days for a widespread infringement or a serious disruption of critical infrastructure, and 10 days where a person has died (Article 73). A deployer that identifies a serious incident must tell the provider immediately. The duty applies when the high-risk obligations do: from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The Commission consulted on draft guidance and a reporting template from September to November 2025.
  • EU AI Act, general-purpose models with systemic risk. The provider tracks, documents and reports serious incidents to the AI Office without undue delay (Article 55). This duty already applies.
  • California SB 53, in force since 1 January 2026. A frontier developer reports a critical safety incident to the California Office of Emergency Services within 15 days, and within 24 hours to an appropriate authority, such as law enforcement, where there is an imminent risk of death or serious physical injury.
  • New York RAISE Act, from 1 January 2027. A large frontier developer reports a critical safety incident within 72 hours to a new office within the New York Department of Financial Services, the state's financial regulator.

For most deploying organisations none of these is the first obligation they will meet. Personal data breach notification under UK GDPR (72 hours to the ICO), sector regulators' own incident rules and contractual notice clauses usually come first, and an AI incident process should be built to feed them.

What good looks like

  • An AI-specific incident category in the existing incident process, with triggers based on harm, not only on availability.
  • A severity scale that maps to the legal definitions, so the team handling an event knows within hours whether a regulatory clock has started.
  • Detection that can see harm: monitoring of outcomes by group, complaint and override patterns, and AI system monitoring and logging that records enough to reconstruct a decision.
  • Pre-agreed containment: the ability to roll back a model or switch to a manual process, through AI incident response and rollback.
  • Hazards recorded as well as incidents. Near misses are the cheapest lessons available, and most organisations throw them away.

The OECD's AI Incidents Monitor, a public database of reported AI incidents, is a useful source of scenarios for playbooks and tabletop exercises.

Frequently asked questions

What is an AI incident? An event in which the development, use or malfunction of an AI system directly or indirectly leads to harm to health, critical infrastructure, rights, property, communities or the environment.

What is the difference between an AI incident and an AI hazard? An incident has caused harm; a hazard is an event that could plausibly have caused it.

What is a serious incident under the EU AI Act? An incident or malfunction leading to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental-rights obligations, or serious harm to property or the environment. Providers of high-risk systems must report them.

Do deployers have to report AI incidents? Under the EU AI Act, a deployer that identifies a serious incident must immediately inform the provider and then the relevant authorities. Other rules, such as personal data breach notification, apply in parallel.

Where it sits in the register

Untested AI failure scenarios is what turns an incident into a surprise, and AI model drift and degradation is the commonest slow-burning cause. The controls are AI incident response and rollback and AI system monitoring and logging. The procedural detail of running an incident is in the incident response entry.