Industries/InsurTech/AI claims triage + initial decisioning
AI claims triage + initial decisioning
Claims-decisioning AI sits at the intersection of GDPR Art. 22 (legal effects on policyholders), IDD Art. 25 product-oversight, and AI Act §5(c) for life + health insurance. EIOPA supervisory expectations push toward per-decision explainability. Promethean records every triage verdict as an L12 entry — the spec, the model, the human reviewer sign-off on high-value claims.
What this is
AI claims triage classifies incoming claim submissions into settlement-track buckets: auto-settle (low-value, low-fraud-signal, simple), investigate (suspect, complex), decline (clear policy-exclusion). The classifier output is typically closed-enum verdict + confidence + rationale, with always-human review on high-value claims and on declines.
Regulatory perimeter: GDPR Art. 22 applies — a declined claim is a legal effect; meaningful human intervention required. IDD Art. 25 requires product-oversight + governance evidence for AI-driven distribution + claims decisioning. For life + health insurance specifically, AI Act Annex III §5(c) makes risk-assessment + pricing AI high-risk (with downstream effects on claims-triage AI feeding the same risk models). EIOPA's 2021 AI governance principles + ongoing supervisory statements push toward explainability + per-decision auditability.
Promethean records each triage decision as an L12 entry. The closed-enum output schema bounds the model; the reviewer-gate primitive captures always-human review on declines + high-value settlements; the chain export is the evidence layer for IDD POG annual reviews, EIOPA inspections, and Art. 22 challenges.
Regulatory pressure specific to AI claims triage + initial decisioning
EU AI Act Annex III §5(c) — life + health insurance
AI for risk assessment and pricing in life and health insurance is high-risk. Full Chapter II applies (Articles 9-15 + Annex IV technical documentation).
Official source ↗IDD Art. 25 — product oversight + governance (POG)
Insurance distributors + manufacturers must operate a product-oversight process. AI-driven claims decisions are inside the POG scope; the substrate's chain feeds the annual POG review.
Official source ↗EIOPA AI Governance Principles (June 2021)
Supervisory expectations on AI use in insurance: explainability, fairness/non-discrimination, governance, robustness, oversight + control. Per-decision evidence underpins all five.
Official source ↗GDPR Art. 22 — automated claim decisions
Claim declines and material settlement-amount decisions produce legal effects. Solely-automated decisions need explicit consent or contractual necessity + meaningful human intervention.
Official source ↗How Promethean addresses this
Per-claim decision provenance
Each L12 entry carries specHash + modelIdentity + inputHash + outputCanonicalHash + reviewerVerdict. The supervisor asking 'why did your AI triage this claim to auto-settle / decline' gets a structured, verifiable answer.
Always-human review on declines + high-value (Art. 22 + IDD)
Reviewer-gate primitive: always-human for decline + threshold-triggered for high-value settlements. The L12 entry records the reviewer identifier + verdict. Override rate over time is the meaningful-intervention evidence.
IDD POG annual review evidence
Time-bounded chain export with verdict + category + reviewer-verdict + fallback statistics. The POG annual report references the chain export as the empirical evidence layer; the operator's analytics + management commentary sits on top.
EIOPA explainability on demand
Spec definition + outputCanonicalHash + per-call rationale (length-bounded by schema) per L12 entry. For a specific claim, the operator can reproduce 'here is the spec + the rationale + the reviewer verdict' — verifiable against the chain by an external auditor.
Reinsurer + large-carrier audit demands
Per-customer (carrier / reinsurer) audit bundle via tenantId filtering. The carrier's audit team verifies with verify.mjs against the bundle, scoped to their MGA portfolio.
What this looks like in practice
Hypothetical: EIOPA-coordinated supervisory inspection of an MGA's claims-AI
An MGA running AI claims-triage across health + life portfolios gets an EIOPA-coordinated national supervisory inspection. The supervisor wants: (1) explainability evidence per claim decided in Q3, (2) demonstration that high-value claims went to human review, (3) per-decision pricing-feedback reproducibility under Art. 22 challenges. Without Promethean: months of cross-referencing claims-system exports with model-deployment logs, partial reconstruction. With Promethean: chain-export filtered to Q3 + outputCategory=auto-settle | investigate | decline; reviewer-verdict distribution shows always-human on declines (Art. 22 satisfied); specHash sequence shows two documented model versions with transition dates; fallback rate over the window is 2.1% — within risk-management plan. Supervisor runs verify.mjs against the chain. The inspection concludes with corrective recommendations rather than enforcement.
Frequently asked
We're an MGA, not the underwriting carrier. Does AI Act §5(c) still apply to our claims AI?
Yes — AI Act §5(c) applies to the AI system regardless of who legally underwrites the risk. Whether you're the MGA, the claims-handling TPA, or the underwriting carrier, the high-risk classification attaches to the AI. Practically, this means the AI Act obligations cascade through your supply chain: the carrier wants evidence from the MGA; the MGA wants evidence from its claims-AI vendor (if applicable). Promethean's per-decision chain is the evidence layer everyone in the chain references.
Solvency II + ORSA — how does Promethean fit?
Solvency II Art. 45 ORSA evaluates the carrier's own risk + capital adequacy, including operational risk from outsourced or AI-supported decisioning. The L12 chain feeds the operational-risk component of the carrier's ORSA — per-decision evidence on AI reliability (fallback rate, schema-validity, reviewer-override rate). For MGAs, you're a third-party ICT provider under DORA Art. 28 to the carrier — the chain serves the carrier's DORA register-of-information for you.
Claims-LLM hallucination — what happens when the AI invents a coverage exclusion?
The closed-enum output schema prevents free-text invention. Your spec declares the valid output categories (e.g. settle / investigate / decline + exclusion-reason-code from a closed enum); the substrate validates output against this. Invalid output triggers the fallback handler (typically queue-for-review). The L12 entry records schemaValid: false + fallbackTriggered: true. A fallback firing on a coverage-exclusion case sends it to human review, not auto-decline — exactly the safety property regulators want.
Can the chain feed our DORA Art. 17/18 incident-classification workflow?
Yes. When AI claims-triage misbehaves (false-positive surge in fraud-flag, drift in settlement-amount recommendations), the chain provides the precise time window via recordedAtIso. fallbackTriggered + schemaValid count over the window give the incident impact metric DORA Art. 18 demands. The 24h early-warning + 72h notification under Art. 19 become reconstructable from verified data rather than narrative.