Reference · Healthcare
The HIPAA Security Rule and AI Workloads, Explained
45 CFR Part 164, Subpart C, with the minimum-necessary standard and the Breach Notification Rule
The Security Rule sets the administrative, physical, and technical safeguards a covered entity or business associate must apply to electronic protected health information. It has been in force since 20 April 2005 (20 April 2006 for small health plans), and since the 2013 Omnibus Rule business associates are directly liable under it. An AI assistant that reads a chart, drafts a patient message, or summarizes a prior-authorization packet is an information system that uses ePHI, and the model provider behind it is a business associate.
Who it applies to
Covered entities (health plans, health care clearinghouses, and providers that transmit health information electronically) and their business associates, including subcontractors. An LLM provider that receives PHI in prompts is a business associate and needs a business associate agreement before PHI reaches it.
The Privacy Rule's minimum-necessary standard (§164.502(b), §164.514(d)) applies to every use and disclosure, which makes each AI prompt a disclosure that must be limited to what the task needs.
The technical safeguards
- Access control (§164.312(a)(1)): only authorized persons and software programs reach ePHI. Encryption and decryption is an addressable specification (§164.312(a)(2)(iv)).
- Audit controls (§164.312(b)): mechanisms that record and examine activity in systems that use ePHI.
- Integrity (§164.312(c)(1)): protection of ePHI from improper alteration or destruction.
- Transmission security (§164.312(e)(1)): protection of ePHI in transit over electronic networks.
- Documentation retained six years (§164.316(b)(2)(i)).
The administrative safeguards that reach AI
- Risk analysis and risk management (§164.308(a)(1)(ii)(A)–(B)): the AI systems that receive PHI, and their providers, belong in the analysis.
- Information system activity review (§164.308(a)(1)(ii)(D)) and information access management (§164.308(a)(4)).
- Security awareness and training (§164.308(a)(5)), including what may be entered into an AI tool.
- Business associate contracts (§164.308(b)(1), §164.314(a)) with every AI vendor that receives PHI, with subcontractor flow-down and incident reporting.
Breach notification and the proposed update
The Breach Notification Rule (§§164.400–414, in force since 23 September 2009) requires notification without unreasonable delay and within 60 days of discovering a breach of unsecured PHI. PHI reaching an unapproved model or provider is the AI-workflow incident that procedures must cover.
A notice of proposed rulemaking to modernize the Security Rule was published on 6 January 2025; the comment period closed on 7 March 2025 and the federal Unified Agenda targets July 2027 for final action. Nothing changes until a final rule is published.
Control mapping
What a reviewer expects to be able to see.
| Obligation | What the system must do | Evidence a reviewer expects |
|---|---|---|
| Minimum necessary | Limit PHI in each use and disclosure, including AI prompts, to what the purpose requires | A standard protocol for routine AI disclosures and a record of what was withheld or redacted |
| Audit controls | Record and examine activity in systems that use ePHI | A tamper-evident record of AI requests and decisions, retained six years |
| Transmission security and encryption | Protect ePHI in transit and, where reasonable, at rest | TLS on the AI request path; encrypted, customer-keyed audit storage |
| Integrity | Protect ePHI and the systems that use it from improper alteration | Configuration change history and drift findings for AI workflows |
| Business associates | Execute BAAs with every AI vendor that receives PHI | The vendor list that actually received PHI, and the agreements covering it |
| Risk analysis, training, breach procedures | Cover AI systems in the risk analysis, the training program, and the breach procedures | The analysis, the training record, and the tested procedure |
Key dates
- 14 April 2003Privacy Rule compliance date, including the minimum-necessary standard.
- 20 April 2005Security Rule compliance date for most covered entities.
- 23 September 2009Breach Notification Rule takes effect.
- 23 September 2013Omnibus Rule: business associates directly liable under the Security Rule.
- 6 January 2025Security Rule modernization NPRM published; comments closed 7 March 2025.
- July 2027Federal Unified Agenda target for final action on the NPRM (not binding).
Primary sources
Common gaps
Where AI workflows most often fail a Security Rule review.
- A model provider with no BAA. A team switches on a copilot under standard API terms. PHI reaches a vendor that has never signed a business associate agreement.
- Minimum necessary treated as a policy, not a control. The policy says limit PHI; the prompt carries the whole chart. Without a redaction step at the request layer, the standard is asserted and never operated.
- A risk analysis that predates the AI program. OCR's first request is the risk analysis. One that does not list the ambient-documentation tool or the messaging assistant is incomplete on its face.
- An audit trail that cannot be examined. Vendor logs, screenshots, and exports read as reconstruction. §164.312(b) asks for a mechanism that records and examines activity.
- Breach procedures with no AI pathway. PHI reaching an unapproved model is a breach assessment trigger. Procedures that never contemplated it stall at the first question.
In practice
Related
Last reviewed September 5, 2026. This reference summarises publicly available regulatory guidance and is provided for general information. It is not legal advice. Obligations depend on an institution's charter, registration status, size, and activities. Verify against the primary sources cited above and consult counsel before relying on any summary here.