Direct comparison

OECD AIM vs. AI Incident Database (AIID)

How AIM and AIID differ on sourcing, latency, dedup and the incident/hazard line - and why neither public corpus is a regulatory reporting channel.

Written and maintained by CASRAI Editorial Board

Last updated 25 September 2026

Ask CASRAI · free to try

Ask about OECD AIM vs. AI Incident Database (AIID)

Ask your first 2 questions free below. Subscribers get 150 a day for $29 a month.

An AI assistant specialized in research administration. It cites the sources behind every answer, labels web answers and says when it can't answer.

Answers draw on CASRAI's guides and dictionary plus the federal and funder documents we index: Federal Register, Grants.gov, Regulations.gov and UKRI.

Works on this site and inside Claude, Cursor and the AI tools you already use.

Ask your first question free Subscribe — $29/month See what it covers →Already subscribed? Sign in

Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.

In summary

The OECD AI Incidents Monitor (AIM) and the AI Incident Database (AIID) are the two public corpora most often cited as "the record" of AI harms, and they are built on opposite methods. AIM is an automated media-discourse monitor: a daily pipeline ingests clusters of news articles from Event Registry, which processes over 150,000 articles a day, and uses large language models running on Microsoft Azure to group, classify and explain each event. AIID is human-curated: reports arrive through a public submission queue and an editor applies a written decision algorithm from the Editor's Guide before anything becomes an incident, a variant, or an issue. One optimises for coverage and speed, the other for reviewed judgement, and the difference propagates into every field you might want to count. The trap is that the two corpora do not draw the incident boundary in the same place, so their counts are not comparable and their rows cannot be merged. AIID defines an AI incident as "an alleged harm or near harm event to people, property, or the environment where an AI system is implicated" - near harm is inside the incident set. AIM defines an AI incident as an event where AI "directly or indirectly leads to" a listed harm, and puts anything that "could plausibly lead to an AI incident" into a separate, co-equal class it calls an AI hazard. The same near-miss is therefore an incident in AIID and a hazard in AIM. AIID does have an adjacent category - an AI issue, "an alleged harm or near harm by an AI system that has yet to occur or be detected" - but it sits at the bottom of the editorial decision algorithm as a residual bucket, not as a peer dataset you browse alongside incidents the way AIM's hazards are surfaced. Anyone reporting "AIM has N more incidents than AIID" is usually reporting a definitional artefact. The load-bearing point is that neither corpus is a regulatory reporting channel. California SB 53's critical-safety-incident duty runs to the California Office of Emergency Services, and the EU AI Act's GPAI Code of Practice serious-incident fields run to the AI Office; both are obligations on a narrow set of large frontier developers, both carry deadlines, and neither feeds AIM or AIID. AIM cannot see a confidentially filed incident because Event Registry only sees published news, and AIID cannot see one because nobody submitted it. A frontier developer can be fully compliant with every incident-reporting duty it owes and appear in neither database. Treating either corpus as a compliance signal - or as evidence that a lab has had no reportable incidents - reads absence of press coverage as absence of harm.

How do OECD AI Incidents Monitor (AIM), AI Incident Database (AIID), Regulatory reporting duties (SB 53 / EU GPAI Code) compare side by side?

The table below compares OECD AI Incidents Monitor (AIM), AI Incident Database (AIID), Regulatory reporting duties (SB 53 / EU GPAI Code) across 13 procurement-relevant dimensions, from who runs it through stated limitations.

Side-by-side comparison

Dimension	OECD AI Incidents Monitor (AIM)	AI Incident Database (AIID)	Regulatory reporting duties (SB 53 / EU GPAI Code)
Who runs it	The OECD, through its AI Policy Observatory (OECD.AI). The site carries an explicit disclaimer that displayed information "should not be reported as representing the official views of the OECD or of its member countries."	The Responsible AI Collaborative, a non-profit. The Wu Foundation is the founding sponsor and Partnership on AI is a database founding sponsor.	Government. SB 53 reports go to the California Office of Emergency Services; EU GPAI Code serious-incident reports go to the European Commission's AI Office.
How an entry originates	Automatically. A daily pipeline pulls AI-tagged event clusters from Event Registry and creates entries without a human asking for them. No submission form is involved.	By submission. Members of the public submit a report through the platform; it enters a Submission Queue and an editor decides what happens to it.	By obligation. The developer itself must file once an incident meets the statutory or Code definition. Nobody outside the developer initiates it.
Source of truth	Published news coverage only. Event Registry processes over 150,000 news articles a day; if an event was never written about in the press, AIM has no way to see it.	Published reports, but assembled and adjudicated by a person. Editors tag developer, deployer and harmed parties, and resolve incident dates against a priority hierarchy.	The developer's own internal knowledge, including material the press never sees. This is the only one of the three with access to non-public facts.
Latency	Roughly daily. The pipeline runs each day and analyses events from one to four days prior, and continues attaching new articles to an event for up to four days after it is first registered.	Variable, and gated on editorial capacity. A submission waits in the queue until an editor works it, so the lag is a function of volunteer throughput rather than a fixed cadence.	Deadline-driven. SB 53 sets a fixed reporting window for a critical safety incident, with a shorter window where there is imminent risk of death or serious physical injury.
Deduplication method	Machine. Event Registry first clusters articles reporting the same happening; AIM then takes the ten most similar existing event summaries by cosine similarity and asks an LLM whether the new item belongs in an existing cluster.	Editorial, via an explicit decision algorithm: is this a current variant, then a current incident, then does it match known incident criteria, then does it meet the incident definition, then the issue definition, else reject.	Not applicable. Each filing is a discrete regulatory act by a named developer, not a record in a corpus that needs merging.
Incident vs. not-yet-harm split	A first-class, co-equal split. An AI hazard is "an event, circumstance or series of events where the development, use or malfunction of one or more AI systems could plausibly lead to an AI incident," browsable alongside incidents.	Present but asymmetric. Near harm is inside the incident definition itself, and the separate AI issue category - "an alleged harm or near harm by an AI system that has yet to occur or be detected" - sits as a residual step in the decision algorithm.	Mostly absent. SB 53's critical-safety-incident categories are framed around materialised events and unauthorised access; there is no general duty to report a hazard that did not materialise.
Where a near-miss lands	In hazards, if no harm occurred. AIM's incident definition requires that the system "directly or indirectly leads to" a listed harm.	In incidents. "Near harm" is written into the incident definition, so a near-miss is counted as an incident, not as a separate class.	Usually nowhere. A near-miss with no materialised harm and no unauthorised access typically triggers no filing at all.
Severity and harm handling	Classified along structured axes: harm type (physical, environmental, psychological, economic or property, reputational, public interest, human rights, other), affected stakeholders, and system characteristics such as autonomy level and AI task.	Handled through applied taxonomies such as CSETv1 and the GMF taxonomy, plus editor-written neutral descriptions that state the incident, the location and the harm.	Handled by threshold, not by scale. An event either crosses the statutory definition and must be filed, or it does not. The EU GPAI Code sets reporting tiers including critical infrastructure disruption, cybersecurity breach, death and serious harm.
Who writes the classification	A model. Classifications and their explanations are AI-generated and entries are labelled as such, which is why AIM is the rare corpus that documents its own reasoning per field.	A person. The Editor's Guide explicitly warns editors about automation bias, confirmation bias and cultural bias during review.	The developer's own accountable staff, under legal exposure for what the filing says.
Normative frame	Events are classified against the OECD AI Principles - accountability, fairness, human wellbeing, privacy and data governance, human rights, robustness and digital security, safety, sustainability, transparency and explainability, and democracy and human autonomy.	No single principle set. Framing comes from the applied taxonomies and from the aviation and computer-security incident-database tradition the project explicitly models itself on.	Statutory text. The frame is whatever the legislature or the Code drafters wrote, and it differs by jurisdiction.
Can a developer be compelled to appear	No. Appearance is a by-product of press coverage.	No. Appearance depends on someone submitting a report and an editor accepting it.	Yes, for in-scope developers. This is the only column where non-appearance can itself be a violation.
Confidentiality	None - everything in it is already public news.	None - the corpus is open and the full database can be downloaded as a snapshot.	Substantial. Filings to a regulator are not automatically public, which is precisely why the corpora cannot see them.
Stated limitations	The OECD states that publicly reported incidents "only represent a subset of all AI incidents and hazards worldwide," that it cannot independently verify third-party information, and that AIM "may contain various errors and omissions."	The project describes its ingestion criteria as adaptive - reports are "accepted or rejected on the basis of a growing rule set defined in the Editor's Guide" - so the inclusion boundary moves over time.	Scope is narrow by design. Duties reach only developers above compute or capability thresholds, so most deployed AI harm falls outside them entirely.

Common questions

Common questions about OECD AI Incidents Monitor (AIM) vs AI Incident Database (AIID) vs Regulatory reporting duties (SB 53 / EU GPAI Code)

Can I compare incident counts between AIM and AIID?

Not directly, and the reason is definitional rather than statistical. AIID writes "near harm" into its incident definition, so a near-miss counts as an incident. AIM requires that an AI system "directly or indirectly leads to" a listed harm for an incident, and routes plausible-but-unmaterialised cases into hazards instead. Before comparing totals you would have to decide whether AIM incidents alone, or AIM incidents plus hazards, is the set that corresponds to AIID incidents - and there is no clean answer, because AIID also carries a separate issue category for harm that has yet to occur or be detected.

Does filing an incident under SB 53 or the EU GPAI Code put it into either database?

No. There is no pipeline from a regulator to either corpus. SB 53 critical-safety-incident reports go to the California Office of Emergency Services and EU GPAI Code serious-incident reports go to the AI Office; neither body forwards filings to AIM or AIID, and filings are not automatically public. AIM only sees what Event Registry finds in the news, and AIID only sees what a member of the public submits. A confidentially filed incident is invisible to both unless a journalist independently reports it.

Is an empty result in AIM or AIID evidence that a lab has had no incidents?

No, and treating it that way is the most common misuse of both corpora. Absence from AIM means no press cluster crossed its pipeline; absence from AIID means nobody submitted a report an editor accepted. Neither is evidence about what happened inside a developer, and both projects say so - the OECD notes that publicly reported incidents represent only a subset of incidents worldwide, and AIID describes its ingestion criteria as an evolving rule set rather than a complete census.

Which one should a governance team actually use?

They answer different questions. Use AIM when you want breadth and recency across jurisdictions and want harms sliced by OECD AI Principle, harm type or affected stakeholder - its daily cadence and automated classification are built for that. Use AIID when you want a specific event you can cite with confidence, because a human editor has adjudicated the facts, tagged the developer and deployer, and applied a published taxonomy. Use neither as a compliance record; that lives in your own incident register and in whatever you have filed with a regulator.

Why does AIM label its classifications as AI-generated?

Because they are. AIM runs large language models to cluster events and to produce both the classifications and the written explanations attached to each one, and it marks the output accordingly. That is unusually candid for a public dataset, and it is also the field you should read most carefully: an AI-generated harm-type label on a news cluster is a model's reading of journalism, two inferential steps away from what actually happened. AIID's equivalent labels are written by people, whose guide warns them about automation, confirmation and cultural bias.

Does NIKOLAI resolve the mismatch between the two corpora?

It documents it rather than resolving it. NIKOLAI's N7 "Incident type" element on the Incidents track is a proposed controlled value that classifies an incident by mechanism and severity, and its crosswalk shows how far apart the source frameworks sit - an exact match against California SB 53's four categories, close readings of Anthropic's and the Frontier Model Forum's vocabularies and the EU GPAI Code's nine data fields, and an unverified low-confidence reading of the UK AI Security Institute. Every one of those rows is a shadow mapping: CASRAI's own independent reading, published without the organisation being consulted. NIKOLAI is not a standard and no organisation has endorsed the N7 definition. What the crosswalk makes visible is why a row-for-row merge of AIM and AIID would have to invent a mechanism field that neither corpus records.

Is any of this relevant to a university research administration office?

Yes, in a narrow and honest way. Neither corpus creates an obligation for a university, and almost no university is an in-scope frontier developer under SB 53 or the EU GPAI Code - so a research institution that deploys AI generally has no incident-reporting channel at all. What the corpora are genuinely useful for is evidence of foreseeable harm: an IRB assessing an AI-involving human-subjects protocol, a research-computing group evaluating a model deployment, or a sponsored-programs office doing vendor due diligence can cite documented real-world failures of comparable systems rather than speculating. Both are free and open, and AIID publishes downloadable database snapshots. The limit is that neither is a complete census, so they can establish that a harm class is real but never that one is absent.

Going deeper