If your application sends real user content to a language model, every name, account number, and secret in that content goes with it. The fix is to redact personally identifiable information before the model call. This guide covers where to put redaction, what to detect, how to keep the model useful, and how to test that it works.
Placement is the most important decision
The single property that matters most is where redaction runs. If it runs after data has already gone to an external model, the exposure has already happened. Redaction has to sit on the path the data takes to the model, at egress from your trusted boundary, so sensitive values are removed before the model and any processor behind it ever receive them.
This reframes the risk. The question stops being whether your model vendor is contractually trustworthy with PII and becomes whether the vendor receives PII at all. Redacting at the boundary makes the answer no by construction.
What to detect
Sensitive data hides in free text, so detection needs both pattern matching and classification. At minimum, cover:
- Direct identifiers: names, emails, phone numbers, addresses.
- Government and financial IDs: SSN, EIN, IBAN, card numbers.
- Health information: medical record numbers and other PHI fields.
- Secrets: API keys, tokens, and passwords pasted into legitimate content.
Regex catches deterministic formats. A classifier is needed for the unstructured personal data, like a name in the middle of a sentence, that format alone cannot catch. PortEden's redaction engine layers both and covers 50-plus identifier types out of the box.
Keep the model useful with stable placeholders
Redaction does not have to make content useless. Replace each sensitive value with a stable placeholder that the model can still reason about. If a name consistently becomes the same token within a request, the model can still summarize who said what. If an account number keeps its last four digits, support staff can still recognize it on the response path. The model gets the structure it needs; the raw value never leaves your perimeter.
Fetch-and-redact: never hold the raw copy
There is a stronger pattern than cleaning data you already hold: never holding the raw version at all. With a fetch-and-redact API, the service reads from the source system (email, drive, calendar) and returns the content already redacted, so there is no raw copy sitting in your application to secure or leak. PortEden's PII API works this way, and you can compare it to other options in our guide to the best PII redaction APIs.
How to test your redaction
Treat redaction like any other safety control and test it adversarially:
- Build a fixture set of real-shaped inputs with known PII, including awkward cases: names that are also common words, numbers split across lines, secrets inside JSON.
- Assert that no known sensitive value appears in the payload that would reach the model.
- Measure recall (did you miss any PII) as the priority metric; a single missed SSN matters more than an over-redaction.
- Keep an audit record of what was redacted on each request, so a miss is detectable after the fact, not invisible.
Common pitfalls
- Redacting after the model call. The data is already gone. Redact at egress, before the call.
- Regex only. It misses unstructured PII in free text. Pair it with a classifier.
- Destroying structure. Blanket masking breaks the model. Use stable placeholders instead.
- No audit. Without a record of what fired, redaction is a black box you cannot defend in a review.
For the underlying concept, see enterprise data redaction.