Insurance for AI Systems, in depth: silent AI, the 2026 generative AI exclusions, affirmative cover and a loss-scenario register

Why AI losses fall between policies

Insurance is sold by line, and each line was written with a particular cause of loss in mind. AI failures do not respect those boundaries. Consider who is harmed and how.

The market calls the resulting uncertainty silent AI: a policy that neither grants nor excludes AI-caused loss, so nobody knows whether it pays until a claim is litigated. The term deliberately echoes silent cyber, the same ambiguity a decade ago when property and liability policies were silent about cyber attacks. Insurers resolved silent cyber by writing explicit exclusions into old lines and selling affirmative cyber policies. The same two moves are now under way for AI.

What changed in the market

Exclusions. On 1 January 2026, Verisk's ISO program made three optional generative AI exclusion endorsements available for commercial general liability: CG 40 47 excludes bodily injury, property damage and personal and advertising injury arising out of generative AI under Coverages A and B; CG 40 48 excludes only personal and advertising injury under Coverage B; and CG 35 08 applies to the products and completed operations coverage part. They are optional, so whether your general liability policy carries one depends on your carrier, your state and your renewal date. The practical consequence is that you must read the endorsement schedule at every renewal, not only the base form.

Affirmative cover. On 30 April 2025, Armilla announced an AI liability policy underwritten by Lloyd's underwriters including Chaucer, a standalone third-party liability product that names AI failures such as hallucinations, model drift and mechanical underperformance as covered events. Earlier products took a warranty approach instead: Munich Re's aiSure, for example, insures a model's performance against an agreed metric, so the payout is triggered by measured underperformance rather than by a lawsuit. Treat both approaches as specialist products: limits, retentions and exclusions differ considerably, and their wording deserves the same review as any other contract.

Vendor indemnities. In 2023 several large model providers, including Microsoft, Google and OpenAI, announced copyright indemnities for some paid offerings, typically conditioned on using the provider's safety filters and not deliberately prompting for infringing output. These are contract terms, not insurance, and they sit inside the provider's limitation-of-liability clause unless stated otherwise. They move part of the IP scenario off your balance sheet, but only for the products and conditions named.

A loss-scenario register in code

The most useful artifact you can build is a loss-scenario register: a short list of concrete failures, each with an estimated frequency and severity, mapped to the policy or contract that is supposed to pay. Keep it in version control next to your risk register so it changes when the system changes. The script below flags three kinds of gap: no responding line, an exclusion on the responding line, and a severity that exceeds the limit available after the retention.

from dataclasses import dataclass, field

@dataclass
class Policy:
    name: str
    limit: float           # aggregate limit available to this scenario
    retention: float       # deductible or self-insured retention
    exclusions: set = field(default_factory=set)

@dataclass
class Scenario:
    sid: str
    description: str
    per_year: float        # expected events per year
    severity: float        # plausible bad-case cost of one event
    lines: list            # policy names expected to respond
    tags: set              # e.g. {"genai", "contractual", "fines"}

def assess(scenarios, policies):
    rows = []
    for s in scenarios:
        responding = [policies[n] for n in s.lines if n in policies]
        live = [p for p in responding if not (p.exclusions & s.tags)]
        if not responding:
            gap = "NO LINE"
        elif not live:
            gap = "EXCLUDED"
        elif s.severity > max(p.limit for p in live) + min(p.retention for p in live):
            gap = "OVER LIMIT"
        else:
            gap = "ok"
        retained = min((p.retention for p in live), default=s.severity)
        rows.append((s.sid, gap, round(s.per_year * min(retained, s.severity))))
    return rows

The third column is the expected cost you carry yourself each year: frequency times the part of each event that falls inside the retention, or the whole event if nothing responds. Summed across scenarios, it is the number to put beside the premium when you decide whether to raise or lower retentions.

Worked example: an LLM support agent

Take a mid-sized software company with an LLM support agent that answers billing questions, can issue refunds up to a cap through a tool, and drafts help-centre images. It holds cyber with a 5 million limit and a 250,000 retention, tech E and O with a 3 million limit and a 100,000 retention whose wording excludes liability assumed under contract, and general liability that renewed with the CG 40 47 endorsement. It has no media liability policy. The register, with deliberately rough numbers, looks like this.

Three findings fall out immediately. S1 is a frequency problem, not an insurance problem: every event sits under the E and O retention, so the fix is an output guard that checks refund statements against the policy table before they are sent, the lesson of the 2024 Moffatt v. Air Canada decision, where a tribunal held the airline liable for a bereavement-fare rule its chatbot had misstated. S3 needs either a vendor indemnity, a media policy that affirmatively names generated content, or a rule that generated images pass a similarity check. S4 is your own money leaving through your own tool, which liability policies do not cover at all; crime or a first-party AI performance product might, so ask. S5 is the case the new exclusions were written for, and it is exactly the scenario an affirmative AI liability policy exists to pick up.

The evidence underwriters want

Underwriters price what they can see. A submission that says 'we use GPT-class models responsibly' gets a conservative quote or a declination; a submission with evidence gets a real one. The good news is that the evidence is the same artifacts a sound security and governance program already produces.

The logging row deserves emphasis because it is the one most teams cannot produce after the fact. A claim may arrive months after the conversation; if you cannot show the exact model version, system prompt and retrieved documents, you cannot defend it and the insurer cannot assess it. The design for that trail is in LLM audit logging architecture, and mapping your controls to a recognised framework such as the NIST AI RMF gives the underwriter a vocabulary they already use.

Claims mechanics that decide coverage

Most coverage disputes are lost on procedure, not on substance. Four mechanics matter for AI incidents.

1. Claims-made triggers. Cyber and E and O are usually claims-made: the policy in force when the claim is first made responds, provided the incident happened after the retroactive date. Switching carriers without preserving the retroactive date can leave every earlier conversation uninsured.
2. Notice of circumstances. If you discover the agent has been quoting a wrong policy for six weeks, you may be required to notify the insurer before any customer complains. Late notice is a standard defence.
3. Consent to settle. Paying customers goodwill credits to make a problem go away can be treated as a voluntary payment the insurer never approved. Agree a protocol with your broker in advance.
4. Evidence preservation. Freeze logs, prompts, model versions and retrieval indexes for the affected window before anyone 'fixes' the prompt. The same step belongs in your incident playbook; see LLM incident response.

Failure modes

• Reading the base form only. The generative AI exclusion arrives as an endorsement at renewal, and the schedule of forms is where it hides.
• Assuming the vendor's indemnity is unlimited. Indemnities typically sit under the provider's overall liability cap and carry conditions such as keeping safety filters enabled.
• Insuring frequency losses. Small, frequent errors under the retention are an engineering budget item; buying lower retentions to cover them is expensive.
• Forgetting first-party loss. Liability policies pay third parties. Money your own tool pays out by mistake needs a different product or a hard control.
• Misstating the application. Describing an autonomous agent as 'human reviewed' when review is sampled can give the insurer grounds to rescind.
• No change trigger. Adding a new tool such as payments to an agent changes the risk materially; some policies require disclosure of material changes.

Trade-offs

There is no single right structure, only a set of deliberate choices.

In practice the order of operations is: remove what you can with controls, transfer what you can by contract, insure the severe and unpredictable remainder, and retain the rest on purpose. The legal theories behind the claims themselves are covered in AI Liability.

What to do next

1. List every AI feature in production with what it can say, decide or do, and who is harmed if it is wrong.
2. Write five to ten concrete loss scenarios with rough frequency and severity, and run them through a register like the one above.
3. Pull every current policy and its full schedule of endorsements; search for generative AI exclusions, including the ISO CG 40 47, CG 40 48 and CG 35 08 forms.
4. Ask your broker, in writing, which policy responds to each scenario, and record the answer next to the scenario.
5. Collect vendor contracts and note each indemnity, its conditions and the liability cap it sits under.
6. Close the cheapest gaps with controls first, such as output checks against policy tables and caps on tool actions.
7. Assemble an underwriting evidence pack: inventory, evaluation results, logging design, incident drills and change log.
8. Add 'notify the insurer?' and 'preserve evidence' as explicit steps in your AI incident runbook.
9. Re-run the register whenever an agent gains a new tool, a new model, or a new class of user.