HIPAA compliance for AI systems requires that any AI tool processing protected health information (PHI) meet the same safeguards as any other covered technology: the minimum necessary standard, access controls, audit trails and a signed Business Associate Agreement (BAA) with the AI vendor. There is no separate, lighter version of HIPAA for artificial intelligence. If a system creates, receives, maintains or transmits PHI on behalf of a covered entity, it is a business associate, full stop, whether it is a claims database or a large language model.
That equivalence is where most organizations get tripped up. Teams that would never let an uncontracted vendor touch a patient record will paste a discharge summary into a chatbot to “summarize it faster,” without asking whether that chatbot’s operator has signed a BAA, retains the input or uses it to train future models. The AI wrapper does not change what HIPAA requires. It just makes it easier to forget to ask.
This guide covers what HIPAA actually requires of AI systems, the four points in an AI pipeline where PHI exposure happens, what to look for in an AI vendor’s BAA, why the in-VPC versus cloud decision determines your compliance posture more than any prompt-engineering choice and how a de-identification layer resolves most of this risk before it starts.
What HIPAA actually requires for AI
HIPAA does not mention artificial intelligence. It does not need to. The Privacy Rule and Security Rule apply to protected health information regardless of what kind of software is processing it, and three concepts do almost all the work.
Protected Health Information (PHI) is individually identifiable health information created, received or maintained by a covered entity or business associate. It becomes identifiable when any of 18 specific identifiers—names, dates tied to an individual, contact details, medical record numbers, biometric data and more—remain attached to health data. HHS’s Office for Civil Rights lays out the full list and the two permitted de-identification methods, Expert Determination and Safe Harbor, in its official guidance on de-identifying PHI.
The minimum necessary standard requires covered entities and business associates to limit PHI use, disclosure and requests to the minimum needed for the task. An AI system that ingests an entire patient chart to answer a narrow clinical question is very likely violating minimum necessary, even if every downstream safeguard is in place.
Covered entities and business associates are the two categories HIPAA regulates. A hospital is a covered entity. An AI vendor that processes PHI on the hospital’s behalf, whether that is a transcription API, an LLM or a data de-identification pipeline, is a business associate, and the relationship must be governed by a BAA before any PHI changes hands.
The Security Rule’s technical safeguards apply to an AI system exactly as they apply to an EHR or a billing platform: access control (who can query the model and what it can see), audit controls (a log of every prompt, every output and every user), integrity controls (protection against unauthorized alteration of PHI as it moves through the pipeline) and transmission security (encryption in transit and at rest). An AI vendor that cannot produce a usable audit log of every interaction touching PHI has a Security Rule gap, not just a nice-to-have missing feature. A hospital evaluating an AI-based triage tool, for example, should be able to ask the vendor for a full log of what patient data a specific query touched and get a real answer, not a vague assurance.
Where AI systems create HIPAA risk: four failure points
AI pipelines introduce risk at points that traditional software often does not touch. Four are worth naming specifically, because each requires a different control.
- Data ingestion. The moment PHI enters a model’s context window—a prompt, an uploaded file, a streamed audio feed—it has left its original system of record. If the ingestion point is a consumer AI tool with no BAA, that transfer is already a potential violation, regardless of what happens next.
- Model training. If a vendor uses customer inputs to train or fine-tune its models by default, PHI can become embedded in model weights. Researchers have shown that training data, including identifiable details, can sometimes be extracted from a model through adversarial prompting, so the exposure persists well past the original interaction, embedded in the model itself rather than sitting in a log file you could simply delete. It is exactly the risk of de-identifying data before it reaches an AI training pipeline that is designed to close.
- Output generation. A model can generate PHI that was never explicitly given, by inferring or hallucinating details from context. Clinical AI outputs need the same access controls and audit logging as the inputs that produced them.
- Vendor transmission. Every hop between systems, from EHR to AI tool, from AI tool to a downstream analytics platform, is a transmission point that needs encryption, access logging and a contractual basis under HIPAA.
A healthcare organization piloting an AI-assisted intake tool, for example, might correctly contract the intake vendor under a BAA, then quietly lose that coverage the moment a nurse forwards a flagged transcript to a second, uncontracted summarization tool to save time. The failure point moved. The risk did not go away.
Output generation is worth a second, separate example, since it is the failure point teams most often overlook. A clinical decision support tool asked to summarize a patient’s history might infer a diagnosis or medication detail that was never explicitly stated in the source record, based on patterns learned during training. That inferred detail is now new PHI the organization has created, and it needs the same access logging, retention policy and downstream handling as anything pulled directly from the chart, even though no one typed it in.
The BAA requirement for AI
A signed BAA is the legal floor for using any AI tool with PHI, and the major model providers now offer one, though eligibility varies sharply by product tier.
OpenAI will sign a BAA for ChatGPT Enterprise, ChatGPT Edu with a sales-managed account and its purpose-built healthcare products, and covers its API platform under a BAA on a case-by-case basis, but explicitly does not offer one for ChatGPT Free, Plus or the standard ChatGPT Business tier. Microsoft folds its HIPAA BAA into the Microsoft Online Services Data Protection Addendum, which applies automatically to in-scope services under a qualifying licensing agreement, including Azure OpenAI Service. Google covers Gemini differently depending on the product: the Google Workspace BAA can extend to Gemini in Workspace on covered editions, and a separate Google Cloud BAA covers a published list of Cloud AI products, but the consumer Gemini app and the free Google AI Studio playground fall outside both.
The pattern across every vendor is the same: the BAA attaches to a specific, contracted product tier, not to the vendor’s brand name. A BAA with a vendor for its enterprise platform says nothing about whether an employee using that vendor’s free consumer app is covered. That gap is where most unintentional violations happen.
Beyond confirming the tier, a BAA worth signing should also spell out subcontractor flow-down (does the vendor use its own third-party processors, and are they bound by the same terms), a defined breach notification timeline and what happens to PHI on contract termination. A vendor that cannot answer these questions in writing, rather than pointing to a general privacy policy, has not actually given you a HIPAA-grade agreement.
| Deployment pattern |
BAA available |
Typical HIPAA posture |
| Consumer or free-tier AI chatbots |
No |
Not appropriate for any PHI, under any circumstances |
| Enterprise cloud AI tiers with a signed BAA |
Yes, contractually |
Compliant only with organizational safeguards layered on top: the BAA covers the vendor’s obligations, not the customer’s |
| In-VPC or on-premises AI deployment |
Not applicable, since no PHI leaves the environment |
Strongest default posture, since there is no third-party transmission to govern |
The same tiering problem shows up across every regulated industry, not just healthcare, which is why vendor-tier discipline, not just a signed contract somewhere in the organization, has become a standard line item in AI procurement reviews. A de-identification layer sits underneath that discipline: Limina’s data de-identification platform removes the need to track vendor-tier exceptions for any workflow where PHI never has to reach the AI model in identifiable form.
A signed BAA covers the vendor. It doesn't cover what your team pastes into a chatbot.
De-identify PHI before it reaches any AI model, inside your own VPC or on-premises, with an audit trail of every detection and transformation.
Talk to an Expert
In-VPC vs cloud AI for HIPAA
Architecture decides compliance more than any other single factor, because it decides whether a BAA is even the right tool for the job. A cloud AI service, no matter how well contracted, still means PHI leaves your environment and reaches a third-party server. The BAA governs what the vendor does with it there, but your organization is still responsible for verifying that, in writing, on an ongoing basis. HHS guidance on cloud computing makes clear that covered entities retain HIPAA responsibility even when a BAA-covered service is involved.
An in-VPC or on-premises AI deployment removes that transmission entirely. If the model runs inside your own cloud environment or your own data center, PHI never crosses into a vendor’s infrastructure, which means there is no third-party BAA obligation to manage for that specific data flow. This is the safest architectural default for high-sensitivity clinical workflows, and it is why healthcare IT teams increasingly treat “does this run in our VPC” as the first compliance question, not the last.
Many organizations end up with a hybrid posture rather than an all-or-nothing choice: high-sensitivity workflows, such as anything touching a full clinical record, run in-VPC, while lower-risk, already-de-identified use cases run through a BAA-covered cloud service. That split lets a compliance team apply the strictest architecture only where it is actually needed, instead of either accepting cloud risk everywhere or absorbing the infrastructure cost of running every AI workload in-house.
| Question to ask a vendor |
Why it matters |
| Which product tier is actually covered by the BAA? |
Coverage does not extend automatically to free or consumer tiers of the same product |
| Does the model train on our inputs by default? |
Training use needs to be explicitly opted out, or excluded by contract, before any PHI is sent |
| Where does the data physically process? |
Determines whether a third-party BAA is even the right control, or whether in-VPC removes the question |
See how Limina keeps this decision simple: when PHI never reaches the model in identifiable form, the in-VPC versus cloud question stops being a compliance risk.
How Limina solves HIPAA AI compliance
Limina AI approaches this from a different angle than a BAA-and-hope strategy: it de-identifies PHI before it ever reaches an AI model, so the model is working with data that no longer carries the 18 HIPAA identifiers in the first place. The platform deploys in-VPC or on-premises, so PHI never has to leave a healthcare organization’s own environment to be processed, and it produces expert determination-ready outputs and audit trails that document exactly what was removed and when. For teams building on ANALYZE, that means clinical text, structured records and even audio can be de-identified before they touch a downstream LLM, closing the ingestion and training risk points described above at the source rather than trying to contract around them after the fact. The same underlying pipeline supports both the Safe Harbor method for fast, checklist-based de-identification and the more selective use cases where Retrieval-Augmented Generation over clinical data needs to stay inside a defined compliance boundary.
See how Limina enables HIPAA-compliant AI: data never leaves your environment.
Vendor BAA terms and product tiers referenced above are current as of September 2026 but change on a rolling basis. Confirm current terms directly with each vendor before making a compliance decision.
