Course: Course 3 — LLM Fine-Tuning Masterclass Module: FT21 — HIPAA and BAA Elimination Duration: 60 minutes Level: Senior Engineer and above Prerequisites: FT20 — Serving Stacks
After completing this module, you will be able to:
The single cleanest move in the entire HIPAA-LLM space: remove the third party, and the regulatory hook disappears with it.
Under HIPAA, any vendor that processes Protected Health Information (PHI) on a covered entity's behalf is a "business associate" and must sign a Business Associate Agreement (BAA). Run the model on your own on-prem GPUs and no third party processes the PHI — no business associate, no BAA.
Read it twice. The BAA is not a magical compliance certificate that "makes a vendor HIPAA-safe." It is a contractual instrument that flows HIPAA obligations down a chain of vendors. It exists because a third party is touching the data. Eliminate the third party and the instrument has nothing to attach to. This is structurally cleaner than any patched-up API arrangement, and it is the reason Pillar 7 (Sensitive Domains) exists in this course at all.
Once this lands, three things that look like HIPAA mysteries become obvious:
The course thesis is the model steers; the harness bounds. Pillar 7 is where "the harness bounds" becomes load-bearing in the most literal sense: the boundary is not a policy gate, it is a physical boundary — the data does not leave the premises. Local serving is the boundary enforced by topology rather than by contract. Contracts can be breached, mis-scoped, or out-of-date; a cable you never plugged in cannot leak.
This is why FT20 (Serving Stacks) is the prerequisite. You cannot make the local-eliminates-the-BAA move unless you can actually serve a model on your own metal. FT20 gave you vLLM, TGI, Ollama, llama.cpp, the quant formats, the VRAM math. FT21 is the regulatory payoff for that operational capability.
From the weakest posture to the strongest. The local/self-hosted path is the destination.
The taxonomy (drawn from the Definite.app HIPAA-LLM guide and consistent with the broader sensitive-data literature) is four deployment shapes. Read it weakest-to-strongest by data-exposure posture:
WEAKEST POSTURE STRONGEST POSTURE
1. Cloud endpoints 2. Dedicated capacity 3. Self-hosted 4. On-prem GPUs
under BAA (single-tenant) open weights (your metal)
(multi-tenant) (your VPC) (your building)
| | | |
PHI leaves -> PHI leaves -> PHI may stay PHI never leaves
vendor infra vendor infra in your VPC the premises
You call an API (e.g., OpenAI, Anthropic, Google) under a signed BAA with zero-data-retention negotiated for the covered endpoints. PHI leaves your network and lands on the vendor's multi-tenant infrastructure. The BAA and the zero-retention commitment are what make this permissible at all, not what make it safe. The vendor still processes the PHI in plaintext to compute the response — that is unavoidable for inference. The exposure window is the request lifecycle plus whatever retention the endpoint does or does not honor.
Posture: weakest. Required artifacts: signed BAA, endpoint-coverage matrix (Section 21.3), DPIA, audit-log integration. Use only when no other option is feasible.
You rent single-tenant capacity (e.g., Azure OpenAI with a dedicated provisioning, a vendor's dedicated tier, or reserved instances). PHI still leaves your network, but it lands on infrastructure you have more control over — fewer noisy neighbors, clearer tenancy boundaries. The BAA is still required because the vendor is still a business associate processing PHI.
Posture: stronger than Option 1, weaker than local. The data still egresses. The win is reduced multi-tenant risk and clearer isolation, not elimination of the vendor relationship.
You run an open-weights model (Llama, Qwen, Mistral, etc.) inside your own cloud VPC on instances you control. You serve it with vLLM, TGI, or Ollama (FT20). The cloud provider is not processing PHI in the business-associate sense if you have configured the instances correctly (no provider-managed agents with PHI access, encryption at rest/transit, no telemetry egress). This is the crossover point: you own the software stack, and with careful configuration you can argue the provider is merely infrastructure — a "conduit" exception rather than a business associate.
Posture: strong. The model is open weights — auditable, controllable, and yours to serve. The residual risk is the cloud provider's physical access and any provider services that touch the instances.
You run the open-weights model on GPUs you physically own, in a building you control, on a network you operate. PHI never leaves the premises. There is no cloud vendor in the data path. There is no API provider. The only business-associate relationships are the ones you choose to create (e.g., a hardware maintainer who never touches data) — and for the LLM itself, there is no business associate at all.
Posture: strongest. This is the only option that eliminates the BAA requirement for the LLM, rather than managing it. The price is operational: you own the GPUs, the cooling, the failover, the patching. (FT20 covered the serving; FT22 covers the air-gapped extremes.)
The four options are not a menu of equally-valid choices. They are a gradient of exposure. Every step toward the right end of the gradient moves the boundary from contractual (a BAA you hope the vendor honors) to physical (a cable that is not plugged in). Pillar 7's job is to push you as far right as your latency, cost, and capability constraints allow. For genuine PHI workloads — clinical decision support, behavioral health, anything with identifiers — Option 4 is the target architecture, Option 3 is the acceptable compromise, and Options 1–2 are last resorts.
You can get a BAA. You cannot get a BAA that covers everything. This is the real driver for local.
OpenAI offers a BAA for Enterprise/API customers that, combined with zero-data-retention (ZDR), is the most permissive mainstream arrangement: the vendor contractually commits to not retaining inputs/outputs for model training or other purposes, and the BAA flows HIPAA obligations. Anthropic offers a BAA but with a more restrictive posture and narrower documented coverage. Google (Vertex AI / Gemini) offers BAAs with HIPAA-eligible APIs on a per-product basis.
This looks like a clean answer: "sign the BAA, turn on ZDR, ship." It is not. The gaps are in the coverage surface, not the contract.
Per OpenAI's own community discussion and analyses (e.g., Protecto's breakdown of the OpenAI-BAA surface), the ZDR commitment is endpoint-specific, not product-wide. The pattern across vendors:
You can't get a BAA that covers everything.
This is the single most important sentence in the module for practitioners who are tempted to treat "we signed the BAA" as the end of the compliance story. The BAA is a contract; the coverage matrix is an engineering artifact. Even with the best-available BAA, a real clinical application almost always touches at least one uncovered surface — a vision endpoint, a stateful assistant, a batch pipeline, an embeddings call whose eligibility you did not check. The exposure is silent: the request succeeds, the response comes back, and PHI has flowed through a path the BAA does not cover.
This is the real driver for local. It is not that local is cheaper (it often isn't). It is not that local is easier (it is operationally harder). It is that local eliminates the coverage question entirely. There is no endpoint matrix to maintain because there are no endpoints you do not own. There is no ZDR to negotiate because there is no retention happening anywhere you did not configure yourself. The structural cleanliness is worth the operational cost when the data is PHI.
Correcting the most common misconception in the procurement conversation.
There is no such thing as a "HIPAA-certified" LLM. HHS does not certify models, vendors, or software. "HIPAA compliant" is not a property of an artifact — it is a property of a deployment, comprising a chain of contracts (BAAs), technical safeguards, administrative procedures, and audit trails. A model is no more "HIPAA certified" than a database engine or a web server is. What makes a deployment compliant is the system around the model, not the model itself.
For an LLM deployment handling PHI, the real requirements decompose into:
The model — its weights, its training, its capabilities — appears nowhere on this list. The model is a component. Compliance is a property of the system. When a vendor says "our model is HIPAA compliant," they are either being loose with language (they mean "we offer a BAA and our deployment can be configured to meet the Security Rule") or they are misrepresenting the regulatory structure. Either way, the practitioner's job is to look past the marketing claim at the actual deployment.
Even under local, de-identify before fine-tuning. Treat the model as one control, not the only control.
A natural (and dangerous) conclusion from Section 21.1 is: "we're local, so we can train on raw PHI." You can. You almost always shouldn't. Here is why.
When you fine-tune a model on data, the model can memorize that data. This is not the FT00 steering thesis ("fine-tuning steers, it does not teach") in tension — steering is a form of low-rank memorization of behavioral patterns, and when the training examples themselves contain PHI, the model can memorize the identifiers along with the patterns. The result: a model from which PHI can sometimes be extracted by prompting. This is well-documented in the literature on training-data extraction from LLMs. A model that has seen 5,000 clinical notes containing patient names may, under the right adversarial prompt, emit one of those names verbatim.
The exposure scales with repetition and rarity. A name that appears once in training is unlikely to be extracted; a name that appears in fifty notes, or a rare identifier that the model latches onto as a pattern, is more extractable. The risk is not theoretical — it is the single most cited reason regulators and security teams are wary of fine-tuning on PHI.
The correct posture is defense-in-depth: de-identify the fine-tuning data before training, even under local. Treat the model as one control in a stack, not as the only control. The stack:
Defense-in-depth is the principle that no single control is trusted alone. You de-identify because the model might memorize. You audit-log because de-identification might miss something. You run local because the API might leak. Each control compensates for the failure modes of the others. A deployment that relies on only local, or only the BAA, or only de-identification is a deployment with a single point of failure. HIPAA's own structure encodes this — the Security Rule lists administrative, physical, and technical safeguards as categories, not as alternatives.
The four ways teams get this wrong, in order of how often I see them.
"We signed the BAA with the vendor, so we're fine to send PHI through any endpoint." This is the most common and the most dangerous. The BAA covers the vendor relationship; it does not cover every surface. The image endpoint, the stateful assistant, the batch pipeline, the embeddings call — each must be checked against the coverage matrix. Teams that skip this check silently route PHI through uncovered paths and discover the gap only during an audit or a breach.
"We're local, so we can train on the raw notes." You can. The model may memorize identifiers, and they may be extractable. The local boundary protects against egress; it does not protect against memorization-then-extraction-by-an-insider. De-identify first, always. The local posture is the outermost defense; it is not a license to drop the inner ones.
"The model is local; we don't need to log every call." You do. The HIPAA Security Rule requires audit controls. An LLM serving a clinical workflow is processing ePHI on every call; every call must be logged (who, when, what prompt, what response, what model version). The audit trail is your detection and your forensics layer. A local deployment with no logging is less auditable than a logged API deployment — and auditability is a HIPAA requirement, not a nice-to-have.
"We're on-prem, so we're compliant." Local eliminates the BAA problem; it does not eliminate the Security Rule. You still need encryption at rest (the model weights, the logs, the prompt cache), encryption in transit (TLS to the serving endpoint), access controls (who can call the model, who can read the logs), a risk analysis, workforce training, incident response. A local deployment that skips these is non-compliant and exposed — the worst of both worlds. Local is the strongest data-exposure posture, but it is not a substitute for the safeguards; it is the foundation they sit on.
| Term | Definition |
|---|---|
| PHI | Protected Health Information — individually identifiable health information held or transmitted by a covered entity or business associate |
| Covered entity | A health plan, health care clearinghouse, or health care provider who transmits health information electronically — the entity with the primary HIPAA obligation |
| Business associate | A vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity — must sign a BAA |
| BAA (Business Associate Agreement) | The contract that flows HIPAA obligations from a covered entity to a business associate and onward to subcontractors |
| Zero-data-retention (ZDR) | A vendor commitment (where offered) to not retain customer inputs/outputs for training or other purposes — coverage is endpoint-specific |
| De-identification | The process of removing PHI from data so it is no longer individually identifiable — via Safe Harbor (18 identifiers) or Expert Determination |
| Defense-in-depth | The principle that no single control is trusted alone — de-identification, audit logging, local serving, access controls each compensate for the others' failure modes |
| DP-SGD | Differentially Private Stochastic Gradient Descent — bounds the model's memorization of any single training example; costly but appropriate for high-sensitivity data |
| Memorization (in LLMs) | The tendency of a fine-tuned model to store training examples verbatim, making them potentially extractable by prompting — the core fine-tuning data risk |
| Open-weights model | A model whose weights are publicly available for download and local serving (Llama, Qwen, Mistral) — the substrate that makes the local path possible |
| Anti-pattern | Why it fails |
|---|---|
| Assuming the API BAA covers everything | BAA covers the vendor relationship, not every surface. Image endpoints, stateful assistants, batch/embeddings are often uncovered. |
| Fine-tuning on raw PHI without de-identification | The model can memorize identifiers, which are then extractable. Local protects against egress, not against memorization-by-insider. |
| No audit logging | The Security Rule requires audit controls. A local deployment with no logging is non-compliant and un-forensicable. |
| Treating "local" as sufficient | Local eliminates the BAA problem; it does not eliminate the Security Rule. Encryption, access controls, risk analysis still required. |
See 07-lab-spec.md. "The HIPAA Architecture" — design (diagram + written defense) the architecture for a clinical-decision-support LLM that handles PHI. Choose local-only or API-under-BAA. Specify the serving stack, the de-identification pipeline, and the audit-logging approach. No GPU required — this is an architecture and judgment lab.
# Module FT21 — HIPAA and BAA Elimination
**Course**: Course 3 — LLM Fine-Tuning Masterclass
**Module**: FT21 — HIPAA and BAA Elimination
**Duration**: 60 minutes
**Level**: Senior Engineer and above
**Prerequisites**: FT20 — Serving Stacks
---
## Learning Objectives
After completing this module, you will be able to:
1. State the core HIPAA logic for LLMs — *any third party that processes PHI on a covered entity's behalf is a "business associate" and must sign a BAA* — and explain why running an open-weights model on your own on-prem GPUs eliminates the business-associate relationship entirely (no third party, no BAA).
2. Distinguish the four ways to run an LLM on PHI (cloud endpoints under BAA, dedicated capacity, self-hosted open weights, on-prem GPUs) and rank them by data-exposure posture, naming the local/self-hosted path as the strongest.
3. Describe the gaps in the API-BAA alternative — *coverage is endpoint-specific, image inputs are typically excluded from zero-retention, Assistants/Threads coverage is unclear, no BAA covers everything* — and explain why this gap is the real driver for local.
4. Correct the misconception that some LLM is "HIPAA certified" (that designation does not exist) and enumerate what is actually required: an unbroken BAA chain *or* its elimination via local, plus audit trails and technical safeguards (encryption at rest/transit, access controls).
5. Apply de-identification as defense-in-depth even under local — de-identify fine-tuning data before training (Tonic Textual, Presidio, custom) — and explain why fine-tuning on raw PHI risks memorization (extractable PHI in the weights).
6. Design, for a clinical-decision-support LLM, the architecture (local vs API-under-BAA), the serving stack, the de-identification pipeline, and the audit-logging approach — and defend the choice.
---
# 21.1 — The Core Logic: Why Local Eliminates the BAA Problem
*The single cleanest move in the entire HIPAA-LLM space: remove the third party, and the regulatory hook disappears with it.*
## The sentence
> **Under HIPAA, any vendor that processes Protected Health Information (PHI) on a covered entity's behalf is a "business associate" and must sign a Business Associate Agreement (BAA). Run the model on your own on-prem GPUs and no third party processes the PHI — no business associate, no BAA.**
Read it twice. The BAA is not a magical compliance certificate that "makes a vendor HIPAA-safe." It is a *contractual instrument* that flows HIPAA obligations down a chain of vendors. It exists because a third party is touching the data. Eliminate the third party and the instrument has nothing to attach to. This is structurally cleaner than any patched-up API arrangement, and it is the reason Pillar 7 (Sensitive Domains) exists in this course at all.
### Why this matters immediately
Once this lands, three things that look like HIPAA mysteries become obvious:
1. **Why a signed BAA is necessary but not sufficient.** A BAA obligates the vendor to safeguard PHI and to flow the same obligations to *its* subcontractors. It does *not* guarantee the vendor's product surfaces all honor zero-retention. You still have to audit which endpoints are covered (Section 21.3). The BAA is the floor, not the ceiling.
2. **Why "local" is a stronger posture than "API under BAA," not just a cheaper one.** Local eliminates the vendor relationship at the structural level — there is no data egress to litigate, no subcontractor chain to map, no endpoint-coverage matrix to maintain. The risk surface is *your* network, *your* GPUs, *your* access controls — things you directly own.
3. **Why the BAA chain must be unbroken end to end.** A single un-BAA'd subprocessor in the chain is a breach waiting to happen. The covered entity remains liable. This is the structural cost of the API path: every link in the chain is a liability surface.
## The defining move of Pillar 7
The course thesis is *the model steers; the harness bounds.* Pillar 7 is where "the harness bounds" becomes load-bearing in the most literal sense: the boundary is not a policy gate, it is a *physical* boundary — the data does not leave the premises. Local serving is the boundary enforced by topology rather than by contract. Contracts can be breached, mis-scoped, or out-of-date; a cable you never plugged in cannot leak.
This is why FT20 (Serving Stacks) is the prerequisite. You cannot make the local-eliminates-the-BAA move unless you can actually serve a model on your own metal. FT20 gave you vLLM, TGI, Ollama, llama.cpp, the quant formats, the VRAM math. FT21 is the *regulatory payoff* for that operational capability.
---
# 21.2 — The Four Ways to Run an LLM on PHI
*From the weakest posture to the strongest. The local/self-hosted path is the destination.*
The taxonomy (drawn from the Definite.app HIPAA-LLM guide and consistent with the broader sensitive-data literature) is four deployment shapes. Read it weakest-to-strongest by data-exposure posture:
```
WEAKEST POSTURE STRONGEST POSTURE
1. Cloud endpoints 2. Dedicated capacity 3. Self-hosted 4. On-prem GPUs
under BAA (single-tenant) open weights (your metal)
(multi-tenant) (your VPC) (your building)
| | | |
PHI leaves -> PHI leaves -> PHI may stay PHI never leaves
vendor infra vendor infra in your VPC the premises
```
## Option 1 — Cloud endpoints under BAA (multi-tenant)
You call an API (e.g., OpenAI, Anthropic, Google) under a signed BAA with zero-data-retention negotiated for the covered endpoints. PHI leaves your network and lands on the vendor's multi-tenant infrastructure. The BAA and the zero-retention commitment are what make this permissible *at all*, not what make it safe. The vendor still processes the PHI in plaintext to compute the response — that is unavoidable for inference. The exposure window is the request lifecycle plus whatever retention the endpoint does or does not honor.
**Posture**: weakest. Required artifacts: signed BAA, endpoint-coverage matrix (Section 21.3), DPIA, audit-log integration. Use only when no other option is feasible.
## Option 2 — Dedicated capacity (single-tenant)
You rent single-tenant capacity (e.g., Azure OpenAI with a dedicated provisioning, a vendor's dedicated tier, or reserved instances). PHI still leaves your network, but it lands on infrastructure you have more control over — fewer noisy neighbors, clearer tenancy boundaries. The BAA is still required because the vendor is still a business associate processing PHI.
**Posture**: stronger than Option 1, weaker than local. The data still egresses. The win is reduced multi-tenant risk and clearer isolation, not elimination of the vendor relationship.
## Option 3 — Self-hosted open weights (your VPC)
You run an open-weights model (Llama, Qwen, Mistral, etc.) inside your own cloud VPC on instances you control. You serve it with vLLM, TGI, or Ollama (FT20). The cloud provider is *not* processing PHI in the business-associate sense if you have configured the instances correctly (no provider-managed agents with PHI access, encryption at rest/transit, no telemetry egress). This is the crossover point: you own the software stack, and with careful configuration you can argue the provider is merely infrastructure — a "conduit" exception rather than a business associate.
**Posture**: strong. The model is open weights — auditable, controllable, and yours to serve. The residual risk is the cloud provider's physical access and any provider services that touch the instances.
## Option 4 — On-prem GPUs (your metal)
You run the open-weights model on GPUs you physically own, in a building you control, on a network you operate. PHI never leaves the premises. There is no cloud vendor in the data path. There is no API provider. The only business-associate relationships are the ones you choose to create (e.g., a hardware maintainer who never touches data) — and for the LLM itself, *there is no business associate at all*.
**Posture**: strongest. This is the only option that *eliminates* the BAA requirement for the LLM, rather than managing it. The price is operational: you own the GPUs, the cooling, the failover, the patching. (FT20 covered the serving; FT22 covers the air-gapped extremes.)
### The teaching point
The four options are not a menu of equally-valid choices. They are a *gradient of exposure*. Every step toward the right end of the gradient moves the boundary from *contractual* (a BAA you hope the vendor honors) to *physical* (a cable that is not plugged in). Pillar 7's job is to push you as far right as your latency, cost, and capability constraints allow. For genuine PHI workloads — clinical decision support, behavioral health, anything with identifiers — Option 4 is the target architecture, Option 3 is the acceptable compromise, and Options 1–2 are last resorts.
---
# 21.3 — The API Alternative and Its Gaps
*You can get a BAA. You cannot get a BAA that covers everything. This is the real driver for local.*
## What the API vendors offer
OpenAI offers a BAA for Enterprise/API customers that, combined with zero-data-retention (ZDR), is the most permissive mainstream arrangement: the vendor contractually commits to not retaining inputs/outputs for model training or other purposes, and the BAA flows HIPAA obligations. Anthropic offers a BAA but with a more restrictive posture and narrower documented coverage. Google (Vertex AI / Gemini) offers BAAs with HIPAA-eligible APIs on a per-product basis.
This looks like a clean answer: "sign the BAA, turn on ZDR, ship." It is not. The gaps are in the *coverage surface*, not the contract.
## The coverage gaps
Per OpenAI's own community discussion and analyses (e.g., Protecto's breakdown of the OpenAI-BAA surface), the ZDR commitment is **endpoint-specific**, not product-wide. The pattern across vendors:
- **Zero-retention is honored on some endpoints and not others.** A covered chat-completions endpoint does not mean a covered batch endpoint, a covered fine-tuning endpoint, or a covered embeddings endpoint. You must read the per-endpoint eligibility table and map every endpoint your application actually calls.
- **Image and multimodal inputs are frequently excluded from ZDR.** The text-in/text-out path may be covered; the image-in path may not be. A clinical workflow that sends a wound photo or a radiology snippet through the vision endpoint can be routing PHI through an uncovered surface *even with a signed BAA*.
- **Stateful products (Assistants, Threads, file storage) have unclear or narrower coverage.** These products retain data by design — that is how they maintain state. ZDR is structurally in tension with a stateful product. Coverage claims must be read carefully and are often subject to change.
- **Subprocessors can sit outside the BAA chain.** The model you call may be served by infrastructure whose subprocessor relationships are not all flowed-down via BAA. A single un-BAA'd link is a breach surface.
## The teaching point
> **You can't get a BAA that covers everything.**
This is the single most important sentence in the module for practitioners who are tempted to treat "we signed the BAA" as the end of the compliance story. The BAA is a contract; the coverage matrix is an engineering artifact. Even with the best-available BAA, a real clinical application almost always touches at least one uncovered surface — a vision endpoint, a stateful assistant, a batch pipeline, an embeddings call whose eligibility you did not check. The exposure is silent: the request succeeds, the response comes back, and PHI has flowed through a path the BAA does not cover.
*This* is the real driver for local. It is not that local is cheaper (it often isn't). It is not that local is easier (it is operationally harder). It is that **local eliminates the coverage question entirely**. There is no endpoint matrix to maintain because there are no endpoints you do not own. There is no ZDR to negotiate because there is no retention happening anywhere you did not configure yourself. The structural cleanliness is worth the operational cost when the data is PHI.
---
# 21.4 — No Model Is "HIPAA Certified"
*Correcting the most common misconception in the procurement conversation.*
There is no such thing as a "HIPAA-certified" LLM. HHS does not certify models, vendors, or software. "HIPAA compliant" is not a property of an artifact — it is a property of a *deployment*, comprising a chain of contracts (BAAs), technical safeguards, administrative procedures, and audit trails. A model is no more "HIPAA certified" than a database engine or a web server is. What makes a deployment compliant is the *system around the model*, not the model itself.
## What is actually required
For an LLM deployment handling PHI, the real requirements decompose into:
1. **An unbroken BAA chain** (if any third party processes PHI) — or the *elimination* of that chain via local serving (Section 21.1). One or the other. There is no third option.
2. **Technical safeguards** — encryption at rest (disk-level), encryption in transit (TLS), access controls (RBAC, least privilege, MFA), audit logging of every PHI touch.
3. **Audit trails** — every prompt, every response, every model invocation, every access, logged and retained per the organization's HIPAA security rule posture. This is non-negotiable and is the single most common gap in LLM deployments.
4. **Administrative and physical safeguards** — workforce training, incident response, risk analysis, facility controls (for on-prem). These are the standard HIPAA Security Rule categories; they do not change because the workload is an LLM.
5. **A risk analysis** — the documented, periodically-refreshed assessment that identifies threats to ePHI and the controls in place. The risk analysis is where you record *why* you chose local vs API-under-BAA, and *what* the residual risks are.
The model — its weights, its training, its capabilities — appears nowhere on this list. The model is a component. Compliance is a property of the system. When a vendor says "our model is HIPAA compliant," they are either being loose with language (they mean "we offer a BAA and our deployment can be configured to meet the Security Rule") or they are misrepresenting the regulatory structure. Either way, the practitioner's job is to look past the marketing claim at the actual deployment.
---
# 21.5 — De-Identification as Defense-in-Depth
*Even under local, de-identify before fine-tuning. Treat the model as one control, not the only control.*
A natural (and dangerous) conclusion from Section 21.1 is: "we're local, so we can train on raw PHI." You *can*. You almost always *shouldn't*. Here is why.
## The fine-tuning data risk
When you fine-tune a model on data, the model can **memorize** that data. This is not the FT00 steering thesis ("fine-tuning steers, it does not teach") in tension — steering *is* a form of low-rank memorization of behavioral patterns, and when the training examples themselves contain PHI, the model can memorize the identifiers along with the patterns. The result: a model from which PHI can sometimes be *extracted* by prompting. This is well-documented in the literature on training-data extraction from LLMs. A model that has seen 5,000 clinical notes containing patient names may, under the right adversarial prompt, emit one of those names verbatim.
The exposure scales with repetition and rarity. A name that appears once in training is unlikely to be extracted; a name that appears in fifty notes, or a rare identifier that the model latches onto as a pattern, is more extractable. The risk is not theoretical — it is the single most cited reason regulators and security teams are wary of fine-tuning on PHI.
## The defense-in-depth posture
The correct posture is defense-in-depth: **de-identify the fine-tuning data *before* training, even under local.** Treat the model as one control in a stack, not as the only control. The stack:
- **De-identify before training.** Run the fine-tuning corpus through a de-identification pipeline that removes or replaces PHI: direct identifiers (names, MRNs, dates, contact info), quasi-identifiers (rare ZIP codes, rare professions, age over 89), and free-text PHI embedded in clinical narrative. Tools: Microsoft Presidio (open source, rule + ML), Tonic Textual (commercial, LLM-aware), custom pipelines built on spaCy + regex + a medical NER model. The output is a corpus that is "PHI-scarce" — de-identified per the HIPAA Safe Harbor or Expert Determination method.
- **Train on the de-identified corpus.** The model learns the *behavior* you want (clinical reasoning patterns, output formatting, differential structure) from the de-identified examples. The behavior transfers; the identifiers do not.
- **Evaluate for memorization.** Before deploy, probe the model for extractable training data — canary insertion, membership inference, extraction attacks on known-rare strings. If the model leaks, you either de-identified insufficiently or you need differential-privacy techniques.
- **Apply differential privacy where the risk justifies it.** DP-SGD (differentially private stochastic gradient descent) bounds the model's memorization of any single example. It is costly (slower training, some quality loss) and is the right call when the training data is high-sensitivity even after de-identification (e.g., behavioral health, substance use, HIV status).
- **Serve under audit.** Even with a de-identified-trained model, log every prompt and response. The audit trail is your detection layer; de-identification is your prevention layer; the model itself is neither.
### Why this is not paranoid
Defense-in-depth is the principle that no single control is trusted alone. You de-identify *because the model might memorize*. You audit-log *because de-identification might miss something*. You run local *because the API might leak*. Each control compensates for the failure modes of the others. A deployment that relies on *only* local, or *only* the BAA, or *only* de-identification is a deployment with a single point of failure. HIPAA's own structure encodes this — the Security Rule lists administrative, physical, and technical safeguards as *categories*, not as alternatives.
---
# 21.6 — Anti-Patterns
*The four ways teams get this wrong, in order of how often I see them.*
### Assuming the API BAA covers everything
"We signed the BAA with the vendor, so we're fine to send PHI through any endpoint." This is the most common and the most dangerous. The BAA covers the *vendor relationship*; it does not cover every *surface*. The image endpoint, the stateful assistant, the batch pipeline, the embeddings call — each must be checked against the coverage matrix. Teams that skip this check silently route PHI through uncovered paths and discover the gap only during an audit or a breach.
### Fine-tuning on raw PHI without de-identification
"We're local, so we can train on the raw notes." You can. The model may memorize identifiers, and they may be extractable. The local boundary protects against *egress*; it does not protect against *memorization-then-extraction-by-an-insider*. De-identify first, always. The local posture is the *outermost* defense; it is not a license to drop the inner ones.
### No audit logging
"The model is local; we don't need to log every call." You do. The HIPAA Security Rule requires audit controls. An LLM serving a clinical workflow is processing ePHI on every call; every call must be logged (who, when, what prompt, what response, what model version). The audit trail is your detection and your forensics layer. A local deployment with no logging is *less* auditable than a logged API deployment — and auditability is a HIPAA requirement, not a nice-to-have.
### Treating "local" as sufficient without the technical safeguards
"We're on-prem, so we're compliant." Local eliminates the BAA problem; it does not eliminate the Security Rule. You still need encryption at rest (the model weights, the logs, the prompt cache), encryption in transit (TLS to the serving endpoint), access controls (who can call the model, who can read the logs), a risk analysis, workforce training, incident response. A local deployment that skips these is non-compliant *and* exposed — the worst of both worlds. Local is the strongest *data-exposure* posture, but it is not a substitute for the safeguards; it is the foundation they sit on.
---
## Key Terms
| Term | Definition |
| --- | --- |
| **PHI** | Protected Health Information — individually identifiable health information held or transmitted by a covered entity or business associate |
| **Covered entity** | A health plan, health care clearinghouse, or health care provider who transmits health information electronically — the entity with the primary HIPAA obligation |
| **Business associate** | A vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity — must sign a BAA |
| **BAA (Business Associate Agreement)** | The contract that flows HIPAA obligations from a covered entity to a business associate and onward to subcontractors |
| **Zero-data-retention (ZDR)** | A vendor commitment (where offered) to not retain customer inputs/outputs for training or other purposes — coverage is endpoint-specific |
| **De-identification** | The process of removing PHI from data so it is no longer individually identifiable — via Safe Harbor (18 identifiers) or Expert Determination |
| **Defense-in-depth** | The principle that no single control is trusted alone — de-identification, audit logging, local serving, access controls each compensate for the others' failure modes |
| **DP-SGD** | Differentially Private Stochastic Gradient Descent — bounds the model's memorization of any single training example; costly but appropriate for high-sensitivity data |
| **Memorization (in LLMs)** | The tendency of a fine-tuned model to store training examples verbatim, making them potentially extractable by prompting — the core fine-tuning data risk |
| **Open-weights model** | A model whose weights are publicly available for download and local serving (Llama, Qwen, Mistral) — the substrate that makes the local path possible |
---
## Anti-Patterns (recap)
| Anti-pattern | Why it fails |
| --- | --- |
| **Assuming the API BAA covers everything** | BAA covers the vendor relationship, not every surface. Image endpoints, stateful assistants, batch/embeddings are often uncovered. |
| **Fine-tuning on raw PHI without de-identification** | The model can memorize identifiers, which are then extractable. Local protects against egress, not against memorization-by-insider. |
| **No audit logging** | The Security Rule requires audit controls. A local deployment with no logging is non-compliant and un-forensicable. |
| **Treating "local" as sufficient** | Local eliminates the BAA problem; it does not eliminate the Security Rule. Encryption, access controls, risk analysis still required. |
---
## Lab Exercise
See `07-lab-spec.md`. "The HIPAA Architecture" — design (diagram + written defense) the architecture for a clinical-decision-support LLM that handles PHI. Choose local-only or API-under-BAA. Specify the serving stack, the de-identification pipeline, and the audit-logging approach. No GPU required — this is an architecture and judgment lab.
---
## References
1. **Definite.app** — *HIPAA and LLMs: The Four Ways to Run a Model on PHI*. The taxonomy of deployment shapes (cloud endpoints under BAA, dedicated capacity, self-hosted open weights, on-prem GPUs) and the posture ranking that anchors this module.
2. **Protecto** — *OpenAI BAA and Zero-Retention: What's Actually Covered*. The endpoint-specific coverage analysis showing image inputs, Assistants/Threads, and other surfaces sit outside ZDR even under a signed BAA.
3. **Tonic.ai** — *The Sensitive-Data Playbook for LLM Training*. The case for de-identification as defense-in-depth before fine-tuning, the Safe Harbor vs Expert Determination methods, and the memorization risk.
4. **Microsoft Presidio** — *Open-source PII/PHI detection and de-identification*. The reference open-source pipeline for de-identifying free text before it reaches a model.
5. **PMC (PubMed Central) sensitive-data framework** — *A Framework for De-identifying Clinical Narratives for Machine Learning*. The peer-reviewed treatment of quasi-identifiers, rare-string risk, and the limits of rule-based de-identification.
6. **HHS.gov** — *HIPAA for Professionals; the Security Rule; Business Associate Contracts*. The primary-source regulatory grounding — the definition of business associate, the BAA requirement, the Security Rule safeguard categories.
7. **Carlini et al.** — *Extracting Training Data from Large Language Models*. The foundational evidence that fine-tuned models memorize and that memorized data is extractable — the technical basis for the fine-tuning data risk.
8. **Module FT20 — Serving Stacks**. The prerequisite: vLLM, TGI, Ollama, llama.cpp, the quant formats, the VRAM math that makes the local path operational.
9. **Module FT22 — Government, Military, and Air-Gapped Deployment**. The next module: takes the local posture to its extreme — no network at all.