How the NAIC AI Model Bulletin Applies to Underwriting AI, and What You Can Enforce and Evidence at Runtime

What the bulletin says and where underwriting sits

The NAIC adopted the Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. It is a template. A state Department of Insurance issues it to insurers holding certificates of authority, reminding them that decisions or actions affecting consumers that are made or supported by advanced analytical and computational technologies, including AI systems, must comply with all applicable insurance laws and regulations.

The bulletin states that AI techniques are used across all stages of the insurance life cycle. It expects the AIS Program to address that life cycle, and it names underwriting, rating and pricing, along with case management, claim administration and payment, and fraud detection. For a carrier or brokerage, underwriting AI is therefore in scope by name, not by interpretation.

The bulletin lists factors that shape the program: the type and degree of potential harm to consumers, the extent of human involvement in the final decision, the transparency and explainability of outcomes to the impacted consumer, and the extent of reliance on data, predictive models and AI systems from third parties. These are the practical lens for any underwriting use case.

One point matters for exam readiness. Whether or not a written AIS Program exists, an insurer can expect to be asked in an investigation or market conduct action about its development, deployment and use of AI systems, or any specific predictive model, and about outcomes, including Adverse Consumer Outcomes. A policy binder does not answer a question about a specific interaction.

Reading the bulletin's factors against underwriting use cases

The bulletin does not enumerate underwriting use cases. The mapping below is a practical reading of how its factors tend to weigh on common ones.

• Risk scoring: Potential harm and explainability weigh heavily. The record should identify the model used, the data it accessed and the action that followed.
• Eligibility and pricing inputs: Harm to consumers and human involvement in the final decision are central. Show where a person approved or overrode an output.
• Submission triage: The question is what the system was allowed to route or decline on its own, and what required review.
• Document extraction: The concern is the data the system touched, including personal information, and whether sensitive fields were handled under policy.
• Vendor-supplied models and data: Third-party reliance applies. Due diligence documents and production records should both tie to the specific vendor system.

Separating documentation from runtime evidence

The bulletin's request categories include inventories and descriptions of predictive models and AI systems that support decisions, information on data used in development and oversight, techniques, measurements and thresholds, validation, testing and auditing documentation, and due diligence on third parties. Most of these describe design, acquisition and validation. They are met by governance work: a written program, assigned accountability, a maintained inventory, validation and testing, and vendor review. A runtime control layer does not produce them.

The bulletin also asks about deployment, use and outcomes. Our reading is that a request about outcomes of systems in use implies records of what the system did in production, in addition to policy documents. The bulletin does not label requests as design-time or runtime. That split is an analytic reading, but it is a useful one for planning evidence.

This is where a policy on paper and a policy in operation diverge. A document can state that an underwriting assistant must not expose certain personal data, or that certain outputs need human sign-off. Only enforcement at the point of the interaction determines whether that happened, and only a durable record can show it afterward. Because the bulletin treats human involvement in the final decision as a factor, an escalate-for-human-approval step is a natural control to enforce and evidence, though the bulletin does not prescribe one.

The tradeoff is scope. Runtime evidence supports the use and outcomes questions. It does not replace model validation, bias testing, or documentation of development data. Treating it as a substitute leaves the design-side requests unanswered.

State adoption and related regimes

The model becomes operative only as each state issues its own bulletin, so adoption and wording vary. As of October 2026, examples from the NAIC adoption map include Alaska (February 1, 2024), Delaware (February 5, 2025) and New Jersey (February 11, 2025). The map does not determine whether a state's bulletin contains every element of the model, so a multistate carrier or brokerage should confirm each operating state's text before mapping controls.

NYDFS Circular Letter 7 and Colorado SB 24-205 are related regimes that may apply to the same underwriting systems. Each has its own requirements and should be assessed separately. The practical benefit of consistent per-interaction records is that one evidence base can be mapped against each regime, rather than reconstructed for each inquiry.

Evaluating a runtime control layer

Start with the questions an examiner could ask. For a given underwriting interaction, can the system show what the AI was permitted to do, what data it accessed and what happened when a policy applied? Can records be tied to an inventory entry and the state bulletin that applies? Does the layer cover vendor-supplied AI as well as in-house models, and does it produce records that support vendor oversight documentation? How are records retained, retrieved and produced during an exam?

Trussed addresses the runtime portion. It enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. That enforcement generates continuous audit-ready evidence mapped to NAIC, among other frameworks. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. It is used by customers in insurance and other regulated verticals.

It does not replace the governance program, model validation, testing, or documentation of development data. It also does not provide model lineage, dataset provenance or end-to-end tracing of agentic workflows. A sound evaluation keeps those boundaries explicit and confirms that the evidence the layer produces fits alongside the governance documents your program already maintains.