Can You Put PHI Into an LLM? A HIPAA Engineer's Decision Tree

Someone on your team has already pasted patient data into a chatbot. That is not cynicism, it is the base rate. The useful question is not whether it happened but what your architecture does about it.

Most write-ups answer "can we use an LLM with PHI?" with "it depends, consult counsel." That is true and useless. Here is the actual decision tree, in the order an engineer hits the decisions.

Node 1: Is it really PHI?

PHI is health information that identifies an individual, held by a covered entity or business associate. The trap is that "de-identified" is a technical standard, not a vibe. Under HIPAA you get there two ways:

• Safe Harbor: strip all 18 enumerated identifiers. Names, geography smaller than a state, all date elements more granular than year (and anything over 89), phone, email, MRN, device IDs, biometrics, full-face photos, and the catch-all "any other unique identifying number, characteristic, or code."
• Expert Determination: a qualified statistician documents that re-identification risk is very small.

If you stripped the name and called it done, you are still handling PHI. Free-text clinical notes are the worst offender here: they smuggle identifiers into prose that a regex will not catch. A note that says "the patient's daughter Marla drove him from the Kirkland clinic on the 3rd" is not de-identified, no matter what your scrubber says about the header fields.

If it is genuinely de-identified → the HIPAA analysis stops. Go build. If not, continue.

Node 2: Is there a BAA with the model provider?

If PHI flows to a vendor, that vendor is a business associate, and you need a signed Business Associate Agreement. No BAA, no PHI. This is binary and it is the node most teams skip because it is procurement's problem and procurement is slow.

Two things engineers get wrong:

The consumer tier is not the enterprise tier. Several major providers will sign a BAA for a specific enterprise or API product and explicitly will not for the consumer chat app. Same brand, same model weights, different contract, different answer. The BAA covers the service you signed for, not everything the vendor ships.

A BAA is necessary, not sufficient. It allocates liability. It does not configure your system. You still owe the risk analysis, the access controls, and the audit trail.

Node 3: Where does the data go, and does it train the model?

Get an explicit, contractual answer to:

• Retention: is the prompt persisted? For how long? Zero-retention modes exist on some enterprise tiers; they are usually opt-in, not default.
• Training: is your input used to improve the model? For PHI the answer must be no, in writing.
• Sub-processors: who else touches it? Inference is frequently not run where you think it is.
• Region: where does it physically execute?

"The vendor says they don't train on API data" is a blog post. What you need is the DPA/BAA clause.

Node 4: Minimum necessary. Are you sending more than you need?

HIPAA's minimum necessary standard is the most underused control in the entire AI stack, and it is the one engineers can implement without procurement.

The reflex is to stuff the whole chart into context because the context window is large. Do not. Ask what the model needs to do the task:

• Summarizing a visit? Send that visit.
• Drafting a prior-auth letter? Send the fields the letter uses.
• Coding assistance? Often you can send structure without identifiers at all.

Every identifier you do not send is a breach you cannot have. A large context window is a capability, not a permission.

Node 5: Can you prove what happened?

The Security Rule wants audit controls, and "the LLM did something" is not an audit trail. You need to log, per request: who invoked it, what was sent (or a hash of it), which model and version answered, and what came back, retained per your policy.

This is also where the ungoverned path bites you. Shadow usage (a clinician pasting a note into a personal account on a personal laptop) generates no BAA, no logs, no minimum-necessary discipline, and no way to scope an incident afterward. You cannot audit what you did not route. The fix is rarely a ban; bans push it further into the dark. Provide a sanctioned path that is easier than the unsanctioned one, then monitor.

Node 6: Have you written it down?

The risk analysis is the obligation OCR enforces most often, and a new class of tooling is exactly the kind of change that makes an old risk analysis stale. If your risk analysis predates the LLM, your risk analysis does not cover the LLM.

Document: what the tool does, what data classes it touches, which safeguards apply, what you decided about retention and training, and what you rejected and why. The "why we said no to X" record is worth as much as the approvals.

The tree, collapsed

Is it PHI?  ── no ──▶ build
   │ yes
   ▼
Signed BAA with the provider (for THIS product tier)?  ── no ──▶ STOP
   │ yes
   ▼
Retention / training / sub-processors / region: contractually pinned?  ── no ──▶ STOP
   │ yes
   ▼
Minimum necessary enforced in the payload?  ── no ──▶ fix before shipping
   │ yes
   ▼
Audit trail on every call?  ── no ──▶ fix before shipping
   │ yes
   ▼
Risk analysis updated to cover this tool?  ── no ──▶ do it now
   │ yes
   ▼
Ship, and monitor for the shadow path you did not authorize

One note on the proposed Security Rule update

You will see a lot of writing that treats the proposed HIPAA Security Rule update as settled law. It is not. It remains proposed, not final, and OMB's Unified Agenda (RIN 0945-AA22) now targets July 2027 for final action, pushed back from a previous May 2026 target. Those timelines are not legally binding; the date has already slipped once.

Two things people get wrong about this:

• The compliance date is later than the rule date. Publication would start a compliance window commonly cited as 180–240 days, so realistic full compliance is a 2028 conversation, not a 2026 one. If a vendor is selling you a 2026 Security Rule deadline, that deadline does not exist.
• The Privacy Rule is a different rulemaking, is targeted for August 2026, and is moving ahead. The thing that slipped is not the thing arriving soonest. These two get conflated constantly.

None of which changes anything above. The Security Rule you are under today already asks for the risk analysis, the audit controls, and the minimum-necessary discipline. The delay buys you runway, not relief.

---

I work on HIPAA risk analysis tooling at Medcurity, where a longer version of this decision tree lives. Opinions and decision trees are my own.