The OECD separates two things that are easy to blur. An incident is harm that happened: a chatbot gives a customer dangerous advice that they follow, a hiring model screens out qualified applicants, an agent deletes production data. A hazard is an event that could plausibly lead to that harm but has not yet, such as discovering that a model can be tricked into leaking customer records before anyone exploits it.
Tracking incidents is how the field learns from failures, the way aviation learns from crash and near-miss reports. The OECD’s AI Incidents Monitor and the independent AI Incident Database both collect public reports. Under the EU AI Act, providers of high-risk AI systems must report serious incidents to authorities.
For a company, the practical question is whether it would notice and reconstruct an incident at all. That depends on an audit trail, AI observability and a named owner who decides what to do next. Editorially, an incident process is the operational counterpart of an AI impact assessment: one predicts harms, the other catches the ones that happen anyway.
Sources
- OECD.AI: AI Incidents Monitor methodology — Defines an AI incident as an event where AI development, use or malfunction leads to listed harms, and an AI hazard as one that could plausibly lead to an incident; checked October 24, 2026.
- OECD.AI: AI Incidents Monitor — Public tracker of reported AI incidents and hazards drawn from news coverage; checked October 24, 2026.
- AI Incident Database — Independent public database that indexes reported AI incidents so builders can learn from past failures; checked October 24, 2026.
- EU AI Act Explorer: Article 73, Reporting of Serious Incidents — Requires providers of high-risk AI systems to report serious incidents to market surveillance authorities; checked October 24, 2026.
