When the examiner asks about your AI, hand them the evidence.
State insurance regulators are adding AI governance to market-conduct exams. The questions are becoming standardized, which means the evidence can be prepared in advance. This page explains what is changing, what examiners ask, and exactly what Castle exports for each ask, so an AI inquiry becomes a document handoff instead of a scramble.
Current status, stated plainly
Castle is built and tested and in early access. It is not yet live-proven with a customer or auditor, and it holds no certifications. Castle is software, not a law firm: regulatory summaries on this page are provided for orientation and should be confirmed with your counsel and your state's current guidance.
The NAIC AI Model Bulletin is now the baseline
The NAIC's Model Bulletin on the Use of Artificial Intelligence Systems by Insurers has been adopted in 24 jurisdictions, 23 states plus the District of Columbia, per the NAIC's implementation tracker (status April 1, 2026). It sets regulator expectations for insurers that use AI: a written program for the responsible use of AI systems, governance and risk management proportionate to the risk of each use, internal controls, and documented oversight of third-party AI systems and data.
The bulletin addresses licensed insurers. MGAs, TPAs, and other partners in the distribution chain are not its direct addressees, but they feel it through carrier oversight: carriers that must answer for their AI increasingly push documentation, audit, and governance requirements down through program agreements. If you build or operate AI in an insurance workflow, someone in the chain will eventually ask you to show your governance.
Castle tracks adoption jurisdiction by jurisdiction inside the product: each adopting jurisdiction's instrument and date, with source-dated records and a built-in content-currency check that flags staleness instead of letting it drift. Kept current to public sources as of the recorded dates; reference material, not legal advice.
We state this carefully on purpose: the bulletin does not bind MGAs directly. The practical pressure arrives through the carriers and contracts above you.
2026: examiners get a standardized AI checklist
From January to September 2026, the NAIC is piloting its AI Systems Evaluation Tool in 12 states: California, Colorado, Connecticut, Florida, Iowa, Louisiana, Maryland, Pennsylvania, Rhode Island, Vermont, Virginia, and Wisconsin. The tool gives market-conduct examiners a standardized AI-governance checklist to use during exams.
This is the part that changes preparation. When every examiner improvised their own AI questions, you could only prepare generally. A standardized evaluation tool means the asks are knowable in advance, which means the evidence can be assembled, kept current, and exported on demand rather than reconstructed under exam deadlines.
What examiners ask
Across the bulletin's expectations and the evaluation tool's structure, the asks group into four buckets:
- AI inventory and extent of use. Which AI systems are in use, where, for what decisions, and at what scale.
- Governance and risk-mitigation practices. Who is accountable, how risk is assessed, what controls exist, how exceptions are handled, and how it is all documented.
- High-risk model detail. Deeper documentation for systems that touch consumer outcomes: how they are tiered, tested, approved, monitored, and overridden.
- Input data and third-party AI documentation. Where the data comes from, how it is classified and protected, and how vendor-supplied AI and data are governed under contract.
Ask one: AI inventory and extent of use
Because the registry is the same system that governs runtime activity, the inventory is not a spreadsheet that drifts out of date. What an agent is declared to reach is what enforcement checks against.
Ask two: governance and risk-mitigation practices
Because decisions come from fixed rules over declared facts, running the same assessment twice gives the same answer. That consistency is itself evidence of a functioning program.
Ask three: high-risk model detail
For agentic systems, runtime enforcement adds the strongest form of detail: a policy decision log showing actions that were authorized, actions that were denied, and any attempt to reach beyond declared access. How runtime enforcement works.
Ask four: input data and third-party AI documentation
Evidence the examiner can verify without trusting you
Everything above exports as a signed evidence packet. Artifacts are hashed when captured, assembled into a Merkle manifest, and signed. The recipient verifies the packet with the standalone castle-verify tool: signature, root, and every per-artifact hash, on their own machine, with zero access to Castle systems.
Every pack ships that verifier inside the packet as a self-contained bundle the examiner runs in one command, led by a 00-START-HERE.md cover sheet that walks them through verifying offline without trusting Castle, and the examiner portal accepts an uploaded packet and verifies it as a convenience; the authoritative check remains the examiner's own offline run. Evidence can also be countersigned across organizations: an independent instance, such as a carrier's, re-verifies the packet and signs a receipt bound to its exact bytes, and receipts aggregate into one offline-verifiable Transparent Statement, aligned to the IETF SCITT architecture (draft-ietf-scitt-architecture, in IESG evaluation).
The exam-readiness view in the product brings this together: the inventory, the decisions, the audit timeline, and the export, organized around the asks rather than around our database. An honest limit, stated here as everywhere: a valid signature proves the evidence was not altered, not that it is complete.
The exam simulator: a mock response package from live data
Castle's exam simulator assembles a response package structured to Exhibits A through D of the NAIC AI Systems Evaluation Tool 4.0 exposure draft:
- Use quantification matrix. Where AI is used and how extensively, built from the use case and agent registries.
- Governance checklist with a citation column. Each item answered with a pointer to the specific record, policy, or chain entry behind the answer.
- Per-model detail sheets. One sheet per system: tier, controls, approvals, monitoring, and audit history.
- Data provenance rows. Input data sources, classifications, and the third-party documentation attached to each.
Every value comes from live registry data. Where Castle does not hold an answer, the package says so with an explicit "requires insurer input" placeholder; it never fabricates a value to look complete.
One command, castle insurance examiner-packet, assembles the whole thing as a single portable deliverable, optionally one ZIP file: Exhibits A through D, a signed Merkle attestation (Ed25519), the bundled standalone verifier (castle_verify.py) with VERIFY-FOR-EXAMINERS.md, and a verify-first cover sheet, 00-START-HERE.md, that carries the Exhibit A-D crosswalk and tells the examiner to run one offline command and confirm the evidence is untampered, without installing Castle or trusting the sender.
Framing, stated plainly: the package is structured to the Tool 4.0 exposure draft as publicly posted by the NAIC. The exposure draft is in active revision and states may customize it. This is preparation material, reviewable with your counsel, not a regulator-endorsed format.
The carrier-delegation pack
For MGAs and other delegated-authority partners, the same machinery produces the pack a carrier asks for when it oversees AI used under its delegated authority: attestation packet, exam-readiness export, and the agent and model inventory. This is carrier oversight of its distribution chain, arriving through program agreements; as noted above, the bulletin addresses insurers, not MGAs directly.
Delegated authority today is mostly overseen through bordereaux-style spreadsheets nobody can independently verify. The countersign flow digitizes that structure for AI governance evidence: the MGA's instance signs the packet, the carrier's instance (or a free verification node, castle countersign serve) re-verifies and countersigns it, and an oversight report summarizes countersign coverage across the chain. Obligations delegate down; verified evidence rolls up.
A note on the written AIS Program
The bulletin expects insurers to maintain a written program for the responsible use of AI systems, often called an AIS Program. Castle does not draft that document, and you should be suspicious of software that claims to. Your counsel drafts the program; Castle provides the evidence layer underneath it, so that what the program says happens is what the records show happened.
Castle output is evidence and documentation support, not legal advice. The program itself is a governance document your counsel owns.
The exam-readiness guide
No form, no email gate. The full preparation sequence we recommend, whether or not you use Castle:
1. Build the inventory before anyone asks for it
List every AI system in use, including embedded AI inside vendor products and any autonomous agents. For each: purpose, decisions it touches, data it reads, owner. The most common exam failure mode is not a bad model; it is an inventory discovered to be incomplete in the meeting.
2. Tier by consumer impact, and write the rule down
Examiners care most about systems that affect consumer outcomes: underwriting, rating, claims, fraud flags. Define the tiering rule explicitly so two people applying it reach the same tier. A tier that depends on judgment is a tier you will be asked to defend case by case.
3. Make governance produce records as a side effect
If documentation is a separate chore, it will lag reality. Route approvals, exceptions, and remediation through a system that records them as they happen, with named owners and dates. The goal is that exam preparation is an export, not a writing project.
4. Treat third-party AI as your problem, because it is
Vendor-supplied AI and data are inside the scope of the asks. Collect each vendor's posture and agreements, map the contract obligations that govern AI and data handling, and tie them to the controls that satisfy them. "The vendor handles that" is not an answer an examiner accepts.
5. Rehearse the handoff
Run the exercise internally: take the four asks above and produce the documents. Time it. If any answer requires reconstructing history from email and chat logs, that is the gap to close first. Evidence that can be verified independently, rather than narrated, shortens every conversation.
6. Keep the written program and the evidence in sync
Review the AIS Program against the actual records on a schedule. Divergence between what the program promises and what the logs show is worse than a modest program faithfully followed.
Proof the model behaves, not a checklist of controls
The asks above prove a governance program runs. The harder question examiners are starting to ask is whether the model itself holds up: is it biased, does it stay grounded in its sources, does it survive small changes to its inputs, has it drifted since it went live. Castle runs a first-party validation battery against your own models and turns each result into obligation-linked, verifiable evidence. This is you validating your own systems and documenting it, not a third-party audit.
Each run is stamped write-once and folded into the same signed evidence packet as everything else, so a validation result anchors and verifies offline with castle-verify exactly like any other artifact, and appears in the exam-readiness export against the obligation it satisfies. Human oversight of the model (producing and reviewing the validation pack) is itself the evidence for EU AI Act Article 14.
First-party framing, stated plainly: Castle helps you test and document your own models. It is not an independent audit, and a passing battery is evidence of validation work, not a regulator-endorsed certification.
Proof your guardrails fired, mapped to the obligation
Examiners have moved past asking whether you have guardrails. Now they ask whether the guardrails fired, and what happened when they did. Castle records every rail decision your guardrail engine makes on the same tamper-evident chain as the rest of your evidence, each mapped to the obligation it satisfies.
Castle governs and evidences the guardrails. It is the system of record for their decisions, not the guardrail engine, and this is not a third-party audit.
Prove your obligation library kept up with the rules
The regulatory surface keeps moving. New state adoptions land, and the NAIC's evaluation tool is already scheduled to churn through 2026 (Tool 4.0 to 5.0 to 6.0). An obligation library that was current at your last exam can be quietly stale by the next.
Castle treats the regulatory content as a dated, sourced feed. It snapshots the obligation libraries and adoption records you rely on, and when that content moves, a new state adoption, a changed instrument, a new tool version, it records the change on the same tamper-evident chain as the rest of your evidence. What changed, and when you saw it, becomes provable rather than remembered.
On demand it produces a currency report: every dated source, its retrieval date, and whether it is current or aging, measured against fixed freshness thresholds. When an examiner or a carrier asks whether your regulatory library is current, the answer is a dated report you hand over, not a promise.
Deterministic: no model sets currency or decides that content changed. Reference material kept current to public sources as of the recorded dates, reviewable with your counsel, not legal advice.
See the evidence layer run
Watch the real product authorize, deny, and block in under ninety seconds, then bring us your exam scenario and we will walk through the exports live.