Large language models arrived faster than the rules that govern patient data, and HIPAA — the US Health Insurance Portability and Accountability Act — never mentions them. So the practical question clinicians and health-IT teams keep asking, what is permitted, has no bespoke answer. It has to be reasoned from the text already on the books: the Privacy Rule and Security Rule at 45 CFR Part 164. The good news is that the text is clearer than the anxiety around it suggests. This page maps four common patterns onto the exact provisions that decide them, reading straight from the rule. It is general information for orientation, not legal advice. As of July 2026.
The one question that decides everything
Almost every HIPAA question about AI collapses into a single prior: is the data you are handing the model protected health information? If the answer is no — because the information was never identifiable, or because it has been properly de-identified — most of the Privacy Rule simply stops applying. If the answer is yes, then a second question follows immediately: who is processing that PHI, and under what agreement? Those two questions, in that order, resolve the large majority of real cases. The glossary entry on de-identification versus anonymization is worth reading alongside this, because the two terms are not interchangeable and the difference has legal weight.
Four patterns, mapped to the rule
Here are the four patterns that cover most of what people actually do with a clinical LLM, each tied to the provision that governs it. Read the verdict column as a starting analysis rather than a clearance.
| Pattern | Is PHI involved? | What HIPAA requires | Starting verdict |
|---|---|---|---|
| Paste PHI into a public chatbot, no agreement | Yes | A business associate agreement and safeguards that are absent here 23 | Outside what the rule permits |
| Use a vendor under a business associate agreement | Yes | Signed BAA, defined uses, Security Rule safeguards 238 | Permitted if the agreement and safeguards hold |
| De-identify first, then use any tool | No (once de-identified) | Proper de-identification; no actual knowledge of re-identification 1 | Permitted; Privacy Rule no longer restricts use |
| Train a model on identifiable records | Yes | Fits health care operations, or authorization, or de-identify first 457 | Unsettled — analyze case by case |
The rest of this page unpacks each row.
Why is de-identification the cleanest permission?
The most durable way to use any model — public or private — is to make sure the data is no longer PHI before it leaves your control. HIPAA is explicit that information which does not identify an individual, and for which there is no reasonable basis to believe it can be used to identify one, is not individually identifiable health information 1. Strip identity properly and the Privacy Rule stops governing the data.
The rule gives two routes to get there, both at 45 CFR 164.514(b):
- Safe Harbor removes 18 specified categories of identifiers — names, geographic subdivisions smaller than a state, all date elements finer than a year for dates tied to an individual, contact numbers, record and device identifiers, biometric identifiers, full-face photographs, and any other unique identifying number or code — and requires that the covered entity have no actual knowledge the residual information could identify the person 1.
- Expert Determination lets a person with appropriate statistical knowledge document that the risk of re-identification is very small, using accepted methods, and record how that conclusion was reached 1.
There is also a middle option the rule defines separately: the limited data set, which may retain some dates and partial geography but strips direct identifiers, and which may be used for research, public health, or operations under a data use agreement 1. A limited data set is still PHI, so it does not carry the same freedom as full de-identification.
Two cautions belong with every de-identification decision. First, free text is hard to de-identify: a clinical note can re-identify a patient through a rare diagnosis, an unusual date pattern, or a quoted detail, so removing the 18 structured fields does not guarantee the narrative is clean. Second, the "no actual knowledge" condition is a live obligation rather than a one-time checkbox — if you know the small population or unique combination that would unmask someone, Safe Harbor is not satisfied.
In practice, teams get the most durable footing by de-identifying at the source — stripping identifiers before any text reaches the model — rather than relying on a vendor to clean the data downstream. The covered entity keeps both the legal obligation and the actual knowledge that the standard turns on, so doing the work upstream keeps the decision, and the audit trail, in the hands of the party the rule holds responsible 1.
What happens when the vendor touches PHI?
If you want a model to work on identifiable data, the question becomes who is running it. HIPAA's definition of a business associate is broad and reaches cloud AI squarely: a business associate is a person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity for a covered function, and the definition lists data analysis among those functions 2. A vendor whose model ingests your PHI to produce an output for you is performing exactly that function.
That status carries obligations. The relationship must be governed by a written business associate agreement that establishes the permitted and required uses of the PHI, requires appropriate safeguards, and requires the associate to report unauthorized use or disclosure 3. Where the vendor uses subcontractors — a foundation-model provider behind an application layer, say — the chain of agreements has to reach them too, because a subcontractor that handles PHI on a business associate's behalf is itself a business associate 2.
Underneath the contract sits the Security Rule. For electronic PHI, 45 CFR 164.312 sets technical safeguards: access control, audit controls, integrity protection, authentication of the person or entity seeking access, and transmission security, with encryption specified as an addressable implementation 8. And the minimum necessary standard applies throughout: reduce the PHI you expose to the least required for the purpose, which for an AI workflow is a direct argument against sending an entire record when a problem list and the relevant note would do 6.
The practical takeaway is that a signed BAA is a necessary condition, never a sufficient one. An agreement without the safeguards behind it is paperwork; the safeguards without an agreement leave the legal relationship undefined. Both have to be real. This is also where prompt content and logging deserve scrutiny — anything a user types can carry PHI, and the pathways that store or transmit those prompts are covered by the same rules. See the glossary note on prompt injection in clinical systems for the security dimension that sits next to the privacy one.
A related subtlety is that a model's outputs are records too. A generated note, summary, or draft answer that contains patient information becomes PHI the moment it exists — which means retention limits, access logging, and a patient's right to their record attach to what the model produces, as well as to what it was given. Treat the prompt, the response, and any stored transcript as parts of the record set, and apply the same access controls and audit trail across all three 8.
Permitted use versus authorization — and the training question
Even with the right vendor relationship, HIPAA still asks why you are using the PHI. The Privacy Rule permits uses and disclosures for treatment, payment, and health care operations without a patient's authorization 4. Uses that fall outside those permitted categories generally require an authorization — a specific, signed permission from the individual 5. So a model that helps draft a note for a patient you are treating sits comfortably inside the treatment purpose; a model used to build a commercial product from identifiable records does not, without more.
This is where the hardest current question lives: is training a model on patient records a permitted use? The answer depends on whether it fits within health care operations, and the definition at 45 CFR 164.501 lists activities such as quality assessment and improvement, developing clinical guidelines, and business planning and development 7. A quality-improvement model trained inside a covered entity has a plausible home there. A general-purpose model trained for broad reuse is a harder fit, because the operations categories were written years before model training was a common activity and were not designed to answer this question. De-identifying the training data, or obtaining authorization, are the two ways to sidestep the ambiguity entirely. The analysis tightens further where the purpose shades into marketing or the sale of PHI: those uses carry their own authorization requirements under 45 CFR 164.508, so a plan to monetize a model built from identifiable records raises a second, separate consent question on top of the operations one 5. Until there is specific guidance, treat training on identifiable records as a case-by-case legal determination rather than a settled permission.
How to read this page
Four cautions travel with everything above.
First, guidance is not the rule, and the rule is not the whole law. This page reads the federal regulation text, which is the primary authority, but agency guidance interprets it and can shift, and HIPAA sets a floor rather than a ceiling.
Second, state law is frequently stricter. Many states add consent requirements, breach rules, or protections for sensitive categories that go beyond HIPAA — a dimension we track for one specific tool class in the US state laws on AI scribes tracker, and more broadly in the global AI in health regulation tracker.
Third, HIPAA is only the privacy-and-security layer. It does not resolve who is responsible when a model-assisted decision goes wrong; that is a separate analysis covered in liability when clinical AI errs.
Fourth — and this is the one that matters most — this is general information, not legal advice. Every real deployment turns on facts this page cannot see: the exact data, the vendor terms, the jurisdiction, and your organization's policies. Confirm any use of patient data with an LLM with your privacy counsel and compliance office before you rely on it.
Sources and method
This page is built from the primary regulatory text — the HIPAA Privacy Rule and Security Rule at 45 CFR Part 164, together with the definitions at 45 CFR 160.103 — read through the Electronic Code of Federal Regulations and cited section by section: de-identification and the limited data set 1, the business associate definition 2, the business associate contract requirements 3, permitted treatment/payment/operations uses 4, the authorization requirement 5, the general rules and minimum necessary standard 6, the definition of health care operations 7, and the Security Rule technical safeguards 8. We revisit this page every 90 days and whenever HHS issues AI-specific guidance, finalizes Security Rule changes, or an enforcement action reframes any of these provisions. Dates and statuses are current as of July 2026.