How to Build an NAIC Bulletin Evidence Binder Organized by Requirement

What the binder has to prove

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers was adopted in December 2023. NAIC describes it as a guiding document rather than a model law or regulation, intended to foster uniformity among state regulators on expectations for carriers that use AI. Its operative effect depends on how each state issues it, so the binder has to record which version applies in each licensed state.

The bulletin reminds insurers that decisions affecting consumers that are made or supported by advanced analytical and computational technologies, including AI, must comply with all applicable insurance laws, including unfair trade practices rules. It sets an expectation that insurers create and implement a written AIS Program, commensurate with an assessment of risk, to help ensure those decisions are accurate and lawful. It also tells insurers what documentation a state Department of Insurance may request during an investigation or examination.

That last point defines the binder's purpose. During a market conduct exam, the question is rarely whether a policy exists. It is whether you can show, quickly and consistently across business units, how each expectation is met. Evidence that sits in policy repositories, committee minutes, vendor files, and system outputs does not answer that question until someone organizes it by requirement.

Step 1: Define the matrix before collecting anything

Start with the structure. Collecting documents first produces a pile that mirrors your org chart. Starting with the matrix forces every artifact to justify its place by naming the requirement it supports.

Use the same columns for every business unit so that a regulator sees comparable answers whether the system sits in claims, underwriting, or distribution.

• Requirement: The bulletin expectation, quoted or closely paraphrased from the version your state issued.
• Artifact: The specific document or record that demonstrates it, with a version or date.
• Owner: One accountable role, not a committee.
• Source system: Where the artifact is stored or generated, so it can be retrieved and verified.
• Refresh cadence: Event-driven, periodic, or continuous.
• Gap status: Current, stale, or missing, reviewed on a fixed schedule.

Step 2: Map the four expectation areas to binder tabs

Organize the binder into tabs that follow the bulletin's expectation areas: governance, risk management and internal controls, third-party AI systems and data, and documentation available to regulators on request. Align the tab headings and row wording to the text of the bulletin as your state issued it, since state versions can differ from the NAIC model.

The tabs hold different kinds of evidence. Governance and documentation evidence is mostly authored. Controls evidence is a mix. Third-party evidence is largely contractual and diligence-based. Treating them uniformly is how binders become either too thin or unmanageable.

• Governance: The written AIS Program, role assignments, committee charters and decisions, and the risk assessment that the program is scaled to. Owners are typically the compliance and risk leads.
• Risk management and controls: Risk assessments per AI system, control descriptions, and evidence that controls operate. This is the tab where runtime records matter most.
• Third-party AI systems and data: Vendor inventory, due diligence files, and contract terms. Owners are procurement, vendor management, and the business sponsor.
• Documentation for regulators: An index of what a Department of Insurance may request, with a pointer to the row that answers each item, checked against the full bulletin text.

Step 3: Separate authored evidence from continuously generated evidence

The most useful decision in the build is which rows can be fed automatically and which must be written and refreshed by people. This split is an operating framework, not a regulatory requirement, but it shapes ownership and cadence.

Authored evidence reflects judgment: what the program is, who decides, and why a risk was accepted. No system produces it for you. Continuously generated evidence reflects behavior: what an AI system was permitted to do, and what happened when policy applied. Enforcement in the execution path can produce that second kind as a by-product, so it does not depend on someone remembering to export it before an exam.

• Authored: AIS Program document: Written, owned by compliance, refreshed on a set review cycle and after material change.
• Authored: roles and committee records: Assigned owners, charters, and decision minutes, refreshed when roles or membership change.
• Authored: risk assessments: Per-system assessments scaled to risk, refreshed on change or periodic review.
• Authored: vendor due diligence and contract terms: Collected at onboarding and renewal, held by vendor management.
• Generated: policy decisions: Allow, redact, and block outcomes for individual interactions and tool calls, produced when policy is enforced at runtime.
• Generated: human approval escalations and retention settings: Escalation records and configured retention, produced and held by the enforcement layer.

Where runtime enforcement fits, and where it does not

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, and coding assistants, and produces audit-ready evidence from those enforcement decisions, mapped to NAIC and NYDFS requirements. Because the policy is enforced at runtime, not reviewed after the fact, the evidence exists whether or not an inquiry ever arrives. Retention and data residency are configurable, and deployment can be self-managed in the customer cloud, which matters when records must stay under the carrier's control. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and generates over 30 GB of audit evidence per day.

The boundary matters for binder design. Runtime evidence covers individual interactions and tool calls. It does not replace the written AIS Program, risk assessments, or vendor diligence, and it does not provide model lineage or dataset provenance. In the matrix, mark those rows as authored and keep the runtime rows distinct, so a reviewer can see what each type of evidence is and is not proving.

Add a jurisdiction tab for state versions and related regimes

Because the bulletin is guidance, add a legal-status register by jurisdiction. For each licensed state, record whether it has issued the bulletin, in what form, and when it took effect. Date every entry, and re-verify before any exam use. As of October 2026, treat the register as a living record rather than a one-time exercise.

New York adds specific expectations. NYDFS Insurance Circular Letter No. 7, issued July 11, 2024, includes a clause drawn from the NAIC bulletin on incorporating certain terms into third-party vendor contracts, where appropriate. It also states that an insurer should not use external consumer data and information sources or AI systems for underwriting or pricing unless it can establish that the data source or model does not use, and is not based in any way on, a class protected under Insurance Law Article 26. Insurers should also be able to demonstrate that such sources are supported by generally accepted actuarial standards of practice and based on actual or reasonably anticipated experience. That is authored analytical evidence, so assign it an owner in underwriting or actuarial and place it under the underwriting and pricing rows.

Add Colorado SB 24-205 to the register as well, and confirm its current status before the binder relies on it.