When One AI Model Fails Many Companies at Once

Cyber insurance works because losses across a book are mostly independent. One insured suffering ransomware tells you little about the next, so a portfolio of many policies is more predictable than any single one.

‍

Shared AI dependencies break that assumption in a specific way. Where a large share of a book depends on the same foundation model or the same inference infrastructure, a single failure produces simultaneous claims across insureds with no commercial relationship to each other. The result is an aggregation problem rather than a frequency problem, and the two are priced differently.

‍

Why Is Aggregation Different From Frequency?

‍

Because it moves the tail rather than the average, and insurers respond to those two with different instruments.

‍

A rise in frequency raises expected loss across the book, which shows up in rate. A correlation between insureds barely touches expected loss, since the same total number of events occurs, and substantially raises the probability that many arrive at once. The change affects capital requirements, reinsurance structure and appetite rather than price.

‍

Which Is Why the Effect Shows Up as Capacity

‍

An insurer facing a correlated exposure it cannot size will limit aggregate exposure to the category rather than charge more for it. An insured experiences that as smaller limits, tighter sub-limits or a declined risk rather than as a higher premium, which is a harder thing to negotiate against because it is not a pricing conversation.

‍

Why Can't Insurers See This in Submissions?

‍

Because the attribute is not collected, and you cannot aggregate on data you do not hold.

‍

A standard submission establishes revenue, sector, records held, control position and claims history. None of those reveals which model an insured's AI capability depends on, or which infrastructure that model runs on. Two insureds can look entirely unrelated on every collected attribute and share the single component whose failure affects both.

‍

Would Asking Fix It?

‍

Only partly, because the insured frequently cannot answer. An organization knows which AI vendors it contracts with and rarely knows where those vendors run inference, since the arrangement is neither disclosed nor stable. So a questionnaire question produces the vendor list and stops one layer above where the correlation sits, which concentration that cannot be diversified away sets out.

‍

Which Attribute Should Be Collected?

‍

The inference infrastructure rather than the model, since the failure that correlates across a book is more likely to be regional or platform-level than model-level.

‍

A model producing degraded output affects the organizations using that model for the affected task, which is a real exposure and a narrower one. An infrastructure failure affects every model hosted in it, across every vendor building on that platform, which is the population that produces simultaneous claims. Collecting the model name captures the smaller effect and misses the larger.

‍

Can an Insurer Establish It Without Asking?

‍

Better than the insured can, which is the useful asymmetry here. The mapping from AI vendor to underlying infrastructure is a property of the vendor population rather than of any insured, so an insurer can establish it once across a few dozen vendors and apply it to the whole book. An insured would have to establish it for its own vendors and could not use the result for anything else.

‍

What Sources Support That Mapping?

‍

Three, all public, none requiring vendor cooperation.

‍

• Where the service endpoint resolves: Public naming and certificate data indicate the hosting platform and frequently the region.
• Published subprocessor disclosures: Maintained by many vendors to satisfy data protection obligations, which makes them available without any relationship.
• Correlated incident history: Vendors whose status pages show simultaneous degradation share something, whether or not either identifies it.

‍

None of the three is definitive and together they support a probable grouping, which is enough for an aggregation model. Grouping insureds by likely shared dependency and running the portfolio under both independence and full dependency produces the range a capacity decision needs, and aggregating with dependency applied is the mechanism.

‍

What Is the Frequency of a Systemic Model Failure?

‍

Unknown, and stating that is more useful than producing a figure. There is no observed population of foundation model failures affecting many organizations at once.

‍

Cloud outages provide a partial analogue, since the mechanism resembles a regional infrastructure failure and those have a history. Model-specific failures, whether a defect, a degradation or a withdrawal, have almost none. So the honest treatment bounds the scenario rather than estimating its rate, and the useful output is the loss given occurrence rather than the annual likelihood, which a documented aggregation event illustrates for a non-AI mechanism.

‍

Which Changes What the Analysis Answers

‍

From how much to charge to how much to accept. An insurer that cannot estimate frequency can still establish what a single systemic event would cost across the book, and compare that against its appetite for a single loss. The capacity question is answerable without a rate, which is why aggregation work proceeds while the frequency debate continues.

‍

What Should an Insured Do About It?

‍

Volunteer the information, which is unusual advice and follows from the insurer being unable to collect it.

‍

An organization able to show that its AI capability runs across genuinely separate infrastructure, or that its availability-critical workflows have a fallback outside the shared layer, holds a differentiator no questionnaire asks about. In a market where the insurer is grouping insureds by inferred dependency, being able to demonstrate that you sit outside a grouping is worth more than the effort of establishing it.

‍

What Does That Disclosure Contain?

‍

Three things. Which AI providers support availability-critical workflows, which infrastructure each resolves to, and what the fallback is where the shared layer fails. The fallback is the item most organizations cannot answer, and answering it is the substance rather than the paperwork, which evidence assembled before the submission window covers as a general practice.

‍

Does the Same Problem Exist Inside One Insured?

‍

Yes, at a smaller scale, and noticing the parallel is useful because the remedy is the same exercise run over a different population.

‍

An enterprise spreading AI usage across several providers faces the same illusion of diversification, since the vendor list looks varied and the infrastructure underneath may not be. An insurer grouping insureds by shared dependency and an enterprise grouping workloads by shared dependency are performing the same analysis on different units, and both need the layer below the contract.

‍

Which Population Is Easier to Map?

‍

The insurer's, counterintuitively. An insurer maps a few dozen AI vendors once and applies the result across thousands of insureds. An enterprise maps its own handful and cannot reuse the work. So the party with the harder aggregation problem has the easier data problem, which is an argument for the mapping being built where it can be amortized.

‍

Does That Suggest Anything About Where the Data Should Live?

‍

A vendor-to-infrastructure mapping sits closer to market infrastructure than to a proprietary dataset. Every party needs the same mapping, none can produce it reliably alone, and it changes without notice. Whether that arrives through insurers, brokers, modeling firms or a shared utility is an open question, and the absence of it is currently absorbed as unpriced tail risk.

‍

How Does This Interact With Coverage Wording?

‍

Awkwardly, and the interaction is worth understanding separately from the aggregation question.

‍

Whether an AI-caused loss is covered at all is a wording question that has been examined extensively. Whether many such losses arriving together exhaust an aggregate, trigger an event definition or fall within a systemic exclusion is a different question, and the second determines what an insured recovers when the scenario in this article occurs. Whether AI incidents are covered is the prior question and not the same one.

‍

Collect the Layer Below the Vendor

‍

Shared AI dependencies produce simultaneous claims across insureds with nothing else in common, which raises the tail rather than the average and therefore shows up as capacity rather than price. The attribute that would let an insurer see it is not collected, and asking the insured produces the vendor list rather than the infrastructure underneath it. An insurer is better placed to establish that mapping than any individual insured, since the vendor population has to be mapped once. Frequency remains unknown, so the analysis bounds a scenario rather than estimating a rate, and the output is a capacity decision. Kovrr's portfolio risk analysis applies correlation across a book, which is what the aggregation question requires. Cyber risk quantification supplies the per-entity figures the aggregate is built from.

‍

To see portfolio exposure with shared AI dependencies grouped and the correlation assumption stated, book a demo mapped to your own book.