How I Would Build an AI-Native Insurance Claims System

Direct Answer

An AI-native insurance claims system is a coordination layer that captures a claim as structured data at first notice of loss, validates coverage automatically, and routes each claim to the cheapest correct path — straight-through settlement for routine cases, a pre-built case file for a human adjuster on everything else. It treats claims handling as a routing problem, not a document-collection problem.

Key Takeaways

• The old claims route is a document-collection relay: first notice of loss, adjuster assignment, email PDFs, manual coverage checks, manual fraud screening, manual settlement math.
• Most of that relay exists because legacy policy admin systems can’t ingest structured data at the point of loss, not because a human needs to read every PDF.
• An AI-native route validates coverage and extracts evidence at first notice of loss, then triages: routine claims settle straight-through, everything else gets a pre-built case file instead of a stack of email attachments.
• Regulators, not the model, set the human boundary. The NAIC Model Bulletin and a growing list of state laws require a human in the loop before an AI-influenced denial or adverse decision.
• The bottleneck is rarely the model. It’s whether the carrier’s core claims system exposes an API at all — if it doesn’t, this is a systems-integration project, not an embedded AI build.

What problem does this system actually own?

A claim is not one document. It’s five or six people each holding a fragment of the same fact, and no shared record until someone re-types all of it into the same place.

The policyholder holds the loss: what happened, when, what it looks like. The agent or call center holds the intake. The adjuster holds the policy interpretation. The repair shop or medical provider holds the cost estimate. Underwriting holds the actual coverage terms, sometimes in a different system than the one the adjuster is looking at. Special investigations holds the fraud signal, usually reviewed after the fact rather than at intake.

None of those people are slow. The relay between them is slow, because each handoff is a re-explanation: a phone call becomes a note, a note becomes an email, an email becomes a PDF attachment, a PDF becomes a manual entry in the claims system. The coordination layer is the product, the same way it was for freight booking or property due diligence. The claim itself is rarely complicated. Getting five systems and five people to agree on the same set of facts is.

The existing workflow I would map first

This is the route I’d expect to find at a mid-size carrier still running a core policy admin system from before 2010, which describes most of the US market:

1. First notice of loss (FNOL). The policyholder calls, emails, or occasionally uses a mobile app. A call-center rep or agent keys the basics into the claims system by hand. Multi-channel intake exists because carriers never fully retired the older channels — an 80-year-old policyholder and a 25-year-old policyholder do not report a claim the same way, and neither should be blocked.
2. Adjuster assignment. The claim is routed by rough rules — geography, line of business, current caseload — not by actual complexity, because complexity isn’t known until someone has read the file.
3. Document collection. The adjuster requests a police report, photos, repair estimates, or medical bills. These arrive as email attachments, scanned PDFs, or fax. This step exists partly for evidentiary reasons — a claim file has to hold the underlying documents, not just a summary — and partly because there’s no shared upload channel that both the policyholder and the carrier’s core system can use.
4. Manual review and re-keying. The adjuster reads the documents, checks policy coverage (sometimes by calling underwriting or opening a second system), and manually estimates the loss or schedules an in-person inspection. Legacy claims systems built in the 1990s and 2000s were never designed to ingest images or PDFs as structured data, so a human has to translate paper into fields.
5. Fraud screening. Special investigations units apply rules-based flags and spot-check a subset of claims, because full manual review of every claim isn’t staffable. This step exists because the cost of missing fraud is asymmetric — cheaper to over-flag than under-flag — and because a false accusation carries legal exposure.
6. Negotiation and settlement. The adjuster and the policyholder or repair shop go back and forth by phone and email on the estimate. This step exists because a first estimate is frequently wrong, and correcting it requires someone empowered to change a number.
7. Approval and payment. A supervisor sign-off is required above a threshold. This step exists because claims payment is a licensed act in most US states — public adjuster and claims-adjuster licensing laws put a name on who is allowed to determine and approve a settlement, and that name has to be accountable for it.
8. Records re-entry. Whatever was on paper or in an email now gets typed into the claims system as a permanent record, often for the second or third time in the same claim’s life.

McKinsey’s research on the industry notes that adjusters already spend most of their time on complex, high-stakes claims while more than half of claims processing activity is handled by some form of technology — which tells you the routine half of this workflow is already the automation target, not a hypothetical one.

How the system would run

The shift isn’t adding a chatbot to step 3. It’s moving structured capture to step 1, so steps 3, 4, and 8 mostly stop existing.

At first notice of loss, a guided intake — not a free-text box — captures photos, video, and structured answers, and checks policy coverage, dates, and exclusions against the policy record in the same interaction. That single change removes the later “manually confirm this is covered” step, because it happened at intake instead of at review.

Evidence extraction runs immediately: photos are checked against metadata and, where relevant, external signals like weather data for the claimed date and location. Repair or medical estimates are parsed into line items instead of stored as an unread PDF. Fraud scoring runs on every claim continuously, not as a spot-check after the fact, because the marginal cost of scoring one more claim is near zero once the pipeline exists.

The triage decision happens here, and it’s the actual product: routine, low-value, low-risk claims settle straight-through with an explained offer. Everything else — high value, contested, fraud-flagged, or missing information — gets routed to a human adjuster with a complete case file already assembled, instead of a raw folder of attachments to work through from zero.

Vendors report claims resolving faster and at lower cost with this kind of pipeline in place — one carrier-facing report cites settlement times dropping from an industry average of around 15 days to under 10 minutes for the most straightforward claims. Read numbers like that as vendor-reported until you’ve measured them against your own book of business — the mechanism (removing re-keying and manual triage) is real even where the specific percentage isn’t independently audited.

What stays under human control?

Denials and other adverse decisions stay human, not by convention but by rule. The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted in December 2023 and now in effect in over half of US states, expects insurers to designate specific points where a human reviews an AI-influenced decision, especially anything touching a denial or a discriminatory outcome. A model can recommend a denial. It cannot be the last signature on one.

Licensed acts stay human. In most states, determining and approving a claims settlement is a licensed function tied to a named individual, not a system. That’s a liability structure, not a technology limitation, and no amount of model accuracy changes who the law says is accountable.

Complex, high-value, and disputed claims stay human, because the value of a system like this is triage, not judgment. Send the AI-native route the claims where the facts are largely settled and the math is mechanical. Send a person the claims where two parties disagree about what happened — the same boundary I laid out in where human-in-the-loop actually belongs in an AI workflow.

Fraud determination stays with special investigations. The model’s job is to raise the signal earlier and on every claim instead of a sample; the decision to investigate, and the decision that a claim is fraudulent, stays with a licensed investigator.

When this is the wrong build

The same handoff test I used for AI automation vs. manual work applies here: if the handoff can’t actually move, don’t automate around it.

If the carrier’s core claims system has no API and IT won’t grant an integration path — common at smaller carriers running decades-old policy admin platforms — this stops being an embedded AI build and becomes a systems-integration project first. That’s a different scope, a different timeline, and often a different team.

If most of the book is already complex commercial or specialty lines where every claim genuinely needs adjuster judgment, there’s little routine volume to triage away, and the return on a straight-through path shrinks fast.

If the carrier can’t name who signs off on an AI-influenced decision — no documented AI governance program, no assigned reviewer — building the pipeline before that exists just moves the compliance problem downstream instead of solving it.

Summary

The old claims route treats every loss as a document to be collected, read, and re-typed by a person. The AI-native route treats it as a fact to be captured once, checked immediately, and routed to whoever — human or system — can close it fastest without changing who’s accountable. The interesting part was never the paperwork. It’s the coordination layer underneath it, and that layer stays a model until someone running a real claims book describes where it actually breaks.