Table of Contents
Fetching ...

From Incidents to Insights: Patterns of Responsibility following AI Harms

Isabel Richards, Claire Benn, Miri Zilka

TL;DR

This paper reorients learning from AI harms away from purely technical remediation toward understanding accountability patterns and social learning that emerge after incidents. Using a three-tier mixed-methods analysis of 962 AI incidents and 4,743 associated reports in the AI Incident Database (AIID), it traces how developers, deployers, victims, and wider society respond to harms. The findings show that the presence of identifiable responsible parties does not reliably boost accountability; responses depend on context, harm type, and deployment modality, with controversy and public pressure playing pivotal roles. The work demonstrates that the AIID, despite limitations, is a valuable resource for mapping socio-technical accountability mechanisms and informing policy and governance around AI harms.

Abstract

The AI Incident Database was inspired by aviation safety databases, which enable collective learning from failures to prevent future incidents. The database documents hundreds of AI failures, collected from the news and media. However, criticism highlights that the AIID's reliance on media reporting limits its utility for learning about implementation failures. In this paper, we accept that the AIID falls short in its original mission, but argue that by looking beyond technically-focused learning, the dataset can provide new, highly valuable insights: specifically, opportunities to learn about patterns between developers, deployers, victims, wider society, and law-makers that emerge after AI failures. Through a three-tier mixed-methods analysis of 962 incidents and 4,743 related reports from the AIID, we examine patterns across incidents, focusing on cases with public responses tagged in the database. We identify 'typical' incidents found in the AIID, from Tesla crashes to deepfake scams. Focusing on this interplay between relevant parties, we uncover patterns in accountability and social expectations of responsibility. We find that the presence of identifiable responsible parties does not necessarily lead to increased accountability. The likelihood of a response and what it amounts to depends highly on context, including who built the technology, who was harmed, and to what extent. Controversy-rich incidents provide valuable data about societal reactions, including insights into social expectations. Equally informative are cases where controversy is notably absent. This work shows that the AIID's value lies not just in preventing technical failures, but in documenting patterns of harms and of institutional response and social learning around AI incidents. These patterns offer crucial insights for understanding how society adapts to and governs emerging AI technologies.

From Incidents to Insights: Patterns of Responsibility following AI Harms

TL;DR

This paper reorients learning from AI harms away from purely technical remediation toward understanding accountability patterns and social learning that emerge after incidents. Using a three-tier mixed-methods analysis of 962 AI incidents and 4,743 associated reports in the AI Incident Database (AIID), it traces how developers, deployers, victims, and wider society respond to harms. The findings show that the presence of identifiable responsible parties does not reliably boost accountability; responses depend on context, harm type, and deployment modality, with controversy and public pressure playing pivotal roles. The work demonstrates that the AIID, despite limitations, is a valuable resource for mapping socio-technical accountability mechanisms and informing policy and governance around AI harms.

Abstract

The AI Incident Database was inspired by aviation safety databases, which enable collective learning from failures to prevent future incidents. The database documents hundreds of AI failures, collected from the news and media. However, criticism highlights that the AIID's reliance on media reporting limits its utility for learning about implementation failures. In this paper, we accept that the AIID falls short in its original mission, but argue that by looking beyond technically-focused learning, the dataset can provide new, highly valuable insights: specifically, opportunities to learn about patterns between developers, deployers, victims, wider society, and law-makers that emerge after AI failures. Through a three-tier mixed-methods analysis of 962 incidents and 4,743 related reports from the AIID, we examine patterns across incidents, focusing on cases with public responses tagged in the database. We identify 'typical' incidents found in the AIID, from Tesla crashes to deepfake scams. Focusing on this interplay between relevant parties, we uncover patterns in accountability and social expectations of responsibility. We find that the presence of identifiable responsible parties does not necessarily lead to increased accountability. The likelihood of a response and what it amounts to depends highly on context, including who built the technology, who was harmed, and to what extent. Controversy-rich incidents provide valuable data about societal reactions, including insights into social expectations. Equally informative are cases where controversy is notably absent. This work shows that the AIID's value lies not just in preventing technical failures, but in documenting patterns of harms and of institutional response and social learning around AI incidents. These patterns offer crucial insights for understanding how society adapts to and governs emerging AI technologies.
Paper Structure (47 sections, 8 figures, 2 tables)

This paper contains 47 sections, 8 figures, 2 tables.

Figures (8)

  • Figure 1: Left: proportion of all incidents by harmed group (not mutually exclusive; see \ref{['tab:harmed']} for full definitions of all groups). Right: co-occurrence of different harmed groups using the Jaccard Similarity Index (Higher values indicate groups frequently appear together).
  • Figure 2: Left: A breakdown of incidents based on whether the developer and the deployer are known and whether they are the same organisation if they are both known. Right: Shown separately for each harmed group.
  • Figure 3: A distribution of number of reports per incident
  • Figure 4: The number of reports submitted by individual submitters
  • Figure 5: A histogram of reports per submitter. Outliers are excluded.
  • ...and 3 more figures