HIPAA Compliance for AI in Healthcare

Last verified: 2026-06-19 — guide reviewed and expanded on 2026-06-19 with a healthcare AI tool-category map and tool-specific FAQs. 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.

Is AI HIPAA compliant? No artificial-intelligence product is "HIPAA compliant" on its own as of June 19, 2026. HIPAA compliance is a property of how a covered entity or business associate configures, contracts for, and controls an AI workflow that touches protected health information (PHI) — not a certification a model carries. An AI system becomes defensible under HIPAA when the organization documents a Privacy Rule basis for the PHI it uses, signs a business associate agreement (BAA) with any vendor that receives electronic PHI (ePHI), and applies the Security Rule's administrative, physical, and technical safeguards across the full data path.

Quick answer

A healthcare AI system is usually HIPAA-relevant when it touches PHI for one of these workflows:

Healthcare AI tool categories and HIPAA posture

Most healthcare AI procurement questions reduce to one issue: does the specific tool category create, receive, maintain, or transmit PHI, and if so, is a BAA in place? The table below maps common categories to their typical HIPAA posture. Posture is a starting point for the organization's own data-flow analysis under the HHS OCR guidance cited throughout this guide, not a determination for any specific product.

The two rows that most often cause incidents are the consumer-chatbot row, where staff paste PHI into a service that has no BAA, and the AI-scribe row, where audio capture and draft-note retention extend the PHI footprint into vendor logs. Both map back to the HHS OCR cloud-computing BAA and Security Rule requirements described below.

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

1. Inventory every AI workflow and mark whether PHI or ePHI enters prompts, files, embeddings, logs, monitoring, model training, or support channels.
2. Classify the actor: covered entity, business associate, subcontractor, workforce member, or outside recipient.
3. Record the Privacy Rule basis: treatment, payment, health-care operations, authorization, de-identification, or another specific permission.
4. Require a BAA before a vendor or cloud AI service receives ePHI.
5. Run Security Rule risk analysis for the end-to-end AI data flow, including model observability and support tooling.
6. Decide whether development or analytics data must be de-identified under Expert Determination or Safe Harbor.
7. Separate FDA medical-device questions from HIPAA questions; answer both when the AI has a medical purpose and receives PHI.
8. Add breach-response triggers for prompts, logs, vendor retention, generated output, and training-data ingestion.
9. Map the same system to state AI laws and federal AI frameworks.
10. 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.

Is ChatGPT or a public AI chatbot HIPAA compliant?

A general-purpose public AI assistant is a consumer service that is not offered under a HIPAA business associate agreement, so PHI should not be entered into it. HHS OCR's cloud-computing guidance frames the BAA and risk-analysis requirements that apply before any service receives ePHI. Some vendors offer separate enterprise or API tiers that can be covered by a BAA — a covered entity should confirm BAA coverage for the exact service tier in writing before any PHI is processed.

What makes an AI tool HIPAA compliant?

There is no HIPAA certification for AI products. A defensible deployment combines a documented Privacy Rule basis for the PHI used, a BAA with any vendor that receives ePHI, Security Rule administrative, physical, and technical safeguards across prompts, logs, and training data, de-identification where development data allows it, and a breach-response path for AI-specific disclosure routes.

Do you need a BAA for an AI vendor?

A BAA is generally required when an AI vendor or cloud AI service creates, receives, maintains, or transmits PHI or ePHI on behalf of a covered entity or business associate. HHS OCR 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 report a breach. If a vendor will not sign a BAA that matches the actual AI workflow, the workflow should not process PHI through that vendor.

Are AI medical scribes HIPAA compliant?

AI medical-scribe and ambient-documentation tools typically capture encounter audio and clinical content, which is PHI, so they are HIPAA-relevant. The covered entity should confirm a BAA, control recording and draft-note retention, apply Security Rule safeguards, and include scribe audio and generated notes in its breach-response analysis before production use.

Cross-references

• Healthcare AI compliance hub
• NIST AI RMF
• ISO/IEC 42001
• AI impact assessment template
• Compliance Checker
• State-by-state privacy law reference — how US state comprehensive privacy laws carve out (or don't) HIPAA-covered health data.