AI for insurance: claims handling, document extraction, classification

A claims handling department receiving hundreds of submissions daily: photos of damages, policy scans, repair invoices, police reports, statements, workshop estimates. Someone opens all of this, copies policy numbers and amounts into the system, sorts by type of damage, and directs to the right adjuster. This isn’t work that requires expert judgment—it’s transcription and sorting. And this is where AI makes real sense. The problem starts when someone promises “automated claims handling without human involvement”: that’s a different conversation, touching on consumer law, RODO, and the AI Act. Below, we separate one from the other, without promises that can’t be kept in insurance.

A claim submission is a file of diverse documents in various formats: PDFs, phone photos, scans, sometimes illegible handwritten notes. The first real area is converting this pile into structured data. OCR reads text from images, and a language model extracts specific fields: policy number, incident date, invoice amount, vehicle details, damage location.

Here, honesty about accuracy is necessary. On clean, typical documents (invoices, workshop estimates, standard forms), well-tuned data extraction usually achieves high field-level accuracy—often above 90%, even higher on standardized forms. But on handwritten documents, poor scans, or atypical layouts, accuracy drops and becomes unpredictable. That’s why you can’t assume the extracted amount is correct—human confirmation is required for fields affecting payouts, and the system shows the source (document snippet) from which the value originates.

Success depends on order in company data. How to structure documents and metadata so AI has something to work with is covered in preparing company data for AI.

The second area is directing a claim where it should go before anyone reads it manually. A classifier identifies the type of damage (motor, property, personal, third-party liability, comprehensive), urgency, document completeness, and assigns the case to the right queue or adjuster. The same claim may also get a “missing documents” label and automatically trigger a request for completion.

The pattern here is identical to customer service: AI filters and sorts, humans decide in borderline cases. We break down the mechanics of this process in AI claim classification and routing. The benefit is measurable: it shortens the time from submission to first contact with the right person, and simple, complete cases don’t wait in the same queue as complex ones. The same routing engine works outside insurance—we set it up similarly in AI for logistics and warehousing.

The boundary is simple: classification directs the case but doesn’t resolve the claim. A “likely total loss” label is a hint for the adjuster, not a payout decision.

This is the area where language is most easily misused—and where real harm to customers can occur. Let’s be clear: AI doesn’t “detect fraudsters.” AI detects patterns and anomalies that historically correlated with disputed or confirmed fraud cases—and flags them for human review.

The difference isn’t cosmetic. A fraud signal might be: unusual claim frequency on a policy, discrepancies between descriptions and photos, the same workshop in multiple suspicious cases, an incident date right after policy inception. Each of these signals has innocent explanations. That’s why a flag means “take a closer look,” not “deny payment.” The decision to deny or investigate belongs to a human who bears legal responsibility—models don’t.

This is also an area directly impacted by the AI Act: a system assessing customer risk or affecting access to benefits may be a high-risk system, with obligations for transparency, human oversight, and documentation. Automatic denial based solely on a model, without real human intervention, is a scenario we advise against—legally and ethically.

The fourth area is handling customer questions about claim status, policy coverage, or required documents. An agent based on policy and regulation knowledge answers typical questions (“what documents do I need to attach,” “what’s the status of my claim”), relieving consultants of repetitive queries.

Two rules apply here that we don’t bypass. First, the assistant must be grounded in the customer’s and company’s actual documents—models without this anchor can fabricate policy conditions that don’t exist. Second, when a question touches an individual claim decision, the assistant hands off to a human instead of improvising. How we build such a grounded system on company knowledge is shown in company GPT based on knowledge.

Status questions work best when the assistant reads data from the system (claim stage, missing documents) rather than guessing. Then the answer is concrete and verifiable, and the customer gets information immediately, anytime.

Insurance is a regulated sector, and claims data often includes sensitive data—in personal injury cases, even health data. That’s why data architecture isn’t a technical detail here, but a foundational project decision.

Three principles we always apply:

• Humans decide on payouts and qualification. AI prepares, classifies, and flags; the decision to approve, deny, or determine benefit amounts is made by an authorized person. This is both a legal and operational requirement.
• Conscious decision on data location. Sensitive data can remain in the company’s infrastructure thanks to locally run models or providers with EU processing guarantees and data processing agreements. The regulatory context is organized in company obligations under AI Act and RODO in 2026.
• Transparency toward the customer. If a decision is significantly supported by automation, the customer has the right to know and the right to appeal to a human. This isn’t negotiable.

Purely administrative systems (invoice extraction to system, claim routing without resolution) are usually not high-risk. But a system assessing customer risk, affecting access to benefits, or automating decisions—may be. Classification should be confirmed for the specific use case before anything goes into production.

The honest sequence is less flashy than slide promises. First, one narrow problem with measurable cost—usually data extraction from one document type or routing one claim type. Then verification that the data is in a state where AI can work with it. Next, a pilot alongside the current process: AI suggests and prepares, the adjuster still decides, and we measure real accuracy before anything operates independently. Only when the numbers add up—gradual expansion, with oversight maintained where customer money is at stake.

This isn’t a shortcut. But it’s a path that doesn’t end with a system no one trusts because it once denied a payout based on a signal that turned out to be a false alarm.

We don’t recommend this, and in many cases, the law doesn’t allow it. AI can speed up processing—extract data from documents, classify claims, prepare decision drafts—but approving a claim, its amount, or denial is a decision made by an authorized person. For significantly automated decisions, customers also have the right to human intervention, as required by RODO and the AI Act.

It depends on document quality. On clean, typical documents (invoices, standard forms), well-tuned data extraction usually achieves high field-level accuracy—often above 90%. On poor scans, handwritten documents, or atypical layouts, accuracy drops and becomes unpredictable, so fields affecting payouts are always confirmed by a human, and the system shows the value’s source.

No. The model detects signals and anomalies that historically correlated with disputed cases and raises a flag for review—it’s a hint, not a verdict. Each signal has innocent explanations, so the decision to investigate or deny is made by a human who bears responsibility. Automatic denial based solely on a model is a scenario we advise against.

That’s a decision, not a necessity. Sensitive data—including health data in personal injury claims—can remain in the company’s infrastructure thanks to locally run models or providers with EU processing guarantees and data processing agreements. In regulated sectors, it’s worth making this decision consciously at the outset, as it determines the entire project architecture.

Sometimes. A system assessing customer risk or affecting access to benefits may be a high-risk system under the AI Act—with obligations for transparency, human oversight, and documentation. Purely administrative systems, like invoice extraction or claim routing without resolution, usually don’t fall into this category, but classification should be confirmed for the specific use case.