NAIC AI Bulletin vs HIPAA for Health Insurer AI Systems

Scope and applicability: who is covered, and how

The two regimes attach to a health insurer in different ways, and that difference drives most of the mapping work.

The NAIC Model Bulletin is adopted state by state. Whether it applies to a given AI system depends on whether a state in which the insurer operates has adopted it, and on the form that state's version takes. The expectation is directed at the insurer's use of AI systems as a whole, and its center of gravity is the governance program around those systems, including outcomes for consumers.

HIPAA applies by entity type. The Privacy Rule and the other Administrative Simplification rules apply to health plans, health care clearinghouses and certain health care providers, which are the covered entities. For an insurer with separable lines of business, the HIPAA regulations apply with respect to the health plan line of business. The Security Rule (45 CFR Part 164 Subpart C) applies to electronic PHI of a covered entity, and it binds covered entities and business associates. HHS OCR implements and enforces the Privacy Rule.

In practice, a claims, utilization management, prior authorization or member services AI system at a multi-line insurer may sit inside both regimes, only one, or partly in each. The first step is determining which systems touch PHI within the health plan line, and which states' Bulletin versions apply to the same systems.

Side-by-side by control domain

The table summarizes how each regime frames the domain. It describes orientation, not a provision-level crosswalk, which should be built against the adopted state text and the CFR sections that apply to your systems.

• Scope and applicability: NAIC Bulletin: applies through state adoption, to insurers' use of AI systems. HIPAA: federal, applies to covered entities and business associates, including the health plan line of a multi-line insurer.
• Governance and documentation: NAIC Bulletin: expects a governance and risk management program for AI, with documentation. HIPAA: administrative requirements (45 CFR 164.530) sit alongside the Privacy Rule, and are not AI-specific.
• PHI handling: NAIC Bulletin: not a PHI safeguards framework. HIPAA: the Privacy Rule governs uses and disclosures of PHI, and the Security Rule governs ePHI.
• Third-party and vendor oversight: NAIC Bulletin: oversight of third parties supplying AI is part of the program expectation. HIPAA: business associates are directly within Security Rule scope.
• Access and audit controls: NAIC Bulletin: documentation and demonstrability of how AI is controlled. HIPAA: technical safeguards under 45 CFR 164.312, including access control (164.312(a)) and audit controls (164.312(b)).
• Evidence expectations: NAIC Bulletin: reviewed through state insurance regulators, focused on the program and its outcomes. HIPAA: enforced by HHS OCR, focused on PHI safeguards and their operation.

Where the regimes overlap

Four domains overlap in practice: access control, vendor oversight, documentation and auditability. Both regimes expect an insurer to know who or what can reach sensitive information and to be able to show that its controls operate as described.

For AI systems, access control extends beyond human users. A model, an agent or a tool call can retrieve member data, so the question becomes what each AI interaction was permitted to access and what it actually did. Under HIPAA, that question lands in the technical safeguards at 164.312, and the Security Rule matrix marks each implementation specification as Required or Addressable. A control mapping for AI systems should record which type each cited provision is, because the distinction affects how the control is documented and defended.

Vendor oversight overlaps in a different way. A third-party model provider or AI service handling ePHI raises business associate questions under HIPAA. The same provider is a third-party oversight item under a governance program built to the NAIC expectation. One vendor inventory can feed both, but the evidence each regime wants from it differs.

Where each regime requires something the other does not

The NAIC Bulletin asks for something HIPAA does not: a program-level governance structure for AI that covers risk management and consumer-outcome expectations, not only data protection. A system can be fully compliant with HIPAA safeguards and still be poorly governed as an AI system. A model that handles PHI lawfully can still produce outcomes in claims or prior authorization that a governance program would need to examine.

HIPAA asks for something the Bulletin does not: PHI-specific rules. The Privacy Rule's limits on uses and disclosures and the Security Rule's technical safeguards apply to PHI whether or not the system is called AI. Minimum necessary, access control and audit controls are obligations about information handling, and an AI system that processes PHI inherits them.

The practical consequence is that neither program can be treated as a subset of the other. Compliance leaders typically need a governance program that satisfies the state-adopted expectation, and a safeguards implementation that satisfies HIPAA for the same systems. The two are linked by shared evidence, not by shared scope.

What runtime enforcement can and cannot cover

Obligations divide into those that can be enforced on individual AI interactions and those that live in organizational processes. Policy ownership, governance documentation, risk management, vendor selection and contracting, and Privacy Rule administrative requirements are programmatic. NIST AI RMF Govern 1, which calls for AI risk policies, processes and practices to be in place, transparent and effectively implemented, is a useful optional reference for that layer. None of this happens in the execution path.

Runtime controls address a narrower set. Applying policy to each interaction and tool call, with outcomes of allow, redact, block or escalate for human approval, produces a record of what the AI system was permitted to do and what it did. That record is relevant to access and audit controls and to PHI handling at the point of use. It should be described as supporting a control, not as satisfying a regulation, because regulators define sufficiency, not tooling.

The tradeoff is scope. Runtime evidence is strong on individual interactions, but it does not describe how a model was built or trained, and it does not replace the governance program a state-adopted Bulletin expects.

Where Trussed fits

Trussed is runtime control and evidence infrastructure for regulated enterprises. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. Enforcement generates continuous, audit-ready evidence mapped to HIPAA and NAIC, which supports the runtime portions of the obligations compared above, including the audit controls expectation at 164.312(b).

Trussed does not satisfy the programmatic governance obligations. Governance programs, risk management processes and vendor oversight remain organizational responsibilities. It also does not provide model lineage, dataset provenance or end-to-end tracing of agentic workflows. Trussed runs in production with healthcare organizations, and deployment is self-managed in the customer cloud with configurable retention and data residency.