Sector note · Insurance

Insurance's AI money is in subrogation, not the chatbot

Carriers are spending their AI budget on the part of the claim the customer can see. The recoverable money sits in the files they have already closed, and nobody is paid to go and find it.

Alphaweb sector note

The value is on the other side of the ledger

The quiet side of the ledger holds more money than the FNOL chatbot, and nobody is measured on it.

Ask an insurance executive where AI belongs and the answer arrives quickly: first notice of loss. Shorten the call, shorten the cycle time, shorten the handling cost. It is a defensible answer, it is where most of the budget has gone, and it is also the part of the business with the thinnest tolerance for error and the loudest audience.

The larger and quieter number sits on the other side of the ledger. Research published in the NAIC's Journal of Insurance Regulation found that salvage and subrogation represent 4.5% of net claims paid across the full sample, but that for liability lines the ratio collapses: an average of 1.1% for commercial auto liability and 2% for personal auto liability. The same paper also carries a trade-press estimate that put missed subrogation opportunities at $15 billion annually (Harman, PropertyCasualty360, 2021, as cited in the NAIC paper). That money is not lost to catastrophe or to fraud. It is lost because nobody read the file closely enough, early enough, to notice that somebody else was liable.

The asymmetry of attention is easy to explain. A chatbot on the FNOL line is visible to the board, to the broker and to the customer. A subrogation referral that never happened is visible to no one. An adjuster is measured on files closed and on cycle time, and a recovery referral makes both of those numbers worse today in exchange for cash that lands in another team's ledger eighteen months from now. This is not a technology gap. It is an incentive gap that happens to have a technology-shaped hole in it.

A missed subrogation referral is not a loss the carrier suffered; it is a dollar the carrier already earned and simply failed to collect.

Why the work suits software that acts

Insurance work is document work, so software that reads, decides within a boundary and shows its trail fits.

Insurance is one of the few industries where the process is literally a document. A claim file is a police report, a repair estimate, a medical narrative, a set of photographs, a recorded statement transcript and a policy wording. A commercial submission is an ACORD application, five years of loss runs, a statement of values and a broker's covering email that contradicts two of them. The work is not creative. It is the disciplined application of a known rule set to evidence that is scattered across three systems and one inbox, followed by a written justification that somebody senior can check.

That shape suits software that can read, compare, decide within a boundary and show its reasoning — much better than it suits a model that emits a score. It also fits the sector's regulatory posture. EIOPA's Opinion on AI governance and risk management, published in August 2025, asks that undertakings "keep appropriate records of the training and testing data and the modelling methodologies to enable their reproducibility and traceability". For an opaque scoring model, that obligation is expensive and never quite satisfied. For a system whose work is an ordered sequence of retrievals and tool calls against named documents, the audit trail is a by-product rather than a project.

The corollary matters as much. Work that depends on a conversation the software cannot have, or on judgement the file does not contain, does not fit. Reserving philosophy, complex bodily injury valuation and coverage denial on ambiguous wording stay with people. The defensible territory is the reading, the reconciling and the drafting that currently consumes the first two hours of an adjuster's or an underwriter's day.

The three processes that go first

Subrogation, submission triage and intake go first because being wrong there costs money, not policyholders.

The sequencing principle is simple: start where a mistake costs money rather than a customer. Subrogation referral, submission triage and claims intake completeness all share that property. A missed recovery is a forgone dollar. A slow quote is a lost account. An incomplete first file is rework. None of them produce a wronged policyholder if the software is wrong, and in all three a named human still signs the consequential decision.

Fraud detection is the obvious omission, and it is deliberate. Fraud is the use case with the loudest vendor noise and the worst first-project characteristics: a false positive lands on a real customer, the fairness question bites hardest there, and most carriers already run a special investigations unit with a scoring model and years of tuning behind it. Adding an agent to that estate is a year-two project undertaken with the model risk function in the room, not a proving ground. EIOPA names fraud detection explicitly among the use cases it expects supervisors to scrutinise, and it is easier to have that conversation once you have already shown a supervisor a clean audit trail from a lower-stakes process.

What actually stops these projects

These projects fail on ownership, adjuster incentives, misfitted model governance and dirty retrieval.

The first obstacle is ownership. In most carriers, recovery sits between claims operations, the subrogation vendor and finance, and the number appears in nobody's objectives. Until one named executive owns the recovery ratio and can be shown the before-and-after, an agent that produces excellent referral memos will produce them into a queue nobody works. Buy the sponsor before you build the software.

The second is the adjuster's incentive, which is worth stating plainly rather than designing around. If your desk staff are measured on files closed per week, every referral the agent raises is a tax on the person who has to action it. Carriers that get this right change the measure before they deploy, and they usually find that the change alone moves the number a little, which is awkward but honest.

The third is governance built for the wrong object. Model risk frameworks in insurance were designed for pricing and reserving models: a fixed artefact, validated once, monitored for drift. They do not know what to do with software that takes actions against live systems. The Bank of England and FCA survey of AI in UK financial services found the insurance sector reporting the highest adoption of any sector at 95%, while 46% of firms across the survey reported only "partial understanding" of the AI technologies they use and a third of use cases were third-party implementations. That combination — high adoption, partial understanding, external dependence — is exactly what a supervisor reads as a warning.

The fourth is technical, and it is not the one people expect. The bottleneck is retrieval, not reasoning. The evidence lives in a document management system where the metadata is wrong, half the medical records are scanned faxes, the policy wording is a PDF of a PDF and the claims system holds a free-text note field that contains the only record of the third party's insurer. Expect the connector and extraction work to consume more of the budget than the agent itself, and expect the first sixty days of output to be worse than your weakest adjuster. Deloitte's 2026 global insurance outlook also reports that only 25% of respondents have taken tangible action to elevate human skills, which is the quiet reason many pilots stall at the handover rather than the build.

A ninety-day sequence

Ninety days settles the question only if the adjudicated evaluation set is built before the agent.

Ninety days is enough to know whether this works in your estate, and not enough to deploy it across a book. The sequence below assumes one line of business, one queue and one named owner. It puts the evaluation set before the build, which feels backwards and is the single decision that most reliably separates a pilot that ends in a decision from one that ends in a demonstration.

The uncomfortable part is step two. Assembling a few hundred closed files with human adjudication costs real time from senior people who have other work, and there is no way to buy it in. Carriers that skip it end up arguing about whether the output is good, with no instrument to settle the argument, which is how pilots die politely.

What it is worth

Do the arithmetic on your own recovery ratio instead of trusting anybody's quoted uplift percentage.

We will not give you a percentage. Any figure quoted as a universal uplift is a figure someone made up, because the answer depends almost entirely on where your baseline sits, and baselines in this sector vary by an order of magnitude between carriers writing the same risks.

The arithmetic you can do yourself is more useful than any benchmark. Take your net claims paid for one liability line. Apply your current recovery ratio — it is in your own statutory filings, and if the honest number is closer to 1% than to 4%, that is the finding. Then ask what a two-point improvement in referral rate would be worth, and what proportion of referrals your recovery function actually converts, because an agent that doubles referrals into a team with no capacity to pursue them is a cost, not a saving. The same discipline applies to submission triage: the value is quote turnaround and hit rate on the accounts you want, not underwriter headcount, and a carrier that treats it as a headcount play will get a worse book.

Alphaweb is a young studio. We have not run this at your scale and we will not pretend otherwise. What we can say is that this class of work — reading the file, applying the rule, writing the justification, leaving the trail — is the part of insurance where software that acts has a real claim, and that the projects which fail here fail for organisational reasons that are visible in the first fortnight if you look for them.

A ninety-day sequence that survives contact

1. Days 1-15 — Pick one queue and write down the baselineOne line of business, one claims or underwriting queue, one named executive who owns the outcome number. Extract the current referral rate, conversion rate and cycle time from your own systems and put them in a document everyone signs. Without a written baseline there is nothing to argue against in ninety days, and the pilot will be judged on anecdote.
2. Days 10-30 — Build the evaluation set before the agentTake 200 to 400 closed files, spanning good and bad outcomes, and have two experienced adjusters or underwriters independently adjudicate each one: referable or not, and why. Reconcile the disagreements. This set is the instrument for every decision that follows, and it is the step that carriers skip and then regret.
3. Days 25-50 — Wire retrieval, read-onlyConnect the document management system, the claims or policy administration system and the shared mailbox in read-only mode. Solve the unglamorous problems first: OCR on scanned correspondence, wrong document-type metadata, free-text note fields. Expect this to take longer than building the agent and budget accordingly.
4. Days 45-70 — Run it shadow-side against the panelThe agent works the live queue and writes its memos into a holding store that nobody actions. Score its output against the adjudicated set and against the panel's own disagreement rate, which is the real ceiling. Examine the declines as carefully as the referrals, because a quiet under-referring agent looks excellent on precision and is worthless.
5. Days 70-90 — Switch on for one team, and instrument itOne team, one queue, human sign-off on every referral and every submission decision. Log each action, each retrieval and each override with its reason, and review the overrides weekly. At day ninety you should be able to answer three questions in front of your model risk function: what it changed, what it got wrong, and what it cost.

What we read

The documents behind this note. Each entry says what it is, what it found, and why it should change what you do — then the link to the original.