AI Agents for Subrogation: Finding Recovery Before the File Closes

Most insurers can describe their subrogation process precisely: identify the responsible third party, preserve the evidence, notify, quantify, negotiate, recover. What they can rarely describe is how much recovery never entered that process at all — because the opportunity was not spotted while the file was open, and a closed file generates no report about the money it did not pursue.

That is what makes subrogation an unusually good candidate for agentic automation, and an unusually poor candidate for the “AI handles claims” framing. The bottleneck is not negotiation skill. It is that identifying recovery potential requires reading every file carefully at the moment it is least convenient — during intake, when the operational pressure is to settle the indemnity claim and move on.

The signal is in the file, not in the fields

Subrogation potential is rarely a structured data point. It lives in the loss narrative (“the neighbour’s contractor hit the pipe”), in the estimate line items (a failed component with a manufacturer), in the photographs, in the police or fire report, and occasionally in a contract clause governing who bears which risk.

None of that is queryable. A rules engine over structured claim attributes catches the obvious cases — a multi-vehicle auto loss with a named other party — and misses the ones where the responsible party is described in a sentence rather than recorded in a field. This is precisely the shape of work a language model does well: read unstructured content, look for a specific pattern, and cite the text that supports it.

Design the screen around three questions the agent must answer with evidence:

• Is there a third party? A person, contractor, manufacturer, carrier, or property owner whose act or product plausibly contributed to the loss.
• Is there a route to them? An identity, an insurer, a policy, a contract, a warranty — something that makes recovery mechanically possible rather than theoretical.
• Is there anything time-critical? Physical evidence that will be repaired or discarded, a limitation period, or a contractual notice deadline.

The third question matters most. Recovery is usually lost not because nobody considered subrogation but because by the time somebody did, the damaged component had been scrapped and the repair completed.

Where the agent adds value, step by step

At first notice. Screen every new claim, not a sample. Produce a recovery flag with a short rationale and a citation into the source text. Cheap, high-volume reading is exactly what a local model is for, and the screen runs regardless of how busy intake is that morning.

On evidence preservation. When the screen fires and the loss involves a physical component, the time-critical action is a preservation instruction before repair or disposal. An agent can draft the preservation notice, identify who must receive it, and raise the task — while a person sends it.

On file assembly. When a recovery file is opened, the agent compiles the pack: loss narrative, damage evidence, payment ledger, policy provisions, correspondence, and the identified third party with supporting citations. This is assembly of material that already exists, and it is where most of the specialist’s clerical time goes today.

On deadline tracking. Limitation periods vary by jurisdiction, cause of action, and party. An agent that monitors open recovery files against a maintained deadline table turns a memory problem into a monitored one — the table being human-maintained reference data, not something the model should infer.

On closed-file review. A one-off pass over recently closed claims tests the screen against reality and finds recoveries still within their limitation period. It is also the most honest way to size the opportunity before committing to the workflow.

The decisions that stay with people

Pursuit is a commitment. It spends money, takes a position on another party’s liability, and can lead to litigation or to a dispute with a policyholder about their deductible. That decision belongs to a recovery specialist, and the agent’s output should be shaped to support it rather than to pre-empt it: a recommendation, a confidence, the evidence, and the specific reason the file was flagged.

Two adjacent lines matter as much. First, the agent should not communicate externally — no notice to a third party or their insurer without a person sending it. Second, nothing in the recovery screen should feed back into a coverage or claims-handling decision for the policyholder; a subrogation flag is about a third party’s responsibility, not about whether the insured is paid. Keep the workflows separated in both design and access, and say so in the documentation.

Governance and the audit trail

Insurance supervisors have moved from asking what an insurer’s AI policy says to asking what it can evidence. The NAIC’s Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted in December 2023, sets expectations for how insurers govern AI use and describes the information departments may request during an investigation or examination — including where the capability comes from a third party. Adoption and examination practice vary by jurisdiction, so confirm what your own supervisors expect rather than assuming one national standard.

In the EU, the AI Act’s Annex III treats risk assessment and pricing in life and health insurance as high-risk, and the application date for stand-alone Annex III systems moved to 2 December 2027 under the 2026 digital omnibus. A subrogation screen is a recovery workflow rather than a pricing or underwriting-risk system, and classification of any particular system is a determination for your legal and compliance function — but the documentation and oversight capability is worth building now either way.

For each flagged file, retain the model and prompt version, the source text cited, the confidence and threshold applied, the specialist’s decision, and the outcome. That record is what lets you answer the two questions that follow any deployment: is the screen working, and can you show how a given file was handled.

Why this workload stays inside the boundary

A subrogation screen reads the most sensitive material in the claim file — loss narratives, medical references, photographs, adjuster notes, and third-party identities. It reads all of it, for every claim, continuously. That is a materially different exposure profile from an assistant a handful of specialists query occasionally.

Running the models inside your own infrastructure keeps prompts, retrieved documents, embeddings, tool outputs, and audit logs within your residency and retention regime, and lets security treat the screen as an internal system rather than an outbound integration. It also makes the economics of screening every claim tractable: a small local model reading short excerpts is a very different cost line from a per-token external call on every file.

How VDF AI supports recovery workflows

In a VDF AI Solution deployment, the screen is an orchestrated workflow over governed components: a local model for reading and classification, private RAG over policy wordings and recovery procedures, purpose-built read tools against the claims and document systems, a maintained deadline reference, and an explicit approval step before any external action. Ask for a demonstration on your own closed files before scaling — the closed-file pass is both the proof and the business case.