Personally identifiable information (PII) redaction is the process of finding personal data in text and removing or replacing it. In AI engineering, it keeps names, emails, and account numbers out of stored prompts, model outputs, and traces while preserving enough context to debug the system.
For example, a support agent receives the message “Email me at maria.ortiz@example.net about order 8841-2290.” Before the trace is stored, a redactor turns it into “Email me at [EMAIL_1] about order [ORDER_ID_1].” You can still see that the model copied an email into the wrong field, but the trace store never holds the real address.
Build better agents with Arize
Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.
Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.
Why PII redaction matters for AI systems
Personal data shows up in more places in a large language model (LLM) system than in a conventional application. Users paste it into prompts. It arrives inside retrieved documents and tool results. Models repeat it, transform it, or infer related facts.
Traces then record all of that. That record is what makes AI observability useful. It also makes unredacted telemetry a concentrated store of personal data.
PII redaction helps with:
- Protecting telemetry: Keep personal values out of trace stores that many engineers can read.
- Sharing evaluation data: Let annotators and evaluators work with text that has identifiers removed.
- Reducing provider exposure: Avoid sending values to a model provider when the task does not need them.
- Debugging safely: Keep the structure of a value, such as its type, without keeping the value itself.
Redaction is one layer of protection. Access control and retention limits are still needed alongside it.
How PII redaction works
Three related jobs are often confused: detection, redaction, and anonymization. Keeping them separate prevents the most common planning error.
Detection
Detection finds spans of text that look like personal data. Most systems combine two methods.
Pattern matching catches structured identifiers such as email addresses, phone numbers, and card-like digit sequences. Named-entity recognition finds names, addresses, and organizations in ordinary prose.
Redaction
Redaction acts on what detection found. Common approaches include:
- Partial masking: Hide part of a value while keeping its shape, such as
***@example.com. - Typed placeholders: Replace the value with a label such as
[EMAIL_1]. - Hashing: Replace the value with a hash.
- Deletion: Remove the span entirely.
Anonymization
Anonymization is a stronger claim. It means a person can no longer be identified from the data, including by combining the fields that remain.
Redacted text often fails that test. A rare job title, a small town, and a date can identify someone even with the name removed.
The common error is running a redactor and then treating the output as safe to share without restriction. Redaction alone does not make a dataset anonymous.
For instrumentation-level controls, see how to mask and redact data in Arize AX. For a full detector-and-anonymizer pipeline, see the walkthrough of removing PII with Microsoft Presidio in a chatbot.
Where to redact in an LLM system
Because personal data enters at many points, you need to choose where redaction happens. Each choice leaves a different exposure window.
- Before the model call: Use this when the model does not need the real value. It limits what a provider or a later trace can contain, but it can break tasks that need the value, such as addressing a letter.
- At instrumentation: Redact before spans are exported or stored. The model saw the value, but your telemetry store does not keep it.
- Before evaluation or dataset export: Make sure annotation and training-adjacent workflows handle redacted text.
- At display: Mask values in a user interface while the underlying store keeps them under tighter control.
Many systems need more than one point. Redacting only at display leaves the store exposed. Redacting only before the model call leaves tool results and model outputs unhandled.
How to implement PII redaction
The following code shows typed placeholder redaction with two regular expressions, using only the standard library. It is a teaching example. Real detectors combine patterns like these with named-entity recognition, because regular expressions cannot reliably find names.
The function gives each distinct value its own numbered placeholder. It also returns a mapping from placeholder to original value.
import re
PATTERNS = {
"EMAIL": re.compile("[A-Za-z0-9._+-]+@[A-Za-z0-9-]+[.][A-Za-z0-9.]*[A-Za-z]"),
"ORDER_ID": re.compile("[0-9]{4}-[0-9]{4}"),
}
def redact(text):
mapping = {}
for label, pattern in PATTERNS.items():
seen = {}
def replace(match):
value = match.group(0)
if value not in seen:
seen[value] = f"[{label}_{len(seen) + 1}]"
mapping[seen[value]] = value
return seen[value]
text = pattern.sub(replace, text)
return text, mapping
original = "Email me at maria.ortiz@example.net about order 8841-2290."
redacted, mapping = redact(original)
print(redacted)
print(f"Placeholders created: {sorted(mapping)}")
Output:
Email me at [EMAIL_1] about order [ORDER_ID_1].
Placeholders created: ['[EMAIL_1]', '[ORDER_ID_1]']
The mapping must stay in the source system. If you export it with the trace, you have exported the personal data too.
Worked example: redacting a support agent trace
Here is the same support message as it moves through a redaction setup.
Original span attribute (support agent input):
"Email me at maria.ortiz@example.net about order 8841-2290."
After pattern + entity detection and typed replacement:
"Email me at [EMAIL_1] about order [ORDER_ID_1]."
Mapping kept only in the source system, not in telemetry:
[EMAIL_1] -> (resolvable in CRM, not exported)
Debug value retained: the value was a well-formed email; the order
reference matched the tool argument; neither fact needs the raw PII.
Typed placeholders keep the debugging signal. You can still see that the model copied the email into the wrong field. You can also see whether two different emails were mixed up, because each gets its own placeholder.
None of that requires exporting the real values.
How to evaluate a redaction setup
Test detection separately from task quality. Build a labeled set of representative inputs, and include awkward cases:
- Ambiguous names: Names that are also common words.
- Split identifiers: Values broken up by punctuation or spacing.
- Structured content: Values inside tables and code.
- Non-English names: Names a detector trained on English may miss.
- Indirect sources: Personal data inside retrieved documents rather than the user’s own message.
Report misses and over-redaction separately. A miss is a privacy failure. Over-redaction is a usability failure, because masking every number can destroy order references, amounts, and dates that debugging needs.
Check downstream effects
Next, check whether evaluations still score sensibly on redacted traces.
Detection can also run as an evaluation. Phoenix provides a pre-built PII detection evaluation that flags personal data in model inputs and outputs. A detector flags, while a redactor transforms. Running detection online shows how often personal data reaches outputs, even when storage redaction is in place.
Review the unredacted copies
Redaction only governs the copies that pass through it. Review who can reach unredacted stores and how long those stores persist.
For more on those controls, see access control for agents and audit logs.
Limitations
Redaction reduces risk, but it is not a guarantee.
- Detection misses: Free-text identifiers, indirect identifiers, misspellings, images containing text, and context-dependent phrases such as “my daughter Ana, at the clinic on 5th” all produce misses.
- Over-redaction: Aggressive rules strip values an evaluator or investigator legitimately needs.
- Data already sent: Redaction cannot pull back data already sent to a model provider, written to an unredacted log, or kept in a copied dataset. Retention rules and provider terms govern those copies.
- Not a substitute for minimization: The safest value is one you never collect or forward. Pair redaction with not sending values the task does not need.
Treat redaction as risk reduction with a measured miss rate.
PII redaction vs. masking and tokenization
These terms overlap, but they make different promises.
Masking usually hides part of a value while keeping its shape, often at display time. The underlying value may still be stored.
Tokenization replaces a value with a surrogate that a separate, controlled system can reverse. It fits cases where a later step must recover the original, such as sending the actual email.
Redaction is the broader term for removing or replacing detected personal data in a given copy of the text.
The difference matters when you describe your controls. A masked interface over an unredacted trace store is not the same control as redaction before export. A tokenized value is only as safe as access to the system that reverses it.
Frequently asked questions
Does redacted data count as anonymized?
Not automatically. Redaction removes detected identifiers. Anonymization requires that no one can reasonably re-identify a person from what remains, including combinations of fields. Have that assessed separately before you share redacted data as anonymous.
Should I redact prompts before sending them to a model?
Yes, when the task does not need the real values. It reduces exposure everywhere downstream. When the task does need them, redact at instrumentation and export instead, and be clear about which copies still contain the data.
What should a redaction placeholder preserve?
A placeholder should preserve the type, such as [EMAIL_1] or [ORDER_ID_1]. It should also keep different values distinct, and it can keep non-sensitive shape such as validity or length.
It should not keep recognizable fragments of the original value unless you have explicitly accepted that risk.
How do I know if my redactor is good enough?
Measure it on labeled, representative data, and report missed personal data and over-redacted content separately. Rerun that check when prompts, tools, or traffic change.
“Good enough” depends on where the redacted copy goes and who can reach the unredacted one.
Putting PII redaction to work
Start by mapping where personal data enters your system: prompts, retrieved documents, tool results, and model outputs. Then decide where each copy should be redacted and who can still reach the unredacted version.
Build a labeled test set and track misses and over-redaction as separate numbers. Arize AX supports masking and redaction at instrumentation, and Phoenix’s PII detection evaluation can measure how often personal data still reaches model outputs.
