This is not compliance or legal advice. It is a technical and architectural explainer for healthcare organizations evaluating AI workflows. Whether a specific use meets HIPAA in your situation depends on your data, your contracts, and your risk analysis. Talk to your privacy officer, your compliance team, and your own counsel before putting PHI near any AI tool.
We build HIPAA-architected software for healthcare organizations, including AI integrations and platforms where protected health information has to stay controlled end to end. We have built a DEA-compliant controlled-substance platform and a HIPAA-compliant healthcare learning platform with AI inside it. The thing that surprises people is how little the model choice matters to the compliance question, and how much everything around it does.
The instinct, when leadership asks whether the team can use AI, is to look for a yes-or-no answer at the vendor level. "Is OpenAI compliant? Is Anthropic?" That framing fails because the same vendor offers both a path you should never put PHI into and a path you can. Compliance lives in the gap between those two paths.
"HIPAA compliant AI" is not a product. It is an architecture.
HIPAA does not certify products, and no model is "HIPAA compliant" on its own. What HIPAA does is impose obligations on covered entities and their business associates: safeguards over PHI, a contract governing anyone who handles it on your behalf, and accountability for where it goes. An AI tool can satisfy those obligations or violate them depending entirely on how it is set up and used.
So when a vendor's marketing page says "HIPAA compliant," read it as shorthand for "we can be configured and contracted in a way that supports your compliance." It is never a guarantee that pasting PHI into the default consumer interface is fine. The model is not the variable. The surface, the contract, retention, access, and review are.
The seven things that actually decide it
If compliance is an architecture, here is the architecture. None of these is about which model is smartest. Every one of them is vendor-neutral, and every one applies whether you are using ChatGPT, Claude, or anything else.
1. A signed BAA with the AI vendor that covers PHI
If an AI tool creates, receives, maintains, or transmits PHI on your behalf, it is a business associate, and HIPAA requires a Business Associate Agreement. This is the first gate, and it is the one most teams skip. The hard truth is that consumer ChatGPT and consumer Claude chat tiers are generally not offered under a BAA. That means putting PHI into the consumer chat tab is a gap no careful prompting can close. The vendors' API and enterprise paths can be brought under a BAA. If a vendor will not sign a BAA for the exact path you are using, that path is off the table for PHI, full stop, no matter how good the model is.
2. Your PHI is not used to train models
A BAA covers the contract; training covers what happens to the data inside it. You want an explicit guarantee that your prompts and the PHI in them are not used to train or improve the vendor's models. On the major API paths this is generally the default behavior rather than something you opt into, but it is worth confirming in writing for your specific account and path. Consumer tiers, by contrast, often have their own data-use behavior. Training-off and retention-off are two different controls, and you want both.
3. Controlled or zero data retention
Training answers "will my data shape the model?" Retention answers "will my data still exist on someone else's server tomorrow?" For PHI you want that answer controlled. Some vendors offer zero-data-retention arrangements on specific paths, where nothing is stored after the request completes. Anthropic, for example, offers zero-data-retention on the API at the organization level, not on consumer chat. The principle generalizes: figure out what is retained, for how long, and where, and minimize it. We cover the Claude-specific details in our zero-data-retention breakdown.
4. Access controls and minimum necessary
HIPAA's minimum-necessary standard says PHI should be limited to what is actually needed for the task. An AI workflow should reflect that. Who can run it, what records it can reach, and how much of a record it sees should all be scoped down rather than wide open. A model with read access to your entire patient database "just in case" is a liability even if every other control is in place. Scope the inputs, scope the people, and log who has access to what.
5. Encryption in transit and at rest
This is the table-stakes control and the one people assume is handled. PHI moving to and from the AI service must be encrypted in transit, and anything stored along the way (including in your own systems, transcripts, caches, and logs) must be encrypted at rest. Encryption does not make a non-compliant path compliant, but its absence makes any path non-compliant. Verify it across the whole chain, not just the model call.
6. An append-only audit trail of every AI access to PHI
HIPAA expects you to be able to account for access to PHI. That means an audit log recording every time the AI workflow touched protected data: who triggered it, what was accessed, when, and what came back. Append-only matters, because a log you can quietly edit is not evidence of anything. This is also the control that turns a vague "we use AI carefully" into something you can actually show during a review or an incident.
7. Mandatory human review of AI output
The last control is not about privacy, it is about clinical safety. AI output can be wrong, confidently. Any AI-generated content that informs a clinical decision, a patient communication, or a record must pass through a qualified human before it is relied on. Build that gate into the workflow as a required step, not an optional courtesy. A workflow that lets AI output reach a patient or a chart unreviewed is a problem no BAA fixes.
The one-line version: A model is not "HIPAA compliant." A workflow is, when it runs on a BAA-covered path, keeps your PHI out of training, controls retention, scopes access to the minimum necessary, encrypts everything, logs every access, and puts a human between the AI and any clinical use.
Consumer chat versus a BAA-covered API or enterprise path
Here is the distinction that most "is ChatGPT HIPAA compliant?" questions are really circling. The same vendor, often the same model, behaves completely differently depending on which path you are on. This table is intentionally vendor-neutral; it describes the typical shape of the consumer chat tier versus the API or enterprise path that can be brought under a BAA. Confirm the specifics for the exact tier and contract you are evaluating.
| Question | Consumer chat tier | API / enterprise with BAA |
|---|---|---|
| BAA available for PHI? | Generally not offered | Can be signed for the path |
| Used for training? | Varies by tier and settings | Generally not, by default |
| Retention control? | Vendor policy applies | Controllable; ZDR on some paths |
| Audit trail of PHI access? | Not designed for it | You can build and own it |
The takeaway is the same one that runs through every honest answer on this topic. "Same model" does not mean "same risk." The consumer chat tab and the BAA-covered API workflow can be running identical weights and carry opposite compliance profiles. When someone asks whether a given AI tool is HIPAA compliant, the only correct first response is "which path are you on?"
The AI is rarely the only thing touching PHI
This is the part that gets missed even by teams that nail the model question. The AI call is usually one link in a chain, and every other link handles PHI too. If you pipe a telehealth consult into an AI summarizer, the transcription service touched PHI first. If the summary lands in a spreadsheet or an automation tool before it reaches a chart, that tool touched it. If a chatbot looks up a record before answering, the lookup path touched it.
Each of those is a vendor that needs the same scrutiny as the model: is there a BAA, what is retained, where does it process, is it encrypted, is access scoped. A flawless BAA-covered model call wrapped in a no-code automation glue layer that quietly stores transcripts is not a compliant workflow, it is a compliant model call inside a non-compliant pipeline. This is also why we are cautious about chaining many convenience tools together for PHI work. Every hop is another place data can rest, cross a border, or escape your audit log. Audit the whole path, not just the model.
The checklist to run before PHI touches any AI tool
Before you let protected health information near a model, you should be able to answer all of these for the specific tool and the specific path. If any answer is "no" or "not sure," stop and resolve it first.
- BAA. Is there a signed Business Associate Agreement covering PHI on the exact path you will use, not just "the vendor in general"?
- Training. Is it confirmed in writing that your PHI will not be used to train or improve models?
- Retention. Do you know what is stored, for how long, and where, and is it as close to zero as the workflow allows?
- Access. Is access scoped to minimum necessary, with the right people and only the records the task needs?
- Encryption. Is PHI encrypted in transit and at rest across every system in the chain, including logs and caches?
- Audit trail. Is there an append-only log of every AI access to PHI that you control?
- Human review. Is there a required human checkpoint before any AI output is used clinically or sent to a patient?
- Whole path. Have you applied all of the above to every other vendor in the workflow, not only the model?
- De-identification. Where the task allows it, can you keep PHI out of the model entirely and send only de-identified context?
That last item is the most underused. For a lot of workflows, especially patient-facing chatbots, the safest architecture keeps PHI out of the model altogether: identifiers and records stay in your own systems, and the AI only ever sees de-identified context. We walk through that pattern in building a HIPAA AI chatbot without PHI.
What this does not mean
It does not mean AI is off-limits in healthcare. A BAA-covered path with controlled retention, scoped access, full encryption, an audit trail, and human review is a defensible architecture, and plenty of valuable workflows fit inside it. It also does not mean an API or enterprise plan is automatically safe; if you skip the audit trail or let output reach a chart unreviewed, you have a non-compliant workflow on a "compliant" path. And it does not resolve every situation, because your specific risk analysis, your state rules, and your contracts still govern. The point is narrower and more useful: stop asking whether a model is compliant and start asking whether your workflow is.
The short version
- "HIPAA compliant AI" is not a product you buy. It is an architecture and a process.
- The model is rarely the variable. The BAA, training, retention, access, encryption, audit trail, and human review are.
- Consumer ChatGPT and Claude chat are generally not offered under a BAA; the API and enterprise paths can be.
- Same model, different surface, opposite risk. Always ask which path you are on.
- The AI is rarely the only vendor touching PHI. Audit the whole path, and keep PHI out of the model where you can.
Frequently asked questions
Is ChatGPT HIPAA compliant?
The consumer ChatGPT product is generally not something you should put PHI into, because consumer chat tiers are typically not offered under a BAA and are not designed around HIPAA confidentiality and retention. "HIPAA compliant" is not a property of a model, it is a property of the path you are on. OpenAI's API and enterprise paths can be configured under a BAA with controlled retention, which is a materially different risk profile than the consumer chat tab even with the identical model underneath. Check the specific tier and contract, not the brand name.
Can Claude be used for healthcare and PHI?
Claude can be part of a HIPAA-compliant workflow, but only on the right path. Consumer Claude chat (Pro or Team) is generally not offered under a BAA. Anthropic offers BAAs and zero-data-retention on specific paths, the API and enterprise tiers, not on consumer chat. PHI through a BAA-covered API workflow with controlled retention and human review is defensible; pasting PHI into the consumer chat tab is not. The question is which path you are on, not whether the model is good.
What makes an AI workflow HIPAA compliant?
Seven things, none of which are the model itself: a signed BAA covering PHI, a guarantee your PHI is not used for training, controlled or zero retention, access controls and minimum-necessary scoping, encryption in transit and at rest, an append-only audit trail of every AI access to PHI, and mandatory human review of output before clinical use. Then apply the same checks to every other vendor in the path, because the AI is rarely the only system touching PHI.
Do I need a BAA with my AI vendor?
Yes, if the AI tool creates, receives, maintains, or transmits PHI on your behalf, it is a business associate and HIPAA requires a BAA. The catch is that consumer chat tiers are generally not offered under a BAA, so using them for PHI leaves a gap no careful prompting closes. The vendors' API and enterprise paths can be brought under a BAA. If a vendor will not sign one for the path you are using, that path is not an option for PHI, regardless of model performance.
Is a HIPAA compliant AI chatbot possible?
Yes, but it depends on how it is built, not on the model behind it. A compliant AI chatbot needs a BAA-covered model path, controlled retention, access controls, encryption, an audit trail of every PHI access, and a clear boundary on what it can see. A safer common pattern for patient-facing bots is to keep PHI out of the model entirely, handling identifiers and records in your own systems and only sending de-identified context to the AI. The same architecture and process rules decide it, the same way they decide any other AI workflow.
Designing an AI workflow you can defend?
We build HIPAA-architected AI integrations and platforms for healthcare organizations, with the BAA path, retention, access controls, audit trail, and human review designed in from the start rather than bolted on. We have shipped a DEA-compliant controlled-substance platform and a HIPAA-compliant healthcare AI learning platform, so this is the part we live in. If you want a straight technical answer on what a defensible setup looks like for your workflow, not a sales pitch, we are happy to walk through it. Simple integrations start at $1,700; custom builds run $17K to $53K depending on scope.
Book a 30-minute architecture call →
Related reading from our healthcare practice:
