how much of the organisation burns down when one AI component fails, which is always more than anyone expected because nobody drew the dependency map.
The scope of impact if a component, system, or vendor fails. Blast radius analysis maps dependencies so a single point of failure does not cascade across the organisation. In AI governance, blast radius extends beyond technical infrastructure to include business process dependencies, data pipeline consumers, downstream decision systems, and contractual obligations that depend on AI system availability or accuracy.
Why It Matters
AI systems are rarely isolated. A single model API powers customer service, fraud detection, content moderation, and internal search. A single vendor provides the embeddings for your RAG pipeline, the classification for your routing layer, and the summarisation for your reporting engine. A single training dataset feeds multiple models across multiple business units. When any of these components fails, the blast radius is not the component itself — it is every system, process, and decision that depends on it.
The challenge is that blast radius in AI systems is frequently invisible. Nobody maintains the dependency map because AI capabilities were adopted incrementally, by different teams, using different procurement processes. The organisation does not have a centralised view of which business processes depend on which AI components. This means the blast radius of a failure is discovered during the failure, not before it.
Taleb’s concept of fragility applies directly: systems optimised for efficiency at the expense of redundancy are catastrophically vulnerable to disruption. An organisation that runs 14 AI features on one vendor API has optimised for cost and simplicity. It has also created a single point of failure with a blast radius that spans the entire AI portfolio.
The Stress Test
Your primary LLM provider announces an emergency maintenance window — all API endpoints unavailable for four hours. Your incident team begins mapping the impact. Customer-facing chatbot: down. Internal document search: down. Automated contract review: down. Fraud scoring pipeline: degraded. Board reporting summarisation: unavailable. Candidate screening tool: offline. The blast radius spans six business units, four customer-facing products, and two compliance-critical functions.
The board asks why a single vendor outage affected this many systems. The answer: because each system was procured independently, each team chose the same provider for cost and quality reasons, and nobody maintained a portfolio view of AI vendor concentration. The dependency existed. The map did not.
In the Wild
A logistics company deployed two AI agents in adjacent business processes: a procurement agent that optimised order volumes based on demand signals, and a pricing agent that adjusted customer quotes based on supply conditions. Both agents were competent individually. Together, they created a feedback loop. The procurement agent interpreted rising prices as demand signals and increased order volumes. The pricing agent interpreted rising volumes as supply pressure and increased prices further. The loop ran for eleven days before a finance analyst flagged the anomaly.
The total financial impact was approximately $2 million in excess inventory and mispriced contracts. Neither agent malfunctioned. Each was responding rationally to the signals it received. The failure was architectural: nobody modelled the interaction between the two agents or the blast radius of their combined behaviour.
Each agent was tested in isolation and performed correctly. The blast radius was the interaction between them, and nobody tested that.
Across enterprises adopting AI at scale, a recurring pattern has emerged: individual teams independently select the same AI vendor for different use cases. The procurement team uses it for contract analysis. Engineering uses it for code review. Marketing uses it for content generation. Support uses it for customer response drafting. Each team reports low vendor dependency because they see only their own use case. At the portfolio level, a single API outage would halt operations across the entire organisation.
This is vendor concentration without vendor management. The AI SBOM does not exist. The blast radius is invisible until the vendor has an outage, changes their pricing, deprecates a model, or changes their data retention policy.
Vendor dependency is not measured at the team level. It is measured at the portfolio level. If you do not have an AI SBOM, you do not know your blast radius.
Blast radius failures in AI follow the same structural pattern as historical cascade failures in algorithmic trading (the 2010 Flash Crash), infrastructure engineering (cascading power grid failures), and financial systems (the 2008 correlation risk crisis). In each case, components were tested individually and performed correctly. The failure emerged from the interaction between components, amplified by feedback loops, and propagated through hidden dependencies. The blast radius exceeded any individual component’s failure mode because the system-level behaviour was never tested.
AI governance that tests components individually but not their interactions is rehearsing for the wrong failure.
How to Govern It
Blast radius is not a metric you calculate after a failure. It is a map you maintain before one.
Within the AI Control Index, blast radius governance spans multiple layers and shields:
- Systems & Sources (L7) — Maintain a dependency map of all AI components, their consumers, and their upstream providers. This is the AI equivalent of an infrastructure architecture diagram — except most organisations do not have one for their AI portfolio.
- Supply Chain (S3) — AI SBOM that documents vendor concentration risk at the portfolio level, not the team level. If three teams use the same provider, the blast radius is three teams — and that information must be visible to risk management.
- Observability (S4) — Cross-system monitoring that detects cascade patterns: correlated failures across AI systems, feedback loops between agents, and propagation of errors through downstream consumers.
- AI Engineering (L5) — Isolation boundaries between AI components. A failure in the customer service chatbot should not propagate to the fraud detection pipeline. Circuit breakers between AI systems, not just within them.
- GRC (S1) — Evidence Factory captures blast radius assessments, dependency maps, and the results of failure scenario testing (tabletop exercises for AI outages) as governance artifacts.
When It’s Relevant
Every AI portfolio with more than one system. Every organisation using external AI vendors. Every deployment where AI outputs feed downstream decisions or processes. Blast radius analysis is not a high-risk-only exercise — it is a portfolio-level discipline that becomes critical as AI adoption scales.
Blast radius analysis is most critical when:
- Multiple AI systems depend on a single vendor, API, or model
- AI agents interact with each other in multi-agent systems
- AI outputs feed automated workflows with no human checkpoint between systems
- The organisation has no centralised inventory of AI components and their dependencies
- A single AI system failure would affect compliance-critical or revenue-critical business processes
Related Terms
References
- [1] Taleb, N.N. (2012) Antifragile: Things That Gain from Disorder. New York: Random House.
- [2] Hollnagel, E., Woods, D.D. and Leveson, N. (2006) Resilience Engineering: Concepts and Precepts. Aldershot: Ashgate Publishing.
- [3] NIST (2024) Artificial Intelligence Risk Management Framework: Generative AI Profile (AI 600-1). National Institute of Standards and Technology, U.S. Department of Commerce.
- [4] Perrow, C. (1999) Normal Accidents: Living with High-Risk Technologies. Updated edn. Princeton, NJ: Princeton University Press.
- [5] European Parliament and Council (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), Article 9: Risk management system. Official Journal of the European Union, L 2024/1689.
- [6] Dekker, S. (2011) Drift into Failure: From Hunting Broken Components to Understanding Complex Systems. Farnham: Ashgate Publishing.
- [7] Meadows, D.H. (2008) Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing.
AI Control Index v6.0 · Glossary · June 2026 · i-DEPOT 158508 (BOIP) · CC BY-NC-ND 4.0
By Jeroen Janssen, Apparens