Choosing the Right LLM De-Identification Strategy: Redaction, Pseudonymization, or Tokenization?

Pick reversible tokenization when the model's output has to go back into a patient record. Pick redaction when it doesn't. Pseudonymization sits in the middle and is the one people over-use. Redaction is cheapest and safest but destroys the co-reference the model needs; tokenization preserves it at the cost of running a vault. The deciding question is not "how sensitive is this data" — it's "does anything downstream need the real value back?"

HIPAA's Safe Harbor route requires stripping 18 specific identifiers, and a single discharge summary can carry most of them in free text. That's the number that should drive your architecture, because a detector that catches 17 of 18 is not 94% done — it's a breach waiting for a name in an unexpected field.

Key takeaways

• Redaction is irreversible by design and belongs in logging, triage, and evaluation sets — not in summarization.
• Pseudonymized data is still personal data under GDPR Recital 26. It reduces risk; it does not remove you from scope.
• Reversible tokenization is the only strategy that survives a clinical drafting loop, because the model needs stable placeholders and you need the mapping back.
• The mapping vault is the real attack surface. If it lives in the same system as the prompt logs, you've built a redaction system with extra steps.
• BAA coverage is route-specific. On our own platform it applies to the Azure routes only — not to every model behind the gateway.

What are the main LLM de-identification strategies?

Three families cover almost everything: redaction (destroy the span), pseudonymization (replace with a consistent fake), and tokenization or reversible masking (replace with a placeholder plus a stored map). They differ on one axis that matters more than any privacy score: whether the transformation can be undone, and by whom. Skyflow's breakdown of common data de-identification techniques covers the same three families if you want a second opinion on the taxonomy.

The mistake I see most often is teams picking pseudonymization because it sounds like the balanced choice. It isn't balanced — it's redaction with better prose. If you throw the surrogate map away, you've lost the ability to re-identify, which means you've lost the ability to act on the model's output.

Redaction: simple, safe, but limiting — when should you use it?

Use redaction when nothing downstream needs the original value back. It is the only strategy with no re-identification path, which makes it the easiest to defend in a review, and the easiest to over-apply. The failure mode is co-reference: strip every name from a note and ask for a summary, and the model can no longer tell you which medication belongs to which patient.

Redaction is genuinely correct for:

• Request and response logging. If you log prompts at all, log the redacted form.
• Evaluation sets. You want your regression suite to be shareable.
• Routing and classification. "Is this a billing question or a clinical one?" needs no names.
• Anything leaving your trust boundary that you'll never need to join back.

Where it breaks is any task where the answer has to be written back into a system of record. A redacted summary is a document with holes in it. Someone has to fill them, and that someone is a clinician doing work the model was supposed to save them.

Pseudonymization: balancing utility and privacy with realistic fakes

Pseudonymization replaces each detected entity with a consistent surrogate — the same patient becomes the same fake name across a document — so the model can still reason about co-reference. That consistency is the whole point, and it's also the trap: consistent surrogates are linkable, and linkable data is still personal data under GDPR.

Two implementation notes from doing this repeatedly:

• Generate surrogates deterministically per session, not per document. If the same patient appears in two documents in one workflow, they need the same fake name or the model will treat them as two people.
• Match the surrogate's shape to the original. A five-character name in a field that expects a long one produces formatting artifacts the model will comment on. Realistic fakes aren't vanity; they keep the output clean.

Under GDPR, Article 4(5) defines pseudonymization as processing that makes data non-attributable without additional information — and Recital 26 is explicit that pseudonymized data remains personal data. So pseudonymization lowers your risk profile and gives you a defensible posture, but it does not take you out of scope. If your compliance lead is treating it as anonymization, correct that before it reaches a DPA. This is posture, not legal advice — ask your counsel.

Reversible pseudonymization and tokenization: the veil-then-reveal approach

Reversible masking swaps each entity for a placeholder, sends the placeholder to the model, and stores an encrypted map so the real value can be restored on the response. This is the only strategy that supports a full clinical loop: the model drafts, you re-identify, the clinician edits, and the record stays coherent. We wrote the mechanics up in detail in reversible PHI masking for LLMs.

The design rules that matter:

1. Scope the map to the request. A per-request map that dies with the response is a much smaller liability than a session-long vault. Where you need session consistency, expire it aggressively.
2. Encrypt the map with a key the model path never sees. If the gateway that holds the map is the same process that holds the prompt logs, you've collapsed two trust boundaries into one.
3. Never let the model see the map, and never let it echo placeholders into output you don't re-identify. A leaked placeholder list is a partial disclosure of what was in the document.
4. Log the re-identification event, not the value. You want an audit trail of who unmasked what and when — see audit trails for LLM API calls.

The cost is real: you now run a stateful component on the hot path, and its availability is your availability.

How do you implement reversible masking? (curl examples)

The mechanism is four headers and a payload that already contains placeholders. The gateway detects or accepts pre-masked spans, routes the request to a region that satisfies your residency rule, and returns a response plus a re-identification handle. Here's the shape we use — treat it as the shape, not a spec, because your gateway's header names will differ.

curl https://cloudsitus.com/api/v1/chat/completions \
 -H "Authorization: Bearer $PHI_API_KEY" \
 -H "Content-Type: application/json" \
 -H "X-PHI-Gate: enforce" \
 -H "X-PHI-Route: azure-eu" \
 -H "X-Residency: eu-central" \
 -H "X-Audit-Trace: 01J8Z..." \
 -d '{
 "model": "gpt-4o-mini",
 "messages": [
 {"role": "user",
 "content": "Summarize the discharge note for [PATIENT_7f3a] seen on [DATE_1]."}
 ],
 "masking": {"mode": "reversible", "map_scope": "request"}
 }'

The response comes back with placeholders intact and a handle you exchange for the mapping:

curl https://cloudsitus.com/api/v1/masking/resolve \
 -H "Authorization: Bearer $PHI_API_KEY" \
 -H "X-Audit-Trace: 01J8Z..." \
 -d '{"handle": "mk_9c1f...", "text": "The patient [PATIENT_7f3a] was discharged..."}'

Two things to check in your own stack before you copy this pattern. First, does the resolve call require a separate credential from the inference call? It should — that's the boundary that stops a compromised model path from unmasking. Second, is the resolve call logged with the caller's identity but not the resolved text? If it logs the text, your vault is now in your log store. Per-request PHI gates covers how we enforce that split.

HIPAA de-identification standards for LLMs: Safe Harbor vs Expert Determination

HIPAA gives you two routes. Safe Harbor requires removing 18 enumerated identifiers, including dates, geographic subdivisions smaller than a state, and any other unique identifying number. Expert Determination requires a person with appropriate statistical and scientific knowledge to determine that re-identification risk is very small. Safe Harbor is a checklist; Expert Determination is a judgement call with a named human behind it.

For LLM workloads, the honest read:

• Safe Harbor is brittle against free text. Your detector has to catch identifiers in prose, in scanned-note OCR, and in fields nobody labelled. Miss one and you haven't de-identified anything.
• Expert Determination is where most clinical LLM work actually lands, because it tolerates a documented residual risk instead of demanding zero. It also requires you to re-run the analysis when your data or your model changes.
• Neither route is a certification. A BAA covers the vendor relationship; it does not make your pipeline de-identified. And BAA coverage is route-specific — on our platform it applies to the Azure routes, not to every model behind the gateway.

If you want the peer-reviewed version of this argument, a 2025 npj Digital Medicine paper on de-identification in clinical AI pipelines and NEJM AI's treatment of the same problem are the two I'd start with.

GDPR anonymization for LLMs: is pseudonymized data still personal data?

Yes. Pseudonymized data remains personal data under GDPR, per Recital 26, because the additional information needed to re-identify it still exists somewhere. True anonymization — irreversible, with no realistic re-identification path — takes you outside the regulation's scope, but it's a high bar and most LLM pipelines don't clear it.

Practical consequences for EU and Swiss workloads:

• You need a lawful basis for pseudonymized prompts, same as raw ones.
• Data residency applies to the inference call, not just storage. If the prompt transits a US region, you've exported personal data. See data residency for LLMs in Europe under GDPR and the EU AI Act.
• Switzerland's nFADP is not GDPR with a different flag. It has been in force since September 2023, fines run to CHF 250,000 and are aimed at individuals rather than companies, and there is no BAA-equivalent mechanism. Don't assume your GDPR paperwork transfers.
• Fines under GDPR Article 83(5) reach €20 million or 4% of global annual turnover, whichever is higher. That's the number your risk register should carry.

Does Presidio cover LLM de-identification?

Microsoft Presidio is a solid detector and a poor complete solution. It gives you PII detection and anonymization operators — replace, mask, hash, encrypt — and it's the right starting point if you're building in-house. What it doesn't give you is the vault, the per-request scoping, the residency routing, or the audit trail. Those are the parts that decide whether your pipeline survives a review.

My rule of thumb: use Presidio (or an equivalent detector) for span detection, and build the mapping and routing layer yourself or buy it. Detector quality is a solved-enough problem. Key management and request scoping are not. If you're weighing build-versus-buy on the surrounding layer, LLM routers and AI gateways for regulated industries is the comparison we keep updated.

Choosing your strategy: a decision framework

Answer these in order. The first "yes" usually settles it.

Then apply the constraints:

• Residency: pin the inference call to a region that satisfies your regime.
• Retention: if you can't state the retention period for the mapping vault in one sentence, you don't have one.
• Blast radius: the vault key holder should not be the prompt log holder.
• Reversibility audit: every unmask is an event with an actor and a timestamp.

Beyond de-identification: what it doesn't solve

De-identification reduces what's in the payload. It does nothing about what happens to the payload after it arrives. Specifically, it doesn't cover: whether the provider logs or trains on your prompts, whether the response is cached across tenants, whether a model can be induced to reconstruct masked entities from context, or whether your own application leaks the mapping through an error message.

Those are gateway and platform properties, not masking properties. Ask for them explicitly — no payload logging, no training on your data, stateless request handling, region residency, and an audit record on every call. LLM data leakage prevention walks through the failure modes we see most.

If you're evaluating routes for a regulated workload, CloudSitus is built around per-request PHI routing, region residency, and an audit trail on every call — and we'll tell you when a hyperscaler direct is the better answer for your case.

FAQ

What is the difference between redaction and pseudonymization for LLMs?

Redaction deletes or blanks the sensitive span, so the value is unrecoverable and the model loses co-reference. Pseudonymization substitutes a consistent fake, so the model can still track the same entity across a document — but the data remains personal data under GDPR because the mapping still exists.

Is pseudonymized data still personal data under GDPR?

Yes. Recital 26 states that pseudonymized data remains personal data, since additional information can re-attribute it. Only irreversible anonymization with no realistic re-identification path takes you outside GDPR's scope, and most LLM pipelines don't meet that bar.

What are the 18 HIPAA identifiers I need to remove?

Safe Harbor requires removing names, geographic subdivisions smaller than a state, dates (except year), phone and fax numbers, email addresses, SSNs, medical record numbers, health plan numbers, account numbers, certificate and license numbers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number or code.

Can I use Presidio for LLM de-identification?

Presidio handles detection and basic anonymization operators well, and it's a reasonable in-house starting point. It does not provide the encrypted mapping vault, per-request scoping, region routing, or audit trail that a regulated pipeline needs — those you build or buy separately.

Do I need a BAA to send PHI to an LLM?

If you're a covered entity or business associate sending PHI to a vendor, yes — you need a BAA covering that route. Note that BAA coverage is route-specific: on our platform it applies to the Azure routes only. A BAA also doesn't make your pipeline de-identified; that's a separate determination. Ask your counsel.