The HIPAA Security Rule (45 CFR Part 164, Subpart C) establishes national standards for protecting electronic Protected Health Information (ePHI). It applies to covered entities (health plans, healthcare clearinghouses, healthcare providers) and business associates. The rule is structured around three categories of safeguards — administrative, physical, and technical — each containing standards and implementation specifications that are either "required" or "addressable." Addressable does not mean optional; it means the entity must assess whether the specification is reasonable and appropriate, and if not, document why and implement an equivalent alternative.
The Security Rule is technology-neutral and scalable, designed to accommodate organizations from single-doctor practices to national health systems. However, this flexibility creates challenges for AI compliance: the rule was written in 2003 (pre-smartphone, pre-cloud, pre-AI), and while the HITECH amendment of 2013 updated some provisions for the cloud era, AI-specific risks are not explicitly addressed. HHS/OCR enforcement focuses on risk assessment adequacy, access control implementation, and breach notification.
Administrative safeguards are the policies and procedures that manage the security program. They constitute over 50% of the Security Rule's requirements and are the foundation for all other safeguards. HIPAA enforcement audits typically start here.
Security Management Process (§ 164.308(a)(1)): Risk Analysis (R), Risk Management (R), Sanction Policy (R), Information System Activity Review (R). The risk analysis is the foundation — OCR enforcement actions consistently cite inadequate risk analyses as the #1 finding.
Assigned Security Responsibility (§ 164.308(a)(2)): Designate a security official (R).
Workforce Security (§ 164.308(a)(3)): Authorization/supervision (A), clearance procedures (A), termination procedures (A).
Information Access Management (§ 164.308(a)(4)): Isolating clearinghouse functions (R), access authorization (A), access establishment/modification (A).
Security Awareness and Training (§ 164.308(a)(5)): Security reminders (A), malicious software protection (A), log-in monitoring (A), password management (A).
Security Incident Procedures (§ 164.308(a)(6)): Response and reporting (R).
Contingency Plan (§ 164.308(a)(7)): Data backup plan (R), disaster recovery plan (R), emergency mode operation plan (R), testing/revision (A), criticality analysis (A).
Evaluation (§ 164.308(a)(8)): Periodic technical and nontechnical evaluation (R).
Business Associate Contracts (§ 164.308(b)(1)): Written BAA required (R) before allowing a BA to create, receive, maintain, or transmit ePHI.
The Risk Analysis (§ 164.308(a)(1)) is the most critical administrative safeguard for AI. OCR's #1 enforcement finding is inadequate risk analyses. AI risk analyses must address: training data containing PHI, model memorization risks, inference endpoint access controls, and adversarial ML threats. An organization that deploys AI without updating its risk analysis to cover these risks is already in violation.
The BAA requirement (§ 164.308(b)(1)) is the gatekeeper for cloud AI in healthcare. Any cloud AI provider processing ePHI must sign a BAA. Microsoft (Azure OpenAI), AWS (HealthLake, Comprehend Medical), and Google (Healthcare API, Vertex AI) offer BAAs for their healthcare AI services. Consumer AI APIs (ChatGPT consumer tier, Claude consumer tier) typically do NOT offer BAAs — meaning PHI cannot be sent to these services. This creates a two-tier AI market in healthcare: BAA-authorized enterprise AI vs. consumer AI that cannot touch PHI.
Security awareness training (§ 164.308(a)(5)) must cover AI-specific threats. Prompt injection, model output PHI leakage, and training data exposure are new risks that traditional HIPAA training doesn't address. The "malicious software protection" specification takes on new meaning when AI models themselves can be weaponized.
Physical safeguards protect the physical infrastructure that houses ePHI systems. These controls address facility access, workstation security, and device/media controls.
Facility Access Controls (§ 164.310(a)(1)): Contingency operations (A), facility security plan (A), access control and validation (A), maintenance records (A).
Workstation Use (§ 164.310(b)): Policies for proper use of and access to workstations processing ePHI (R).
Workstation Security (§ 164.310(c)): Physical and technical safeguards for workstations accessing ePHI (R).
Device and Media Controls (§ 164.310(d)(1)): Disposal (R), media re-use (R), accountability (A), data backup and storage (A). Requires proper disposal of ePHI media and sanitization before reuse.
AI training infrastructure (GPU servers, TPU pods) must be physically secured under facility access controls. Organizations hosting local AI must document facility access, workstation security, and device accountability for their AI infrastructure. The Device and Media Controls are particularly relevant: hard drives and SSDs containing PHI training datasets must be properly disposed of and sanitized before reuse.
GPU VRAM is an overlooked media sanitization risk. VRAM can retain residual data from training runs, creating a gap in the media re-use requirement (§ 164.310(d)(1)). Organizations must implement procedures to clear VRAM between training jobs.
Cloud AI providers handle all physical safeguards at their data centers. Covered entities can rely on the provider's SOC 2 / HITRUST attestations to satisfy physical safeguard documentation requirements under the BAA. This eliminates a major scope area for organizations using cloud-hosted AI — the physical security of the GPU infrastructure is the provider's responsibility, not the covered entity's.
Technical safeguards are the technology and policies that protect ePHI and control access to it. These are the controls most directly affected by AI system architecture.
Access Control (§ 164.312(a)(1)): Unique user identification (R), emergency access procedure (R), automatic logoff (A), encryption and decryption (A).
Audit Controls (§ 164.312(b)): Hardware, software, and/or procedural mechanisms that record and examine activity in systems containing ePHI (R).
Integrity (§ 164.312(c)(1)): Protect ePHI from improper alteration or destruction (R). Mechanism to authenticate ePHI (A).
Person or Entity Authentication (§ 164.312(d)): Verify that a person or entity seeking access is the one claimed (R).
Transmission Security (§ 164.312(e)(1)): Guard against unauthorized access to ePHI during transmission (R). Integrity controls (A), encryption (A).
Access Control (§ 164.312(a)(1)) is the most challenging technical safeguard for AI. Unique User Identification (R) must extend to every entity that accesses ePHI through AI systems, including API calls to inference endpoints. AI agents making decisions on behalf of clinicians must be traceable to a unique identity. Encryption (A) should be treated as Required for AI systems — both training data at rest and inference traffic in transit must be encrypted.
Audit Controls (§ 164.312(b)) are critical: every inference request, model update, and training run must be logged. AI systems generate massive audit log volumes that can overwhelm traditional audit systems. The logs must capture who initiated the inference, what data was sent, and what the model returned.
Integrity (§ 164.312(c)(1)) is uniquely challenging for AI. Detecting unauthorized alteration of model weights (model poisoning) has no established technical solution. The "mechanism to authenticate ePHI" specification (A) could be interpreted to require model integrity verification — but no standard tools exist for this. Transmission Security (§ 164.312(e)(1)) requires TLS for all API calls to AI inference endpoints, and integrity controls must verify that AI outputs haven't been tampered with in transit.
Organizational requirements govern the contractual relationships between covered entities and business associates, including the specific provisions that must be included in Business Associate Agreements (BAAs).
Business Associate Contracts (§ 164.314(a)(1)): The BAA must require the BA to comply with applicable Security Rule requirements, ensure subcontractors agree to comply through flow-down contracts, and report any security incident including breaches of unsecured PHI per § 164.410.
Requirements for Group Health Plans (§ 164.314(b)(1)): Plan documents must be amended to require plan sponsors to safeguard ePHI, ensure adequate separation, require agent agreements, and report security incidents.
The BAA requirement is the single most important organizational requirement for AI in healthcare. Key considerations: (1) Cloud AI providers must sign a BAA before any ePHI is processed — Azure OpenAI, AWS HealthLake, Google Vertex AI (healthcare tier), and Databricks (healthcare tier) offer BAAs. Consumer AI APIs without BAAs cannot be used with PHI. (2) The subcontractor flow-down means the AI provider's infrastructure subcontracts (GPU cloud providers, model hosting services) must also be covered by BAAs.
Incident reporting requirements mean the AI provider must notify the covered entity of any breach, including AI-specific incidents. Model inversion attacks that could expose training data PHI, prompt injection that causes the model to disclose ePHI, and training data leaks all constitute reportable security incidents under the BAA.
Organizations fine-tuning models on PHI must ensure the fine-tuning service has a BAA in place. The fine-tuned model weights themselves become ePHI artifacts covered by the BAA. This means model weights cannot be shared, published, or transferred without authorization — a constraint that fundamentally changes how AI teams work. Open-source model sharing practices are incompatible with PHI fine-tuning under HIPAA.
The documentation requirements bind the entire Security Rule together: every safeguard must be documented, maintained, and retained for 6 years. Documentation must be updated in response to environmental or operational changes.
Policies and Procedures (§ 164.316(a)): Implement reasonable and appropriate policies and procedures to comply with the standards (R). Policies may be changed at any time, provided changes are documented and implemented per the rule.
Documentation (§ 164.316(b)(1)): Maintain documentation in written (may be electronic) form (R). Retain for 6 years from creation or last in-effect date (R). Make available to responsible persons (R). Review and update periodically in response to environmental or operational changes (R).
Documentation requirements are where AI compliance often fails. Organizations must document: AI system risk assessments, BAA coverage for AI providers, access control policies for AI inference endpoints, audit logging configurations for AI systems, and incident response procedures covering AI-specific threats. The 6-year retention requirement means AI system documentation must be maintained even after models are retired or replaced.
The "updates in response to environmental or operational changes" requirement means every model update, new AI use case, or change in cloud AI provider triggers a documentation update. OCR audit findings frequently cite inadequate or outdated documentation. The rapid iteration cycle of AI model development creates a documentation treadmill that many organizations fail to keep up with. Organizations deploying AI must ensure their documentation process can match the pace of AI model updates — a challenge that favors organizations with mature GRC tooling over those relying on manual documentation.
Original compliance deadlines (now historical): Health plans (non-small) — April 20, 2005; Small health plans — April 20, 2006; Healthcare clearinghouses — April 20, 2005; Covered healthcare providers — April 20, 2005.
The HITECH Act amendment (effective March 26, 2013) extended direct liability to business associates and subcontractors, meaning cloud AI providers acting as business associates are directly liable for Security Rule violations. OCR enforcement is ongoing and risk-based, with penalties up to $1.5 million per violation category per year.
HITECH's extension of direct liability to business associates (2013) means cloud AI providers are directly liable for HIPAA violations. Not just contractually liable to the covered entity — directly liable to HHS/OCR. This creates dual enforcement risk: the covered entity is liable for inadequate vendor due diligence, and the AI provider is directly liable for Security Rule violations.
OCR has not yet issued AI-specific guidance, but the existing rule's technology-neutral framework means AI systems are implicitly covered. The risk-based enforcement approach means organizations deploying AI without updated risk analyses are prime targets for OCR enforcement actions and corrective action plans. As AI adoption in healthcare accelerates, OCR is expected to increase enforcement focus on AI-related violations, particularly around BAA coverage gaps and inadequate AI risk assessments.
Related frameworks: NIST SP 800-53 Rev 5 (federal healthcare systems must comply with both HIPAA and 800-53; shared control principles) · NIST SP 800-171 Rev 2 (defense health contractors processing both CUI and PHI must satisfy both frameworks) · FedRAMP (cloud AI providers with FedRAMP authorization partially satisfy HIPAA due diligence, though BAA still required) · EO 14409 (includes provisions for AI in healthcare, references HIPAA as baseline) · CMMC v2 (DoD healthcare contractors face layered HIPAA + CMMC compliance for AI systems)