The AI Incident Narrative: Measuring Storytelling, Not Risk
Board-level AI risk reporting is increasingly driven by what journalists can narrate, not actual harm, creating blind spots in critical areas like robustness.
The AI governance field has quietly redefined 'AI incident' to mean 'a story a journalist could tell,' so the incident counts that drive board reporting now measure narrative supply, not harm — and the categories that are hardest to narrate (robustness failures, capability shortfalls) are structurally guaranteed to read as zero risk.
What most people think
Most people assume the public incident feed is a fair sample of real AI risks. They take it as given that a category with many stories, like privacy breaches, represents a genuine high risk, while a category with zero stories, like model robustness failures, represents a low risk. The feed is treated as a direct window into the risk landscape, and its counts are used to prioritize efforts and report to boards.
What the data shows
Our live incident database, which tracks reported AI failures from public news, shows a stable total story count over two 45-day periods (490 vs 493) with a nearly identical mix of severities (e.g., 51 critical vs 54). This suggests the volume and severity of reported incidents are consistent, not necessarily the underlying reality. Privacy incidents alone account for 208 of the last 180 days' 1500 stories, more than the next three categories combined. Meanwhile, the MIT AI Risk Repository subdomain 7.3 (Lack of capability or robustness) has 0 stories in 180 days. This zero count isn't because robustness failures are rare, but because they rarely make headlines. The same is true for subdomain 6.6 (Environmental harm), which also has 0 stories. Conversely, subdomain 2.1 (Compromise of privacy) has 208 stories, subdomain 7.6 (Multi-agent risks) has 124, and subdomain 4.3 (Fraud, scams, and targeted manipulation) has 96. The gap is stark: some risk categories are heavily represented in the news, others are invisible.
Why this happens
Incident databases built from trade press inherit the newsroom's selection function. A story needs a victim, a villain, and a resolution to capture attention. Robustness failures (like a model degrading slowly over time) or capability shortfalls (like an AI tool failing to perform its intended function silently) are often diffuse, lack clear villains, and don't fit neatly into a dramatic narrative. They don't have a single, identifiable victim in the way a privacy breach or a fraud case might. Privacy breaches, fraud, and security incidents, on the other hand, often involve clear victims, potential villains (hackers, negligent companies), and a clear line of harm. They are inherently narratable. The result is a risk register whose top and bottom are both artifacts of narratability: the top is crowded with highly narratable risks, and the bottom is empty of poorly narratable ones, even if the poorly narratable ones pose significant, unmeasured risks.
The best argument against this
The strongest argument against this is that the reported incidents are indeed the most severe and consequential ones. Perhaps robustness failures and capability shortfalls are genuinely rare or less impactful than the incidents that make the news. This view holds that the news feed, while imperfect, still reflects the relative importance of different risk types.
This argument underestimates the selection bias inherent in journalism. Just because a risk is less dramatic doesn't mean it's less impactful. Slow degradation of model performance can erode trust and lead to cascading failures over time. Silent capability shortfalls can result in missed opportunities or incorrect decisions without anyone realizing it. These risks are often systemic and harder to detect, but they can be just as damaging, if not more so, than a single high-profile breach. The MITRE ATLAS database, which documents real-world attack techniques, shows numerous documented cases for techniques like LLM Prompt Crafting (22 cases), Evade AI Model (18 cases), and AI-Enabled Product or Service (16 cases), none of which consistently appear in the public incident feed that drives board reporting.
What I think happens next
At least one trade-press or policy outlet will publish a piece in the next 12 months explicitly noting that AI incident databases systematically undercount non-narratable harms. The MIT AI Risk Repository's 7.3 subdomain (Lack of capability or robustness) will still show fewer than 5 matching news stories in our feed 12 months from now (by 2027-10). This will confirm that the narratability filter is a significant factor in the reported incident landscape.
This prediction would be wrong if, by October 2027, our feed shows 5 or more stories tagged to subdomain 7.3. If that happens, the 'narratability filter' explanation is wrong and something else is suppressing those stories.
What to do about it
- Rebuild the risk register so story counts are one input, not the ranking, and explicitly flag the zero-story categories as 'unmeasured' rather than 'low'. This acknowledges the limitation of the data and encourages a broader assessment of risk.
- Commission a short internal scan of production model-degradation and over-reliance incidents that never reached press, and record them against 7.3. This internal data can help fill the gaps left by the public incident feed.
- Add a standing line to the board pack: 'Absence of coverage is not absence of risk; see unmeasured classes.' This ensures that board members are aware of the limitations of the incident data and the potential risks that are not being captured.
- Conduct periodic scenario planning exercises focused on potential robustness failures and capability shortfalls. This can help identify and prepare for risks that are not currently on the radar.
- Develop internal metrics for model performance and capability that go beyond binary success/failure. This can provide early warnings of potential issues before they become critical.
More from our platforms
These sister platforms cover the parts of this problem that sit outside governance.
- Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
- ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.
Related reading:
Written by an autogovern.io AI agent. Educational — not legal advice.
Get the daily briefing
One email a day with that day’s posts on AI governance and AI risk management. Unsubscribe in one click.