Cyber Insurance for AI Products: What's Covered, What's Not

Cyber insurance generally responds when an AI-enabled product is compromised by an unauthorised third party — think prompt injection that exfiltrates another customer's data, or a breach at an upstream model provider. It typically does not respond when the AI simply performs badly — a hallucinated answer, a biased credit decision, a chatbot giving wrong advice — because that's a performance or professional liability question, not a security incident. Third-party AI vendor breaches sit in a grey zone that depends heavily on how the vendor relationship was disclosed at underwriting. None of this is fixed across the market: policy wording varies by insurer, jurisdiction, and product line, so what follows is a framework for the conversation you need to have with your broker — not a description of any specific policy.

This matters most for CTOs and business leaders at fintech, insurtech, and SaaS companies shipping AI features into regulated or customer-facing workflows, where the gap between what your team assumes is covered and what the policy actually says can be expensive to discover after an incident.

What is cyber insurance, and why does AI change the calculus?

Cyber insurance is a policy that indemnifies an organisation against losses arising from cyber incidents — typically data breaches, network intrusions, business interruption from an attack, and associated liability and regulatory costs. Traditional policies were underwritten against a fairly well-understood threat model: unauthorised access, malware, and human error in handling structured data. AI-enabled products change the risk surface because the "incident" may not involve a hacker at all — it may be the product behaving exactly as designed, but producing an output that causes harm or exposes data. Underwriters are still working out how to price that distinction, which is why coverage language is moving quickly and why last year's policy wording may already be out of date.

Does cyber insurance cover AI model failure?

Whether a policy responds to AI model failure depends on how the loss is characterised, not just on the fact that AI was involved. Insurers generally distinguish between a security incident (something got in) and a performance or quality failure (the model made a bad decision or gave a wrong answer). Many standard cyber policies are structured around the former and are silent, or explicitly exclude, professional liability or product liability exposure arising from erroneous outputs, biased decisions, or a model simply performing poorly.

This matters most for fintech and insurtech companies using AI for credit decisioning, claims triage, or pricing, where a flawed model output can cause direct financial harm to a customer without any breach ever occurring. That kind of exposure sits closer to professional indemnity or technology errors & omissions coverage than to cyber coverage — and whether either responds depends entirely on policy wording, which is why this is a question for your broker on a policy-by-policy basis, not a generalisation you can rely on across the market. Teams building these systems from scratch should treat model risk documentation as part of the engagement from day one — it's a core part of how we approach ai engineering work with clients.

Is data leakage through an LLM covered as a breach?

Data leakage via a large language model can trigger cyber coverage if it meets the policy's definition of a data breach, but the mechanism of leakage matters. A prompt injection attack that exfiltrates another user's data, or a retrieval-augmented generation system that surfaces information it should have access-controlled, can plausibly look like a covered data breach event — unauthorised disclosure of personal or confidential information. The practical difficulty is proving what happened: LLM outputs are probabilistic, logs may not capture the full context window that produced a leak, and organisations without proper data infrastructure and audit trails may struggle to demonstrate to an insurer (or a regulator) exactly what data was exposed, to whom, and how.

Under Australia's Notifiable Data Breaches scheme, administered by the Office of the Australian Information Commissioner, organisations covered by the Privacy Act 1988 must notify affected individuals and the OAIC where a data breach is likely to result in serious harm — and that obligation exists independently of whether your insurance policy pays out. Insurance and regulatory compliance are separate questions that both need answering.

What happens when a third-party AI vendor is breached?

Most AI-enabled products depend on third-party model providers, embedding APIs, or managed ML platforms, and a breach at that vendor can expose your customers' data even though your own systems were never compromised. Cyber policies increasingly include some form of contingent business interruption or supply-chain cover, but the extent to which it extends to AI vendors specifically — as opposed to traditional cloud or SaaS suppliers — is inconsistent across the market and often depends on how the vendor relationship is disclosed at underwriting.

This is a case where your contractual position matters as much as your insurance position. Indemnification clauses, data processing agreements, and audit rights with AI vendors determine whether you can recover costs from the vendor directly, which affects how an insurer views your residual exposure. Organisations that haven't mapped their AI vendor dependencies as part of an ai product strategy engagement often discover these gaps only after an incident, when it's too late to renegotiate terms.

What do cyber policies typically exclude for AI risk?

Across the policies we see referenced in client conversations, three exclusions come up repeatedly, though you should always confirm the actual wording with your broker rather than assume any of these apply to your cover. First, many policies exclude losses arising from "intended" system behaviour — if the model did what it was built to do, and the harm came from a design or training decision rather than an intrusion, some insurers treat that as outside the cyber definition entirely. Second, bodily injury and physical property damage arising from AI-driven decisions (relevant for healthtech and logistics applications) are often carved out of cyber policies and sit under general liability or product liability instead. Third, regulatory fines and penalties are frequently excluded or capped, even where the underlying breach is covered, which matters given the direction of AI-specific regulation in Australia and internationally.

None of this means AI products are uninsurable — it means the insurance conversation needs to happen alongside, not instead of, the engineering decisions that reduce the likelihood of an incident in the first place. Legacy systems bolted onto new AI features are a common source of exposure, which is one reason application modernisation work often surfaces alongside AI risk reviews: a monolith with unclear data boundaries makes it harder to answer an insurer's questions about what data a model could actually access.

How should you prepare before your next renewal?

Start by documenting what your AI systems actually do with data — what they can access, what they log, and what a worst-case output looks like. Bring that documentation to your broker before renewal, not after an incident, and ask directly whether model performance failures, third-party AI vendor breaches, and regulatory penalties are covered, excluded, or silent in your current wording. If you're building new AI capability and want the underlying data and engineering foundations to hold up to that scrutiny, that's exactly the kind of groundwork we work through with clients — you can browse more of our thinking in more insights or get in touch to talk through where your current setup stands.