AI-assisted claims triage that adjusters trust and regulators can audit

The situation

A multi-line insurer in the United States handled first notice of loss through a mix of call centre notes, web forms, emails with attachments and broker submissions. Triage was manual: a team read each new claim, decided its complexity, picked a queue and flagged anything suspicious. At peaks, the backlog meant simple claims waited behind complex ones, and the quality of triage depended on who happened to read the file.

Leadership wanted AI in the loop. The claims and compliance teams wanted something else first: confidence that no model would quietly decide a claim, and evidence they could show a regulator about how AI was governed.

What had to be true

• Adjusters decide. AI summarises, extracts and suggests; coverage, payment and denial decisions stay with licensed staff.
• Every flag has a reason a person can read and challenge.
• Testing for error and unfair outcomes before release and on a schedule, by line of business.
• One inventory of AI systems with owners, purpose, data and controls.
• No change to the claims system of record; AI writes suggestions alongside it, not into it.

These map closely to the NAIC model bulletin, which asks insurers to maintain a written programme for the responsible use of AI systems, including governance, risk management controls and testing for errors, bias and unfair discrimination¹. A growing number of states have adopted it, so building to it was the safest baseline across jurisdictions²³.

Architecture

The data flow, end to end

Extraction used structured outputs validated against a schema, so a malformed response fails fast rather than reaching an adjuster, the pattern described in structured outputs for reliable LLM integration. Fraud signals drew on relationships between parties, addresses, repairers and prior claims, using the graph approach in entity resolution for knowledge graphs.

The hard part: fairness and explainability, not extraction

Getting a model to read a claim form well is now the easy part. The difficult questions were about outcomes. Does a fraud signal fire more often for claims from certain postcodes for reasons unrelated to fraud? Does a severity hint systematically under-prioritise one line of business? The bulletin expects insurers to test for exactly these risks¹, and the NIST AI Risk Management Framework gave a practical structure for mapping, measuring and managing them⁴.

• An evaluation set of historical claims with known outcomes, refreshed regularly, scored for extraction accuracy and routing agreement.
• Outcome comparisons across segments the compliance team defined, reviewed before each release.
• Fraud signals limited to features the special investigations team could explain, with every flag showing its contributing reasons.
• Override rates tracked by signal; a signal adjusters routinely override gets investigated, not ignored.

How it ran

Key decisions and trade-offs

For insurers with European operations, the EU AI Act adds another layer: its Annex III lists AI used for risk assessment and pricing of natural persons in life and health insurance as high-risk⁵. Claims triage sits next to that boundary, so classification should be confirmed with counsel; the governance described here is a strong starting point either way. See ISO 42001 vs the NIST AI RMF and Colorado's AI law reset for the wider landscape.

What I'd do again, and differently

Again: write the AI programme and the evaluation set before writing the first prompt, and run in shadow mode. Differently: involve the special investigations team in designing fraud signals from the first week. Their sense of what makes a signal actionable shaped the design more than any model choice.

If you're bringing AI into claims, underwriting or service, my AI architecture work covers how I approach it, or analyse your challenge and bring the result to a call.