HIPAA Requirement-to-Control Matrix for Health System AI Platforms

What the matrix covers and what it assumes

Policy documents and after-the-fact reviews show intent. They do not show what an AI system was permitted to do with PHI or what it actually did. A requirement-to-control matrix closes that gap by naming, for each HIPAA requirement, the control that applies and the artifact an auditor can inspect.

Scope matters first. The matrix should define the AI execution path as the set of information systems that contain or use ePHI: models, agents, tools, MCP servers, AI sites and coding assistants. The access control standard in 45 CFR 164.312 refers to allowing access only to persons or software programs that have been granted access rights. It is reasonable to treat agents and tools as software programs that need individually granted rights. That is an inference from the text, not an HHS statement about agents.

Scope should also include model and data assets. In the preamble to the January 2025 Security Rule NPRM, HHS states that ePHI maintained for covered functions, including ePHI in AI training data, prediction models and algorithm data, is protected by the HIPAA Rules. This is proposed-rule preamble language, not final rule text, and the NPRM content should be treated as proposed. Requirement text in this guide reflects current regulations as of November 2026. The control and evidence mappings are practitioner analysis, not HHS acceptance criteria.

The requirement-to-control matrix

Each row gives the AI-specific risk, the enforceable control, the evidence artifact, and whether the requirement is technical, administrative, contractual or split. Add an accountable owner column in your own version, since responsibility is often shared between the health system, vendors and the platform operator.

• Access control, 164.312(a): Risk: an agent or tool reaches PHI beyond the rights granted to it. Control: allow or block each interaction and tool call against rights set under 164.308(a)(4); escalate for human approval where policy requires it. Evidence: per-interaction access decisions tied to the agent or tool identity. Type: split. Administrative processes grant the rights; runtime enforcement applies them.
• Audit controls, 164.312(b), required: Risk: no record of what the AI did with PHI. Control: record each policy decision at the point of enforcement, and define who examines the records and how often. Evidence: decision, redaction and approval records plus review sign-offs. Type: technical for recording, administrative for examination.
• Integrity of transmitted ePHI (addressable): Risk: prompts, tool calls or responses carrying ePHI are modified without detection. Control: integrity checks on payloads in the path, with block or escalate on failure. Evidence: check results and a documented decision on whether and how the specification is implemented. Type: technical plus an administrative decision.
• Minimum necessary (Privacy Rule): Risk: prompts or retrievals include more PHI than the task needs. Control: redact fields before they reach a model or tool; block PHI categories for tools that have no need for them. Evidence: redaction records showing what was removed per interaction. Type: split. Deciding what is necessary is a policy judgment.
• Risk analysis and asset inventory: Risk: AI systems missing from the analysis and inventory. Control: none at runtime; add AI systems to scope. Enforcement records can inform the analysis. Evidence: risk analysis documentation. Type: administrative.
• BAAs, workforce training, contingency planning: Risk: obligations assumed to be covered by platform features. Control: none at runtime. Evidence: executed agreements, training records, documented plans. Type: contractual and administrative.

Making audit controls evidence hold up

The audit controls standard requires hardware, software or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Recording alone does not meet the word examine. Each row that depends on 164.312(b) should name the artifact that records AI activity and the process that reviews it.

The five runtime control types each produce a different artifact. Allow produces an access decision. Redact produces a record of what was removed. Block produces a denial and the policy behind it. Rate limit produces a threshold event. Escalate produces an approval record with the approver and outcome. Together these show what the AI was permitted to do and what it did, which a policy document cannot.

Two decisions need to be made explicitly. First, retention and review cadence for AI activity records, and who examines them. Set these deliberately and record the rationale rather than inheriting defaults. Second, who holds the evidence when control is shared. The NPRM preamble gives the example of a cloud-based EHR vendor, where both the covered entity and the vendor have control over the ePHI. AI platforms follow the same pattern, so record which party operates each control and which holds its evidence.

What runtime controls do not satisfy

Some requirements are organizational by nature. All covered-entity providers must perform a risk analysis and keep reviewing and updating their protections. OCR publishes guidance on risk analysis requirements, and AI systems belong in the scope and asset inventory it uses. A runtime control can feed that process with evidence, but it cannot replace it.

Access control is a split case. The standard ties technical enforcement to access rights specified under 164.308(a)(4), which come from administrative decisions. If those decisions are missing or vague, enforcement has nothing correct to apply. Business associate agreements, workforce training and contingency planning are contractual or administrative and need their own artifacts.

Avoid wording that says a control satisfies a standard. The regulations state required outcomes. They do not set acceptance criteria for particular tools. The accurate claim is narrower: a control enforces a defined policy and produces evidence that supports the organization's compliance position.

Where runtime enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It applies allow, redact, block, rate limit and escalate for human approval at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and that enforcement generates audit-ready evidence mapped to HIPAA.

Deployment is self-managed in the customer cloud, with configurable retention and data residency. That bears directly on the shared-control and evidence-holder questions above. Trussed runs in production with healthcare organizations.

It addresses the technical-runtime rows of the matrix. Risk analysis governance, business associate agreements, workforce training and the administrative decisions behind access rights remain with the health system.