Reducing AI Operating Costs for Insurers While Maintaining NAIC AI Model Bulletin Controls

What the bulletin expects regardless of AI spend

The NAIC adopted the Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. It expects an insurer to develop, implement and maintain a written program, the 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. The bulletin describes these functions as playing a core role in mitigating the risk that AI-driven decisions violate unfair trade practice laws and other legal standards.

The program should also document the insurer's risk identification, mitigation and management framework, and its internal controls, for AI Systems generally and at each stage of the AI System life cycle. Risk management and internal controls should cover the oversight and approval process for developing, adopting or acquiring AI Systems, constraints and controls on automation and design, and management of predictive models, including inventories, descriptions and detailed documentation of development and use.

Control intensity is meant to follow risk. The expectation is that controls are proportionate to the insurer's own assessment of risk to consumers, including its reliance on data, predictive models and AI Systems from third parties. That is the lever cost decisions can legitimately use, but only through a documented reassessment. Reducing review for a use case because budget is tight, without a risk-based rationale, leaves nothing for an examiner to rely on.

These elements form the baseline. A proposal that removes or weakens any of them, or moves AI use to tools that sit outside the program, fails the test before any savings are counted. Insurers should also confirm with counsel which state adoptions and related state requirements apply to their business, since those can add to this baseline.

What can be consolidated and what must stay

The distinction is between control work that repeats and control work that carries judgment or accountability. Repeated work is a candidate for consolidation or automation, provided the documented coverage stays the same. Work that carries judgment should keep a human owner.

• Manual evidence collection: Consolidate or automate. Generate records when each interaction or tool call occurs, rather than assembling them after the fact.
• Per-team review steps: Consolidate where teams repeat the same check. Apply one shared policy and keep team-specific rules where use cases differ in risk.
• Vendor-by-vendor control configuration: Consolidate into one policy layer applied to all AI use, so third-party tools receive the same controls as internal ones.
• Adoption or acquisition approval: Keep human oversight. The bulletin lists an oversight and approval process for developing, adopting or acquiring AI Systems.
• Risk reassessment before reducing review: Keep and document. Lower review intensity needs a recorded, risk-based rationale and approval.
• Internal audit: Keep. Automation can supply audit inputs, but it does not replace the audit function the bulletin names.

Enforcing policy at runtime and the evidence it produces

Most duplicated control work exists because controls are applied at different points by different teams, then reconstructed for review. Moving enforcement into the execution path changes that. Policy is enforced at runtime, not reviewed after the fact, and each enforcement decision produces a record at the moment it occurs. One policy layer can apply across teams and vendors, which is where consolidation comes from without reducing coverage.

The mapping below is a practical way to connect enforcement actions to the evidence an examiner may want. Each record is most useful when it carries identifiers linking the interaction to an inventoried AI system and its use case.

Scope matters. These records describe individual interactions and tool calls. They do not by themselves document how a model was developed, where a dataset originated, or how a multi-step workflow unfolded. The AIS Program still has to address those through its own lifecycle documentation.

• Allow: Records that an interaction or tool call was permitted, under which policy, for which AI system and use case.
• Redact: Records that specified content was removed before reaching a model or tool, and which rule applied.
• Block: Records the denied request and the policy that stopped it, showing a constraint on automation operating in practice.
• Rate limit: Records throttling applied to a use, supporting evidence that usage limits are enforced rather than only documented.
• Escalate for human approval: Records the request, the reviewer and the decision, preserving human oversight where the program requires it.

Inventory, third-party oversight and bypass risk

Regulators have tools for asking what AI an insurer uses. NAIC's AI risk evaluation supplement consists of optional exhibits that help regulators determine the extent of AI Systems usage, including a request for a model inventory or accompanying documentation with the AI Model name, how the model is used, and the broader use case. NAIC's AI Systems Evaluation Tool, a guide for regulators in market conduct, financial analysis or financial exam contexts, remained in development as of October 2026. It is intended to help regulators learn about the extent and use of AI, governance and risk mitigation practices, potentially high-risk models, and the types of data used as inputs.

Two implications follow. First, keep the inventory current and tie enforcement records to its fields, so a request can be answered from existing records. Second, treat third-party AI as inside the program. Reliance on third-party data and models is a factor in how much control the program needs, so any vendor or tool consolidation should be documented along with its effect on due diligence and oversight. Task force materials from 2024 also raise whether systems permit bypassing model results, which is a useful question to ask of any cost-driven tool change.

The risk in cost reduction is often a quiet move to unmonitored tools. Anything outside an enforcement point produces no record and applies no policy, which leaves a coverage gap and a hole in the evidence trail.

Trussed is one way to enforce policy in the execution path. It covers models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. The enforcement generates audit-ready evidence mapped to NAIC, NYDFS and other frameworks. It can be self-managed in the customer's cloud, with configurable retention and data residency. Trussed supports customers in insurance and three other regulated verticals, and runs 100+ models under one policy plane.