Subrogation is where your AI vendor contract meets your insurance policy

Section 1. The mechanic, and why it is invisible

Subrogation sits at the end of the claims process, which is why it is the part of insurance that operators know least about. The sequence is simple. A claim is made against your organisation. Your insurer investigates, defends, and eventually pays. Having paid, the insurer acquires your rights against any third party who was responsible for the loss, and may pursue them in your name to recover what it paid out.

The economics of this are worth stating plainly, because they explain why an underwriter cares about a document that has nothing to do with insurance. An insurer prices net exposure. If a class of loss is reliably recoverable from a well capitalised third party, the insurer's true cost is lower than the gross claim, and the premium reflects that. If a class of loss is not recoverable from anyone, the insurer absorbs it in full, and the premium reflects that instead. Recovery prospects are a pricing input, not an afterthought.

For most established liability lines this works quietly and predictably. A defective component that caused a fire has a manufacturer, a supply contract, product liability law and usually an insurer of its own. The chain is well trodden.

For AI it is not, and there are five distinct reasons why.

Section 2. The cap you already agreed

The first and most consequential is the simplest. A subrogated insurer generally takes the insured's rights as they are, subject to the same terms and the same defences the third party could have raised against the insured. It does not acquire better rights than you had.

Enterprise software agreements have converged on a familiar limitation structure: aggregate liability capped by reference to fees paid over some preceding period, indirect and consequential loss excluded, and a set of carve-outs for confidentiality, data protection and sometimes intellectual property indemnities. That structure was designed for a world in which a software failure meant downtime, and downtime meant an outage credit.

Applied to an agent that gives advice, prices contracts, screens applicants or moves money, the same structure produces an awkward result. The loss an agent can cause bears no relationship to what the agent costs. An organisation paying a modest annual subscription for a model API can generate a seven figure liability through it in a fortnight. The cap does not scale with the exposure because nothing in the pricing model was ever asked to.

The exclusion of indirect and consequential loss compounds it. Most AI liability claims are, in contractual terms, exactly the kind of loss that exclusion is aimed at: lost profit, third party claims, remediation cost, regulatory expense. A cap that looks negotiable and an exclusion that looks standard can between them remove almost the entire recovery.

Section 3. The clause that can breach your own policy

The second reason is a live compliance risk rather than a pricing one, and it runs in the opposite direction to the one operators expect.

Liability wordings commonly contain a condition requiring the insured to preserve rights of recovery, to do nothing that prejudices the insurer's subrogation rights, and to cooperate in pursuing them. Against that, a growing proportion of AI and platform agreements contain a waiver of subrogation, a covenant not to sue, a release extending to affiliates and subprocessors, or an exclusive remedies clause that forecloses claims outside the contract.

Where such a term is agreed before the policy incepts and is disclosed, an insurer will usually accept it, having priced accordingly. Where it is agreed during the policy period, without the insurer's knowledge or agreement, it can engage the condition. The consequences vary by wording and by governing law, and they range from a reduction in the amount payable to a defence to the claim itself.

The structural problem is organisational rather than legal. The person who signs a software agreement and the person who completes an insurance proposal usually sit in different functions, use different systems, and have never had reason to read each other's documents. Nobody is behaving badly. The failure is that no process connects the two, and the connection point is a single question that takes a minute to ask.

Section 4. Who exactly would you be pursuing

The third reason is that AI deployments rarely have one supplier. A representative chain runs: a foundation model provider, a platform or orchestration layer that packages the model, sometimes an integrator or consultancy that built the deployment, one or more tool and data providers the agent calls, and your own configuration sitting on top of all of it.

Each link has its own contract, its own cap, and its own exclusions. The caps do not aggregate in your favour. In practice recovery has to be pursued link by link, and each link can point at the one above or below it, which is expensive before it is anything else.

The regulatory framing of who occupies which role in that chain sits on agentliability.eu, on Article 25 and value chain responsibilities, and the liability question in the abstract is treated at agentliability.co, on foundation model provider against deployer. What the contract layer adds to that analysis is a hard ceiling that regulatory allocation does not touch. Establishing that a provider bears responsibility is one question. Establishing that anything can be recovered from it is a different one, answered by a document your legal team already signed.

Section 5. The evidence problem, and who holds it

The fourth reason is proof. Even with recovery rights fully intact and a generous cap, a subrogated claim has to establish that the third party caused the loss. For an AI failure that means answering questions about behaviour inside a system you do not operate.

Did the model change. Was a safety behaviour altered. Did a documented capability regress. Was there a known defect at the time. These are answerable questions, and the answers sit with the provider, who is the defendant in the recovery action and has no reason to volunteer them.

What partially closes this gap is your own record of the boundary between your system and theirs. An operator who can show, with dates, that no prompt, no retrieval source, no tool permission and no configuration on their side changed in the window in which the behaviour changed, has isolated the variable that did. An operator who cannot show that has no case, because the most likely explanation for a behaviour change is a change somebody made, and in the absence of records the somebody is presumed to be you. The discipline this requires is the same one certification assessments look for, treated at agentcertified.eu, on change control as certification evidence.

It is worth being direct about the asymmetry. Provider-side changes that nobody announced are among the more common causes of an agent quietly starting to behave differently, and they are also the hardest thing in this entire analysis to prove after the fact. A contractual right to model version information and to change notification is worth more at recovery stage than several million of nominal cap.

Section 6. What European law adds, and what it does not

Two instruments are routinely cited as though they solve this, and the honest position on both is narrower than the citation implies.

The revised Product Liability Directive. Directive (EU) 2024/2853 was published in the Official Journal on 18 November 2024, entered into force on 8 December 2024, and must be applied by Member States from 9 December 2026, repealing Directive 85/374/EEC with effect from the same date. It treats software as a product for strict liability purposes, which is genuinely significant, and it opens a route that does not depend on proving fault.

The limit is the damage it covers: death or personal injury, damage to property, and destruction or corruption of data. Read that list against the AI claims that actually arise. A price honoured that should not have been. A recommendation acted on that was wrong. A screening decision that produced a discrimination claim. A regulatory penalty. A contract mispriced across a quarter. None of those is death, personal injury, property damage or data destruction. They are pure economic loss, and the Directive does not reach them. Where an AI failure does cause physical harm or destroys data, the route is real and worth pursuing. For the modal AI claim it is not available at all. Our readiness treatment is at the Product Liability Directive and AI coverage readiness.

The AI Liability Directive that is not coming. The instrument that would have addressed fault-based AI claims, including presumptions of causation and disclosure obligations that would have helped precisely with the evidence problem above, was proposed as COM/2022/496 on 28 September 2022 and has been withdrawn. The withdrawal was signalled in the Commission work programme, COM(2025)45 final of 11 February 2025, Annex IV, and the formal withdrawal notice was published in the Official Journal on 6 October 2025 as C/2025/5423. No replacement has been adopted. Fault-based AI claims across the Union therefore proceed under national law, which differs materially between Member States on causation, on disclosure and on the availability of pure economic loss recovery.

The practical consequence for a subrogating insurer is that the recovery analysis is jurisdiction-specific in a way that the underwriting was not. A pan-European deployment with a single policy can produce recovery prospects that vary by the Member State in which the loss landed.

Section 7. Six things to establish at contract stage

All six are answerable from documents you already hold, by somebody willing to read the vendor agreement and the policy in the same sitting.

1. What is the aggregate liability cap in each AI vendor agreement, how is it calculated, and how does it compare to the largest single loss that deployment could produce?
2. Does any agreement contain a waiver of subrogation, a covenant not to sue, an exclusive remedies clause, or a release extending to affiliates and subprocessors?
3. Does our liability policy contain a condition on preserving rights of recovery, and would any term identified in question two engage it?
4. Which of these agreements were signed before the current policy incepted, and were any of them disclosed in the proposal?
5. What is the vendor obliged to tell us after an incident, and does that obligation extend to model version history, change notification and the results of its own investigation?
6. For a loss occurring in each Member State where we deploy, what is the realistic recovery route, and does it depend on damage types the Product Liability Directive does not cover?

An organisation that can answer all six is in a materially better position at quotation, because it can describe its net exposure rather than its gross one. That is a more attractive risk to write and a more defensible one to price. What a full submission looks like is set out in preparing an AI agent underwriting submission, and the questions underwriters are asking are in what underwriters ask before writing a policy.

Section 8. The point in one sentence

Insurance moves a loss from your balance sheet to an insurer's, and subrogation is the mechanism that can move it one step further, to whoever actually caused it. Every clause that shortens that second step leaves the loss with the insurer, and an insurer that cannot recover charges the organisation that could not preserve the right. The vendor agreement is therefore an insurance document, whether or not anyone treated it as one when it was signed.

Section 10. Sources