MICKAI®ArticlesWhat an Insurer Must Show a Regul…
Article · 8 July 2026

What an Insurer Must Show a Regulator About Its AI

A supervisor expects an insurer to reconstruct any AI decision on demand: the model version, the inputs, the oversight and an unaltered record.

Author
Micky Irons
Published
8 July 2026
Follow Micky Irons
LinkedInX
insuranceeu ai actai governanceregulatory supervisionaudit trail
What an Insurer Must Show a Regulator About Its AI

An insurer must be able to reconstruct any AI-assisted decision on demand and show five things about it: the exact model version that produced the outcome, the inputs that model received, the human oversight applied to it, the governance over the data behind it, and an unaltered record that ties those four together. Regulators do not primarily ask whether a model is accurate. They ask whether the insurer, and not a vendor, can account for what the model did, because supervision rests on evidence the firm controls rather than assurances it has bought.

This question has sharpened in 2026. Insurance sits in the high-risk column of the EU AI Act, and the same expectation is arriving through UK and global supervisors who treat model governance as core prudential risk. The obligations once due on 2 August 2026 have moved, but the direction of travel has not. An insurer that cannot produce its own evidence is exposed whichever framework reaches it first.

What exactly must an insurer be able to produce?

A supervisor is not testing the cleverness of the model. It is testing whether the firm can answer a specific decision with a specific record. In practice an insurer should hand over the following for any underwriting, pricing, claims or fraud decision:

  • The model version and configuration that were live at the moment of the decision, not the version running today.
  • The exact inputs the model received, including the data fields and their provenance.
  • The human oversight applied: who could override the output, whether they did, and when.
  • The data governance behind the inputs: lawful basis, quality controls, retention and access.
  • An unaltered record that binds all of the above to a timestamp and cannot be edited after the fact.

If any of these five cannot be produced, the insurer relies on trust, and supervision does not run on trust.

Why has supervision shifted from the result to the record?

Older oversight looked at outcomes: was the pricing fair, was the loss ratio sound. AI systems change faster than an annual review can track. A model can be retrained, a prompt altered, a threshold nudged, and the outcome can look identical while the reasoning has changed entirely. So supervisors now ask for the record, because only the record shows what the system actually did on a named date for a named policyholder. The centre of gravity has moved from the answer to the ability to prove it.

Supervision is no longer a test of the model; it is a test of whether an insurer can prove, without trusting anyone, exactly what the model did.

Which rules make this necessary?

Several frameworks converge on the same demand for an accountable record. The EU AI Act places insurance pricing and risk assessment in Annex III as high-risk, which carries duties on logging, human oversight, data governance and technical documentation. Those Annex III obligations, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read this as a build window, not a reprieve. Alongside it, DORA demands operational resilience and traceability, NIS2 raises security governance, GDPR governs the lawful basis for automated decisions, and ISO/IEC 42001 offers a management-system standard for AI that auditors recognise.

Why is a public cloud AI service hard to show a regulator?

Public cloud services such as ChatGPT, Claude or Gemini are governed by the vendor, not the insurer. The insurer often cannot pin the exact model version, guarantee the inputs stayed in jurisdiction, or produce an unaltered record it alone holds. The US CLOUD Act can reach data held by a US provider wherever it sits, which creates jurisdictional exposure for a European insurer. A contractual promise is not a technical guarantee, and sending underwriting data to a shared service can create risk to confidentiality and legal privilege rather than remove it. This describes exposure an insurer must answer for, not a breach asserted as settled fact.

How does a sovereign architecture support the duty?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, so the insurer holds the model, the data and the record in one place under its own control. A zero-egress inbound perimeter keeps data inside the estate. Hardware-attested identity binds every action to a verified operator and machine, and writes that identity into the audit chain. Every decision is written to a post-quantum signed audit ledger, using the ML-DSA signature standard defined in FIPS 204, so the record can be verified offline and shown to be unaltered; key material is protected with the separate ML-KEM standard in FIPS 203. Cross-model consensus lets more than one sovereign model check a high-stakes output before it stands. We do not claim this satisfies or guarantees any regulation, only that it supports the insurer's duty to produce evidence it controls.

What can an auditor actually check?

The plain test is reconstruction. Give the auditor a single past decision and ask the insurer to rebuild it offline: the model version, the inputs, the oversight and the signed record, with no third party and no gap in the ledger. If the ledger signature verifies and the reconstruction matches, the firm can account for its AI. If the record can be edited, is held only by a vendor, or cannot be tied to a specific model version, the reconstruction fails. This engineering work sits within a wider estate of 104 filed UK patent applications, 2,340 claims, owned by Mickai LTD, all patent pending and never granted or patented.

What should insurers do before 2 December 2027?

Treat the deferral as time to build the record, not to defer the work. Inventory every AI-assisted decision point, decide where each model and its data will physically run, and put an unaltered, verifiable log under the insurer's own control. Firms that reach the deadline able to reconstruct a decision on demand will answer a supervisor in an afternoon. Firms still depending on vendor assurances will be answering questions they cannot evidence.

Frequently asked questions

What does a regulator actually ask an insurer to prove about its AI?

A regulator asks the insurer to reconstruct a specific decision: the live model version and configuration, the inputs the model received, the human oversight applied, the data governance, and an unaltered record binding them. The point is accountability, so the insurer must control the evidence rather than point to a vendor.

Is 2 August 2026 still the deadline for high-risk insurance AI under the EU AI Act?

No. The Annex III high-risk obligations that once fell on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028. The Article 50 transparency duties are largely unchanged. We read the deferral as a build window, not a reprieve.

Can an insurer use ChatGPT or Claude for underwriting and still satisfy a supervisor?

It is difficult, because a public cloud service is governed by the vendor, not the insurer. The firm may be unable to pin the exact model version, keep data in-jurisdiction, or hold an unaltered record itself, and the US CLOUD Act adds jurisdictional exposure. That is supervisory risk rather than a guaranteed breach, but risk the insurer must be able to answer for.

How does a signed audit ledger help in a regulatory review?

A signed ledger records each decision with a cryptographic signature checkable offline, so an auditor can confirm the record has not been altered. The FIPS 204 ML-DSA post-quantum signature standard means verification holds even against future quantum attacks. It supports the insurer's duty to produce a trustworthy record, without claiming to certify compliance.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/what-an-insurer-must-show-a-regulator-about-its-ai. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles
18 Aug 2026
How Telecoms Operators Meet the Telecommunications Security Act With AI That Never Leaves the Network
Telecoms operators meet the Telecommunications Security Act code of practice with AI that runs inside the security-critical boundary on operator-owned hardware. A zero-egress perimeter keeps network configuration and signalling data within operator control, so nothing sensitive crosses out to a public cloud service.
18 Aug 2026
Can energy operators run AI on grid and OT data on-premise to satisfy the Cyber Assessment Framework?
Yes. Energy operators can run forecasting and anomaly detection on grid and OT data entirely on their own hardware, and this satisfies the Cyber Assessment Framework more cleanly than cloud analytics, because telemetry never leaves the audited perimeter and no third-party processor exists to assess.
18 Aug 2026
How Airports Meet EASA Part-IS from February 2026 with On-Site AI
Part-IS applies to aerodrome operators from 22 February 2026 and makes the airport, not its vendor, accountable for information-security risk. Running AI on operator-owned hardware behind a zero-egress perimeter keeps passenger and operational data inside that boundary, so a supplier's SOC 2 cannot discharge it.
18 Aug 2026
Can Automotive Suppliers Use AI on OEM Design Data While Keeping TISAX Prototype Protection?
Automotive suppliers can run AI on OEM design and prototype data and keep TISAX prototype protection, but only when the model runs on their own hardware inside the protected zone. Public cloud AI transmits the data outward, which prototype protection forbids.