Written and maintained by CASRAI Editorial Board
Last updated
The AI Incident Database (AIID) is a public catalogue of reported AI-related harms and near-harms, run by a nonprofit called the Responsible AI Collaborative. It is frequently confused with a regulatory reporting system because it sits in the same conversation as California’s SB 53 and New York’s RAISE Act — both of which also use the words “incident” and “reporting.” The two are not the same kind of thing. The AIID is a voluntary, crowdsourced historical record that anyone can search or contribute to. SB 53 and the RAISE Act are statutory duties that require specific companies to notify a specific government office within a specific deadline. This guide explains what the AIID actually is, who runs it, and where the line between the two sits.
Who Runs the AI Incident Database
The AIID is operated by the Responsible AI Collaborative, a nonprofit. Its board includes Patrick Hall (George Washington University), Heather Frase (Veraitech / Virginia Tech), and Kristian J. Hammond (Northwestern University); Sean McGregor serves as executive director and Daniel Atherton as lead editor. It is not a government body, a standards-setting organization, or a regulator, and it does not certify, audit, or accredit AI systems or developers.
What Gets Catalogued and How
The database describes its own purpose as building the kind of repository that other industries already have: aviation and computer security both keep centralized records of past failures so that future incidents can be recognized and avoided rather than relearned from scratch. The AIID applies that model to AI systems, indexing publicly reported cases where a deployed AI system caused or nearly caused a real-world harm.
Two things make it a catalogue rather than a registry:
- Submissions are crowdsourced. Anyone can submit a candidate incident, generally built from public reporting — news coverage, research papers, regulatory filings, or firsthand accounts — rather than a private disclosure channel.
- Entries go through editorial curation. Incident editors, including Atherton and McGregor, review submissions before they are added, and the project has drawn on external classification work — including taxonomy contributions from the Center for Security and Emerging Technology (CSET) — to categorize incidents once they are in the database.
Coverage is broad by design: it is not limited to frontier models, to a single sector, or to a single country. As of this writing, individual incident records in the database carry IDs past 1,690, spanning cases reported from the United States, Australia, Switzerland, and elsewhere.
How This Differs From SB 53 and RAISE Act Incident Reporting
The AIID and the statutory reporting regimes already covered in this cluster answer different questions, and conflating them leads to a real compliance mistake: assuming that having submitted something to the AIID, or that an incident appearing there, satisfies a legal reporting duty. It does not.
- Who has to act. Under SB 53, every frontier AI developer must report a qualifying “critical safety incident” — there is no opt-out. The RAISE Act’s duty falls specifically on large frontier developers (prior-year revenue of $500 million or more that trained a frontier model). Nobody is obligated to submit anything to the AIID; it accepts contributions from any source, including third parties uninvolved in the incident.
- Who receives it. SB 53 reports go to California’s Governor’s Office of Emergency Services (Cal OES); RAISE Act reports go to New York’s Department of Financial Services (DFS). Both are non-public government offices, and SB 53 reports are explicitly exempt from California Public Records Act requests. The AIID is the opposite: everything in it is public and searchable by default.
- What qualifies. SB 53 and the RAISE Act each define a narrow, specific trigger — unauthorized model-weight access causing injury, a materialized catastrophic risk, loss of control causing death or bodily injury, or deceptive behavior outside testing that demonstrates materially increased catastrophic risk. The AIID’s scope is much wider and less formally defined: any publicly reported case where an AI system is credibly linked to a real-world harm can be a candidate entry, regardless of severity or jurisdiction.
- What it produces. A statutory report is a compliance action with a deadline and legal consequences for missing it. An AIID entry is a historical record with no deadline, no enforcement mechanism, and no legal weight of its own.
Put simply: SB 53 and the RAISE Act are about a company’s legal duty to notify a regulator about its own incident, fast. The AIID is about the public record of what has already happened, contributed and curated after the fact, from any source.
Where It Fits in an AI Safety Program
The AIID is a research and pattern-matching resource, not a substitute for either statutory reporting or an internal response process. A program built along the lines described in Building an Internal AI Safety Incident Response Program can use the AIID during the risk-assessment and triage stages — checking whether a similar failure mode has been publicly documented elsewhere — without treating a search of the database as satisfying any reporting obligation triggered by SB 53 or the RAISE Act.
The AIID also sits at a different layer than NIKOLAI, CASRAI’s cross-lab, cross-regulator dictionary of frontier AI safety terminology, which includes incident-reporting terms among its tracked elements. NIKOLAI maps how different organizations define a term; the AIID records what has actually happened. Used together, one clarifies vocabulary and the other supplies real-world cases — but neither one is a reporting channel, and neither replaces the statutory duties covered elsewhere in this cluster.
