Table of contents
The moment you route protected health information through an AI tool, that tool’s vendor becomes a business associate under HIPAA. That is not a contract term you negotiate — it is a status the law assigns based on what the vendor does with the data. And once a vendor is a business associate, the HIPAA Security Rule’s Administrative Safeguards apply to it directly.
Most AI buyers evaluate vendors on model quality, latency, and price. Those matter. But an auditor reviewing your AI deployment will not ask about model quality. They will ask whether your business associate meets the standards in 45 CFR § 164.308. That section is the most useful checklist a buyer has, because it is the same checklist a regulator uses. This post walks the standards of § 164.308 and translates each one into a concrete question to put to an AI vendor.
Why § 164.308 is the right lens for an AI vendor
The HIPAA Security Rule splits its requirements into three groups: administrative, physical, and technical safeguards.[1] The technical safeguards — encryption, access control, audit controls — get most of the attention because they map cleanly to software features. But § 164.308, the Administrative Safeguards, is where most real-world failures happen, because it covers how an organization runs, not just what its software does.[5]
For an AI vendor, that distinction matters. A vendor can ship strong encryption and still have no documented risk analysis, no defined process for handling a security incident, and no record of which employees can read customer prompts. The Administrative Safeguards are the standards that catch those gaps. They apply to business associates by the same force they apply to covered entities.[1]
One structural detail to carry through the rest of this post: implementation specifications under the Security Rule come in two kinds. Required specifications must be implemented as written. Addressable specifications give the regulated entity flexibility — it may implement the specification, implement a reasonable equivalent, or document why the specification is not reasonable and appropriate for its environment.[2] “Addressable” does not mean optional. It means the choice must be made deliberately and written down. We will return to that distinction at the end, because a proposed rule would change it.
Risk analysis: has the vendor mapped where PHI flows?
The first standard in § 164.308 is the security management process — § 164.308(a)(1). Its first required implementation specification is risk analysis: an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information.[2] Risk management — implementing measures sufficient to reduce those risks to a reasonable level — is the required specification that follows it.
For an AI vendor, the risk analysis question is specific: has the vendor mapped where PHI travels through the inference path? A prompt does not go straight to a model and back. It may pass through routing layers, prompt-processing services, model providers, and logging systems. Each hop is a place PHI can be exposed. A vendor that has done a real risk analysis can describe that path and name the controls at each step. A vendor that has not will describe its product instead of its data flow.
Ask for it directly: where does a prompt containing PHI go, what processes touch it, and what is the documented risk at each point. The NIST guidance on implementing the Security Rule treats risk analysis as the foundation everything else rests on — you cannot manage a risk you have not identified.[3]
Workforce security and access management: who can see PHI?
Two standards in § 164.308 govern people. Workforce security — § 164.308(a)(3) — requires policies ensuring that workforce members have appropriate access to PHI and that those who should not have access are prevented from getting it. Information access management — § 164.308(a)(4) — requires policies for authorizing access to PHI in the first place.[1]
Translated to an AI vendor: who at the vendor can read customer prompts and model responses? The honest answer is almost never “nobody.” Engineers debug. Support staff investigate tickets. The real questions are narrower. Is that access role-restricted, so that only specific staff can reach customer data? Is every access event logged against a named identity? Is access granted through a documented authorization process and revoked when an employee leaves? The 2025 proposed update to the Security Rule highlights how critical this is, suggesting a mandatory one-hour window for terminating access after an employee leaves.[4]
These standards also apply inside your own organization. A general-purpose AI tool has no concept of who in your practice should be allowed to submit a diagnosis versus who should not. An AI platform built for regulated work enforces that — role-based access at the organization level — so your own answer to § 164.308(a)(3) and (a)(4) is “the system enforces it,” not “we trust people to follow policy.”
Security incident procedures and contingency planning
Section 164.308(a)(6) requires security incident procedures — a defined process to identify and respond to suspected or known security incidents, mitigate their effects, and document them.[1] Section 164.308(a)(7) requires a contingency plan: data backup, disaster recovery, and an emergency mode operation plan, so that PHI remains available and protected when systems fail.
For an AI vendor, incident procedures raise a question buyers rarely ask in the demo: if PHI is exposed — through a misconfiguration, a logging bug, a compromised credential — what happens, and how fast do you find out? A vendor should be able to describe its detection mechanism, its notification timeline to affected customers, and where incidents are documented. HIPAA’s breach notification rules make your organization responsible for reporting; you cannot meet that obligation if your business associate cannot tell you what happened.
Contingency planning is more concrete than it sounds for AI. If the vendor’s primary model provider has an outage, does PHI handling fail safely, or does it fall back to an endpoint outside your BAA? “Fail open” — quietly routing around a broken safeguard to keep the service running — is the wrong answer. A compliant system fails closed: if it cannot enforce the policy, it does not process the data.
Evaluation: can the vendor show its work?
Section 164.308(a)(8) requires periodic evaluation — a technical and nontechnical review of how well the entity’s security policies and procedures meet the Security Rule’s requirements, performed in response to environmental or operational changes.[1]
This is the standard that separates a vendor’s marketing from its practice. Anyone can say their platform is secure. Evaluation asks whether they check, on a schedule, against the actual requirements — and whether they can produce the result. For an AI vendor, “environmental or operational changes” is not abstract. Adding a new model provider, changing how prompts are logged, or shifting where inference runs are all changes that should trigger a fresh evaluation.
Ask what the vendor’s most recent evaluation covered and when it happened. A useful follow-up: what does the audit trail let you, the customer, verify independently? An AI deployment that mishandles PHI can produce real HIPAA violations from AI, and the evaluation standard is the discipline meant to catch the gaps before a regulator does. A vendor that treats evaluation as continuous, and gives you the records to check its work, is operating the way the rule intends.
Business associate contracts: § 164.308(b) and the chain behind the vendor
Section 164.308(b) is the standard most directly about contracts. It permits a covered entity to let a business associate create, receive, maintain, or transmit ePHI on its behalf only after obtaining satisfactory assurances — documented in a written contract — that the business associate will appropriately safeguard the information.[1] Crucially, the same requirement flows downstream: a business associate may use a subcontractor that touches ePHI only after obtaining the same satisfactory assurances from that subcontractor.[1]
That downstream rule is the one AI buyers most often miss. The AI vendor you contract with is rarely the only entity handling your data. The model provider behind it is a subcontractor under § 164.308(b), and that provider needs to be covered too. A BAA with the AI vendor alone leaves a gap if the model provider behind it is not under a BAA the arrangement relies on.
This is why a BAA included on every paid plan is only useful if it covers the whole path. HASP holds BAAs directly with its inference providers, so the customer’s single BAA covers the entire inference chain — the standard in § 164.308(b) is satisfied end to end, not just at the first hop. That is the design behind BAA-included AI: one agreement, no uncovered subcontractor.
The proposed Security Rule update — and what it would change
A buyer evaluating an AI vendor in 2026 should know that § 164.308 may not stay as it is. In January 2025, the HHS Office for Civil Rights published a Notice of Proposed Rulemaking to strengthen the Security Rule — the first major proposed overhaul since the 2013 Omnibus Rule.[4] The public comment period closed in March 2025.
The most significant proposed change: the rule would eliminate the distinction between “required” and “addressable” implementation specifications, making nearly every specification mandatory.[4] For AI vendors and the organizations that buy from them, that would remove the flexibility some vendors currently use to defer controls they have judged “not reasonable and appropriate.”
One point of accuracy matters here. As of May 2026, this is a proposed rule, not law. OCR has kept finalization on its regulatory agenda, with a target around mid-2026, but no final rule has been published and the timeline is not guaranteed.[4] Treat it as direction, not deadline: the proposal signals where the regulator wants the bar to move. A vendor already operating as though every specification is required is well-positioned for the final rule whenever it lands — and is a safer business associate today regardless.
The Administrative Safeguards in § 164.308 give you a stable, regulator-aligned way to evaluate any AI vendor: map the data flow, name who can see PHI, check incident and contingency handling, demand evidence of evaluation, and confirm the BAA chain has no gaps. A vendor that answers those questions with specifics is one you can defend in an audit. For a fuller picture of what a compliant deployment requires across every safeguard, see the complete guide to HIPAA-compliant AI.
Sources
U.S. Department of Health & Human Services. “Summary of the HIPAA Security Rule” (2013).
hhs.gov
U.S. Department of Health & Human Services. “Guidance on Risk Analysis” (2010).
hhs.gov
National Institute of Standards and Technology. “SP 800-66 Rev. 2: Implementing the HIPAA Security Rule” (2024).
csrc.nist.gov
U.S. Department of Health & Human Services Office for Civil Rights. “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information,” NPRM (2025).
federalregister.gov
HHS Office for Civil Rights. “HIPAA Enforcement Data” (2025). Analysis of 2024–2025 settlements shows Administrative Safeguard failures, particularly in Risk Analysis, as the most common violation.
hhs.gov