HIPAA Compliance for AI in Healthcare
Last verified: 2026-05-08 — primary sources: HHS OCR HIPAA Privacy Rule, treatment/payment/operations guidance, Security Rule, cloud-computing guidance, de-identification guidance, Breach Notification Rule, and FDA AI-enabled medical-device resources (retrieved 2026-05-08).
HIPAA compliance for AI is not a separate AI statute. For covered entities and business associates, the threshold question is whether an AI workflow creates, receives, maintains, transmits, uses, or discloses protected health information (PHI). HHS OCR describes the Privacy Rule as the federal baseline for medical records and other individually identifiable health information, with limits and conditions on uses and disclosures without an individual's authorization. Source: HHS OCR HIPAA Privacy Rule, retrieved 2026-05-08.
Quick answer
A healthcare AI system is usually HIPAA-relevant when it touches PHI for one of these workflows:
| AI workflow | HIPAA control surface | Primary-source anchor |
|---|---|---|
| Clinical summarization, coding, prior authorization, care-management triage | Privacy Rule basis for using PHI, minimum-necessary design where applicable, Security Rule safeguards | HHS OCR Privacy Rule + TPO guidance |
| Vendor-hosted model, cloud AI platform, medical scribe, or API service receiving ePHI | Business associate agreement (BAA), risk analysis, service-level limits, ePHI availability controls | HHS OCR cloud-computing guidance |
| Model development or analytics on de-identified data | Expert Determination or Safe Harbor de-identification; re-identification controls | HHS OCR de-identification guidance |
| AI-enabled diagnostic or treatment software | HIPAA plus FDA device / software-as-a-medical-device analysis when the product has a medical purpose | FDA AI in SaMD resources |
| Impermissible disclosure through prompts, logs, telemetry, support tickets, or model training | Breach risk assessment and notification workflow | HHS OCR Breach Notification Rule |
What counts as PHI in an AI project
HHS OCR explains that PHI is individually identifiable health information held or transmitted by a covered entity or its business associate, in any form or medium. It includes information relating to an individual's health condition, health care, or payment for health care when the information identifies the individual or could reasonably identify the individual. Source: HHS OCR de-identification guidance, retrieved 2026-05-08.
For AI programs, PHI can appear outside the obvious clinical note. It may be in prompts, embeddings, fine-tuning data, model-evaluation sets, telemetry, chat transcripts, call-center recordings, screenshot attachments, support tickets, audit logs, and vendor observability tooling. A defensible AI inventory should record each PHI-bearing data path before the organization decides whether the model is safe for production use.
Permitted use is not the end of the analysis
HHS OCR's treatment, payment, and health-care-operations guidance states that the Privacy Rule permits covered entities to use and disclose PHI for treatment, payment, and health-care operations with limits and protections. It also notes that administrative, financial, legal, and quality-improvement activities may be health-care operations when they support treatment and payment. Source: HHS OCR TPO guidance, retrieved 2026-05-08.
That means some AI uses can fit within treatment, payment, or operations, but the workflow still needs controls. The organization still has to determine role, purpose, disclosed data elements, vendor status, user access, logging, retention, and whether the notice of privacy practices and contractual terms support the use.
Vendor and cloud AI controls
HHS OCR's cloud guidance says covered entities and business associates may use cloud services if they enter into appropriate BAAs and conduct risk analysis and risk management for ePHI. The same guidance states that a cloud service provider acting as a business associate is directly liable if it uses or discloses PHI outside the contract, fails to safeguard ePHI under the Security Rule, or fails to notify the covered entity or business associate after discovering a breach of unsecured PHI. Source: HHS OCR cloud-computing guidance, retrieved 2026-05-08.
For AI procurement, this turns the vendor review into a concrete checklist:
- Does the vendor receive, store, log, process, or train on PHI or ePHI?
- Is the vendor willing to sign a BAA that matches the actual AI workflow?
- Do the service terms prohibit secondary model training or product improvement on PHI unless expressly authorized?
- Can the organization disable prompt retention, debug logging, human review, or telemetry that would expose PHI outside the agreed service boundary?
- Does the service-level agreement support availability, backup, recovery, termination return/destruction, and disclosure limits consistent with the BAA?
Security Rule baseline for AI
HHS OCR states that the HIPAA Security Rule requires appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of ePHI created, received, used, or maintained by covered entities and business associates. Source: HHS OCR Security Rule, retrieved 2026-05-08.
AI controls should therefore include model-access controls, least-privilege roles, prompt and output audit logs, encryption in transit and at rest, environment separation for testing, retention limits for prompts and generated content, incident-response playbooks, vendor monitoring, and documented risk analysis for the full data flow. For high-impact clinical or coverage workflows, the HIPAA security analysis should be paired with NIST AI RMF MAP/MEASURE controls and ISO/IEC 42001 Annex A governance controls.
De-identification is a method, not a label
HHS OCR's de-identification guidance says the Privacy Rule provides two methods for de-identifying health information: Expert Determination and Safe Harbor. It also states that properly de-identified health information is no longer PHI, while warning that de-identified data retains some residual re-identification risk. Source: HHS OCR de-identification guidance, retrieved 2026-05-08.
For AI development, de-identification should be documented before data enters training, fine-tuning, retrieval, evaluation, or analytics pipelines. The record should identify the method used, the expert or Safe Harbor process, residual risk assumptions, prohibited re-identification behavior, retention, and whether downstream recipients can combine the data with other sources. Synthetic data should not be treated as de-identified merely because it is generated; the organization should test whether it leaks or reconstructs source-record characteristics.
Breach-response path for AI disclosures
HHS OCR's Breach Notification Rule page states that covered entities and business associates must provide notification after a breach of unsecured PHI. The same source describes breach analysis as a risk assessment of the nature and extent of PHI involved, the unauthorized recipient, whether the PHI was actually acquired or viewed, and mitigation. Source: HHS OCR Breach Notification Rule, retrieved 2026-05-08.
AI-specific breach planning should cover prompt misrouting, unauthorized training ingestion, vendor log exposure, overbroad human-review queues, exported model-evaluation files, and generated outputs that reveal patient information. The incident plan should make clear who can suspend a model, revoke vendor access, preserve audit logs, run the HIPAA breach risk assessment, and notify the business owner.
FDA overlap: when healthcare AI is also medical-device AI
FDA says AI and machine learning technologies are used in medical devices and that AI technologies benefit from careful management across the medical-product life cycle. FDA also maintains an AI-enabled medical-device list for devices authorized for marketing in the United States. Sources: FDA Artificial Intelligence in Software as a Medical Device and FDA Artificial Intelligence-Enabled Medical Devices, retrieved 2026-05-08.
FDA authorization does not replace HIPAA analysis. A medical-device AI product can be FDA-cleared or FDA-authorized and still require HIPAA controls if a covered entity or business associate uses PHI or ePHI with the product. Conversely, an internal administrative AI tool can be outside FDA device scope while still being HIPAA-relevant because it processes PHI.
State AI law overlap
HIPAA is only one layer. Healthcare AI can also fall within state AI laws tracked by the Atlas. Examples include Colorado AI Act high-risk systems affecting health-care services, Texas TRAIGA disclosure and discrimination controls, Utah AI Policy Act health-care professional disclosure provisions, and Illinois HB 3773 where employment or workforce decisions are involved. Use the healthcare industry hub to map the state-law layer after the HIPAA data-flow analysis is complete.
Practical HIPAA AI checklist
- Inventory every AI workflow and mark whether PHI or ePHI enters prompts, files, embeddings, logs, monitoring, model training, or support channels.
- Classify the actor: covered entity, business associate, subcontractor, workforce member, or outside recipient.
- Record the Privacy Rule basis: treatment, payment, health-care operations, authorization, de-identification, or another specific permission.
- Require a BAA before a vendor or cloud AI service receives ePHI.
- Run Security Rule risk analysis for the end-to-end AI data flow, including model observability and support tooling.
- Decide whether development or analytics data must be de-identified under Expert Determination or Safe Harbor.
- Separate FDA medical-device questions from HIPAA questions; answer both when the AI has a medical purpose and receives PHI.
- Add breach-response triggers for prompts, logs, vendor retention, generated output, and training-data ingestion.
- Map the same system to state AI laws and federal AI frameworks.
- Re-verify sources at least annually or whenever HHS OCR, FDA, or state AG guidance changes.
Frequently asked questions
Does HIPAA allow AI in healthcare?
HIPAA does not categorically prohibit AI. The Privacy Rule controls uses and disclosures of PHI, the Security Rule controls safeguards for ePHI, and the Breach Notification Rule controls response to unsecured PHI breaches. The AI workflow must fit those rules before it is deployed.
Can a hospital use a public chatbot with patient information?
A public chatbot or general AI service should not receive PHI unless the service arrangement satisfies HIPAA requirements, including an appropriate BAA and safeguards for ePHI where applicable. HHS OCR's cloud guidance frames the BAA and risk-analysis requirements for cloud providers that handle ePHI.
Is de-identified data outside HIPAA?
HHS OCR states that de-identified health information is no longer PHI when it satisfies the Privacy Rule de-identification standard, but de-identification is not a label applied by convenience. The organization should document Expert Determination or Safe Harbor methodology and control re-identification risk.
Does FDA authorization prove HIPAA compliance?
No. FDA's AI-enabled device resources address medical-device safety and effectiveness pathways. HIPAA analysis separately asks whether a covered entity or business associate uses, discloses, or safeguards PHI/ePHI in the AI workflow.