Personally identifiable information (PII) — names, account numbers, addresses, health details — often rides along in text that has nothing to do with the task. A support ticket asking "why was I double-billed" does not need the customer's card number for Claude to classify it. A redaction pipeline enforces that principle mechanically: detect PII, replace it with placeholders, send the sanitized text, and re-verify on the way out. This is defense in depth: whatever retention and compliance posture your platform provides, data you never sent needs none of it.
Stage 1: detect — code first, model second
Structured PII is a deterministic problem. Card numbers, national ID formats, emails, phone numbers, and IBANs have syntax and checksums; regex plus validators catch them reliably and free. Run this layer first, always. The model layer handles what code cannot: unstructured PII like names, addresses written in prose, or indirect identifiers ("the only cardiologist in Elm County"). If you use Claude itself as the secondary detector, use a fast model with structured outputs so the result is a machine-readable list of spans and categories — and note the boundary condition: the detector call does see raw PII, so it must run under the same data-handling rules as the rest of the pipeline, or use an on-premises detection library instead if your policy requires it. Purpose-built cloud tooling is also worth evaluating where you run — Bedrock users, for example, should look at Bedrock Guardrails' PII capabilities.
Stage 2: redact with reversible placeholders
Replace each detected span with a typed, numbered placeholder — [PERSON_1], [ACCOUNT_2] — and keep the placeholder-to-value mapping in your own secure store, never in the prompt. Consistent placeholders preserve meaning ("[PERSON_1] emailed [PERSON_2]" keeps who-did-what intact), and the mapping lets your application re-insert real values into the final rendered output after the model response returns, when the workflow genuinely needs them. That re-insertion happens in your infrastructure, not in the model's context.
Stage 3: verify the response
Trust but verify, in code: scan every model response for (a) any raw value from the mapping table — exact and normalized-form matching — and (b) any PII pattern your stage-1 detectors know, since a model can echo fragments from context you missed. A response that fails the scan is quarantined, not delivered. Log the failure with the request ID that every API response carries, because each miss is a detector gap to fix upstream. For periodic assurance, re-scan a sample of stored transcripts as a batch job — at 50% of standard token prices via Anthropic's Message Batches API where available, or each cloud's own batch inference on Bedrock and Vertex AI.
Audit trail
Record, per request: which detectors ran and their versions, counts of redactions by category (counts, not the values), the sanitized prompt hash, the verification result, and reviewer actions for quarantined outputs. This gives privacy teams evidence that controls operated, without the log itself becoming a PII store. Tie log retention to your governance policy — see PII handling and data classification.
Platform and retention notes
The pipeline's control logic is platform-neutral; the Claude-facing pieces vary. Structured outputs (for detector output) are GA on the Claude API, Claude Platform on AWS, Bedrock, and Vertex AI, beta on Foundry. Be deliberate about features that store data by design: the Files API persists uploads until deleted and is not eligible for Zero Data Retention, batch processing is likewise not ZDR-eligible, and Managed Agents sessions store history server-side (though sessions and uploaded files can be deleted via the API at any time). Note also that Claude Fable 5 requires 30-day data retention and is not ZDR-eligible — model choice interacts with data policy. Each platform inherits your cloud provider's broader compliance posture; confirm specifics with your provider rather than assuming.
Where to go next
Pair this with audit trail design and data privacy basics. For where redaction sits in a broader moderation flow, see the content moderation pipeline.