NAIC AI Model Bulletin Implications for Insurance Internal Audit

What the Bulletin expects of insurers

The NAIC adopted the Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. It is a guiding document, not a model law or regulation, and it is meant to foster uniformity among state regulators' expectations for carriers that deploy AI. It reaches a given carrier only through state action, such as a state bulletin.

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 requirements. To support that, insurers are expected to develop and maintain a written 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, along with internal controls for AI systems generally and at each stage of the AI system life cycle. The Bulletin also advises insurers that regulators may request information and documentation in an investigation or examination, including on governance, risk management and internal controls.

Scoping the audit from the AI inventory

Start with the inventory. The Bulletin's risk management language points to inventories and descriptions of predictive models, and to detailed documentation of development and use. An audit scope built on any other starting point will inherit the gaps in that list. Test whether the inventory covers every model, vendor service and tool that makes or supports a decision in a regulated insurance practice, including AI embedded in vendor products and AI used by employees through external tools.

Then apply a risk-based lens consistent with the Bulletin's scoping factors: the type and degree of potential consumer harm, the extent of human involvement in final decisions, transparency and explainability of outcomes to the affected consumer, and the extent of reliance on third-party data, models and AI systems. Rank inventory items on those factors and document why each one is in or out of scope.

Jurisdiction matters. Because the Bulletin takes effect state by state, tie scope to the bulletins in the states where the carrier operates. As of April 2026, the NAIC implementation map lists bulletins in at least 17 jurisdictions and notes that it does not confirm a state's bulletin contains every element of the model. Other regimes, such as NYDFS Circular Letter 7 and Colorado SB 24-205, may apply separately and should be scoped on their own terms.

Testing governance, risk and life-cycle controls

Convert each element of the written program into a control objective, then into a test. For governance, confirm that ownership, escalation and reporting lines exist for AI control exceptions, and sample actual exceptions to see whether they followed those lines. For risk management, compare the documented risk identification and mitigation framework against what is recorded for a sample of inventoried systems.

For life-cycle controls, test validation and retesting. The Bulletin's language contemplates comparing performance on unseen data at development time with post-implementation performance, measuring performance against expert review, or using other methods. It also addresses the suitability of data used to develop, train, validate and audit models, and measures such as reproducibility, traceability and model drift, where appropriate. Auditors should ask which of these the carrier committed to in its program, then ask for the artifacts. NIST AI RMF MEASURE 2.1 offers a useful evidence target here: test sets, metrics and details of the tools used in testing, evaluation, verification and validation are documented.

These artifacts are largely documentary and sit in model development and risk management systems. They are necessary, but they describe how a system was built and tested, not how it behaved in a given interaction.

Assessing third-party AI oversight

The Bulletin addresses third-party oversight, and the scoping factors include how heavily the insurer relies on third-party data, predictive models and AI systems. Auditors should test two things: whether reliance on third parties shaped the program's risk scoping, and whether the carrier performs audits or other activities to confirm a vendor's compliance with contractual and, where applicable, regulatory requirements.

The second test is where evidence is often thin. A contract clause granting audit rights is not evidence that the rights were exercised. Ask for the schedule of vendor reviews, the results, the follow-up on findings, and the mechanism by which the carrier knows what a vendor's AI did on its behalf. Where a vendor's AI is reached through the carrier's own systems, the carrier may hold its own records of those interactions. Where it is not, the audit should record that as a limitation on assurance.

Controls on paper versus controls enforced at runtime

Most carriers rely on policy documents and periodic reviews. Those show what the carrier intended and what a reviewer concluded at a point in time. They do not show what an AI system was permitted to do, or did, in a specific interaction. When a regulator asks about a particular application, a sampled review rarely answers the question.

Policy enforcement in the execution path changes the kind of evidence available. If a policy is enforced at runtime, each decision to allow, redact or block an interaction or tool call can be recorded when it happens. An auditor can then test operation directly: select a policy, select a period, sample decisions, and confirm that the recorded outcomes match the policy as written. Exceptions and approvals can be tested the same way.

The limits are equally important. Runtime evidence is scoped to individual interactions and tool calls. It does not substitute for evidence on model development, validation, model lineage or dataset provenance, and it does not by itself trace a multi-step agentic workflow from end to end. Those areas still need documentary and technical evidence from other sources, and the audit report should state which assurance comes from which evidence type.

Where Trussed fits

Trussed is control, provenance and evidence infrastructure for regulated enterprises that must show what their AI was allowed to do and what it did. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalation for human approval, at the level of individual interactions and tool calls. That enforcement generates continuous audit-ready evidence, mapped to NAIC requirements among other frameworks, which gives auditors a record to sample and test.

Trussed can be deployed self-managed in the customer's cloud, with configurable retention and data residency. It has run continuously in production in a regulated enterprise for more than 18 months, and it serves customers in four regulated verticals, including insurance. Trussed does not provide model provenance, model lineage or end-to-end tracing of agentic workflows, so it complements, rather than replaces, the validation and documentation evidence described above.