Insurance reference architecture — EMENA

How an EMENA insurer deploys Operayde to keep underwriting AI inside jurisdiction, retain evidence under Solvency II timelines, and hold actuarial models under governance.

Regulatory context

An EMENA insurer sits at the intersection of Solvency II (prudential regime, model governance, ORSA), EIOPA's supervisory statements on AI (which read Solvency II Art. 41's system of governance into any AI touching underwriting or claims), and the data-protection floor of the jurisdiction it underwrites in — PDPL in the Kingdom, GDPR in the EU, DIFC DP Law No. 5 for the Dubai free zone. Operayde deploys as an on-premises appliance so that underwriting-decision AI, claims triage, and actuarial model copilots all run under one governance surface without exporting policyholder data.

Architecture

The insurer runs an appliance pair per underwriting region — one primary, one warm-standby — in the same jurisdiction as the book being underwritten. Workspace-runtime handles vLLM-compatible inference plus the RAG index that carries actuarial memoranda, reinsurance treaty text, and rating manuals. Appliance-gateway authenticates the underwriting workbench with ak_... keys scoped per line of business (motor, life, health, marine), and the audit-emitter chains every decision-relevant call into a tamper- evident log. The central plane holds only fleet telemetry and daily Merkle roots; policyholder PII and model prompts never traverse it.

Data residency

Underwriting decisions in the Kingdom must be produced by a model in the Kingdom. The operayde.residency rule pins each virtual key to its regulated region and denies any cross-region routing at the gateway boundary:

package operayde.residency
 
import rego.v1
 
default allow := false
 
allow if {
    input.source == "gateway"
    some region in input.params.virtual_key.residency
    region == input.ctx.region
}
 
reason := "region not in allowed residency" if {
    not allow
}

For a DIFC-issued underwriting key the residency list is ["ae-difc"]; a shared EU treaty-analysis key is scoped to ["eu-central", "eu-west"]. A policy-issue engine attempting to call a US-hosted model is denied and the denial is signed into the audit chain — evidence the insurer can attach to its ORSA report.

Audit evidence

Every underwriting-decision LLM call is chained into audit.events:

{
  "event_id": "01JC7CQ8H2M6P0R5T9V4W7Y3Z1",
  "prev_hash": "3a7bd3e2360a3d29eea436fcfb7e44c735d117c42d1c1835420b6b9942dd4f1b",
  "hash":      "1c9d0e7f8a3b5c2d4e6f8a0b1c3d5e7f9a1b3c5d7e9f0a2b4c6d8e0f1a3b5c7d",
  "signature": "MEUCIH...base64url-Ed25519...pQ==",
  "actor":     { "subject": "uw-motor-engine", "realm": "tenant:insurer-difc" },
  "tenant_id": "insurer-difc",
  "action":    "gateway.inference",
  "resource_uri": "model://claude-sonnet-4-6",
  "outcome_status": "ok",
  "occurred_at": "2026-07-13T11:12:04.902Z"
}

Under jurisdiction-specific data-preservation rules (Solvency II Art. 35 log retention, PDPL Art. 18 record-keeping), the appliance enforces a minimum retention of the audit chain locally and lets the insurer configure a maximum. Merkle-root export gives the insurer a proof of completeness that survives any later retention purge.

Actuarial model governance

Actuarial copilots run through a distinct virtual key with its own model allowlist — typically a locally-hosted 8B–70B model plus a capped external model for out-of-band research use. The insurer's model-risk-management function publishes the OPA policy that enforces "no exposure of proprietary rating tables to external models" and the appliance-gateway rejects any request that would violate it. Every actuarial call is logged with the model version and prompt, so the model-risk-management committee has an auditable record of what the copilot was asked and what it answered.

How this maps to the regulations

Requirement	Operayde surface	Evidence
Solvency II Art. 41 — system of governance for AI-assisted decisions	Per-LOB virtual key scoping + OPA policy bundle	Cosign-signed policy hash; audit chain of every AI call
EIOPA AI supervisory statement (2021) — traceability & documentation	audit-emitter chain + model manifest per appliance	Signed daily Merkle root; `/docs/appliance/model-cards`
PDPL Art. 18 / GDPR Art. 30 — record of processing	audit.conversations table + Merkle chain	Exportable per-tenant conversation log + daily hash

Deployment topology

The customer-hosted appliance is the trust boundary — no policyholder prompt or model response leaves the datacentre. Operayde's control plane receives (a) health and version telemetry and (b) daily Merkle roots over a mutually-authenticated reverse tunnel. Every operator action on the appliance requires step-up MFA every five minutes of privileged work, and every OPA policy change is cosign-signed before the appliance will load it.