How to Explore Real-World AI Incidents and Harms on the MIT AI Risk Initiative Site

Updated

Open the Incidents section of airisk.mit.edu to browse and compare documented real-world AI harms. The site lets you filter incidents by risk domain, type and severity of harm, number of people affected, alleged developer, time, and national security impact. Use it when you need concrete examples of AI harms rather than abstract risk categories — for instance, to ground a policy discussion, benchmark a company's disclosed risks, or find precedents for a specific harm type.

What the incident data contains

The MIT AI Risk Initiative describes its incidents dataset as a way to "explore and compare real-world AI incidents." Each record is organized around dimensions that let you move from a single case to broader patterns:

  • Risk domain — the category of risk the incident falls under
  • Type and severity of harm — what kind of damage occurred and how serious it was
  • Number of people affected — the scale of impact
  • Alleged developer — the organization linked to the system involved
  • Time — when the incident occurred
  • National security impact — whether the incident carries national-security relevance

These fields are the comparison axes. You can hold one constant (say, a risk domain) and compare across another (severity, or time) to see how harms cluster.

Step-by-step: from a single incident to a pattern

  1. Start in the Incidents view. This is the entry point for real-world harms, distinct from the risk repository and governance sections.
  2. Pick a comparison axis. If you're investigating a specific harm type, filter by risk domain first. If you're tracking a company, filter by alleged developer.
  3. Narrow by severity or scale. Add the harm severity or number-of-people-affected filters to separate minor incidents from high-impact ones.
  4. Check the time dimension. Sorting or filtering by time reveals whether incidents in your domain are increasing, concentrated in a period, or isolated.
  5. Flag national-security relevance if your question involves security policy, since this is a separate field from general severity.
  6. Record what you find — the site presents incidents for exploration and comparison; the filtering is how you turn a list into evidence.

Expected result: a filtered set of incidents you can cite as concrete examples, plus a sense of how your chosen risk domain behaves across severity, scale, and time.

Connecting incidents to the rest of the site

The incidents data is one of several linked datasets, and the AI Risk Navigator is the tool that connects them: the site says the Navigator "connects our datasets so you can move between them and surface the patterns that matter." That matters for incidents because a single harm usually has three companion views:

Question Where to look How it links to incidents
What risks exist and how do they emerge? Living repository of AI risks Maps each incident to its underlying risk category
Which risks matter most? Expert consensus survey Shows whether the harms you're seeing match expert priority rankings
What laws cover these risks? Governance database Filters global laws by risk domain to find rules addressing the harm
How are companies responding? Company disclosures Compares which of 24 AI risks 200 large companies acknowledge against expert priorities

A practical workflow: find an incident in your domain, note its risk category, then check the expert survey to see whether that category is ranked as high-severity, and the governance database to see which laws address it. The company disclosures view adds a fourth check — whether major companies publicly acknowledge that risk at all.

What the incident data is useful for

  • Grounding abstract risk discussions. Instead of arguing about hypothetical harms, point to documented incidents with severity and scale attached.
  • Testing disclosure gaps. Compare incidents in a risk domain against company disclosures to see whether firms acknowledge the risks that are actually materializing.
  • Prioritizing governance work. Cross-reference incident frequency and severity with the expert consensus survey to decide which risks deserve attention first.
  • Policy and legal mapping. Use the risk domain of an incident to filter the governance database for relevant laws and frameworks.

The site's stated purpose is to "help you identify, prioritize, and manage the risks from AI," and the incidents dataset serves the identify step most directly — it is the empirical record against which the other datasets can be checked.

Common sticking points

  • Don't treat the incident list as exhaustive. The site calls its risk repository "living," implying ongoing updates; incident coverage should be read the same way.
  • Severity and national-security impact are separate fields. An incident can be severe without national-security relevance, so filter both if your question spans security policy.
  • Alleged developer is not a finding of liability. The field is labeled "alleged," so attribute carefully when citing.
  • Use the Navigator for cross-dataset questions. If you find yourself manually jumping between incidents, risks, and governance pages, the Navigator is designed to move between them in one place.