How the NAIC AI Model Bulletin Applies to Life Insurers, and What Can Be Enforced and Evidenced at Runtime

What the bulletin expects of a life insurer

The NAIC Model Bulletin on the use of AI Systems by insurers is a template. Each state issues its own bulletin, so the binding requirements depend on the version in force where the insurer is domiciled and operates. The model's core message is that insurers remain responsible for complying with insurance laws, regulations and consumer protection rules when they use AI, and regulators may require them to explain how AI tools are used in underwriting, pricing, marketing or claims decisions.

The operational expectation is a written AIS Program for the responsible use of AI Systems that make or support decisions related to regulated insurance practices. The program should address governance, risk management controls and internal audit functions. It should document the insurer's framework for identifying, mitigating and managing risk, and its internal controls, both generally and at each stage of the AI System life cycle.

Scope is broad in two directions. Across the insurance life cycle, it reaches underwriting, rating and pricing, case management, claim administration and payment, marketing and fraud detection. Across the AI System life cycle, it reaches design, development, validation, implementation, use, on-going monitoring, updating and retirement. NAIC notes that life insurers use AI to reduce policy issuance time, make approval or denial decisions, assign underwriting risk classes, and target online advertising and offers to existing customers. Those uses fall within the program's scope whether the model is built in-house or supplied by a vendor.

State adoption and what it means for multistate carriers

The NAIC implementation map, with a status date of April 1, 2026, lists bulletins for 18 states and the District of Columbia: AK, AR, CT, DE, DC, IL, IA, KY, MD, MA, MI, NV, NH, NJ, NC, OK, RI and VT. The listed bulletins carry dates from February 2024 (Alaska) to February 2025 (New Jersey). Status can change, so confirm the current position for each jurisdiction before relying on this list.

The map also shows state action or pending state action, and it does not tell you whether a state's text contains every element of the model. For a multistate life insurer, that makes the model a design baseline rather than a compliance answer. A practical approach is to build one AIS Program to the model's structure, then check each domicile and operating state's bulletin for differences in wording, scope or expectations. Where a state has not issued a bulletin, the underlying expectation still applies: insurers remain accountable under existing insurance and consumer protection law.

What regulators may ask for in an investigation or market conduct action

An insurer should expect questions about its development, deployment and use of AI Systems and their outcomes, including Adverse Consumer Outcomes, regardless of whether a written AIS Program exists. Expected requests include inventories and descriptions of predictive models and AI Systems, and documentation of compliance with the insurer's AI program policies, protocols and procedures.

For a specific model under examination, requests may extend to the data used in development and oversight, techniques, measurements and thresholds, and documentation of validation, testing and auditing. The bulletin also expects processes for notifying impacted consumers that AI Systems are in use and giving them appropriate levels of information.

Third parties are explicitly in scope. If an investigation concerns data, models or AI Systems collected or developed in whole or in part by third parties, the Department may request additional information, including the due diligence performed on those third parties and their data, models or AI Systems. Insurers should retain documentation relating to AI programs, data and predictive models developed by third parties.

The practical gap is the difference between a policy and proof. A written policy states what a system should do. Examiners ask about outcomes and about compliance with that policy, which requires records of what actually happened in production.

What audit-ready evidence looks like in practice

Consider a life insurer using an AI system to triage claims, with a vendor-hosted model summarizing medical records. An examiner asking about compliance with program policies and about outcomes needs more than the policy document. Useful evidence includes which policy applied to each interaction, what decision was taken (allowed, redacted, blocked or escalated), what was sent to the third-party model, and who approved any escalated action. Records need defined retention, and they need to be retrievable by system, use case and period.

This is the part of the program a runtime layer can support: policy enforced at runtime, not reviewed after the fact, with each decision recorded as evidence. Trussed is one way to do this. It enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence mapped to NAIC and other frameworks. It can be deployed self-managed in the insurer's cloud with configurable retention and data residency.

It does not supply model validation records, dataset documentation, vendor due diligence files or the AI System inventory. Those must come from the model risk, procurement and compliance functions. Evidence from enforcement is strongest when it sits alongside those records and can be cross-referenced to the same system names and use cases.