There is a strange gap in claims technology right now: adoption is nearly universal and production use is nearly absent. Bain’s survey of 160 global insurers found 78% of property and casualty carriers have adopted generative AI while only 4% have scaled it across claims. The same research puts the prize at roughly a 35% productivity gain for carriers that redesigned claims work around it, with homeowners’ claim handling time cut in half.
The technology works and the value is real, yet almost nobody is past the pilot. What stalls is rarely model quality. It is that the pilot was built as a demo rather than a system: no integration path, no way to validate an output, no record an auditor could follow, and no answer for the moment the model is confidently wrong. Carriers that get through treat the following as design decisions before the first use case ships.
Start where no judgment is required
The fastest route past a pilot is work that is repetitive, document heavy, rule driven, and that nobody would call a claims decision: first notice of loss intake, evidence classification and validation, coverage lookup, estimate extraction, adjuster note generation, status updates to the insured, triage routing. None of these decide a claim. All of them consume adjuster hours, and all produce an output you can check against a system of record.
The temptation is to aim at end to end automation, because that is what the category sells. Resist it in the first release. A narrow task with a measurable cycle time reduction gives you a production integration, a control model, and an audit trail you can reuse. The whole claim gives you a long project and no shipped controls.
Put the AI in a layer, not inside the core system
The second decision is architectural, and it usually determines whether a second use case is cheap or expensive.
Build the intelligence as its own layer beside the claims platform rather than inside it. The core stays the system of record; the layer reads from it, proposes or performs specific actions, and writes back through defined interfaces. You then do not have to modernise a legacy core before automating anything, and the same layer serves a dashboard, a copilot, and a batch process without being rebuilt.
Integration depth should follow ambition. A read only point integration is enough for assistive work such as summarisation and lookup. Anything that writes back, spans systems, or runs unattended needs a real integration layer with APIs, middleware, and, where a vendor gives you nothing better, a robotic interface against the screen. That is custom software development in the honest sense, and treating it as a line item in an AI budget is how timelines slip.
Match the model to the task
Not every step needs a language model, and using one everywhere is a quiet source of cost and error. Reasoning heavy steps such as triage, summarisation, and decision support are what large language models are for. Data capture steps such as document classification, field extraction, and visual intake are better served by encoder models and purpose-built extraction. Those models do not reason or draw conclusions, so they cannot invent a policy number that was never on the page. On a document-heavy pipeline that removes an entire class of failure at the point it would be hardest to detect. Planning that split, and where each model is allowed to act, is the core of the AI development engagement, and the part most demos skip.
Design for the model being wrong
Assume a wrong answer reaches production, and build for that moment. This is what separates business automation a claims leader will defend from a tool the floor quietly stops using.
- Ground every generative output in your own data. Retrieval against policy documents, claim files, and guidelines, not the model’s memory.
- Keep agents narrow. Several small agents with defined tools and scope fail more predictably than one agent that does everything.
- Validate deterministically. Check outputs against business rules and the system of record before anything is written or paid. Rules are not a backward step; they make an AI output safe to act on.
- Score confidence and route on it. Low risk and high confidence processes automatically; anything uncertain goes to an adjuster with the reason attached.
- Instrument behaviour continuously. Tracing and evaluation on live traffic, so drift shows up as a metric, not a complaint.
Make every decision reconstructable
A claims decision that cannot be explained afterwards is a liability, however good it was.
Log the source data, the model and prompt version, the output and its confidence score, the rules applied, exceptions raised, human intervention, and the final action. Version prompts and models under production change control, because “which version handled this claim in March” is a question you will be asked.
This is where regulation has landed too. The NAIC adopted its Model Bulletin on the Use of Artificial Intelligence Systems by Insurers in December 2023, and about half of US states and districts have now adopted it in whole or in part. It expects a written program governing AI that supports regulated decisions, plus diligence on third-party data and models. Build the record from the first use case; retrofitting it later is far harder.
Give agents an identity, not a shared key
An AI agent acting on claims is an actor in your environment. Govern it like one.
Put agents inside the existing identity platform with their own credentials and least privilege scoping, so an agent handling auto claims cannot read life files. Mask and redact personal data before it reaches a model or a log. Constrain agents to approved systems and trusted sources, and treat prompt injection and excessive agency as live threats rather than theory: both sit in the OWASP Top 10 for LLM applications. Before any third-party model touches claim data, settle residency, retention, training use, logging, and subcontractor access in the contract. Route agent activity into the monitoring your security team already watches, which is why the cybersecurity review belongs in the plan rather than after go-live.
A realistic shape for the work
The pattern that holds up across carriers runs roughly like this. Two to four weeks of discovery to pick the use cases, write the business rules, map the systems, define the AI metrics and human checkpoints, and settle the architecture, integration, security, and governance models. Six to twenty weeks to take one narrow use case through engineering, integration, testing, controls, and a staged rollout. Then eight to twenty four months to extend across claim types and lines of business, delivered incrementally rather than as one programme. The long number is not a warning; it is what incremental delivery behind real controls looks like.
Where to start
Pick one claim type, one task, one measurable outcome. Build the layer, the validation, and the audit trail around it, then reuse all three. The carriers in the 4% did not find a better model; they built the surrounding system once and kept adding to it.
247 Labs builds that system: the integration layer over the existing core, the agents and extraction pipelines, and the controls that make the output defensible. See our insurance and insurtech work, or get in touch to scope a first use case.
