AI and Insurance Coverage: What Policies Actually Cover

AI incidents do not map neatly onto existing insurance categories, which leaves gaps organisations discover at claim time rather than at renewal. This guide covers which policies respond and what to check now, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal or insurance advice.

Which policy responds to which incident?

Broadly three categories, with the most likely AI failure sitting awkwardly between them.

Incident	Likely policy
Data breach through an AI system	Cyber
Prompt injection causing unauthorised action	Cyber, possibly
Wrong advice to a client from AI output	Professional indemnity
Product defect in AI-enabled software	Technology errors and omissions
System simply wrong, causing loss	Potential gap
Discrimination claim from AI decision	Employment practices, possibly

What is the common gap?

A system producing wrong output that causes loss, without a security breach, a professional service failure, or a defined product defect.

That is the most likely AI incident and the one least clearly covered. An assistant that gives a customer wrong information about their entitlements, at scale, produces loss through a route that traditional wordings did not contemplate. Ask your broker specifically about that scenario rather than about AI in general.

Are AI exclusions appearing?

In some markets, yes, with wordings varying considerably. Some address generative AI specifically, others autonomous decision-making, and others sit in cyber wordings as carve-outs.

Read the actual policy. Broker summaries and marketing material are not the contract, and the distinction matters at claim time rather than at renewal.

What does disclosure require?

Insurers increasingly ask about AI use, and answers given at placement matter.

An organisation that said it did not use AI in decision-making, and does, has a disclosure problem separate from the coverage question. Establish an accurate internal picture before the next renewal — which requires the inventory that every other governance activity also depends on. See what is an ai inventory.

What evidence do you need?

Policy wordings with AI-relevant clauses identified, records of what was disclosed to insurers about AI use, incident records that would support a claim, and evidence of the controls insurers expect.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes incident recording and control evidence into operations. A claim depends on being able to show what happened, when, what the system did, and what controls were in place.

Systems that cannot reconstruct an incident — because trajectories were not recorded or logs rotated too quickly — make claims harder to substantiate regardless of the policy wording.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Assuming cyber cover extends to wrong output. Relying on broker summaries rather than wordings. Answering placement questions without an accurate inventory. And retaining logs for less time than a claim would need.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this affect vendor contracts?

Directly. Where a supplier's system causes loss, the contractual allocation and their insurance both matter, and a supplier without appropriate cover is an unmitigated exposure regardless of what the contract says.

Ask suppliers what cover they carry and whether it responds to AI incidents specifically. Suppliers who have thought about it answer clearly; those who have not reveal something useful by hesitating.

What should you do first?

Ask your broker how your current policies would respond to an AI system giving customers wrong information at scale. The answer is usually less reassuring than expected.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: incident trajectories recorded and retained long enough to substantiate a claim, control evidence maintained as operations run, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and product liability.