AI in insurance — RAG for claims documents, without deciding the payout

AI in insurance can speed up work with documents without taking over the payout decision. The sound setup is RAG grounded in your claims files, policies, correspondence and procedures — answering an adjuster’s questions with a cited source, read-only — plus agents that propose an action while a human makes the call (approve, decline, the amount). This is not “automated claims handling”. It is a tool that takes the digging through files and procedures off your team, and leaves the ruling where the regulatory risk actually is — with people.

This post is about building it safely: what AI really does with a claims file, where the boundary of automation sits, and what you must keep for audit. If you want an overview for your organization instead, start with the AI for finance and insurance page. Below we assume you’re asking about the engineering, not the pitch.

How RAG differs from a “claims automation” accelerator

The market is starting to productize ready-made claims-automation accelerators whose promise is to close the process: the system reads the notice, classifies, calculates and — in the maximal version — decides on its own. It’s an attractive slide. The problem isn’t the technology; it’s where its responsibility ends.

RAG is a narrower, more cautious approach: the model answers from your documents — the policy, the terms and conditions, the loss report, the correspondence, the compliance procedures — not from general knowledge about insurance. An adjuster asks “is this loss within the scope of policy X?”, and the system cites the specific clause instead of guessing. The difference isn’t “nicer answers”; it’s that every answer can be checked back to a source, and the decision stays with a human. It’s the same mechanism we describe in RAG on company documents, applied to a claims file.

This distinction isn’t about “who is compliant and who isn’t” — it’s a difference in design philosophy. An accelerator optimizes time-to-close. We optimize checkability: the adjuster works faster, but they own the ruling and have the source it rests on within reach.

What AI actually does with a claims file

In this setup AI reads, retrieves and collates — it does not rule. Concretely: it pulls facts scattered across several documents, finds the right policy clause for the situation, summarizes correspondence with the client, checks the notice for completeness against the procedure. All of it read-only and with a reference to the source document.

Suitable for this are documents that genuinely answer questions and have one current version: terms and conditions, policy texts, loss reports and estimates, correspondence, internal claims-handling and compliance procedures. Not suitable is data with no owner and no single version of truth — five variants of the same terms circulating over email will undermine any model. Before you build, walk data readiness for RAG.

Risk → control → audit artifact

In an industry under a regulator’s supervision, it pays to assign each use case a control and a trail you can later show an auditor, right away. Treat this table as a starting point for a conversation with your risk team, not as a finished offer.

Risk	Control	Audit artifact
Model invents a policy clause that doesn’t exist	RAG with a source — answer only from retrieved passages	Log: query + cited passages + document version
AI “decides” on the payout instead of supporting	Read-only; the ruling and sign-off stay with a human	Record of who approved and when, with operator identity
Analysis run on a stale policy	Document versioning; RAG shows the version	Document version ID attached to every answer
Personal data of a claim leaks out of control	Processing in your AWS account, isolation, encryption	Access and processing-region trail (GDPR)
Silent change in model behavior after an update	Test set on real cases, run on every change	Test result with date and model version

Note that each row ends in an artifact, not a declaration. “We have human oversight” means nothing without a record of who approved what. We develop this audit-first architecture in AI on AWS and compliance.

The boundary: why AI doesn’t decide the payout

The most common question is “can AI approve or decline a claim on its own?”. Technically, yes. Sensibly, no — and not only out of engineering caution. A decision to pay or decline produces legal effects for the client, and the GDPR (Art. 22) restricts decisions based solely on automated processing where they significantly affect a person. Fully automating a claim ruling walks straight into that area.

The safe pattern is read-only + a human ruling: the agent reads the file, collates facts, proposes a specific conclusion with a link to the source, and the adjuster makes and signs off the decision. It’s the same principle we set out for agents in general — an agent reaching into your systems needs explicit boundaries and supervision; we develop this on the AI agents page and in Guardrails are not an AI policy. The practical rule is simple: reads and proposals can be automated, the ruling can’t.

Where the AI Act and the regulator fit in

We classify risk per deployment, not up front — and that’s the crux. Analyzing claims documents is not, by itself, named in the AI Act as a high-risk system. Annex III does explicitly name systems for risk assessment and pricing in life and health insurance — those are high-risk. So a PoC that stays at supporting an adjuster in reading files is a different thing from a system that scores a client or computes a premium. That’s why we settle the scope before anything reaches production; we describe the method in AI Act risk classification.

One trap worth naming outright: human oversight is an obligation of a high-risk system, not an exemption from classification. “There’s a human in the loop, so the AI Act doesn’t apply to us” is a faulty shortcut — first you settle the system’s class, then its obligations. On timelines: the Digital Omnibus deferred the application of obligations for Annex III systems to 2 December 2027, but the AI Act’s general provisions have applied since 2 August 2026, unchanged.

On national supervision we stick to what’s verified: financial regulators and EIOPA emphasize risk management, accountability and oversight of outsourcing (cloud included), not a ready-made “AI checklist for claims handling” that simply doesn’t exist. So we don’t cite non-existent requirements — we design so the architecture supports the standard needs: an audit trail, access control and a constrained processing region, instead of bolting them on after the fact. We collect the regulatory context for supervised industries in AI governance in regulated industries and on the AI Act page.

What to log for audit

Auditability isn’t a separate module bolted on at the end; it’s what you record on every answer from day one. The minimal set: the adjuster’s query, the source passages the model actually retrieved, the document identifier and version, the generated answer, and — for any action leading to a decision — who approved it and when. Plus an access and processing-region trail for GDPR.

Such a log answers three of the auditor’s questions at once: where the answer came from (whether from a real document), whether someone approved it, and whether the data left the controlled environment. When all of this lives in your AWS account — in the chosen region, in an isolated network, encrypted — compliance starts from architecture, not from a policy written after the fact. We break this down in AI on AWS and compliance.

The same pattern — RAG over sensitive data, with a trail and citations — we run on our own healthcare product; we describe it in mojApteczka as proof. That is not an insurance deployment, but proof that the pattern holds where a mistake costs more.

Where to start

Not with “AI across the whole claims operation”, but with one narrow use case on clean data — usually reading and collating files of a single loss type, read-only, with citations to the terms. A PoC like that will show real quality on your documents and a real cost within a few weeks, before you decide on anything larger. What such a system costs and what drives the bill, we break down in how much an AI agent or RAG costs.

FAQ

Can AI decide on an insurance payout?

Technically yes, but it shouldn’t do so on its own. A decision to approve or decline a claim produces legal effects for the client, and the GDPR (Art. 22) restricts rulings based solely on automated processing. The safe pattern is AI supporting the adjuster — reading the file and proposing a conclusion with a source — while a human makes and signs off the decision.

How do you cite sources in claims documents?

The answer is built from passages actually retrieved from your documents, and the system returns a link to the specific clause together with the document identifier and version. That lets the adjuster see which sentence of the terms or the report the answer rests on, and verify it, rather than taking the model’s word for it.

What documents are suitable for RAG?

Those that genuinely answer questions and have one current version with an owner: terms and conditions, policy texts, loss reports and estimates, correspondence, internal claims-handling and compliance procedures. Documents with no single version of truth and no one responsible for updating them are not suitable.

What should you log for audit?

The query, the retrieved source passages, the document identifier and version, the generated answer, and — for any action leading to a decision — who approved it and when. Plus an access and processing-region trail for GDPR. The log should answer where the answer came from, who approved it, and whether the data left the controlled environment.

What next

What AI for finance and insurance looks like with us — systems grounded in your documents, with a cited source and an audit trail, on AWS — is on the AI for finance and insurance page. How we run a deployment step by step (tidying data, PoC, production) is in how we work. If you don’t know where to start, start with an audit: we’ll find where AI genuinely helps your process and what it needs — a concrete map, not a sales pitch.