Insurance readiness: a risk-mitigating technical measure for AI-exposed policies
PRML is an open, vendor-neutral primitive that lets an insured AI provider commit each evaluation claim cryptographically before the run, in a format any third party can re-verify. For D&O, cyber, and AI-specific liability underwriting, the manifest is a concrete, mechanically checkable risk-mitigating measure that can be referenced in policy precondition language without locking the insured into a single proprietary GRC vendor.
The underwriting question
By 2026, the major reinsurers and primary carriers writing AI exposure have moved past "loose self-attestation." Munich Re's Tech Trend Radar 2026 publicly tracked AI risk from "Assess" into "Adopt/Trial" status, meaning underwriting teams now expect to see evidence of an AI governance framework before binding, not just a yes/no checkbox on the application. On the casualty side, the rise in employment-practices and bias-related claims has pushed Hiscox, Allianz, AXA XL and similar carriers toward concrete preconditions for AI-touching exposures: documented testing procedures, immutable logging of accuracy and robustness checks, and a written commitment to evaluation methodology.
For the insured, that translates into a single hard question on a renewal call: how do you prove the accuracy and robustness claims you made about your AI system are the ones you actually tested, and that nobody quietly tuned the threshold after seeing the result?
If the answer is "we keep internal spreadsheets and a Jira ticket," the underwriting team has to either price the unknown in (higher premium, exclusions, sublimits), refer the risk to the carrier's AI risk committee, or decline. None of that is good for the insured or for the broker placing the risk.
What PRML provides, in one paragraph
PRML (Pre-Registered ML Manifest) is an open specification (CC BY 4.0) for committing an ML evaluation claim to a SHA-256 hash before the run. The manifest fixes eight fields, including the metric, comparator, threshold, dataset hash, seed, and model identifier. Once the hash is published to a durable public record, any party with the manifest can re-derive the hash and check it against the commit. Retroactive tuning of the threshold, swap of the dataset, or redefinition of the metric becomes mechanically detectable. Four byte-equivalent reference implementations exist in Python, JavaScript, Go and Rust, with twenty conformance vectors, so verification is one terminal command for an auditor or underwriter who has the manifest text.
The risk-mitigating measure framing
The underwriting language that fits PRML is identical to the language already in use for two other open primitives that survived rapid carrier adoption: SBOM-based attestation for software supply chain (CycloneDX, SPDX) and Sigstore-based code signing for build provenance. The parallel is direct:
| Risk family | Open primitive | What the carrier asks for |
|---|---|---|
| Software supply chain | SBOM (CycloneDX / SPDX) | Machine-readable component inventory delivered on demand to a forensic team |
| Build / code provenance | Sigstore + in-toto attestations | Cryptographic signature that links the binary in production to the build that produced it |
| AI evaluation integrity | PRML manifest + public commit | Cryptographic pre-registration of every accuracy / robustness claim, third-party re-verifiable |
In each row, the insured is not asked to adopt a proprietary platform. The standard is open, the verification step is mechanical, and the carrier's underwriting team can satisfy itself with the artifact alone, without a vendor relationship. That matters because no underwriting committee wants the renewal conversation to begin with "first we need to install a GRC platform."
Policy language that fits
The following sample clauses are illustrative only and not legal advice. They show where PRML naturally drops into existing language for AI-touching coverages.
D&O AI-conduct extension
The Insured shall, for any AI system materially relied upon for business decisions, maintain a tamper-evident pre-registration record for each declared performance characteristic, using an open and third-party verifiable specification. Pre-registration must be committed prior to the evaluation event and the cryptographic commit must be retained for the longer of seven years or the applicable regulatory retention period.
Cyber AI-augmentation rider
For any AI model whose output is used to filter, prioritise, or block events in the Insured's incident-response or detection pipeline, the Insured shall maintain pre-registered accuracy and false-positive-rate claims under an open machine-readable specification, such that the carrier or its forensic vendor may, in the event of a covered loss, independently re-derive the cryptographic commit and verify that the claimed performance has not been retroactively edited.
AI-specific liability primary form
"Documented evaluation procedure" includes, where the Insured operates a high-risk AI system within the meaning of Regulation (EU) 2024/1689 Article 6, a pre-registered open manifest (such as PRML or equivalent) whose canonical hash is published to a durable, public, third-party-resolvable record before the evaluation event. Retention shall be no less than the period required by Article 18 of that Regulation.
What PRML does not certify
The same scope discipline applies here as in the spec itself. The manifest is one input to a broader risk assessment, not a substitute for it.
- PRML does not assert that the model is safe, fair, fit for purpose, or compliant with any specific regulation. It only ties an evaluation claim to a cryptographic commit so that retroactive edits are mechanically detectable.
- PRML does not detect execution-time tampering inside the eval harness. If the harness silently truncates the dataset between load and metric computation, the manifest hash will still verify.
- PRML does not address model binary integrity or runtime supply chain (that is Sigstore / in-toto territory) and does not constitute a notified-body conformity assessment under the AI Act.
- PRML does not eliminate the need for independent review. It makes that review cheaper because the reviewer has a fixed, hashable target to verify against.
Spec section 8.1 enumerates these limitations in full. A risk-mitigating measure that overstates its own scope is not a risk-mitigating measure.
For underwriters and actuarial reviewers
Suggested workflow for an underwriter evaluating PRML as an acceptable risk-mitigating measure for a class of AI exposures:
- Read the eight-field schema and the canonicalisation rules in spec v0.1. The schema is short by design; a senior underwriter can understand the full data model in twenty minutes.
- Run the verification command against a published manifest from the public registry at registry.falsify.dev. Confirm that the SHA-256 derivation is reproducible from your own machine, with no dependency on the spec maintainer or the insured.
- Review the four byte-equivalent reference implementations and the twenty conformance vectors at github.com/studio-11-co/falsify/tree/main/conformance. Disagreement between implementations is treated as a spec bug, not an implementation bug.
- Cross-check the policy language against the limitations section above. PRML is appropriate as a "documented evaluation procedure" precondition; it is not appropriate as a "compliance with the AI Act" precondition.
- For an existing book of business, request an Evidence Pack from any insured running an AI Act high-risk system. See a sample Evidence Pack for the format an Audit Review produces.
For brokers placing AI-touching risks
Two practical uses:
- Forward the sample Evidence Pack to underwriting teams during submission so the carrier sees what a "documented evaluation procedure" precondition could mechanically look like. The artifact is auditor-ready and broker-forwardable as a single PDF.
- For insureds in the EU AI Act perimeter (Annex III high-risk categories), pair this page with the Article 12 checklist when responding to underwriter questionnaires. The checklist makes the regulatory exposure concrete; this page makes the technical mitigation concrete.
For insureds
If your renewal conversation is heading toward "documented evaluation procedure" preconditions and you want a single artifact that shows your accuracy and robustness claims are pre-registered and third-party verifiable, a Sprint Audit Review (/sprint/) produces exactly that artifact for one evaluation claim in five business days for EUR 15,000. For multiple claims or CI pipeline integration, the Full Sprint or Enterprise Engagement tiers exist. All deliverables are written, all communication is via email, all invoicing is wire-transfer from Studio 11 Türkiye Ltd. Şti.