Industries/InsurTech/AI underwriting + pricing
AI underwriting + pricing
Underwriting + pricing AI in life and health insurance is explicitly high-risk under EU AI Act Annex III §5(c). The Annex IV technical-documentation burden + EIOPA's explainability expectations are non-negotiable. Promethean is the per-decision evidence layer that makes Annex IV documentation generatable from production data, not authored as a separate compliance artifact.
What this is
AI underwriting + pricing in life + health insurance typically produces: a risk-band classification (preferred / standard / substandard) from applicant data, a recommended premium adjustment + reasoning, and (sometimes) a recommended exclusion-list per policy. The decisions feed into the binding underwriter or — in fully-automated tiers — into the policy issuance directly.
AI Act Annex III §5(c) is the most explicit high-risk classification for insurance AI. Full Chapter II obligations attach: Art. 9 (risk management), Art. 10 (data governance + training-data lineage), Art. 11 (technical documentation per Annex IV), Art. 12 (record-keeping), Art. 13 (transparency to deployers), Art. 14 (human oversight), Art. 15 (accuracy + robustness + cybersecurity).
Promethean ships the per-decision evidence layer that maps directly to several Chapter II obligations — Art. 12 (record-keeping is exactly what the L12 chain is), Art. 14 (reviewer-gate evidence), Art. 15 (fallback-rate + schema-validity rate). For Art. 10 + Art. 11, the substrate supplies the documentation-generation primitives (Enterprise tier framework handoff templates); the operator's actuarial + risk-management functions sit on top.
Regulatory pressure specific to AI underwriting + pricing
EU AI Act Annex III §5(c) — life + health risk assessment + pricing
AI for risk assessment and pricing in life and health insurance is high-risk. Full Chapter II obligations — risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11 + Annex IV), record-keeping (Art. 12), transparency (Art. 13), human oversight (Art. 14), accuracy/robustness (Art. 15).
Official source ↗GDPR Art. 22 — solely-automated decisions
Pricing decisions producing legal effects or similarly significant effects require explicit consent or contractual necessity + meaningful human intervention. Post-Schufa CJEU, scoring-style processing materially influencing pricing is in scope.
Official source ↗IDD Art. 25 — product oversight + governance (POG)
Insurance manufacturers + distributors must operate a product-oversight + governance process. AI-driven pricing decisions require per-decision traceability + an annual POG review.
Official source ↗Solvency II Art. 45 — ORSA
Own Risk and Solvency Assessment includes the operational risk arising from AI-supported decisioning. The carrier's ORSA references per-decision evidence on AI reliability for the operational-risk component.
Official source ↗How Promethean addresses this
AI Act Annex IV technical documentation
Annex IV expects: detailed description of the AI system, its elements + integration with the broader product, training methodologies + data, validation + testing procedures, monitoring + control mechanisms. Promethean's Enterprise tier generates the Annex IV-mapped contribution from the workspace's actual state (per-spec definitions, model identity, reviewer policy, fallback behaviour, anchor cadence). Your actuarial + ML-engineering teams provide the rest.
Art. 12 record-keeping
L12 chain is the record-keeping mechanism. Each pricing decision is an entry with specHash + modelIdentity + inputHash + outputCanonicalHash. Retention is operator-controlled (the substrate doesn't auto-delete); the chain is tamper-evident across the policy lifecycle.
Art. 15 accuracy + robustness
Fallback rate + schema-validity rate computable from the chain are direct proxies for the operating-envelope metrics Art. 15 demands. Drift detection is a chain-export query (fallback rate over rolling 30 days), not a separate analytics dashboard.
Reproducibility on supervisor demand
specHash + inputHash + modelIdentity per L12 entry mean a specific pricing decision is reproducible from its inputs + model version. For deterministic models, full byte-equivalence; for stochastic, the chain proves the configuration that was active. This is the foundation of explainability that EIOPA + national supervisors are increasingly demanding.
Multi-carrier-customer audit isolation
For underwriting-AI platforms serving multiple carriers (MGA platforms, vendor underwriting engines), R4 tenantId on each L12 entry lets the platform issue per-carrier audit bundles. Each carrier's actuarial + risk team verifies with verify.mjs against their own slice.
What this looks like in practice
Hypothetical: EU AI Office reading-room inspection of an AI-driven pricing engine
A digital life-insurance SMB receives an EU AI Office reading-room request following a customer complaint about premium pricing. The AI Office wants: (1) the Annex IV technical documentation, (2) evidence of human oversight on the pricing decisions in the affected window, (3) demonstrable reproducibility on the specific contested premium calculation. Without Promethean: a 40-page Annex IV doc authored over six weeks + a defensive narrative on oversight + a regression run that's not the original computation. With Promethean: Annex IV-mapped handoff packet generated from the workspace (Enterprise tier) — Annex IV.A.1-2-3 covered by the substrate's per-spec definitions; chain-export for the affected window shows reviewer-gate firings + override-rate + fallback-rate; the specific premium-calculation chain entry is reproducible via inputHash. AI Office runs verify.mjs against the chain. Inspection concludes with corrective recommendations rather than enforcement.
Frequently asked
Annex IV documentation is huge. Does Promethean really generate it?
Promethean generates the substrate-side contribution to Annex IV — sections covering the AI system's architecture from the substrate's perspective (specs, model identities, output schemas, reviewer policies, fallback behaviours, recording mechanisms). The actuarial + data-science contribution (training methodology, dataset lineage, validation procedures, fairness analysis) is operator-side. Most insurtech SMBs find the substrate-side handoff packet shortens the operator-side Annex IV authoring effort by 30-50%, because the substrate sections are auto-generated against the workspace's actual state.
Pricing AI is often a complex ensemble — gradient-boosted trees, LLM rationale, lookup tables. Does Promethean handle that?
Yes. The substrate's spec abstraction works at the decision level — what's being decided, with what inputs, with what valid outputs. Underneath, your pricing engine can be any combination of ML + rules + lookups. Each consequential decision becomes an L12 entry with the spec hash binding the configuration that produced it. The substrate doesn't care about the internal architecture; it cares about the per-decision evidence.
We don't sell directly — we sell into carriers. How does the audit chain work across boundaries?
The chain is operator-side. If you're the underwriting-AI vendor and the carrier is your customer, the chain belongs to whoever owns the workspace (typically the carrier in this configuration; or you, with per-carrier tenant filtering). When the carrier's supervisor inquires, the carrier (or you, on their behalf) exports the relevant chain slice + hands it over. The audit trail crosses the contractual boundary cleanly because verify.mjs is operator-independent.
How does this affect our reinsurance arrangements?
Reinsurers increasingly demand per-decision evidence on the AI driving the underwriting they're taking risk on. The chain serves the reinsurer's diligence by providing a verifiable record of model identity + decisioning consistency over time. For larger treaties, the reinsurer may even request an independent reading of the chain via verify.mjs — this is increasingly common as reinsurers' own supervisors (Solvency II + EIOPA) scrutinise their AI-supported tail-risk assumptions.