Insurance · Playbook 07

Claims intake and triage

Every claim read, sorted and routed within minutes. Simple claims ready for one-click approval, complex ones flagged early, and people making every decision that matters.

  • Document AI
  • Agents with tools
  • Human in the loop
  • Event-driven integration
  • FCA Consumer Duty
  • FCA ICOBS 8
  • UK GDPR

At a glance

The problem
Claims arrive by email, web form and broker portal, then get read and re-keyed by hand
Typical volume
Around 4,000 new claims a week, across home, travel and motor
Who's involved
Claims operations, fraud, IT, compliance, data protection, the broker channel
Pilot
8–10 weeks after a 2–3 week discovery
Platforms
AWS, Azure, or a sovereign or on-prem stack

An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.

The business problem

Claims arrive in every shape: emails with photos attached, PDFs of handwritten forms, web forms with free-text descriptions, and broker submissions in their own formats. Before anyone makes a decision, a handler has to read it all, work out what kind of claim it is, find the policy, and re-key the details into the claims system.

In a typical mid-sized insurer, that reading and re-keying takes around 40% of a handler's day. Simple claims, such as a lost phone or a cancelled flight, wait in the same queue as complex ones. Signs of fraud or of a vulnerable customer are often spotted late, after the money has gone or the customer has already had a poor experience.

Claims handling is also under the regulator's spotlight. The FCA's 2026 insurance priorities put claims handling at the top of its supervisory focus. Following the Which? super-complaint, it is reviewing claims service quality in home and travel insurance during 2026. Any change to how claims are handled has to show it improves customer outcomes, not just costs.

What AI changes

  • Every claim is read and its key details extracted within minutes of arriving, whatever channel it came from.
  • Claims are sorted by type, complexity and urgency, then routed to the right team automatically.
  • Simple, low-value claims arrive in the handler's queue already filled in, with the policy checked, ready for one-click approval.
  • Complex or suspicious claims go straight to senior handlers or the fraud team, with a summary and the specific reasons they were flagged.
  • Possible signs of vulnerability are flagged to a trained handler on the first day, not the tenth.
  • People stay in control: the AI recommends, a person decides, and every step is logged for audit and for Consumer Duty evidence.

How success is measured

Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.

Time to first touch

How long a customer waits before anyone acts on their claim.

ExampleFrom 2 days to under 2 hours

Handler time on re-keying

Time moved from copying details to making decisions.

ExampleDown by half

One-click approval rate

The share of simple claims a handler approves without editing.

Example60–70% of simple claims

Override rate

How often handlers disagree with the AI's recommendation. Very high means it isn't helping; near zero can mean people have stopped checking.

ExampleStable, and reviewed weekly

Leakage

Money paid that shouldn't have been, including fraud caught late.

ExampleMeasured against last year

Customer outcomes

Complaints, claim acceptance by product, and satisfaction, split out for vulnerable customers.

ExampleNo group worse off

UK regulation and controls

Cross-sector rules are on the UK regulation map.

  • FCAConsumer Duty (PRIN 2A)

    There's no AI-specific rulebook. The FCA applies the Duty to AI like any other change. Every recommendation carries a plain-English reason, outcomes are monitored by customer group, and the firm can explain any decision if challenged.

  • FCAICOBS 8: claims handling

    Claims must be handled promptly and fairly. The AI can speed claims up and route them, but it never rejects a claim on its own. Every decline is a person's decision.

  • FCAVulnerable customers (FG21/1)

    Signs of vulnerability in the claim text, such as bereavement, illness or financial difficulty, are flagged to a trained handler, never acted on automatically.

  • ICOUK GDPR and the Data Protection Act 2018

    Claims often contain health and other special category data. That means a DPIA before the pilot, collecting only what's needed, processing in UK regions, a clear retention period, and a contract that stops providers training their models on your data.

  • ICOAutomated decisions (UK GDPR, as amended by the Data (Use and Access) Act 2025)

    Since 5 February 2026, the strict limit on solely automated significant decisions applies mainly where special category data is involved, and claims often include health data. Every other automated decision needs safeguards: telling people, letting them challenge it, and a person who can step in. A person on every adverse decision keeps the design clearly within the rules.

The solution

Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.

Claims intake and triage: reference architecture
  1. 01Channels

    • Email
    • Web claim form
    • Broker portal
  2. 02Intake

    • Amazon SESLogic Apps email connectorYour existing mail serverInbound email
    • API GatewayAPI ManagementKong, or your existing API gatewayAPI for forms and brokers
    • Amazon S3Blob StorageCeph, or IONOS S3 Object StorageFile store
  3. 03Intelligence

    • Amazon TextractContent Understanding (Document Intelligence)Docling plus an open-weight vision modelRead documents
    • Bedrock Knowledge BasesFoundry IQ (Azure AI Search)OpenSearch, or PostgreSQL with pgvectorPolicy knowledge
    • Agent
      Bedrock AgentCoreFoundry Agent ServiceLangGraph on Kubernetes, with open-weight models via vLLMTriage agent
  4. 04Orchestration

    • Step FunctionsLogic Apps / Durable FunctionsTemporalClaim workflow
    • EventBridge + SQSEvent Grid + Service BusApache Kafka or RabbitMQEvents and queues
  5. 05Systems of record

    • Core claims system
    • Policy admin system
    • Fraud scoring
  6. 06People

    • Person
      Handler: one-click approval
    • Person
      Senior handler queue
    • Person
      Fraud and vulnerability teams
  • Cloud or platform service (AWSAzuresovereign / on-prem)
  • AI agent
  • A person decides
  • Your existing systems
  • Outside your organisation

Components, side by side

Claims intake and triage: components on AWS, Azure and a sovereign or on-prem stack
LayerAWSAzureSovereign / on-prem
Intake: email, forms, filesAmazon SES, API Gateway, S3Logic Apps connectors, API Management, Blob StorageYour mail server, Kong, Ceph or IONOS S3 Object Storage
Reading documentsTest on real phone photos of handwritten forms, not clean PDFs.Amazon TextractAzure Content Understanding (includes Document Intelligence)Open-source parsing (e.g. Docling) plus an open-weight vision model
Reasoning and summariesAWS and Azure both offer a choice of models, including Claude. On-prem and sovereign options run open-weight models.Amazon BedrockMicrosoft FoundryOpen-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub
Policy knowledge (retrieval)So the agent answers from your policy wordings, not from general knowledge.Bedrock Knowledge BasesFoundry IQ, built on Azure AI SearchOpenSearch, or PostgreSQL with pgvector
Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore.Amazon Bedrock AgentCoreFoundry Agent ServiceAn open-source agent framework (e.g. LangGraph) on Kubernetes
WorkflowAWS Step FunctionsLogic Apps or Durable FunctionsTemporal, or n8n
Middleware and eventsAmazon EventBridge, SQSEvent Grid, Service BusApache Kafka or RabbitMQ
Link to the core claims systemReuse the integration layer you have. Don't buy a new one for this.API Gateway, plus your existing integration platform if you have oneAPI Management, plus your existing integration platform if you have oneKong or your existing API gateway, plus your existing integration platform if you have one
Human reviewPeople review where they already work, not in a new screen.In the handlers' existing claims workbenchIn the handlers' existing claims workbenchIn the handlers' existing claims workbench
GuardrailsBedrock GuardrailsFoundry guardrails (Azure AI Content Safety)Open-source guardrails (e.g. NeMo Guardrails, Llama Guard)
Identity, keys, data protectionIAM Identity Center, KMS, MacieEntra ID, Key Vault, PurviewKeycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM
Monitoring and auditLog every recommendation and every human decision, with the reason.CloudWatch, CloudTrailAzure Monitor, Log AnalyticsPrometheus, Grafana, OpenTelemetry
UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency.eu-west-2 (London)UK South / UK WestYour own UK data centre, or a UK or EU provider

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

Hybrid and on-prem

Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.

Stays on-prem

The core claims system, the policy admin system and the fraud engine stay where they are. Many insurers still run these on their own servers, and nothing in this design needs them to move.

Uses cloud AI

Document reading, the policy knowledge index and the triage agent can run in AWS or Azure, or on your own GPUs with open-weight models if claim data must not leave your estate.

How they connect

A private link (AWS Direct Connect or Azure ExpressRoute) and the API layer. Only the fields the AI needs are sent, and results come back as events onto your queue.

If the link drops

Claims keep arriving and queue safely on your side. Handlers work them exactly as they did before the AI, and the backlog is triaged when the link returns.

The agents

What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.

Triage agent

May do

  • Look up the policy and check what it covers
  • Check the customer's claim history
  • Request a fraud score from the existing fraud system
  • Draft a summary with its reasons
  • Create and route a task in the claims system

May not do

  • Pay, reject or close a claim
  • Contact the customer
  • Change policy or customer data
  • Override a fraud or vulnerability flag

Where a person signs offA person signs off every payment, every decline, and every claim flagged as suspicious or vulnerable. The agent's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.

Middleware and integration

The core claims system is reached only through an API layer, never directly. If you already run an integration platform, the AI uses it like any other system does.

Events decouple the AI from the systems of record. Each new claim becomes a message on a queue. If the claims system is slow or down, claims wait safely in the queue, and nothing is lost or processed twice. Every message carries an ID, so a retry never creates a duplicate claim.

The AI can be switched off without stopping the business. If it's paused, claims flow straight to handlers, exactly as they did before.

Process and people

  • An exception queue for claims the AI isn't confident about, with a clear owner.
  • Override rules, so handlers know when and how to disagree, and their reasons are captured.
  • A weekly quality review of a sample of AI recommendations, including vulnerable-customer cases.
  • A named owner for every prompt, policy document and model, with change control like any other system.
  • Handlers trained before go-live, not after, including what the AI can't see.
  • Consumer Duty monitoring updated to report outcomes for AI-assisted claims separately.

Delivery plan

  1. 2–3 weeks

    Discovery

    Map today's process, measure the baseline, check data access, and pick the first claim type.

  2. Gate · must be true to passBaseline measures agreed, data access confirmed, DPIA started, and compliance involved.

  3. 6–8 weeks

    Pilot

    One claim type, in shadow mode: the AI recommends, handlers work as normal, and the two are compared.

  4. Gate · must be true to passAccuracy and override rate within agreed limits, no customer group worse off, and compliance sign-off.

  5. 4–6 weeks

    Production

    Recommendations go live for the first claim type, with monitoring, support and a rollback plan.

  6. Gate · must be true to passMonitoring, support model, rollback plan and handler training in place.

  7. Ongoing

    Scale

    Add claim types one at a time, then reuse the pattern for complaints and underwriting referrals.

  8. Gate · must be true to passEach new claim type passes the same pilot gate.

Roles and RACI

Who is responsible, accountable, consulted and informed, by activity
ActivityClaims directorProduct ownerSolutions architectI can fill thisTechnical PMI can fill thisEngineersI can fill thisCompliance & DPOSecurityI can fill this
Business case and benefitsAccountableResponsibleConsultedConsultedInformedConsultedInformed
Target architectureInformedConsultedAccountable and ResponsibleConsultedConsultedConsultedConsulted
DPIA and Consumer Duty reviewAccountableConsultedConsultedInformedInformedResponsibleConsulted
Build and integrationInformedConsultedAccountableResponsibleResponsibleInformedConsulted
Accuracy testing on real claimsInformedAccountableResponsibleConsultedResponsibleConsultedInformed
Go-live decisionAccountableResponsibleConsultedResponsibleInformedConsultedConsulted
Run, monitor and improveInformedAccountableConsultedConsultedResponsibleConsultedConsulted

Business case and benefits

Claims director
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
I · Informed
Compliance & DPO
C · Consulted
Security
I · Informed

Target architecture

Claims director
I · Informed
Product owner
C · Consulted
Solutions architect
A/R · Accountable and Responsible
Technical PM
C · Consulted
Engineers
C · Consulted
Compliance & DPO
C · Consulted
Security
C · Consulted

DPIA and Consumer Duty review

Claims director
A · Accountable
Product owner
C · Consulted
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Compliance & DPO
R · Responsible
Security
C · Consulted

Build and integration

Claims director
I · Informed
Product owner
C · Consulted
Solutions architect
A · Accountable
Technical PM
R · Responsible
Engineers
R · Responsible
Compliance & DPO
I · Informed
Security
C · Consulted

Accuracy testing on real claims

Claims director
I · Informed
Product owner
A · Accountable
Solutions architect
R · Responsible
Technical PM
C · Consulted
Engineers
R · Responsible
Compliance & DPO
C · Consulted
Security
I · Informed

Go-live decision

Claims director
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
R · Responsible
Engineers
I · Informed
Compliance & DPO
C · Consulted
Security
C · Consulted

Run, monitor and improve

Claims director
I · Informed
Product owner
A · Accountable
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
R · Responsible
Compliance & DPO
C · Consulted
Security
C · Consulted

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

Option A

Lead the architecture

If there's no architect on the programme, I'd own the design end to end: the target architecture, the integration with your claims system, and the gates. I'd report to your programme board.

Option B

Support your architect

If your partner or your own team already has an architect, I'd take on the document AI, the agent and the claims-system integration under their lead, and give them a second senior opinion on the rest.

Where this goes wrong

  1. Goes wrong

    The demo used clean PDFs. Real claims are phone photos of handwritten forms.

    How the design avoids it

    Pilot on last month's real claims, every channel, not a curated sample.

  2. Goes wrong

    The AI talks to the claims system directly, so one outage stops everything.

    How the design avoids it

    An API layer and a queue in between, and a switch that sends claims straight to handlers.

  3. Goes wrong

    Nobody owns the prompts or policy documents, so quality drifts quietly.

    How the design avoids it

    A named owner for each, change control, and a weekly sample review.

  4. Goes wrong

    Handlers don't trust it and re-check everything, so nothing is saved.

    How the design avoids it

    Shadow mode first, override reasons fed back, and handlers involved in setting the rules.

  5. Goes wrong

    Compliance sees it a week before go-live.

    How the design avoids it

    DPIA and Consumer Duty review at the discovery gate, not the production gate.

On the horizon

Changes already announced or under way that affect this design. More in the UK horizon scan.

  1. By end of 2026
    The FCA's public update on the Which? super-complaint

    The FCA has been analysing claims service quality in home and travel insurance. Expect sharper expectations on claim acceptance, delays and communication. Build the outcome reporting now, split by product and customer group.

  2. 2026–2027
    The ICO's code of practice on AI and automated decision-making

    Regulations in force since May 2026 require the ICO to produce a statutory code. Keep the decision log, the explanations and the human review records in a form you could show the ICO.

  3. Late 2026–2028
    The Cyber Security and Resilience Bill

    Medium and large managed service providers come into regulation for the first time, with faster incident reporting. Expect your IT and AI suppliers to face new duties, and your contracts and supplier assurance to need updating.

  4. 2028
    The NCSC's post-quantum cryptography milestone

    The NCSC asks organisations to have a full migration plan by 2028. Claims data is sensitive and long-lived, so record which encryption the new platform uses and keep it easy to change.

Questions to ask your partner or vendor

Good answers are specific. Vague answers to any of these are worth following up.

Copy them into your next supplier meeting

  1. What happens to a claim when the core claims system is down?
  2. How will we measure accuracy on our own claims, not a supplier's benchmark?
  3. Which actions can the agent take without a person, and where is that enforced?
  4. Where is our data processed and stored, and is it used to train anyone's model?
  5. Who owns the prompts, policy documents and test sets after you leave?
  6. What does it cost to run per thousand claims, at our volume?

Planning something like this?

Whether you need someone to lead the design or to support the architect you already have, let's talk it through.

Sam Naseem
Sam NaseemBirmingham, UK · UK & Europe
Available now