An AI that routes motor claims, from the insurer's own framework to a DORA report

Why claims triage owes anything at all

A motor claims assistant is not in Annex III of the EU AI Act (Regulation (EU) 2024/1689). The insurance use case there, point 5(c), is risk assessment and pricing for life and health insurance, and the Commission's draft guidelines on classifying high-risk systems (19 May 2026) say that motor insurance is not covered by it, and that a system checking whether a claim is valid, or how much to pay, falls outside it. The guidelines are still a draft, and the classification is the insurer's to make: it records its call on the profile.

• The AI Act still reaches it in two places. Claimants chat with the assistant, so they must be told they are dealing with an AI system unless that is obvious (Art. 50(1)), which applies from 2 August 2026. And a referral to fraud investigators has to rest on the claim's facts, not on who the claimant is: assessing a person's risk of offending from profiling alone is prohibited (Art. 5(1)(d)), and the Commission's guidelines on prohibited practices place an insurer's ordinary checks in its own interest outside that prohibition.
• DORA (Regulation (EU) 2022/2554) applies to insurance undertakings (Art. 2(1)(n)), and has since 17 January 2025. The model provider's contract goes in the register of information (Art. 28(3)), and when the provider fails, the incident is classified and, if major, reported (Arts. 18–19). The insurer classifies claims handling as a critical or important function, which adds testing at least yearly (Art. 24(6)) and an exit strategy from the provider (Art. 28(8)).
• Under the GDPR, a decision based solely on automated processing may not rest on health data unless the claimant has given explicit consent or there is a substantial public interest, with suitable safeguards (Art. 22(4)), and injury claims carry health data. The routing policy below keeps every claim that reports an injury for a person.
• EIOPA's Opinion on AI governance and risk management (EIOPA-BoS-25-360, 6 August 2025) says what supervisors expect of AI in insurance that is neither prohibited nor high-risk under the Act: a risk-based approach, fairness and ethics, data governance, record keeping, transparency and explainability, human oversight, and accuracy, robustness and cybersecurity. It sets no new requirements; it reads existing ones — Solvency II's system of governance, the Insurance Distribution Directive, DORA — for AI. EIOPA's first focus area for 2027 is DORA compliance, including compliance with the Opinion (EIOPA-BoS-26/235).

No built-in pack covers the Opinion, so Example Insurance writes its own, below, and adopts it with the EU AI Act and DORA packs. A framework pack maps a framework's requirements onto Deliverd's common controls as a starting point for your own review. It is not legal advice and does not establish that any use complies with the framework. Whether a requirement applies, and whether the mapped controls meet it, is for your organisation to decide.

The assistant, and what the work owes

Claims operations registers the assistant once, as an AI system on Example Models' model, in production (register_ai_system, or in the app). The work it does — routing motor claims — is a governed task, and its profile says what kind of work it is:

The insurer's own framework

Compliance adds the one control its mapping needs that no common control covers — a fairness review, paragraph 3.15 — and the agent drafts the framework from the Opinion (create_custom_framework). A draft holds nothing to anything. The agent's attempts to publish it, or to adopt it, are refused; compliance reads it, publishes it and adopts it.

With the three packs, the profile owes these 24 controls. Six are met by what the profile already records, sixteen need evidence and two need a person's approval. Of the EU AI Act, only Art. 50 reaches this work. Nobody wrote this list: Deliverd works it out from the profile and the packs, and the integration test holds the page to it.

One bar for every claims model

The actuarial function sets the organisation's bar for model evaluation once, in the app, and every governed task without a bar of its own is judged against it. No key can set it: whatever submits the results must not also decide what passes.

Both are Langfuse scores over 400 historic claims that senior handlers routed. route_correct is whether the assistant chose their route; injury_detected is scored only on the 120 claims that report an injury, and is whether the assistant flagged it.

The build pulls the evaluation from Langfuse

Claims operations connects the insurer's Langfuse project in the app, as a person: the key is tried against Langfuse, sealed, and never handed back. The build names the experiment, and holds no Langfuse key:

deliverd governance evidence $TASK --langfuse motor-triage-v3 --control model_evaluation

The routes are good enough; the injuries are not. Three claims that reported an injury went unflagged, each listed with a link to its trace in Langfuse. That matters more than the number suggests: the routing policy below lets a small claim through on the fast track only when it reports no injury, and it is the assistant that says whether a claim does. The bar on injury_detected is what makes that rule safe to write. The gate stays closed, and the task says why: injury_detected was 0.975; the threshold is >= 0.99.

The team rewrites the chat's questions about injuries, and motor-triage-v4 meets the bar. The other fifteen pieces of evidence are documents people write, sent the same way with deliverd governance evidence $TASK --type … --title … --control …, or added on the task's page:

Compliance approves the release and the head of motor claims approves going live (request_control_approval), and the gate opens.

A policy says what the assistant may do

The assistant's authority is a policy, not a prompt. Claims operations registers what it does as an action, claims.route — the claim, the route, the amount and whether an injury is reported — and writes the policy against it, from their own key:

deliverd actions push --file claims.actions.json
deliverd policy push --file claims-routing.policy.json --activate

An agent's key is refused both. A policy decides when an agent needs a person, so an agent that could write one would decide that for itself. The first rule that matches decides:

Before each route the assistant asks (check_gate), and the product answers from the policy in force:

The senior handler approves MC-26-10932: “Soft-tissue injury, GP's note attached. Fast track, with the injury handled as its own claim.” The SIU lead turns MC-26-10933 down: “The second key is with the finance company, as the claimant said. Standard handling.” The assistant routes it to standard handling instead, which the policy allows. Each permission is used once, and the assistant records that it acted. No key decides an approval, the assistant's included.

The provider goes down

At 07:10 the assistant's calls to Example Models start failing. The agent reports an incident against the AI system (report_ai_incident) at high severity, which closes the gate on the work. First notice moves to the phone line, and handlers triage by hand under the continuity plan.

An agent cannot classify an incident: one that could call an outage minor would stop its own reporting clock. At 09:30 the head of ICT risk classifies it from the facts:

Critical services were affected and two criteria met their thresholds, so it is major (Commission Delegated Regulation (EU) 2024/1772, Art. 8). The initial notification is due by 13:30: 4 hours from classification, which comes before 24 hours from detection (Commission Delegated Regulation (EU) 2025/301, Art. 5).

The agent drafts it (draft_incident_report), and it goes to compliance to sign off. Only once it is approved can the head of ICT risk record it as filed, with the authority's reference, IR-2026-0117. The intermediate report is then due within 72 hours, and the final report a month after the last intermediate one; Deliverd works out each deadline, and files nothing itself.

The register had already said how much rested on this provider (get_ict_register): two of the insurer's three AI systems, both in production, one of them supporting a critical function, and hard to replace. The provider restores service after 30 hours; the head of ICT risk resolves the incident, and the gate opens again.

What the supervisor gets

One evidence pack for the work (get_evidence_pack, or Evidence pack on the task's page), with a sha256 digest so a copy can be checked against the one that left:

• The AI system, its contract with the provider, and what the register says of it.
• Each control, how it was met, and the requirements behind it: the AI Act, DORA and the EIOPA Opinion as the insurer mapped it.
• The bar, who set it, and each Langfuse run judged against it.
• Each approval with who was asked and who decided.
• The incident: its classification and the facts behind it, its deadlines, each report, who signed it off and when it was filed.
• The audit timeline of the work.

Each route the assistant asked for — what it asked, the rule that decided, and who approved — is on its gate and in the organisation's audit trail, not in the work's pack. The register of information exports on its own, in the shape of the templates of Commission Implementing Regulation (EU) 2024/2956.

The pack assists audit; it does not certify compliance with any law, and says so in its own text. Compliance Mode is in Business and Enterprise, and policies for an agent's actions are in Business and Enterprise; framework packs, an organisation's own frameworks and the ICT register, which this story uses, are in Enterprise.