NAIC AI Bulletin vs SOC 2: Does a SOC 2 Report Cover AI Oversight?

Two instruments with different jobs

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers was adopted on December 4, 2023, as a model for state departments of insurance to issue. It sets out how a department expects insurers to govern the development, acquisition and use of AI Systems. It reminds insurers that decisions and actions affecting consumers, whether made or supported by AI, must comply with all applicable insurance laws. It also tells insurers what information and documentation a department may request in an investigation or examination.

States issue or adapt the bulletin individually, so obligations differ by jurisdiction. State-specific regimes such as NYDFS Circular Letter 7 and Colorado SB 24-205 should be tracked separately from the model text.

SOC 2 is a different kind of instrument. It is an independent auditor's attestation on system controls, based on the AICPA Trust Services Criteria covering security, availability, processing integrity, confidentiality and privacy. The Bulletin states what a regulator expects. A SOC 2 report gives an opinion on whether a described set of controls was designed and operating. One does not substitute for the other.

Mapping Bulletin expectations to SOC 2

The classification below is an analytical view of how a typical SOC 2 report relates to each area. Confirm it against the adopted Bulletin text, the criteria in scope, and your own report.

• Written AI Systems program: Not addressed. A SOC 2 report may describe a service organization's controls, but it is not the insurer's own program for governing AI used in consumer-impacting decisions.
• Risk management and internal controls: Partially supports. General control environment and risk processes can support the narrative, but they are not AI-specific risk management for accuracy, fairness or appropriate use.
• Security, availability and confidentiality of systems: Supports. Type II testing over a period is useful assurance for the infrastructure that carries AI workloads, if those workloads are in scope.
• Adverse consumer outcomes, including unfair discrimination: Not addressed directly. SOC 2 concerns controls over a system, not the outcomes of decisions that affect consumers.
• Third-party AI oversight: Partially supports. A vendor's report is one input. Responsibility for AI-supported decisions stays with the insurer.
• Examination evidence for a specific AI system: Not addressed at system level. The report includes the auditor's tests and results, but they concern controls, not what an individual AI system did.

What a SOC 2 Type II report scopes, and what that limits

A Type II opinion covers three things: whether the description of controls is fair, whether the controls were suitably designed, and whether the tested controls operated effectively over a specified period. The assurance is reasonable, not absolute. A Type I report speaks only as of a single date. Both are bounded by the system description and the commitments the service organization chose to include.

That boundary matters for AI. The Bulletin lets a regulator ask about any specific model, AI System or application, which is a more granular level than an organization-level control attestation. A clean Type II opinion says the described controls worked for the period tested. It does not say a particular AI system stayed within approved use, produced accurate outputs, or avoided unfair outcomes for consumers.

Before citing any SOC 2 report, record its type, its testing period and its system description scope, then check whether the AI systems you use fall inside that scope. If they do not, the report supports nothing about them.

Third-party AI and vendor due diligence

Because the Bulletin reaches decisions made or supported by AI, an insurer in principle remains responsible for AI supplied by a vendor. Collecting a vendor's SOC 2 report is a reasonable first step, and it tells you something about the vendor's security and operational discipline. It does not tell you how the vendor's AI behaves inside your underwriting, claims or distribution workflows.

Vendor due diligence for AI therefore needs questions that a SOC 2 report does not answer. Which of your use cases does the vendor's AI touch? What data does it receive? What can it be permitted to do? What records exist to show what it did? The answers should sit in your own oversight records, not only in the vendor's attestation.

The NAIC is also developing a third-party data and models regulatory framework intended to streamline how regulators gather information about third-party data and models used by insurers. As of October 2026 it is still in development. Track it, because it may change the vendor information regulators expect you to hold.

Where runtime enforcement fits

The gap in the mapping above is interaction-level control and evidence. Policy documents state what an AI system should do. Closing the gap requires enforcing that policy while the system runs, and keeping a durable record of the result.

Trussed enforces policy in the execution path, at the level of individual interactions and tool calls across models, agents, tools and MCP servers. Each interaction can be allowed, redacted, blocked or escalated for human approval, enforced at runtime, not reviewed after the fact. That enforcement generates continuous audit-ready evidence mapped to NAIC, among other regimes, so a compliance team can show what an AI system was allowed to do and what it did. Trussed is deployed self-managed in the customer cloud, with configurable retention and data residency.

Trussed holds SOC 2 Type II. That report covers Trussed's own controls. It does not replace the customer's AI program, risk management or oversight obligations under the Bulletin, and it should be treated like any other vendor attestation in your due diligence.