AI Incident Database (AIID)

• AIID is a human-curated, public repository that aggregates and groups multiple incident reports of AI failures to build a searchable collective memory.
• It features a flexible data model with faceted search, stable identifiers, and namespaced taxonomies to accommodate diverse perspectives on incidents.
• AIID supports research, governance, and education by enabling risk analysis, comparative studies, and the development of safety benchmarks in AI.

The AI Incident Database (AIID) is a human-curated, public repository of real-world failures of intelligent systems, designed to create a searchable, citeable, and extensible collective memory of harms and near harms associated with AI deployment. It was introduced as shared infrastructure for “remembering and learning from real-world failures of intelligent systems,” with the practical aim of helping developers, managers, researchers, and other stakeholders answer the question, “what can go wrong when someone deploys this system?” The database was presented as an industrial/non-profit cooperative effort under the Partnership on AI (PAI), and, at the time of its founding paper, supported faceted and full-text search over more than 1,000 publicly available incident reports (McGregor, 2020).

1. Origins, rationale, and institutional setting

AIID was created in response to a perceived absence of systematic incident learning in AI. Its founding argument is that intelligent systems were already being deployed in consequential domains such as transportation, law enforcement, and hiring, yet the field lacked a formal, searchable collective memory of what had gone wrong. In this view, failures scattered across ad hoc Google Docs, GitHub lists, and personal archives could not perform the institutional function served by incident databases in mature sectors such as aviation, where archived failures support pattern discovery, training refinement, and continual safety improvement. The project also drew an explicit analogy to the Common Vulnerabilities and Exposures system in cybersecurity, particularly the value of stable identifiers that enable downstream taxonomies and analyses (McGregor, 2020).

The institutional setting matters to its design. AIID emerged under PAI, described as a multi-stakeholder organization funded by technology companies but governed jointly by corporate and civil-society actors. The database was therefore not designed to impose one authoritative account of AI harms. Instead, it was intended to preserve multiple viewpoints and support a pluralistic ecosystem in which partners and users could build taxonomies, summaries, and analyses on top of a shared incident corpus. This suggests that AIID was conceived not merely as an archive, but as governance infrastructure shaped by the practical difficulty of achieving consensus on prescriptive norms across competing constituencies (McGregor, 2020).

The founding paper did not provide a sharply formalized standards-style definition of “AI incident,” but it consistently described incidents as real-world cases in which intelligent systems “have caused safety, fairness, or other real world problems,” or more broadly “failures experienced in the real world.” Later work quotes AIID’s definition as “an alleged harm or near harm event to people, property, or the environment where an AI system is implicated,” while also noting that the database later distinguished “AI issues” from incidents and introduced the notion of “incident variants” to manage repeated, closely related events (Agarwal et al., 1 Jan 2025).

2. Data model, identifiers, and curation workflow

AIID’s core unit is the incident, not the report. A single incident may aggregate multiple incident reports, where a report is a publicly available document drawn from popular press, trade press, or academic press. Multiple reports may describe the same underlying event and are grouped under one incident identifier. This grouping is intended to preserve multiple perspectives on contested events, to allow the number and type of reports to function as a rough proxy for public salience, and to improve discoverability by expanding the vocabulary attached to the incident. The Boeing 737 MAX 8 crashes were given as an illustrative case, with one incident number linked to 18 separate reports (McGregor, 2020).

Incidents are numbered, citeable, and linked to the submitter who first created the incident record. They are intentionally left untitled. The reason given is that descriptions of incidents often evolve as more information emerges, and agreeing on a stable title across a corporate/non-profit coalition would be difficult. Stable numeric identifiers therefore play an infrastructural role analogous to CVE identifiers in security (McGregor, 2020).

The ingestion process begins with publicly available reporting. AIID’s “Submit” application allows users to submit links to reports, and metadata captured on entry includes title, source, author, submitter, publication date, incident date, and incident number. The founding paper anticipated that incident resolution would become more sophisticated over time, because reports often arrive long after an incident is first entered and may need to be matched to existing incidents rather than creating new ones. Deduplication and incident-resolution were therefore presented as ongoing curation problems rather than solved tasks (McGregor, 2020).

Later work formalized some of the editorial pressure created by this design. After two years of operating the database, AIID proposed a two-tier indexing system distinguishing AI incidents, AI issues, and AI incident variants. In that proposal, an AI incident was defined as “an alleged harm or near harm event where an AI system is implicated,” an AI issue as “an alleged harm by an AI system that has yet to occur or be detected,” and an incident variant as “an incident that shares the same causative factors, produces similar harms, and involves the same intelligent systems as a known AI incident.” The same paper introduced a namespaced identifier format, {NAMESPACE:INCIDENT#.VARIANT#}, to support citation and future federation across jurisdictions or databases (McGregor et al., 2022).

3. Architecture, search, and extensibility

Architecturally, AIID was implemented as a collection of web applications backed by a MongoDB document database storing both report text and metadata. Search and discovery were treated as central features. The “Discover” application supports full-text search and faceted filtering, with search described as “instant,” returning results in less than a second and updating as the user types. Full-text search operates over report texts and displays matching snippets, while facets allow filtering by metadata such as publication, authors, submitters, and incident numbers. The system also supports faceting over taxonomic tags (McGregor, 2020).

A key design decision was that AIID does not enforce one universal taxonomy. Instead, it supports interoperable, namespaced taxonomies managed by different individuals or partner groups. The founding paper illustrated this with namespaces such as “Industry” and “Fairness,” and explicitly framed the approach as a response to governance reality: stakeholders disagree deeply on some issues, so the system is designed to let multiple classifications coexist rather than forcing consensus on a single ontology. Objective metadata fields are collected for every report, while subjective classifications are layered on through these taxonomies (McGregor, 2020).

The web architecture was also designed for extensibility and low-cost publication of derived views. In addition to search and submission, AIID hosts documentation, data products, and contributor-recognition features such as leaderboards. To avoid expensive dynamic rendering for views that require scanning the full corpus, the system periodically pre-renders database views as static web applications via a Netlify-based build process that queries the database, generates summaries and visualizations, and deploys them through a content distribution network. The founding paper explicitly noted that word-frequency summaries, topic models, and trend analyses could be incorporated into this build pipeline (McGregor, 2020).

Subsequent research treated these architectural choices as both strengths and limitations. A comparative standards paper found that AIID and AIAAIC shared only six common fields—Incident ID, Title/Headline, Description, Occurrence date, System deployer, and System developer—and argued that current repositories were not interoperable enough for aggregation or robust comparative analysis. The same study identified AIID’s public weekly snapshots in JSON, MongoDB, and CSV as a strength, while noting the absence of an API and the lack of sector and country fields as important limitations for standardization (Agarwal et al., 1 Jan 2025).

4. Taxonomies, analytic overlays, and downstream reuse

AIID was designed from the outset to support downstream classification, and later work demonstrates how the corpus can be reanalyzed through multiple analytic lenses. One line of work used AIID to build a practical taxonomy of “AI ethics issues in real world,” selecting 150 incidents mainly from AIID and identifying 13 application areas and 8 forms of ethical issues. In that study, “intelligent service robots,” “language/vision model,” and “autonomous driving” were the most frequent application areas, while “Inappropriate use (bad performance),” “Racial discrimination,” and “Physical safety” were the most frequent issue categories (Wei et al., 2022).

A second line of work proposed a taxonomic system for failure-cause analysis of open-source AI incidents, specifically to make AIID more analytically useful for technical safety analysis. That paper introduced the GMF taxonomy—Goals, Methods/Technologies, and Failure Causes—and argued that although the exact causes of AI incidents are seldom known by outsiders, experts can infer plausible technical causative factors from public incident records, analogous incidents in AIID, and domain knowledge. In its early annotation state, the project reported 41 annotated AIID incidents, 12.40% coverage of AIID at that stage, and an average of 1.20 goals, 2.43 methods/technologies, and 3.78 technical failure causes per incident, with annotations marked as either “known” or “potential” (Pittaras et al., 2022).

A third line of work reclassified AIID through a diversity-and-inclusion lens. Using an AIID snapshot of 551 incidents timestamped on 24/07/2023, that study manually classified all incidents into “related to diversity and inclusion,” “not related to diversity and inclusion,” or “more information required.” It found 189 AIID incidents related to D&I issues, 80 requiring more information, and 282 not related. Race, gender, and age were reported as especially prominent diversity attributes, with 78 incidents involving race, 60 involving gender, and 24 involving age (Shams et al., 2024).

More recent work has treated AIID as a substrate for higher-order risk modeling. The CORTEX framework, for example, reported manually mapping “each of the 1,200+ incidents” into 29 technical vulnerability groups spanning seven domains such as Input and Data Layer, Model Behavior, Privacy and Compliance, and Human Factors and Feedback Loops. In that framework, AIID frequency ranks serve as the basis for likelihood scoring within a composite risk architecture that also includes contextual, governance, technical-surface, environmental, and residual-risk modifiers (Muhammad et al., 24 Aug 2025).

5. Uses in research, governance, and education

The founding paper emphasized practical use cases across roles. A product manager could search for incidents involving recommender systems for children and discover the YouTube Kids case; a risk officer evaluating automatic translation could find examples of harmful mistranslation and learn about mitigations such as clearly labeling machine-generated text; engineers could use incidents to design better tests grounded in unusual but real deployment conditions; and researchers could cite stable incident records in scholarship (McGregor, 2020).

Later work broadened this use profile. A classroom study at an R1 institution evaluated AIID as an educational tool in a graduate-level AI ethics course and found that interacting with the database helped students better understand the magnitude and severity of AI harms. Among the 30 students who completed both pre- and post-questionnaires, 66.7% said AIID increased their motivation for taking the course and 33.3% said it did not change. The study also reported a qualitative shift in emphasis toward safety and accountability/governance, and noted that the individual incidents students selected were coded primarily as Safety (16 of 31), followed by Fairness (8), Autonomy (5), Privacy (1), and Transparency (1) (Feffer et al., 2023).

AIID has also been used to ground benchmark construction. A child-safety evaluation framework for generative AI used AIID together with AIAAIC as a source of real-world incidents to validate an expert-derived taxonomy and generate synthetic prompts. That study filtered incident databases with child-related terms such as “child,” “students,” and “teens,” producing about 250 incidents, manually reduced to 90 relevant to child safety; from there it selected 13 education incidents involving human-AI interaction and generated 65 unsafe educational prompts plus 65 safe prompts for evaluation. This suggests a concrete pathway from incident narratives to benchmark artifacts: incident title and description become contextual inputs for prompt generation rather than the benchmark being drawn directly from raw incident records (Kong, 1 Jul 2026).

Another recent use case treats AIID not as a technical postmortem archive but as a dataset for studying patterns of institutional response after AI harms. A mixed-methods analysis of 962 incidents and 4,743 reports argued that AIID’s greatest current value may lie in revealing relationships among developers, deployers, victims, wider society, and lawmakers. In that study, 39% of incidents harmed the Public, 35% harmed Users, and 34% harmed Vulnerable individuals; only 3.4% of all reports were tagged as responses, corresponding to 48 incidents and 163 reports, and the authors concluded that the presence of identifiable responsible parties does not necessarily lead to increased accountability (Richards et al., 7 May 2025).

6. Biases, editorial challenges, and standardization pressures

AIID’s reliance on publicly available reporting creates systematic limitations. The founding paper acknowledged that visibility depends on media attention and disclosure, so incidents that are more sensational, damaging, or publicly contested are more likely to attract reports, while quieter or undisclosed failures may be underrepresented. It also noted that reports may disagree about causes or fair characterization, which is why multiple viewpoints are preserved rather than collapsed into one authoritative truth (McGregor, 2020).

Later editorial analysis made these challenges more explicit. A study of “750+ AI incidents” and two AIID-hosted taxonomies identified four recurring structural ambiguities: temporal ambiguities, multiplicity, aggregate and societal harms, and epistemic uncertainty. It argued that long-running incidents, repeated variants, recommender-system harms to democratic processes, and uncertain technical details of implicated systems all strain straightforward indexing. The same paper emphasized that AIID’s editor guidelines define an AI incident as “an alleged harm or near harm event to people, property, or the environment where an AI system is implicated,” and described AI issues as “an alleged harm or near harm by an AI system that has yet to occur or be detected” (Paeth et al., 2024).

Comparative standards work identified further shortcomings shared by AIID and other repositories: non-identical definitions of what counts as an incident, insufficient and incompatible data fields, narrow contributor and source bases, lack of APIs, voluntary reporting without incentives, and demographic or sectoral underrepresentation. That study reported 657 incidents in AIID as of 05-05-2024 and noted concentration among a small number of submitters and source domains, using this to argue for common definitions, standardized schemas, quality audits, sector and country metadata, better data-sharing mechanisms, and broader international participation (Agarwal et al., 1 Jan 2025).

A related schema proposal for critical digital infrastructure treated AIID as a useful but underspecified repository and proposed a standardized incident schema with 30 fields, including incident severity, incident causes, structured harm categories, application version, incident location, sectors impacted, transparency, and redacted submitter metadata. The proposal is not an operational standard, but it makes explicit a broader pressure on AIID-like systems: movement from narrative incident archives toward interoperable, policy-relevant incident intelligence infrastructures (Agarwal et al., 28 Jan 2025).

7. Later developments and the evolving role of AIID

AIID has increasingly been used not only as an archive of discrete failures but as a basis for monitoring, retrieval assistance, and higher-level risk interpretation. One retrieval study formalized report-to-incident association as a ranking problem and evaluated semantic retrieval over an AIID snapshot containing 815 AI Incidents and 3,805 reports. The best model, multi-qa-MiniLM-L6-cos-v1, achieved Accuracy@3 of 0.982, MRR@3 of 0.963, and NDCG@3 of 0.968, substantially outperforming lexical baselines and showing that report linking can be partially automated while remaining human-in-the-loop (Russo et al., 31 Jul 2025).

At the same time, several papers argue that incident databases cannot be read naively as direct measures of risk. A public-health-inspired monitoring framework used AIID as a surveillance stream but argued that incident counts alone do not measure risk because they lack denominators such as system prevalence or exposure and are confounded by reporting propensity. That paper described AIID as capturing media-reported incidents that “systematically underrepresents minor events and overrepresents high-profile cases,” and proposed using AIID together with exposure proxies, delay correction, media adjustment, and expert judgment to classify incident emergence into six phases rather than treating counts as direct evidence of worsening or improving safety (Abraham et al., 21 Apr 2026).

A related trajectory-classification paper similarly argued that public incident counts conflate reporting propensity, deployment growth, and harm frequency per unit of exposure. It proposed the SORT format—Subject, Opportunity, Risk event, Timeframe—for defining monitoring questions, a tiered estimation process for harm and exposure, and four trajectory categories: Escalating, Mitigating, Concentrating, and Receding. Applied to AIID and OECD data, the framework treated AIID as indispensable but insufficient, implying that AIID is best understood as a lower-bound harm record and one input into broader governance inference (Mengesha et al., 23 Apr 2026).

The trajectory of later research therefore suggests a dual role for AIID. On one side, it remains foundational public-interest infrastructure for preserving, citing, and searching records of intelligent-system failures. On the other, it increasingly functions as substrate: for taxonomies, educational interventions, benchmark construction, response analysis, retrieval systems, and risk-monitoring frameworks. A plausible implication is that AIID’s long-term significance lies not only in the incidents it stores, but in the analytic ecosystem it enables (McGregor, 2020).