AI Incident Reporting with the OECD Common Reporting Framework
Description
AI incident reporting with the OECD common reporting framework records each event in which an AI system caused harm, or could plausibly have caused it, in the common set of 29 fields the OECD published in February 2025, so that reports from different organisations, sectors and countries can be compared and pooled. The framework is meant for both mandatory and voluntary reporting and defines what a report contains, not the reporting interface or what should happen afterwards. The reporter first classifies the event using the OECD's definitions: an AI incident is an event in which the development, use or malfunction of an AI system directly or indirectly leads to harm to people's health, disruption of critical infrastructure, a violation of human rights or of laws protecting fundamental, labour or intellectual property rights, or harm to property, communities or the environment, and an AI hazard is one that could plausibly lead to such harm. Seven fields are mandatory: a title, a description, how the AI system was involved (as a direct cause, a contributing factor, a failure to act, through over-reliance or misuse, through human error, or through a failure to comply with the law), who is reporting, supporting material, the severity (hazard, serious hazard, incident, serious incident or disaster) and the type of harm. The other 22 record, where known and among other things, when and where it happened, the system and the organisations behind it, the people affected, the sector, how widely the system was deployed, whether training data, the model or several interacting systems were involved, the system's task and level of autonomy, and any action taken, giving an inspectable register of what went wrong in operation.
Example Use Cases
General
A retail bank's model risk team logs every complaint from customers or staff about its credit, fraud and customer-chatbot models that meets the OECD definition of an AI incident or hazard. A wrongly refused loan, an account frozen by a fraud alert and a chatbot quoting the wrong fees are recorded on the same severity scale and harm types, with the model and version and how the model was involved, so the quarterly risk committee can see which systems recur and which harms dominate.
A hospital records near misses as well as harms. When a radiologist notices that the imaging triage model has put an urgent scan at the back of the queue, the event is logged as an AI hazard, with the model's erroneous ranking as a direct cause, its autonomy recorded as human-in-the-loop, and the action taken, so that patterns of near misses are visible before one becomes an incident.
A national regulator that receives AI incident reports from deployers in several sectors asks for them in the OECD format, with a published note on how it judges seriousness, so that it can count serious incidents by sector and harm type and compare its figures with those of other authorities using the same fields.
A city transport authority running an AI traffic-signal optimiser records a period of emergency-vehicle delays as an incident affecting critical infrastructure, with the system as a contributing factor and an operator's configuration change as human error, so the record shows both causes and the follow-up actions assigned to the supplier and to its own staff.
Limitations
- A register is only as complete as the reports that reach it. Harms nobody notices, such as people quietly refused a service, and events staff have reasons not to report go unrecorded, so a short register is weak evidence that a system has caused little harm unless the organisation can also show how incidents are detected and how reporting is encouraged.
- The OECD's own definitions say that seriousness is highly context-dependent, that each jurisdiction may define it differently, and that several small incidents can add up to a serious one. Two reporters can classify the same event differently, so counts of serious incidents can be compared only between reporters that share a written severity rule.
- The framework standardises what is recorded, not how an incident is investigated or fixed, and the OECD paper explicitly gives no guidance on corrective or preventive action. Its field for how the AI system was involved is a short category list, and the fields on training data and the model are optional free text, so an organisation needs its own root-cause and follow-up process if records are to lead to changes.
- None of the seven mandatory fields identifies the system or its version, the organisation that deployed it or the date of the event. Records kept to the mandatory minimum cannot trace incidents to a model release or show repeated failures of one system; the framework lets a reporting scheme make more fields mandatory, and an organisation that needs this traceability has to do so.
- The framework is a recent proposal that the OECD planned to test through open submissions to its AI Incidents Monitor. Regulators that impose a legal duty to report incidents set their own format, categories and deadlines, so an organisation under such a duty reports in the regulator's format, may need to keep the OECD fields alongside, and cannot assume that an event serious on the OECD scale meets the legal definition of a serious incident, or the reverse.