Implement DLP for LLM Apps (2026): Pre-Inference PHI/PII Redaction

Three response strategies when DLP detects sensitive data in a prompt:

Redact / replace (most common): swap the sensitive value with a role-based placeholder. The LLM can still complete the task because the type information is preserved. Best for clinical assistance, customer support, document drafting where the actual identifier isn't needed for the LLM's response.

Tokenize (advanced): replace the sensitive value with an opaque token, store the real value in a vault keyed by the token, restore the real value in the LLM response if needed. Best when the LLM needs to operate on the data and your application needs the real identifier in the response (e.g., 'send the patient a follow-up about X' where X is composed by the LLM using a tokenized patient ID). Skyflow Vault is the dominant vendor here.

Refuse / block: simply refuse to send the prompt to the LLM and surface an error to the user. Best for clearly-impermissible use cases (e.g., a user pastes a CSV of 1,000 patient records into a chat with no clear business purpose). Combine with rate-limiting and abuse detection.

Pick per use case. A clinical documentation assistant typically redacts/replaces. A patient-outreach orchestrator typically tokenizes. A general-purpose chat that detects an unexpectedly large PHI payload typically refuses.

Most teams implement input-side DLP and forget the output side. The LLM can — and sometimes does — repeat sensitive identifiers from the input even when you de-identified the input, because of context leakage, hallucination, or because the user's input contained one identifier the recognizers missed.

Output-side DLP: run the LLM's response through the same DLP pipeline before showing it to the user or persisting it. If detected PHI appears in the output, redact, replace, or flag for review.

Pattern: async def safe_llm_call_with_output_dlp(...): ... response = await llm_client.complete(...); deid_response, output_entities = deidentify(response.text); if output_entities: audit_log.write({event: 'output_pii_detected', ...}); return deid_response.

Bedrock Guardrails offers output filtering as a Bedrock-side feature. Azure OpenAI offers content filters. Both are useful complements to your own application-layer DLP, not replacements.

No DLP tool achieves 100% recall (catches every instance) or 100% precision (no false positives). 2026 NER-based DLP achieves ~95-99% recall on common PII types in clean English text, lower for medical-specific entities, lower in mixed languages, lower in OCR'd / messy input.

Production posture: tune for high recall (catch the PHI) at the cost of some precision (over-redact). False positives degrade LLM output quality; false negatives are HIPAA violations. The trade-off favors over-redaction.

Human review for high-stakes paths: for clinical decision support, billing, prior auth, or any path where an LLM error has significant consequences, include a human-in-the-loop review of LLM outputs that touch PHI. The LLM is a draft author; the clinician / coder is the editor.

Continuous tuning: log detected entities (types, not values) and false-positive feedback. Periodically review the data and tune recognizers. The DLP pipeline should be a living component, not set-and-forget.

Every DLP decision is an auditable event. The audit log should record: timestamp, user ID, session ID, request ID (for correlation), model, detected entity types (NOT values), action taken (redact / replace / tokenize / refuse), token counts (before and after redaction).

Do NOT log the redacted values themselves. The audit log is a target for the same regulators that scrutinize the LLM call. Logging the values would create a second PHI surface that has to be safeguarded.

Do log the type information: 'detected: PATIENT_NAME, MRN, DOB; action: replaced with placeholders'. This is sufficient for compliance evidence without re-creating the PHI exposure.

Audit log destination: encrypted-at-rest CloudWatch Log Group / Cloud Logging bucket / Azure Monitor Workspace in the appropriate region. Access controls per SOC 2 / HIPAA. Retention per your retention schedule (commonly 6-7 years for HIPAA / healthcare).

Querying: support per-user export (DSR / patient access request), per-incident export (forensics), aggregated reporting (volume by entity type, error rates). The query patterns drive the storage choice and indexing.

DLP adds latency and cost to every LLM call.

Presidio (self-hosted): adds 10-200ms per call depending on text length and recognizer count. Self-hosted means the inference happens in your infra; cost is your compute. Typical: a few dollars per million calls on small instances.

AWS Comprehend Medical: managed service, adds 50-300ms per call. Per-character billing.

Google Cloud DLP API: managed service, adds 50-300ms. Per-GB billing.

Nightfall: managed API, adds 100-400ms. Quote-based pricing.

Skyflow tokenization: adds 50-200ms per tokenize / detokenize. Vault hosts the real values; per-stored-token + per-API-call billing.

For high-throughput workloads (>1k req/sec), self-hosted Presidio with optimized batching often becomes the best cost/perf option. For low-throughput workloads, managed services trade higher per-call cost for zero ops burden.

Caching: identical prompts produce identical DLP decisions. Cache the DLP result by prompt hash for hot paths to eliminate redundant work. Be careful: caching by raw prompt hash can leak PHI through the cache key; hash the prompt after a one-way transform (HMAC with a server-side key).

HIPAA Safe Harbor is a US-specific framework. Other jurisdictions have different identifier sets and de-identification standards.

GDPR pseudonymization (Article 4(5)) vs anonymization: pseudonymized data is still personal data; anonymized data is not. DLP that replaces with reversible tokens is pseudonymization (still subject to GDPR). True anonymization requires the link to be irreversibly broken.

UK ICO de-identification guidance is broadly aligned with GDPR with some additional specificity. ICO publishes the Anonymisation: managing data protection risk code of practice as a reference.

Canada PIPEDA, Singapore PDPA, Australia Privacy Act, Brazil LGPD: each has its own identifier scope and de-identification criteria. The HHS Safe Harbor 18 elements are a reasonable superset baseline for most jurisdictions; add jurisdiction-specific identifiers as needed.

Practical pattern: maintain a per-jurisdiction config for your DLP recognizer set. Route prompts to the right recognizer config based on the user's jurisdiction (typically derived from account region or explicit user metadata).

Mistake 1: implementing only input-side DLP. Mitigation: implement output-side DLP too.

Mistake 2: redacting too aggressively, hurting LLM output quality. Mitigation: use role-based placeholders that preserve type info.

Mistake 3: missing custom organization identifiers (e.g., your member ID format). Mitigation: write custom Presidio recognizers for org-specific formats.

Mistake 4: not handling non-English text. Mitigation: configure language-specific recognizers; default English-only is a HIPAA gap for non-English-speaking patient populations.

Mistake 5: caching DLP results by raw prompt hash, leaking PHI to the cache. Mitigation: hash with a server-side HMAC or skip caching for sensitive paths.

Mistake 6: not auditing DLP misses. Mitigation: periodic red-team / sampling of pre-DLP prompts to validate recall; track false-negative rate.

Mistake 7: relying on the LLM vendor's filter without application-level DLP. Vendor-side filters are useful but not a replacement; you remain the controller and the minimum-necessary obligation is yours.