AI Agents for Insurance Claims Triage and Underwriting Support

The regulatory perimeter an insurance agent has to respect

Insurance is a supervised line of business, and an agent that touches claims or underwriting inherits every constraint that applies to the humans it supports. In the United States that means the NAIC Model Bulletin on the use of AI systems, adopted by a growing list of state departments of insurance, plus unfair claims settlement practices acts and the anti-discrimination provisions that prohibit proxy discrimination in rating and underwriting. Colorado's SB21-169 and its life insurance regulations set an explicit bar for testing external data and models for bias. In the EU and UK, the EU AI Act treats life and health insurance risk pricing and claims as high risk, and the UK operates under the FCA and PRA Consumer Duty and the Senior Managers regime, where a named individual is accountable for the system's outcomes.

The practical consequence is that a black box is a non-starter. Every agent action has to be explainable in the terms the regulator uses, traceable to the data it relied on, and free of features that act as proxies for protected characteristics. We design the agent so that adverse or coverage-affecting steps are logged with their inputs, the retrieved evidence, and the model output, and so that the human of record signs off before anything reaches the policyholder. Data handling sits inside a GDPR and SOC 2 aligned control set, because claims files contain medical, financial, and special category data that cannot leak into a training run or a model provider's logs.

Why this is an agent and RAG problem, not a fine-tuning problem

The instinct to fine-tune a model on claims data is usually the wrong first move here. Your policy wordings, endorsements, underwriting guidelines, and claims procedures change on their own cadence, and a fine-tuned model bakes yesterday's rules into weights that are expensive to correct and impossible to audit line by line. Retrieval augmented generation is the correct spine: the agent reads the current policy schedule, the specific endorsement in force on the date of loss, and the live underwriting appetite document at query time, and it cites them. When a wording changes, you update the source, not the model.

The agent layer exists because triage and underwriting support are multi-step tasks, not single questions. A claims triage agent has to classify the loss type, retrieve the governing coverage, check limits and exclusions, pull loss history, run fraud signal checks, and assemble a routing recommendation. That is a sequence of tool calls against real systems with branching logic, which is what an agent is for. Fine-tuning still has a narrow role, on classification tasks like loss-type tagging or document type detection where you have thousands of labeled examples and need low latency at high volume. The honest answer is a mix, and we make the split explicit rather than reaching for one technique to cover everything.

Where agents produce measurable lift, with honest ranges

First notice of loss triage is the highest-value entry point. An agent that classifies the claim, checks coverage in force, and recommends a routing path can compress manual triage handling time, with time savings on the triage step commonly landing in the 40 to 70 percent range depending on how clean your document intake is. Straight-through processing for simple, low-value, clearly covered claims can lift into the 20 to 45 percent range of eligible volume once eligibility rules are conservative and well tested, with everything else escalated to a human.

On the underwriting side, a submission-intake agent that extracts data from broker packets, reconciles it against appetite and referral rules, and pre-fills the underwriting workbench reduces the manual data assembly that eats an underwriter's day, again in the 40 to 70 percent range on the assembly step, not the decision. Fraud signal surfacing is a support function, not a verdict: the agent flags anomalies such as inconsistent loss dates, duplicate claims across policies, or narrative details that contradict the police report, and routes flagged files to the special investigations unit. We quote ranges because the real number depends on your data quality and baseline, and we would rather calibrate against your files during a scoped pilot than promise a figure we cannot stand behind.

What it connects to, and the pipeline underneath

An insurance agent is only as useful as its integration into the systems your teams already live in. That means the policy administration and claims platform, whether that is Guidewire ClaimCenter and PolicyCenter, Duck Creek, Sapiens, or an in-house core, plus the document management store, the loss-run and prior-claims history, and any bordereaux or broker submission feeds. We connect through the platform's supported APIs and event streams rather than scraping screens, so the agent reads coverage and writes recommendations into the same records your handlers audit.

The pipeline behind that is deliberate. Documents flow through extraction and normalization, where policy schedules, medical reports, and broker packets become structured, typed data validated at the boundary. Retrieval runs against a versioned index of wordings and guidelines so the agent always cites the version in force on the relevant date. Latency matters because a triage agent sits in a queue a human is waiting on, so we engineer for responsive turnaround rather than treating speed as an afterthought. Running underneath all of it is an evaluation loop: a held-out set of real, de-identified claims and submissions that the agent is scored against on every model or prompt change, so a provider's silent model update cannot quietly degrade coverage accuracy without us seeing it in the numbers first.

Failure modes, guardrails, and the human sign-off

The failure that matters most in this domain is a confident wrong answer about coverage or a hallucinated exclusion, because it can wrongly deny a valid claim or expose the carrier to bad-faith liability. We control it structurally rather than hoping the model behaves. The agent answers coverage and eligibility questions only from retrieved policy text and returns a grounded citation for every assertion. When retrieval confidence is low or the file is ambiguous, the agent is built to abstain and escalate rather than guess, and it discloses that it is an AI system to any human it interacts with.

No agent output settles a claim, sets a price, or issues a denial on its own. Every coverage-affecting or adverse action is a recommendation that a licensed handler or underwriter reviews, with the evidence and reasoning presented for inspection, and the human decision is the record of account. Governance is continuous: the evaluation set is refreshed as new claim patterns appear, bias and outcome monitoring runs on the routing and flagging behavior, and the full audit trail of inputs, retrievals, and outputs is retained for supervisory review. Because we own the system end to end, from design through the ops and infrastructure that runs it, there is one accountable team behind the behavior in production, not a prompt handed over a wall.

Common questions

Will the agent decide claims or set premiums automatically?

No. The agent triages, retrieves coverage, assembles evidence, and surfaces fraud and appetite signals, then hands a recommendation to a licensed handler or underwriter. Coverage decisions, denials, and pricing remain human decisions of record, both because that is sound practice and because regimes like the NAIC Model Bulletin, the EU AI Act, and FCA Consumer Duty require accountable human oversight for high-impact insurance outcomes.

How do you keep the agent from discriminating or using biased proxies?

We treat proxy discrimination as a design constraint, not an afterthought. Underwriting and rating support features are reviewed against anti-discrimination rules such as Colorado SB21-169 and state unfair practices acts, the agent's routing and flagging behavior is monitored for disparate outcomes on a held-out set, and any feature that could act as a proxy for a protected characteristic is excluded. All of it is logged so an examiner can inspect what drove a recommendation.

Can this work with our existing Guidewire or Duck Creek core without a rip and replace?

Yes. The agent integrates through your core platform's supported APIs and event streams, whether that is Guidewire, Duck Creek, Sapiens, or an in-house system, and reads and writes against the same claims and policy records your teams audit. There is no core replacement. We scope integration to what a pilot needs first, prove accuracy and latency against your real files, then expand from there.