PII Redaction Pipeline for LLM Workloads (2026 Architecture)

Q: Why is regex-only PII redaction insufficient for production LLM workloads?

Because regex achieves roughly 71% recall on multilingual PII benchmarks of customer-support transcripts, and modern privacy regulators do not accept a 29% leak rate. The misses concentrate in free-text addresses ("opposite the petrol pump near MG Road"), occupational descriptors that uniquely identify ("the only paediatric neuro-oncologist at AIIMS Delhi"), code-mixed names (Devanagari script intermixed with Latin transliteration), and unicode-confusable bypasses (Cyrillic А masquerading as Latin A). The production answer is defence-in-depth: layer 1 is regex with checksum validators (Aadhaar Verhoeff, PAN alphanumeric, Luhn for cards, mod-97 for IBAN); layer 2 is a transformer NER fine-tuned for PII (DeBERTa-v3-pii or piranha-v1) catching free-text spans; layer 3 is an LLM-judge fallback called only on ambiguous spans the first two layers disagreed on. Merged with span deduplication and confidence-weighted conflict resolution, the same dataset hits 99.4% recall with 1.7% false-positive rate at 18 ms p50 added latency. Sub-95% recall is not a tradeoff against latency; it is a compliance incident.

Q: How do I decide between salted hash, deterministic tokenisation, FPE, and vaulted tokenisation?

The choice is not yours; it is the regulatory pack’s. Tier 1 (salted hash with per-tenant pepper in HSM) is safe only when re-identification is genuinely impossible and the regulator accepts pseudonymisation — typically analytics correlation surfaces. Tier 2 (deterministic HMAC-SHA256 with per-tenant key in KMS) is the default for operational PII inside a tenant boundary because same-input-yields-same-token preserves the model’s ability to reason about "the same person mentioned earlier"; the failure mode is analytics-grade re-identification risk if token frequency leaks. Tier 3 (NIST SP 800-38G FF1 format-preserving encryption) is mandatory for PCI PANs that must remain 16 digits and pass Luhn through legacy systems, with a per-field tweak so card_number cipher differs from routing_number cipher. Tier 4 (vaulted tokenisation with random opaque tokens, real values held in HSM-backed enclave like Skyflow, VGS, AWS Payment Cryptography, or self-hosted Vault Transform engine) is mandatory for GDPR Article 9 special categories and HIPAA-18 medical identifiers. Hard-code the regulatory-pack-to-tier mapping; never let runtime configuration override it.

Q: What does the DPDPA + EU AI Act lineage requirement actually demand from my architecture?

It demands a provenance graph queryable by Data Principal. DPDPA 2023 grants Indian Data Principals a right of correction (30-day response) and a right of erasure; EU AI Act Article 10 requires high-risk AI systems to document training-data provenance and to make data sets examinable for bias. Both imply your system must be able to answer, for any individual, "every place this person’s data has been processed" — every cached response derived from a prompt containing their PII, every fine-tuned model snapshot trained on a corpus that included them, every vault entry holding a token that references them, every WORM audit event recording an interaction. The architecture is a provenance graph keyed by hashed data_principal_id, with edges to vault tokens, cache keys, model invocations, and training corpora. Erasure becomes a graph walk: invalidate caches, flag fine-tuned snapshots for retraining or sunset, delete vault entries, preserve WORM audit (deletion of audit is itself a violation). It is heavy infrastructure but it is the only architectural answer to combined DPDPA + EU AI Act compliance — and the cost of building it after a regulator demand is multiples of building it before.

Q: How do I prevent PII leaking through retrieved RAG documents?

By redacting at ingest into the vector store, not at query time. The common architectural mistake is to redact the user’s prompt thoroughly but to let the retriever return raw documents containing PII because the index was built from the source corpus without a redaction pass. The fix is a two-step ingest pipeline: every document is run through the same three-layer detector (regex + NER + LLM-judge) before embedding; PII spans are tokenised with the per-tenant key and the tokens are embedded; the original-to-token map is held in the tenant’s vault keyed by document ID. At query time the retriever returns token-laden chunks (which the LLM sees), and the egress rehydrator substitutes tokens back to real values only after the model has produced its answer. The index itself is PII-free; this also means that any cross-tenant data leakage at the retrieval layer cannot expose raw PII even if the isolation controls fail. The pairing with the multi-tenant RAG isolation pattern aligns per-tenant vaults with per-tenant vector indices for end-to-end isolation.

Q: What is the per-tenant CMK requirement and why can’t I use a single shared key?

A single shared encryption key across tenants is one rogue insider away from a cross-tenant correlation incident — the same deterministic token for the same email would let an attacker who exfiltrates the key correlate user identities across every tenant’s data. The fix is one Customer-Managed Key (CMK) per tenant in AWS KMS, Azure Key Vault, or GCP KMS, with the tenant ID derived from the request authentication context, the key alias derived from the tenant ID (alias/pii-tenant-${tenantId}), and IAM policies that scope kms:Decrypt to a service role that can only run inside the redaction enclave. The detector pipeline never has direct access to the key; it calls the tokenisation service, which holds the IAM trust. PCI-DSS Requirement 3.6 mandates 90-day key rotation; the architecture must support atomic rotation — new tokens encrypted under the new key version, old tokens still decryptable under the previous version, vault background job migrating contents to the new key version within a defined RTO. Ship rotation tests in CI from week one, or the first rotation event is a multi-day outage.

Q: How does egress rehydration handle hallucinated tokens the model invents?

Carefully, because hallucinated tokens are a cross-request leak surface that has caused real incidents. The model can emit tokens in three shapes: faithfully echoed (PERSON_a3f2 — looked up in the per-request rehydration map), paraphrased (PERSON_a3f2 wrapped in markup or punctuation — still looked up by typed-prefix regex), and hallucinated (PERSON_a3f3 — the model invented a plausible-looking token that the system never minted). The rehydrator’s policy on the third case is critical: never echo a hallucinated token back to the user, because it may collide with a real token from a different request. The architectural rule is replace with [redacted], emit a high-severity telemetry event, and (in regulated workloads) hold the response from the user pending operator review. Tokens must be UUIDv7-suffixed per request to minimise the collision probability further, and the rehydrator must work over per-request token maps that are deleted at response completion — never share the token namespace across requests, never persist the rehydration map.

Q: How do I prevent streaming SSE chunks from leaking partial tokens?

By buffering until the regex-anchor pattern is complete. Server-Sent Events streaming emits the model’s response in 50-token chunks; a tokenisation token like PERSON_a3f2 may arrive split across two chunks as PERSON_a3 in chunk N and f2 in chunk N+1. A naive per-chunk regex pass over the rehydrator emits the literal "PERSON_a3" to the user (a leak of the typed prefix) and then in the next chunk emits "f2" (orphan suffix that does not rehydrate). The fix is to maintain a small look-back buffer in the SSE handler (typically the last 32–64 bytes) and to flush only when the regex anchor is satisfied or the stream ends. The performance cost is negligible (sub-millisecond) and the safety property is critical. The broader pattern for SSE/WebSocket streaming structure is covered in the streaming LLM response pattern; the redaction layer composes with it cleanly because the rehydrator is just one more transform in the streaming pipeline, sitting after the model’s tokens and before the user’s socket.

Q: What goes into the WORM audit log and what stays out?

What goes in: every PII detection event, every tokenisation, every rehydration, every vault access, every key rotation, every cross-boundary call. The schema is structured — timestamp, tenant_id, request_id, span_label (the regulatory category like IND_AADHAAR or GDPR_SPECIAL_CATEGORY_HEALTH), tier_used (hash, deterministic, FPE, or vaulted), key_version, actor (service role ARN), action (detect, tokenise, rehydrate, decrypt). What stays out: raw PII. The audit log must never contain the value being protected; it contains only the typed label and the token. The storage is write-once-read-many (AWS S3 Object Lock in Compliance mode, Azure Immutable Blob Storage, GCP Bucket Lock) with retention configured at the bucket level so even an administrator cannot truncate it. Retention is 7 years for HIPAA-bound workloads, 6 years for GDPR-aligned, indefinite for DPDPA breach-notification provenance. The audit log is the single most important artefact in a regulator’s investigation — treat it as load-bearing infrastructure with replication, monitoring, and disaster-recovery testing, not as a logging convenience.

Q: How do I handle PII inside attached images, PDFs, and other binary inputs?

By routing every binary input through an OCR + same-detector-pass before the model sees it. A common failure mode is that the text path is fully redacted but the agent accepts an image attachment (medical scan, ID-card photo, screenshot of a database table) and forwards the binary to a multimodal model with PII intact. The fix is a preprocessing layer that runs OCR (Tesseract, AWS Textract, Azure Document Intelligence, GCP Document AI, or a vision-language model with structured extraction) on every uploaded file, extracts the text, runs the same three-layer detector over the extracted text, tokenises any PII found, and either (a) re-rasterises the image with PII regions blurred and tokenised text overlaid, or (b) passes the original image to the model only after a confidence check that the OCR coverage was high enough to trust the redaction. Files where OCR confidence is below a threshold (typical: 90%) are rejected with a user-visible error rather than risk silent PII leakage to the multimodal model. The same principle applies to PDFs, spreadsheets, and any other format where text is embedded in a binary container.

Q: What’s the five-stage maturity ladder for a PII redaction pipeline and where do most teams stall?

Stage 0 is nothing — raw PII flows to the provider, failures look like front-page news and six-figure fines. Stage 1 is a single regex pass on the user prompt, masking with asterisks; misses 29% of spans on multilingual benchmarks and breaks the model’s semantic anchors so answer quality drops. Stage 2 is three-layer detection (regex + NER + LLM-judge) with deterministic per-tenant tokenisation, FPE for PCI PANs, per-tenant KMS keys; recall above 95% but no provenance graph so the first DPDPA erasure request is a manual multi-week job. Stage 3 is regulatory-pack routing (DPDPA, GDPR Article 9, HIPAA-18, PCI-DSS), vaulted tokenisation for special categories, WORM audit log with 7-year retention, per-tenant CMK with 90-day rotation, streaming-safe rehydration with chunk buffering, cross-request token uniqueness. Stage 4 is provenance graph queryable by hashed data_principal_id with lineage-aware erasure that walks the graph and invalidates caches, flags fine-tuned snapshots, deletes vault entries; adversarial harness in CI tests unicode-confusable bypass, OCR’d image bypass, paraphrase bypass, cross-request collision, prompt-injection extraction. Most teams stall at Stage 1 or 2 because the regulator has not yet asked and the incident has not yet happened — and that is exactly when the build cost is multiples lower.

Satyam Kumar

ブログに戻る

cyber-security-patterns

PII Redaction Pipeline Architecture for LLM Workloads — Presidio, NER, and Reversible Tokenisation (2026)

May 28, 202621 min read

Frequently Asked Questions

この記事を共有する

Twitter LinkedIn WhatsApp

Satyam

AI＆クラウドアーキテクト。数百万人にスケールするシステム構築を支援。

PII Redaction Pipeline Architecture for LLM Workloads — Presidio, NER, and Reversible Tokenisation (2026)

Frequently Asked Questions

この記事を共有する

Comments

Leave a comment