Insurance claims automation, the knowledge gap nobody talks about

Every claims automation project starts with the same slide. A funnel showing volume in at the top, a stack of automation layers in the middle, and a much smaller number of adjuster-touched cases at the bottom. The pitch is straight-line: intake gets OCR'd, first notice of loss gets classified, straightforward claims get auto-approved, and the rest gets routed to a human.

Then the project goes live. And the number at the bottom of the funnel, the claims that still need an adjuster, barely moves.

If you run claims operations, you already know why. The tools do the easy part. The hard part is the part they were never built for: the operating knowledge that lives inside your best adjusters.

This is the knowledge gap almost nobody talks about when they sell you claims automation.

What "automating claims" usually means

Most claims processing AI on the market today does one of four things well. It extracts structured data from unstructured documents. It classifies claims into buckets. It runs a fraud or leakage model against a case file. It surfaces missing information the adjuster would otherwise chase by email.

All four are useful. All four save time on the parts of claims work that are already routine. And all four have been available, in some form, for years.

But they share one thing. They work on the surface layer of a claim, the fields, the documents, the metadata. They do not know why a specific case is different from the one filed an hour earlier that looked identical on paper. They do not know which line in the loss description is the tell. They do not know that a certain broker's submissions run clean and another's always need a second look before you fast-track anything.

Your senior adjuster knows all of that. And none of it lives in any system your automation vendor can read.

The real reason claims automation stalls

There is a widely cited MIT NANDA finding that 95% of enterprise AI investments show no measurable business impact. Gartner has projected that 40% of agentic AI projects will be cancelled by the end of 2027. These are not model quality problems. The models are fine. The reasons those pilots stall are almost always structural, the same reasons enterprise AI pilots fail across every industry.

The problem is upstream of the model.

Claims automation stalls on the same wall every time: the adjuster knows which cases to fast-track and which to flag, and that knowledge was never captured anywhere the automation can reach. Roughly 80% of operational processes are undocumented (Tallyfy). In claims, that undocumented portion is not a rounding error. It is the substance of the work.

When you deploy a claims processing AI on top of what is written down, you get an automation that handles the easiest 20% of your book cleanly, produces confident but wrong outputs on the middle 60%, and correctly punts the hardest 20% to a human. And you have made your best adjusters slower, because now they are auditing the AI's outputs on cases they used to handle intuitively.

That is not a technology failure. It is a substrate failure. The AI is reading from the wrong source.

What actually lives inside a senior adjuster

Sit with a senior claims adjuster for a day and write down what they do. You will fill a notebook with things that do not appear in your policy manual, your SOP, or your workflow tool.

Fast-track judgment. They know that a specific claim type, from a specific channel, under a specific dollar threshold, with a specific set of attachments, is safe to expedite. They also know when the same claim from the same channel should be flagged instead, because of something in the loss description, or a pattern with that policyholder, or the way a repair estimate is written.

Flag logic. They know which fields to check first. They know which system holds the version of the truth for coverage, and which one is often stale. They know that a specific broker submits well-organized files that rarely need a second look, and that a specific vendor's estimates run about 15% high on labor.

Escalation triggers. They know the exact moment to stop working a file and hand it to SIU, subrogation, or complex claims. Not because a rule fired. Because they have seen this pattern before.

Reserve intuition. They know when the reserve someone else set is going to be wrong. They cannot always tell you why in the language of your reserving model. They can tell you which cases will run over and which will close inside.

Vendor and partner context. They know which appraiser to call for a specific type of loss in a specific region. They know which counsel to route a litigated file to. They know how to frame a request to a preferred body shop so the estimate comes back within two days instead of ten.

None of this is written down. Not because your adjusters are hoarding it, but because most of it is tacit. They do not know they know it until a case hits their desk that requires it. And when they retire, or move to a competitor, or get promoted out of the desk, all of it walks out with them. This is exactly the problem of capturing tribal knowledge before it walks out the door, and in claims, the door is closer than most carriers admit.

The U.S. private sector median tenure is 3.5 years (Bureau of Labor Statistics). In claims, senior desks tend to run longer, but the retirement cliff for the most experienced adjusters is real, and every carrier we talk to feels it.

Why RAG, workflow tools, and copilots miss this

The market has responded to the knowledge problem in three main ways, and each one misses the same layer.

RAG on your policy library. Useful for answering "what does our policy say about X." Not useful for "which of these two claims should be fast-tracked and why." The answer to the second question was never written into a policy document, so retrieval cannot find it.

Insurance claims workflow automation. BPM tools, decision engines, workflow orchestrators. Extremely useful for enforcing the official process. But they enforce the official process, which is not the same as the real process. The real process is the workarounds, the exceptions, the "check this field first, ignore the other one until Tuesday" heuristics that make the operation actually work.

Adjuster copilots. Chat surfaces that let an adjuster ask questions of the case file, the policy, prior claims history. Genuinely helpful for surfacing information the adjuster would otherwise have to hunt for. But they do not carry the operating logic of a senior adjuster, because that logic was never written into anything the copilot can retrieve.

Every one of these tools is reading from a substrate that does not contain the answer. You cannot fix that by improving the retrieval pipeline or the chat interface. You have to change the substrate.

That is the frame we use across Verti's platform: every layer of enterprise AI reads from a substrate, and none of the common substrates contain tacit operating knowledge. Whichever tool you use, you still have to do expertise mining first.

The fix, capture the operating logic first

The claims automation projects that actually move the bottom-of-funnel number do one thing before they touch a workflow tool: they capture how their best adjusters actually decide.

Not a transcript. Not a wiki page. A structured, machine-readable expert profile that an AI can use directly: the decisions, the reasons, the exceptions, the trusted sources, the moments the adjuster stops and escalates.

This is what expertise mining is. Process mining mines logs. Enterprise search mines documents. Expertise mining mines people. It captures the substrate that no other approach can reach, the tacit judgment behind claims work, and turns it into operating knowledge that an AI can operate on. This is a different job than retrieval, which is why expertise mining sits in a different place than RAG in the stack.

Once the operating logic is captured, the same tools you already have start behaving differently. Your workflow engine can route on the real logic, not the official one. Your fast-track path can include the specific patterns your senior adjuster recognizes, not just the ones your product team documented. Your copilot can answer "should I flag this?" the way the person at the next desk would have answered it, because it now carries their reasoning.

At a large multi-brand insurance group we work with, the insurance renewal workflow went from six minutes to one minute, a roughly 83% cut in handling time, and about 833 labor hours saved per 10,000 renewals per month, after the operating knowledge behind the renewal decision was captured and put behind a governed agent. Nothing about the underlying policy system changed. What changed was the substrate the AI was reading from.

This is the same shift that has to happen for insurance underwriting AI to stop missing the real cases, and it is the same shift that sits underneath knowledge transfer in insurance operations. The retirement cliff is not solved by more documentation. It is solved by capturing operating knowledge from the people who still have it.

What a claims ops lead should actually do next

If you are running claims operations and you have already spent budget on a claims automation program that is not moving the number, the question to ask is not "which vendor should we try next." The question is: where is the operating knowledge that decides these cases, and who has it?

The honest answer, in most carriers, is: one or two senior adjusters per line of business. Their names come up every time a hard case lands. New hires are told to "just ask them." When they take vacation, the queue backs up in ways that have nothing to do with volume.

Those are the people to mine. Not to replace, to make permanent. Their judgment is the source of value in your operation, and it should not live only in their heads.

Capture the operating logic first. Then let your workflow tools, your copilots, and your governed agent teams operate on the real process, with a human still in the loop on anything that touches a real system.

Mine your first process.