HIPAA and BAA Elimination
Module FT21 · Course 3 — LLM Fine-Tuning Masterclass
60 minutes · The boundary becomes physical: data does not leave the premises.
Prerequisite: FT20 — Serving Stacks. This module is the regulatory payoff for the operational capability.
Pillar 7 — Sensitive Domains · Layer 5 (Boundary)
The core logic — one sentence
Any vendor that processes PHI on a covered entity's behalf is a business associate and must sign a BAA.
Run the model on your own on-prem GPUs and no third party processes the PHI — no business associate, no BAA.
The BAA is not a magic compliance certificate. It is a contractual instrument that flows HIPAA obligations down a vendor chain.
It exists because a third party touches the data. Eliminate the third party and the instrument has nothing to attach to.
Structurally cleaner than any patched-up API arrangement.
A BAA is necessary but not sufficient
Necessary
Flows HIPAA obligations to the vendor and subcontractors. Without it, the vendor cannot lawfully process PHI.
Not sufficient
Does not guarantee every product surface honors zero-data-retention. The BAA is the floor, not the ceiling.
The teaching point: you can get a BAA. You cannot get a BAA that covers everything. Coverage is endpoint-specific, not product-wide. A real clinical workflow almost always touches at least one uncovered surface.
This — not cost, not ease — is the real driver for local.
The four ways to run an LLM on PHI
Ranked weakest to strongest by data-exposure posture.
1. Cloud endpoints under BAA (multi-tenant) · PHI leaves → vendor infra · BAA required
2. Dedicated capacity (single-tenant) · PHI leaves → single-tenant · BAA required
3. Self-hosted open weights (your VPC) · PHI may stay in tenancy · BAA often avoidable
4. On-prem GPUs (your metal) · PHI never leaves the building · NO BAA for the LLM
Every step rightward moves the boundary from contractual (a BAA) to physical (a cable not plugged in).
The API-BAA coverage gaps
You signed the BAA + zero-data-retention. Now check the surface:
| Surface | Coverage under ZDR |
|---|
| Chat completions (text) | Typically covered |
| Image / vision inputs | Frequently EXCLUDED |
| Assistants / Threads (stateful) | Unclear / narrower |
| Batch / embeddings / fine-tuning | Check per endpoint |
| Subprocessors | Flow-down not always complete |
The exposure is silent. The request succeeds. The response comes back. PHI has flowed through a path the BAA does not cover. You discover the gap during an audit — or a breach.
No model is "HIPAA certified"
HHS does not certify models, vendors, or software. "HIPAA compliant" is a property of a deployment, not a model.
What is actually required for an LLM handling PHI:
- An unbroken BAA chain — or its elimination via local. One or the other.
- Technical safeguards — encryption at rest/transit, access controls
- Audit trails — every prompt, response, access, logged + retained
- Administrative + physical safeguards — training, IR, risk analysis, facility controls
- A documented, refreshed risk analysis
The model appears on none of these. It is a component. Compliance is the system around it.
De-identification as defense-in-depth
Even under local — de-identify before fine-tuning.
The fine-tuning data risk: a model trained on raw PHI can memorize identifiers — and they become extractable by prompting. (Carlini et al.) Local protects against egress, not against memorization-by-insider.
The defense-in-depth stack:
- De-identify the corpus (Presidio / Tonic / custom)
- Train on PHI-scarce data — behavior transfers, identifiers do not
- Evaluate for memorization (canary, extraction attacks)
- DP-SGD for high-sensitivity subsets
- Serve under audit + access controls
No single control trusted alone. HIPAA's structure encodes this — safeguards are categories, not alternatives.
The local architecture — data stays on-prem
The trust boundary: everything that touches PHI lives inside your building, your network.
CLINICIAN UI · RBAC, MFA
↕ TLS (encryption in transit)
SERVING (vLLM / TGI / Ollama — from FT20) · open-weights model
↑ trained on
DE-IDENTIFIED FINE-TUNING CORPUS · PHI-scarce
↑ produced by
DE-IDENTIFICATION PIPELINE · Presidio / Tonic
↑ fed by
CLINICAL DATA SOURCES · EHR, notes, imaging metadata
Crosses the boundary outbound: the one-time model download (no PHI), and optionally the audit log → SIEM (under BAA). No PHI egress.
Anti-patterns — the four failures
1. Assuming the API BAA covers everything. It covers the vendor relationship, not every surface. Image endpoints, stateful assistants, batch pipelines — each must be checked against the coverage matrix.
2. Fine-tuning on raw PHI without de-identification. The model can memorize identifiers. Local protects against egress, not against memorization-then-extraction-by-insider.
3. No audit logging. The Security Rule requires audit controls. A local deployment with no logging is non-compliant AND un-forensicable.
4. Treating "local" as sufficient. Local eliminates the BAA problem, not the Security Rule. Encryption, access controls, risk analysis still required.
The bridge to FT22 and FT23
FT22 — next module
Government, Military, and Air-Gapped Deployment.
FT21 is "the data stays in the building." FT22 is "the building has no door."
FT23 — the synthesis
The steered model inside the bounded harness.
Everything in the course comes together: a model steered toward your intent, deployed inside a harness that bounds what it may do, on infrastructure that keeps the data where you put it.
The thesis, restated: the model steers; the harness bounds. In Pillar 7, the harness bounds physically. That is the strongest form of boundary there is.
What you can now do
- State the core HIPAA logic and explain why local eliminates the business-associate relationship.
- Rank the four deployment options by exposure posture; name local as the target.
- Describe the API-BAA coverage gaps — and why they are the real driver for local.
- Correct the "HIPAA certified" misconception; enumerate what is actually required.
- Apply de-identification as defense-in-depth, even under local.
- Design the architecture for a clinical-decision-support LLM — and defend the choice.
The lab: a design lab, not a build lab. Architecture diagram + written defense. No GPU required. The judgment is the deliverable.
Next: FT22 — Government, Military, and Air-Gapped Deployment