Personal data
stays home.

Every hosted-model call crosses a trust boundary: your prompt travels to a third party's servers, where it may be logged, cached, or — depending on the terms — retained. Anything personal in that prompt goes with it. For data governed by regulation (health records under HIPAA, personal data under GDPR, and their kin) that transfer can be unlawful without the right agreements; even where it's permitted, it enlarges the set of places your users' data lives and the number of ways it can leak.

The principle is straightforward: personal data you don't send can't be exposed. So the goal is to let the model do its job without ever seeing the actual PII. You can't just strip the data and hope the request still makes sense — a support summarizer needs to know that there's a customer and an email, even if it doesn't need the real address. The trick is to preserve the structure while hiding the values, and that's exactly what redact-before-send does.

The redact-before-send pattern is a round trip. On the way out, you detect PII in the prompt and mask each value — swap it for a placeholder token like [PII_0] — keeping a private mapping from placeholder back to the real value. You send the masked prompt; the provider sees only placeholders. On the way back, you restore: replace the placeholders in the model's response with the real values from your mapping, inside your own trust boundary.

The model reasons about a request that's structurally intact — "email [PII_0] asked about their order" — and produces an answer that references the placeholders, which you rehydrate into "email jane@acme.com asked about their order." The whole exchange with the provider is placeholder-only. The invariant you're enforcing is that the outbound text contains no original PII — that's the property to test, and the math makes it exact.

A subtlety makes the pattern actually usable: the same value must map to the same placeholder. If a prompt mentions one email twice, both occurrences become [PII_0], so the model understands they're the same entity and its reasoning stays coherent — and you can restore them together. Map them inconsistently and the model would think one person is two, garbling the answer.

Equally, distinct values get distinct placeholders ([PII_0], [PII_1], …), preserving the relationships in the text — who emailed whom, which id belongs to which record. So the mapping is a bijection between the real values and the placeholders: consistent within a value, unique across values. That's what lets a masked prompt carry all the structure the model needs while carrying none of the content that's sensitive. Get the mapping right and the model can't tell it's working on redacted data — except that it never learns anything it shouldn't.

Masking maps each token through a substitution: PII values become placeholders, everything else passes through. The mapping m is a bijection from the PII values to fresh placeholders. The property that matters is the leakage invariant: the masked, outbound text contains none of the original PII:

Every detected PII value is replaced, so nothing on the deny-list survives into the text you send. That empty set is the guarantee.

And because the mapping is a bijection, masking is reversible — restore composes with mask to recover the original exactly:

So you lose nothing: the provider sees placeholders, you keep the ability to reconstruct the real answer. The runnable version below masks PII, checks the leak invariant is empty, and round-trips the restore.

Redaction is powerful but not sufficient alone — because detection is imperfect. Combine it with other controls:

Structured PII — emails, phone numbers, card numbers, IDs — is easy to detect with patterns and reliable to redact. The hard cases are names, addresses, and context-dependent identifiers, where even good detectors miss some. So layer the controls: redaction as the main line, minimization to shrink the surface, contracts and (for the most sensitive data) local models to bound the worst case, and output scanning to catch anything that slips through. This is the same defense-in-depth logic as everywhere in security — no single control is perfect, so you stack independent ones.

The core limitation to internalize: a missed entity is a leak. Redaction is only as good as detection, and no detector catches every name or oddly-formatted identifier — so treat it as strong risk reduction, not an absolute guarantee, and back it with minimization and contracts. A related trap is redacting too aggressively and destroying the task: strip so much that the model can't understand the request, and you've traded a privacy win for a broken feature. Preserve structure with consistent placeholders rather than blanking everything.

Two more. Leaking through the response or logs: your own logs, traces, and prompt-caches can store the un-redacted prompt if you're not careful — apply the same discipline to observability data, and restore PII only at the last moment, inside the boundary. And PII in unexpected places: it hides in free-text fields, file uploads, image content, and tool results, not just the obvious form fields — scan everything that becomes part of a prompt. Done well, redact-before-send lets you use hosted models on real-world data without handing that data away — the personal parts simply never leave.