ISO/IEC 23894 vs NAIC AIS Program: Risk Management Mapping for Insurers

Two instruments with different jobs

ISO/IEC 23894:2023, titled Guidance on risk management for artificial intelligence, describes processes for the effective implementation and integration of AI risk management. It is a standard an insurer chooses to adopt. It tells you how to structure a risk management process. It does not tell a regulator what your program must contain.

The NAIC Model Bulletin on the use of AI systems by insurers was adopted on December 4, 2023. NAIC describes it as establishing guidelines and expectations for responsible use of AI by insurers, aligned with the NAIC Principles of Artificial Intelligence. It centers on the AIS Program, described as the controls and processes an insurer adopts and implements to ensure responsible use of AI systems. A program may comprise general guidelines, a governance framework, risk management and internal controls, and third-party oversight.

The practical consequence is that an ISO/IEC 23894-aligned risk process can supply much of the substance of an AIS Program, but it is not the program. The insurer still has to show regulators that the controls were adopted and implemented, and by whom.

Side-by-side crosswalk by function

The table organizes both instruments by risk management function. The ISO column reflects the process elements of AI risk management guidance (context, assessment, treatment, monitoring and review, communication, recording and reporting). Check each row against the standard text before relying on it. Mappings are an analytical aid, not a statement of equivalence.

• Governance and accountability: ISO/IEC 23894: process guidance on integrating risk management into the organization. NAIC AIS Program: a governance framework with named accountability. Alignment: partial. The insurer must document who owns the program and how it reports.
• Risk identification and assessment: ISO/IEC 23894: establishing context, then identifying and assessing AI risk. NAIC AIS Program: risk management within a risk-based program. Alignment: strong. The risk register is the shared artifact.
• Risk treatment and controls: ISO/IEC 23894: selecting and implementing treatments. NAIC AIS Program: risk management and internal controls that are implemented, not only written. Alignment: strong on intent. Divergence on proof that controls operate.
• Monitoring and review: ISO/IEC 23894: ongoing monitoring and review of risks and treatments. NAIC AIS Program: controls and processes maintained over time. Alignment: strong. Evidence of operation is the open question.
• Third-party oversight: ISO/IEC 23894: addressed through general process guidance. NAIC AIS Program: a named program component. Alignment: weakest. Insurers need vendor-specific oversight procedures and evidence.
• Documentation and evidence: ISO/IEC 23894: recording and reporting of the risk process. NAIC AIS Program: documentation available for regulatory examination. Alignment: partial. Process records are not the same as examination-ready evidence.

Where the instruments diverge

The largest gaps sit where a regulatory expectation meets process guidance. Accountability is one. A risk process can describe roles in general terms, but an examiner will look for a governance structure that is documented, staffed and reporting to senior management. Charters, committee records and board reporting are organizational artifacts. They are not produced by risk assessment, and they are not runtime controls.

Third-party oversight is another. The AIS Program definition names it as a component, and many insurers rely on vendor models, embedded AI features and external tools. Closing this gap usually means contractual terms, due diligence records, vendor-supplied documentation, and a way to apply your own policy to vendor AI where it is reachable. Note that commentary on NAIC materials cautions that questions about vendor oversight, validation or governance structure should not be read as creating requirements beyond applicable law or adopted regulatory guidance. Treat the state instrument you are subject to as the authority.

Examination readiness is the third. The AIS Program speaks of controls that are adopted and implemented. A risk register entry stating that personal data is redacted from prompts is documented policy. Evidence that redaction occurred on a specific interaction is something different. Risk leaders should keep these two states visibly separate in the register.

State implementation: check the instrument, not only the model bulletin

The NAIC bulletin is a model. Each state decides whether and how to implement it, and NAIC tracks implementation in an adoption map. A state's instrument may differ from the model text, so a single crosswalk to the model bulletin should be re-checked against each state where you write business.

Colorado illustrates the point. The NAIC adoption map lists Colorado 3 CCR 702-10 as effective November 13, 2023, with amendments effective October 15, 2025. Separately, the Colorado Division of Insurance published a notice dated August 20, 2025 that the Commissioner adopted amended Regulation 10-1-1, covering governance and risk management framework requirements for life, private passenger automobile and health benefit plan insurers' use of external consumer data and information sources, algorithms and predictive models. Confirm the operative text and effective dates in the official Colorado regulatory publications for the lines you write.

As of November 2026, insurers with multistate footprints should maintain a per-state register of implementing instruments and map each to the same internal control set, rather than maintaining parallel programs.

Which treatments can be enforced at runtime

Sort every treatment in an ISO/IEC 23894-aligned register into two groups. The first group is organizational: risk assessments, validation and testing, governance charters, accountability roles, vendor due diligence, training, and board reporting. These live in documents and processes. Runtime tooling does not replace them.

The second group acts on individual AI interactions and tool calls. Examples include redacting personal or sensitive data before it reaches a model, blocking a tool call outside an approved scope, rate limiting an agent, and escalating a consequential action for human approval. These treatments can be enforced in the execution path and can produce a record each time they operate.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants: allow, redact, block, rate limit, and escalate for human approval. Scope is individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to NAIC and NYDFS, among other frameworks, with configurable retention and self-managed deployment in the customer cloud. This addresses the risk treatment and monitoring rows of the crosswalk where a treatment is expressible as a policy on an interaction. It does not cover governance structure, vendor due diligence, model validation, or workflow-level governance across tasks and agents.

Useful evidence for an enforced treatment is traceable. Each record should identify the policy and version applied, the decision taken, the time, the requesting identity, the tool or model involved, and, for escalations, the approver and outcome. Tie each record type to a register entry and an AIS Program component so that the control, its operation and its owner can be shown together.