Evaluating LLM Governance Tools Against HIPAA and the NAIC Model Bulletin

Two regimes with different scopes

HIPAA is organized around who handles protected health information. The Privacy Rule applies to health plans, health care clearinghouses, and covered health care providers, along with their business associates. The Security Rule's technical safeguards in 45 CFR 164.312 apply to a covered entity or business associate and protect electronic PHI. A Congressional Research Service analysis states that the Privacy Rule likely applies to AI-enabled tools used by health plans to the extent those tools handle enrollee PHI. For an LLM deployment, prompts, retrieved context, and outputs that contain ePHI fall within the technical safeguards. Whether a given data flow contains ePHI has to be assessed use case by use case.

The NAIC Model Bulletin is organized around the insurer's AI program rather than a data category. It sets expectations for a written AI Systems program, governance, risk management and internal controls, third-party oversight, and the ability to produce documentation for regulators. HIPAA evidence is mostly about how ePHI was handled and how system activity can be reviewed. NAIC evidence is mostly about whether the insurer has a functioning program and can show it.

The two overlap in one practical way: both reward evidence that is specific, retrievable, and tied to a named control. They diverge on what the evidence describes. That difference is why a vendor statement that a product covers both regimes is not a useful claim until it is broken into capabilities that can be tested.

What each tool category can and cannot evidence

Governance, documentation, and GRC tools generally record the program: AI inventories, policies, risk assessments, approvals, and assigned owners. This evidence shows intent and design. It cannot show what a specific LLM interaction did last Tuesday, because the tool is not in the path of that interaction.

Model risk and testing tools generally produce evidence about behavior before release, measured against test sets. That evidence is point-in-time. Observability tools generally record activity in production and are strong for review and investigation, but they typically describe events after they occur rather than deciding what is permitted.

Runtime policy enforcement sits in the AI execution path and applies a decision to each interaction before it completes: allow, redact, block, or escalate for human approval. Its evidence is a record of those decisions as they were made. This matters for ePHI because a control that acts in the path can limit what reaches a model, while a control that reviews afterward can only report what already happened.

The NIST AI RMF supports separating these evidence types. Its Measure guidance expects control effectiveness to be reassessed regularly, which argues for operational evidence and not only pre-deployment documentation. The AI RMF is a framework and is not itself a HIPAA or NAIC requirement. Capabilities vary by product within every category, so verify each claim against the product's actual behavior. Most insurers will need more than one category, and the question is which gaps remain.

Obligations that sit outside any tool

Under HIPAA, obligations attach to the covered entity or business associate, so accountability stays with the insurer regardless of what is purchased. The insurer must determine its own status, each vendor's role, and which LLM use cases handle PHI. An inventory of use cases is the starting point, since applicability turns on whether a tool handles enrollee PHI.

Under the NAIC Model Bulletin, the written AI Systems program, the governance structure, and the decisions about third-party oversight are organizational responsibilities. A tool can store the program and produce evidence that it is being followed. It cannot decide risk tolerance, assign accountability, or approve a use case on the insurer's behalf.

Two further responsibilities are easy to miss. First, someone must own the review of tool-generated evidence and set how often it happens. Evidence nobody reads does not show an effective control. Second, someone must track regulatory change. HHS published a proposed rule to modify the HIPAA Security Rule on January 6, 2025. As of October 2026, the current text of 45 CFR 164.312 is the operative reference, and a proposed requirement should not be treated as binding until its status is confirmed. NIST AI RMF Govern 1.1 describes the underlying practice: legal and regulatory requirements involving AI are understood, managed, and documented.

Runtime enforcement as one control among several

Runtime enforcement closes one specific gap: proving what an LLM was allowed to do and what it did, interaction by interaction. It does not replace the written program, the inventory, pre-deployment testing, or human review of evidence. Placing a component in the execution path also adds an operational dependency, so availability and failure behavior belong in the evaluation alongside compliance mapping.

Trussed is one example of this category. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants, with actions that include allow, redact, block, rate limit, and escalate for human approval. Scope is individual interactions and tool calls. The enforcement generates continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed runs in production with healthcare organizations, and its evidence is meant to sit alongside the program and documentation records the insurer maintains, not stand in for them.