AI Incident Database Comparison: Which One to Use

Search for “AI incident database” and you get at least six projects, none of which record the same thing. One indexes realized harms and near harms to people. One ingests press coverage worldwide and splits it into harms that happened and hazards that could. One deliberately includes controversies that never produced a measurable harm. One catalogs failure modes rather than events. One is a matrix of adversary techniques with case studies attached. They share a name and almost nothing else.

That matters more than it sounds. If you go looking for an autonomous-vehicle collision in a vulnerability catalog you will conclude it never happened. If you cite an aggregated press-monitoring feed as evidence that a specific harm occurred, you have cited a headline, not a finding. The right move is to know what each project’s unit of record actually is, and to pick on that basis.

Why the definitions diverge

The split traces back to a question the field never settled: is an AI incident an event or a property?

The event camp says an incident is something that happened at a time, to someone, with consequences. The property camp says the useful record is the weakness that made the event possible, because the weakness recurs across deployments while the event does not. Both are defensible. They produce completely different databases.

A third camp records neither, and instead records attention: the fact that a deployment became publicly contested. That is not a lesser standard, it is a different research question, and it captures things the other two miss entirely, such as a system withdrawn before it caused harm.

We work through this split in more detail in our working taxonomy of incident, vulnerability, disclosure and misuse. The short version is that these four words describe four different events with four different response paths, and a database that blurs them will mislead you at exactly the moment precision matters.

The projects, one by one

AI Incident Database (AIID)

Maintained by the Responsible AI Collaborative, a nonprofit chartered specifically to run it. AIID indexes, in its own words, harms or near harms realized in the real world by the deployment of AI systems. Its unit of record is the incident, and each incident aggregates multiple reports covering the same event, which is a genuinely useful structure: it separates the thing that happened from the coverage of the thing that happened.

Submissions are open to the public and pass through a visible review queue before they are indexed. Incident ids are sequential and had passed 1,600 by August 2026, with several times that many underlying reports, since one incident aggregates every report about it. It is the closest thing the field has to an aviation-style shared learning record, and it is the default citation in most academic work.

Weaknesses: incident boundaries are editorial judgments, so one organization’s single incident is another’s three. Dates are usually disclosure dates rather than occurrence dates, which is a recurring problem across all of these projects and one we cover in reconstructing an incident timeline from primary sources.

OECD AI Incidents and Hazards Monitor (AIM)

Run by the OECD.AI Policy Observatory. AIM ingests press reporting globally, via the Event Registry news feed, and classifies items into two buckets: incidents, where harm occurred, and hazards, where the conditions for harm existed. The combined count had passed 17,000 by August 2026, an order of magnitude above AIID, and the gap is the definition rather than better coverage: AIM counts news items about events, AIID counts events.

The scale comes from automation, and so do the tradeoffs. AIM is the right tool for asking “what is the trend line for AI harms in the health sector in Europe”, and the wrong tool for asking “what exactly happened on this date”. Multiple articles about one event can surface as multiple items. Treat it as a monitoring instrument, not as a case file.

AIAAIC Repository

An independent, openly accessible repository covering AI, algorithmic and automation incidents and controversies. The scope decision is the point: AIAAIC records systems that drew sustained public objection even where no harm was ever demonstrated, which makes it the only one of these that reliably captures withdrawn products, cancelled pilots and contested procurements.

If your question is about public legitimacy, regulatory pressure or reputational consequence, this is the richest source. If your question is strictly about demonstrated harm, its inclusion criteria are broader than you want.

AI Vulnerability Database (AVID)

Maintained by the AI Risk and Vulnerability Alliance, AVID inverts the model. It describes itself as a knowledge base of failure modes for general-purpose AI systems, and it is built as two halves: a taxonomy library that classifies failure modes across the security, ethics and performance axes, and a database of evaluation examples supplying reproducible evidence that a given failure mode is real. The count of distinct failure modes is deliberately far smaller than any event catalog, because the taxonomy is the product and the evaluations are illustrations of it.

Use it when you are threat-modeling a system you are about to deploy and want a checklist of what has gone wrong in that class of system, or when you need a reproducible eval rather than a press citation. Do not use it as a census of events.

MITRE ATLAS

Not marketed as an incident database, and it is not one, but analysts keep reaching for it as if it were. ATLAS is a matrix of adversary tactics and techniques against AI systems, modeled on ATT&CK, with a set of curated case studies. The case studies are the incident-shaped part, and they are deliberately few and deeply documented rather than many and shallow.

ATLAS is the right vocabulary layer for describing how an adversarial incident was carried out. Pair it with an event database that tells you that it happened. Our incident-response playbook for AI systems sets out how ATLAS, NIST SP 800-61r3 and the OWASP LLM Top 10 divide the labor during an actual response.

NVD, CVE and the ML supply chain

For anything that is a software defect in a machine-learning dependency rather than a model-behavior failure, none of the above apply. Those live in CVE records and the National Vulnerability Database, and reading them for ML libraries has its own pitfalls, which we cover in decoding NVD CVE entries for ML libraries. A deserialization bug in a model-loading path is a CVE. A model that produced defamatory output is not.

MIT AI Risk Repository and derived trackers

Worth separating, because the name gets misused. The MIT AI Risk Repository proper is not an incident database at all: it is a living taxonomy of AI risks extracted from dozens of published frameworks, well over a thousand classified risk statements, and it belongs next to AVID rather than next to AIID. The project separately runs an AI Incident Tracker that does record real-world harms, classified by risk category and harm severity, with large-language-model classifiers in the pipeline.

That LLM-assisted classification is the thing to hold in mind for this and every derived tracker. They are downstream: coverage cannot exceed the upstream sources they ingest, and classification error compounds silently rather than surfacing as a gap. Use them for mapping between taxonomies and for trend shape. Cite the upstream record when you are making a claim about a specific event.

The catalog on this site

Our own AI Incident Explorer is a deliberately small, hand-curated set of well-documented incidents, each classified under a fixed six-facet taxonomy (incident type, harm domain, modality, actor class, source tier, verification status) and linked to its single strongest primary source. It is not trying to be comprehensive. It is trying to be checkable: every entry sorts on the date the harm occurred rather than the date it was reported, carries an explicit source tier, and exports APA or BibTeX citations. Where the actor is unknown it stays unknown, per our policy against attribution speculation.

Side by side

Project	Unit of record	Scope boundary	Maintained by	Best for
AIID	Incident (with many reports)	Realized or near harms from deployed AI	Responsible AI Collaborative (nonprofit)	Citing a specific event in research
OECD AIM	Press item, split incident vs hazard	Global media reporting on AI harms	OECD.AI Policy Observatory	Trend and sector analysis at scale
AIAAIC	Incident or controversy	Includes contested deployments with no harm	Independent, open repository	Legitimacy, procurement and policy questions
AVID	Failure mode, with evaluations	Failure modes, not events	AI Risk and Vulnerability Alliance	Pre-deployment threat modeling
MITRE ATLAS	Technique, plus case studies	Adversarial behavior against AI systems	MITRE	Describing attack mechanics precisely
NVD / CVE	Software vulnerability	Defects in ML libraries and tooling	NIST / CVE Program	Patching the AI supply chain
This site’s Explorer	Curated incident, six facets	Small, source-tiered, date-of-harm sorted	AI Incidents Editorial	Verifiable citations with source tiers

Picking one, by the question you are actually asking

• “Has this exact thing happened before?” Start with AIID, then AIAAIC for anything that was contested rather than harmful. Neither is complete; check both.
• “Is this category of harm increasing?” OECD AIM, because volume is the point and its ingestion is automated. Report the counting method alongside the number.
• “What could go wrong with the system we are about to ship?” AVID for failure classes, MITRE ATLAS for adversarial technique coverage.
• “Do we need to patch something?” CVE and NVD. Nothing else in this list tracks patch state.
• “I need a citation an editor or reviewer will accept.” Use whichever database led you to the event, then follow it to the primary source and cite that. Our five-tier source verification ladder sets out when a single primary document is sufficient and when ten secondary reposts still are not.

What none of them solve for you

Three problems survive every one of these projects, and they are the ones that produce wrong analysis.

Dating. Most entries carry the date the event entered the public record, not the date the harm occurred. Those can be months apart. Any time-series built without separating the two is measuring disclosure behavior and calling it harm frequency.

Deduplication across projects. The same event appears in AIID, AIAAIC and AIM under three ids, three titles and sometimes three dates. Counts do not add. If you merge sources you must dedupe on the underlying event, which usually means matching on the primary source URL rather than on the title.

Attribution. Several projects record an alleged responsible party from press coverage. Press attribution early in an incident is frequently revised and rarely retracted in the database. Treat any actor field as a claim with a source, not as a finding.

The practical consequence is that these catalogs are a discovery layer, not an evidence layer. They tell you where to look. The evidence is the advisory, the filing, the regulator notice or the paper they point at, and reading those correctly is a separate skill, covered in our incident logging methodology and in anatomy of a vendor advisory.

Contributing an incident back

AIID and AIAAIC both accept public submissions, and both will ask for the same things: a dated primary source, a description of the harm, and the system involved. Submitting well is worth doing, because the gap in every one of these catalogs is not analysis, it is coverage of events nobody wrote up.

Note that a voluntary submission to a research database is not a regulatory report and does not discharge any legal obligation. If the event involves personal data, a listed company, or a vehicle on a public road, a mandatory clock is already running in parallel, and for high-risk systems in the EU one is scheduled rather than live, because the Digital Omnibus moved the AI Act’s high-risk dates in July 2026. Which is which, and by when, is set out in AI incident reporting requirements.