Azure Zero-Trust Agentic AI Platform for Life Insurance Claims Adjudication

A reference architecture for AI-assisted, human-governed life claims

By Harish Kumar — VP of Engineering, Platform Engineering · August 2026

FNOL → Beneficiary Verification → Evidence → Coverage → Contestability → Risk → Adjudication → Human Review → Settlement

Contents

1. Executive summary
2. Why life claims are not motor claims
3. Reference architecture
4. The claims journey end to end
5. Worked example: a death claim
6. The claim evidence package
7. Adjudication: who decides what
8. Data separation: knowledge is not evidence
9. Zero-trust and regulatory controls
10. An adoption path
11. Conclusion

1. Executive summary

Most insurers approaching generative AI in claims start from the pattern they already know: motor and property. A photograph of damage, an estimate, a repair network, a settlement. That pattern has produced genuinely useful automation, and it has also produced a generation of proofs of concept that quietly break when they are pointed at a life book.

Life claims are different in kind, not degree. The customer who files the claim is usually not the customer who bought the policy. The evidence is medical and legal rather than photographic. The decision turns on questions — contestability, disclosure, exclusions, beneficiary entitlement — that are matters of contract law and regulatory obligation, not damage assessment. And the failure mode is not a mispriced repair; it is a wrongly denied death benefit to a grieving family, or a wrongly paid one that a regulator will ask about.

This paper sets out a reference architecture for life insurance claims on Azure that takes those differences seriously. Its central design decision is a separation of duties that most chatbot-shaped architectures collapse:

AI gathers, extracts, compares, summarises and recommends. The claims domain adjudicates. A human approves where required.

Everything else in this architecture — the agent decomposition, the evidence model, the data separation, the zero-trust wrap — follows from holding that line. The result is not an AI chatbot for life insurance. It is a governed, auditable claims platform in which AI does the work it is genuinely good at, and the systems of record retain the authority they are accountable for.

2. Why life claims are not motor claims

Before discussing architecture, it is worth being precise about what changes. The table below is the practical basis for almost every design choice that follows.

The consequence is that the centre of gravity moves. In motor, the hard problem is assessment. In life, the hard problem is verification and entitlement: proving who the claimant is, establishing what the contract actually covers on the date of the event, and assembling an evidence package that will still stand up two years later when someone reviews it.

3. Reference architecture

The platform is organised as a single request path from the claimant experience through to the model layer, with an orchestration layer that owns the claims-specific reasoning.

flowchart TD
    CH["Beneficiary · Policyholder · Agent · Call Centre"]
    PORTAL["Web / Mobile / Agent Portal"]
    AFD["Azure Front Door + WAF"]
    APIM["Azure API Management"]
    BFF["Claims BFF"]

    subgraph ORCH["LIFE CLAIMS ORCHESTRATION LAYER"]
        A1["FNOL /<br/>Claim Intake<br/>Agent"]
        A2["Beneficiary<br/>Verification<br/>Agent"]
        A3["Document and<br/>Medical Evidence<br/>Agent"]
        A4["Policy<br/>Coverage<br/>Agent"]
        A5["Contestability /<br/>Exclusion<br/>Agent"]
        A6["Fraud / Risk<br/>Agent"]
        A7["Adjudication<br/>Assistant"]
        A1 ~~~ A5
        A2 ~~~ A6
        A3 ~~~ A7
    end

    FOUNDRY["Azure AI Foundry"]
    MODELS["Foundry Models / Azure OpenAI"]
    SAFETY["Content Safety"]

    CH --> PORTAL
    PORTAL --> AFD
    AFD --> APIM
    APIM --> BFF
    BFF --> ORCH
    ORCH --> FOUNDRY
    FOUNDRY --> MODELS
    MODELS --> SAFETY

    classDef edge fill:#EDF0F4,stroke:#1B2A41,color:#1B2A41
    classDef ai fill:#E4F1F2,stroke:#0F6E77,color:#1B2A41
    classDef guard fill:#FBF0DE,stroke:#B4690E,color:#1B2A41
    class CH,PORTAL,AFD,APIM,BFF edge
    class A1,A2,A3,A4,A5,A6,A7,FOUNDRY,MODELS ai
    class SAFETY guard

Figure 1 — End-to-end platform stack, from claimant channels to the model and content-safety layer.

Three things are worth noting about this path.

• Every external entry point passes Azure Front Door and WAF before Azure API Management. API Management is the enforcement point for authentication, rate limiting, payload inspection and — importantly — the only sanctioned route to downstream claims and policy systems.
• The Claims BFF exists so that the portal, mobile app and call-centre desktop share one composition layer with one set of claim-level authorisation rules, rather than each channel assembling claim data independently.
• Content Safety sits after the model layer, not around it. Life claims involve bereavement, medical detail and occasionally suicide-clause assessment; output handling needs to be deliberate rather than incidental.

3.1 The orchestration layer

The orchestration layer is where most life-specific value sits. Rather than one general assistant, it decomposes into agents with narrow, testable responsibilities — which matters because each one can then be evaluated, versioned and audited independently.

flowchart TD
    ORC["LIFE CLAIMS ORCHESTRATOR"]
    G1["Intake Agent"]
    G2["Evidence / Medical Agent"]
    G3["Coverage Agent"]
    G4["Risk Agent"]
    D1["Claim type<br/>Missing information<br/>Beneficiary identity"]
    D2["Document extraction<br/>Date validation<br/>Medical summary<br/>Missing evidence"]
    D3["Sum assured<br/>Riders<br/>Exclusions<br/>Waiting period"]
    D4["Fraud signals<br/>Inconsistencies<br/>Claim history<br/>Anomalies"]

    ORC --> G1
    ORC --> G2
    ORC --> G3
    ORC --> G4
    G1 -.-> D1
    G2 -.-> D2
    G3 -.-> D3
    G4 -.-> D4

    classDef ai fill:#E4F1F2,stroke:#0F6E77,color:#1B2A41
    classDef agent fill:#E8EDF6,stroke:#1B2A41,color:#1B2A41
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class ORC ai
    class G1,G2,G3,G4 agent
    class D1,D2,D3,D4 note

Figure 2 — Agent decomposition and the determinations each agent is responsible for.

The discipline here is that an agent's output is always a determination with supporting evidence, never a decision. The Coverage Agent does not approve a claim; it states the sum assured, the applicable riders, the exclusions it found and the clauses it relied on. The Risk Agent does not decline a claim; it surfaces signals and inconsistencies with references. That framing is what makes the downstream governance model possible.

3.2 Downstream domain services

Behind the orchestrator, three distinct capability groups serve very different data with very different handling requirements.

flowchart TD
    CO["Claims Orchestrator"]
    EP["Evidence Processing"]
    RAG["Policy Knowledge / RAG"]
    CT["Claims Tools"]
    ADI["Azure AI Document Intelligence"]
    AIS["Azure AI Search"]
    APIM2["Azure API Management"]
    E1["CLAIM EVIDENCE<br/>Death certificate<br/>Medical certificate<br/>Hospital records<br/>Diagnosis reports<br/>ID / KYC documents<br/>Beneficiary documents"]
    E2["ENTERPRISE KNOWLEDGE<br/>Policy wordings<br/>Riders<br/>Exclusions<br/>Contestability<br/>Procedures<br/>Regulations"]
    E3["CLAIMS SYSTEM<br/>FNOL<br/>Status<br/>Decision<br/>Payment"]
    E4["POLICY ADMIN<br/>Coverage<br/>Beneficiary<br/>Premium status"]

    CO --> EP
    CO --> RAG
    CO --> CT
    EP --> ADI
    RAG --> AIS
    CT --> APIM2
    ADI --> E1
    AIS --> E2
    APIM2 --> E3
    APIM2 --> E4

    classDef ai fill:#E4F1F2,stroke:#0F6E77,color:#1B2A41
    classDef svc fill:#E8EDF6,stroke:#1B2A41,color:#1B2A41
    classDef evidence fill:#F8EAE7,stroke:#9E3B2E,color:#23303F
    classDef knowledge fill:#E7F1EB,stroke:#2F6B4F,color:#23303F
    classDef sys fill:#EDF0F4,stroke:#1B2A41,color:#23303F
    class CO ai
    class EP,RAG,CT,ADI,AIS,APIM2 svc
    class E1 evidence
    class E2 knowledge
    class E3,E4 sys

Figure 3 — Evidence processing, policy knowledge retrieval and transactional claims tools.

Note the deliberate asymmetry. Evidence processing runs through Azure AI Document Intelligence into a claim-scoped evidence store. Policy knowledge runs through Azure AI Search over non-personal enterprise content. Transactional access to the claims system and policy administration platform runs through API Management, so that every read and write against a system of record is a governed, logged API call rather than a database connection. Section 8 returns to why the first two must never be merged.

4. The claims journey end to end

The full journey is twelve steps. The first six establish who is claiming, under what contract, and what evidence is required; the remaining six turn that evidence into a decision and a payment.

flowchart TD
    S1["1 · Claim notification / FNOL"]
    S2["2 · Identify claimant / beneficiary"]
    S3["3 · Retrieve policy"]
    S4["4 · Validate policy status"]
    S5["5 · Determine claim type"]
    S6["6 · Collect required evidence"]
    X4["In force?<br/>Lapsed?<br/>Reinstated?<br/>Rider applicable?"]
    X5["Death<br/>Critical illness<br/>Disability<br/>Hospitalisation<br/>Living benefit<br/>Waiver of premium"]
    X6["Death certificate<br/>Medical certificate<br/>Hospital / physician records<br/>Diagnosis evidence<br/>Claimant identity<br/>Beneficiary relationship<br/>Bank details"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6
    S4 -.-> X4
    S5 -.-> X5
    S6 -.-> X6

    classDef step fill:#EDF0F4,stroke:#1B2A41,color:#1B2A41
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class S1,S2,S3,S4,S5,S6 step
    class X4,X5,X6 note

Figure 4 — Steps 1–6: intake, identification, policy validation and evidence collection.

flowchart TD
    S7["7 · AI document extraction and validation"]
    S8["8 · Policy / coverage assessment"]
    S9["9 · Fraud / risk review"]
    S10["10 · Adjudication recommendation"]
    S11["11 · Final claims decision"]
    S12["12 · Beneficiary payment"]
    X8["Sum assured<br/>Rider coverage<br/>Waiting period<br/>Exclusions<br/>Contestability<br/>Premium status"]
    X10["Straight-through<br/>Refer<br/>Investigate<br/>Human review"]

    S7 --> S8 --> S9 --> S10 --> S11 --> S12
    S8 -.-> X8
    S10 -.-> X10

    classDef step fill:#EDF0F4,stroke:#1B2A41,color:#1B2A41
    classDef ai fill:#E4F1F2,stroke:#0F6E77,color:#1B2A41
    classDef out fill:#E8EDF6,stroke:#1B2A41,color:#1B2A41
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class S8,S9 step
    class S7,S10 ai
    class S11,S12 out
    class X8,X10 note

Figure 5 — Steps 7–12: extraction, coverage assessment, risk review, adjudication and settlement.

Two steps in this sequence are routinely underestimated.

Step 4 — policy status validation — is not a lookup. A policy that lapsed and was reinstated, or that was paid up under a waiver-of-premium rider, produces a materially different entitlement position than the current status field suggests. The determination has to be made as at the date of the insured event, not as at the date of the query.

Step 6 — evidence collection — is where most claims actually stall. Getting the required-evidence list right on first contact, and specific to the claim type and jurisdiction, is one of the highest-value applications of AI in the entire journey, and one of the lowest-risk: the model is helping a claimant understand what to send, not deciding anything.

5. Worked example: a death claim

Death claims make the control flow easiest to see, because each stage has a clear failure consequence.

flowchart TD
    D1["Death claim received"]
    D2["Beneficiary verification"]
    D3["Policy retrieval"]
    D4["Policy in force?"]
    D5["Death certificate validation"]
    D6["Cause of death extraction"]
    D7["Contestability check"]
    D8["Exclusion check"]
    D9["Fraud / risk assessment"]
    D10["Claim recommendation"]
    D11["Claims adjudicator"]
    D12["Payment authorisation"]
    C7["Within contestability period?<br/>Non-disclosure review<br/>Underwriting re-examination"]
    C8["Suicide clause<br/>Policy-specific exclusion<br/>Material misrepresentation"]

    D1 --> D2 --> D3 --> D4 --> D5 --> D6 --> D7 --> D8 --> D9 --> D10 --> D11 --> D12
    D7 -.-> C7
    D8 -.-> C8

    classDef step fill:#EDF0F4,stroke:#1B2A41,color:#1B2A41
    classDef human fill:#FBF0DE,stroke:#B4690E,color:#1B2A41
    classDef out fill:#E8EDF6,stroke:#1B2A41,color:#1B2A41
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class D1,D2,D3,D4,D5,D6,D7,D8,D9,D10 step
    class D11 human
    class D12 out
    class C7,C8 note

Figure 6 — Death claim flow, from notification to payment authorisation.

The contestability and exclusion checks deserve particular attention. Contestability is time-bound and jurisdiction-specific: whether the event falls inside the contestable window determines whether the insurer may re-examine the original underwriting disclosure at all. Suicide clauses operate on similar time boundaries with far greater sensitivity.

These are exactly the determinations that should never be produced by a model as free text. The AI layer establishes the facts — date of policy inception, date of event, cause of death as stated on the certificate, reinstatement history — and a deterministic rule engine evaluates them. The model reads the certificate; the rules decide what the certificate means for entitlement.

6. The claim evidence package

A life claim needs a first-class evidence artefact — not a folder of attachments and a case note, but a structured, versioned package that constitutes the complete basis of the decision.

The last three rows carry disproportionate weight. Recording the AI recommendation separately from the human decision is what makes the model's contribution auditable — including the cases where the adjudicator disagreed with it, which are the most valuable evaluation data the platform will ever produce.

7. Adjudication: who decides what

This is the governing control of the whole architecture. The AI layer never writes a decision to the claims system. It produces a recommendation, and that recommendation enters a domain service that applies deterministic rules before anything becomes binding.

flowchart TD
    AI["AI / Agent Layer"]
    REC["Recommendation"]
    API["Claims Adjudication API"]
    RULES["Coverage rules<br/>Beneficiary validation<br/>Contestability rules<br/>Exclusion rules<br/>Fraud controls<br/>Approval threshold"]
    HUMAN["Human approval where required"]
    CORE["Core Claims System"]
    PAY["Payment System"]

    AI --> REC --> API
    API -.-> RULES
    API --> HUMAN --> CORE --> PAY

    classDef ai fill:#E4F1F2,stroke:#0F6E77,color:#1B2A41
    classDef svc fill:#E8EDF6,stroke:#1B2A41,color:#1B2A41
    classDef human fill:#FBF0DE,stroke:#B4690E,color:#1B2A41
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class AI,REC ai
    class API,CORE,PAY svc
    class HUMAN human
    class RULES note

Figure 7 — Recommendation, deterministic control, human approval, settlement.

Two properties follow from this shape, and both matter to regulators.

1. Explainability is structural, not emergent. The reason a claim was approved or declined can be stated in terms of named rules and cited evidence, because the rules — not the model — produced the outcome.
2. The model can be changed without recertifying the decision logic. Upgrading a model, or swapping one, alters the quality of the recommendation and the extraction, not the adjudication criteria. That separation is what makes the platform maintainable over a five-year horizon.

Straight-through processing is still achievable within this model — for clean, low-value, non-contestable claims where every rule passes and no risk signal fires. The point is that straight-through is a deliberate policy decision expressed in thresholds, not a byproduct of the model being confident.

8. Data separation: knowledge is not evidence

The single most common architectural mistake in insurance AI programmes is treating all documents as RAG content. Policy wordings and a claimant's hospital records end up in the same index, retrieved by the same service identity, under the same access model. That is a data protection incident waiting for an audit.

flowchart TD
    subgraph K["ENTERPRISE KNOWLEDGE RAG"]
        K1["Policy wordings<br/>Claims manuals<br/>Product rules<br/>Regulatory guidance<br/>SOPs"]
        K2["Broad retrieval scope<br/>Role-based access<br/>Reusable across claims<br/>Non-personal content"]
        K1 --- K2
    end

    subgraph V["CLAIM EVIDENCE STORE"]
        V1["Medical records<br/>Death certificates<br/>Beneficiary data<br/>Claim forms<br/>KYC<br/>Investigation evidence"]
        V2["Claim-level access control<br/>Very limited retrieval scope<br/>Purpose-bound to one claim<br/>Full audit trail on every read"]
        V1 --- V2
    end

    SEP["Separate stores · separate identities · separate retrieval paths"]
    K --> SEP
    V --> SEP

    classDef knowledge fill:#E7F1EB,stroke:#2F6B4F,color:#23303F
    classDef evidence fill:#F8EAE7,stroke:#9E3B2E,color:#23303F
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class K1 knowledge
    class V1 evidence
    class K2,V2,SEP note

Figure 8 — Enterprise knowledge and claim evidence require different stores and different access models.

Enterprise knowledge is reusable, non-personal and broadly retrievable: policy wordings, claims manuals, product rules, regulatory guidance, standard operating procedures. Any assessor working any claim may legitimately retrieve it.

Claim evidence is the opposite on every axis. Medical records, death certificates, beneficiary data, KYC and investigation material are personal, special-category and purpose-bound. Retrieval must be scoped to the specific claim, tied to the identity of the person or process acting on that claim, and logged. A model working claim 10042 must be structurally incapable of retrieving evidence from claim 10041 — not merely prompted not to.

For a life insurer this is also a medical-information separation problem, and it is worth stating that explicitly to stakeholders. Medical evidence should not become generic RAG content under any circumstances.

9. Zero-trust and regulatory controls

Described as a whole, the solution is a stack of planes, each with its own trust boundary, wrapped in a consistent set of Azure platform controls.

flowchart TD
    subgraph ZT["ZERO-TRUST CONTROL WRAP"]
        P1["Experience Plane"]
        P2["Claims Intake Plane"]
        P3["AI / Agentic Processing Plane"]
        P4["Life Insurance Evidence Plane"]
        P5["Claims Domain / Adjudication Plane"]
        P6["Policy / Customer / Medical / Fraud Systems"]
        P7["Payment / Settlement Plane"]
        ZTN["Entra ID · Managed Identity · Private Link · Key Vault<br/>Azure Firewall · Defender · Sentinel · Purview<br/>Azure Policy · Immutable audit logging"]
        P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7
        P7 ~~~ ZTN
    end

    classDef plane fill:#EDF0F4,stroke:#1B2A41,color:#1B2A41
    classDef ai fill:#E4F1F2,stroke:#0F6E77,color:#1B2A41
    classDef evidence fill:#F8EAE7,stroke:#9E3B2E,color:#23303F
    classDef human fill:#FBF0DE,stroke:#B4690E,color:#1B2A41
    classDef note fill:#FFFFFF,stroke:#4A5B70,color:#23303F,stroke-dasharray: 4 3
    class P1,P2,P6,P7 plane
    class P3 ai
    class P4 evidence
    class P5 human
    class ZTN note

Figure 9 — Architecture planes and the zero-trust control wrap.

None of these are unusual on their own. What matters is that they apply uniformly across the AI planes, which is precisely where AI initiatives tend to acquire exceptions — a public endpoint for convenience during a pilot, a shared key for a demo, an index without classification. In a life claims context those exceptions are not technical debt; they are regulatory findings.

10. An adoption path

This architecture does not have to be delivered at once, and it should not be. A workable sequence puts the lowest-risk, highest-friction problems first and defers anything decision-adjacent until the evidence and audit foundations are real.

1. Evidence guidance and intake quality. Help claimants and call-centre staff establish the correct evidence list for the claim type. No decision authority, immediate cycle-time benefit.
2. Document extraction and validation. Automate extraction from certificates and clinical documents into the evidence package, with human confirmation on every extracted field that feeds a rule.
3. Coverage and contestability assembly. Assemble the facts a rule engine needs — dates, statuses, riders, reinstatement history — and present them to the assessor as a structured position.
4. Adjudication recommendation. Introduce a recommended outcome alongside the assessor's own assessment, and measure agreement before it influences workflow routing.
5. Selective straight-through processing. Only after the preceding stages have produced sustained agreement data, and only within explicit thresholds.

Each stage produces value on its own, and each produces the evaluation data needed to justify the next one to a risk committee.

11. Conclusion

The reason to describe this work as a claims adjudication platform rather than an AI assistant is not presentation. It is that the two framings lead to different architectures, and only one of them survives contact with a life insurance regulator.

An assistant framing puts the model at the centre and treats governance as constraint. A platform framing puts the evidence package and the adjudication service at the centre, and treats the model as a highly capable component that gathers, extracts, compares, summarises and recommends — extremely well, and without authority.

For life claims specifically, that division of labour is not a limitation of current models. It is the correct allocation of accountability for a decision that determines whether a bereaved family is paid what a contract promised them. The architecture should make that allocation explicit, visible and impossible to bypass.

FNOL → Beneficiary Verification → Evidence → Coverage → Contestability → Risk → Adjudication → Human Review → Settlement