PII Redaction for LLMs: Masking Data Before It Reaches a Model

Sketch of masked data and model pathways

PII redaction for an LLM means detecting personal data in a prompt, a retrieved document or an agent’s tool payload, and removing or replacing it before the model sees it. Redaction swaps a value for a generic marker that cannot be recovered. Masking swaps it for a typed placeholder that can be restored in the response. The step has to run inside infrastructure you control, in front of whatever model you call, or it protects very little.

This guide covers how to choose between redaction and masking, where to place the control in chat, RAG and agent flows, how to test it, and where an LLM is the wrong tool for the redaction job itself.

TL;DR

Redact when data must never be recoverable. Mask with typed placeholders when the model needs to keep track of who is who, then restore values after the response.
Put the control at the inference boundary: after retrieval, before the model call, and on tool payloads for agents.
Do not rely on a generative model alone to find PII. Use deterministic detection, and treat LLM-based detection as a second layer that you verify.
Build a manually annotated test set, measure recall and precision, and re-run it after every update.
If the redaction layer itself sends data to an outside service, you have moved the leak, not closed it. Keep it in your perimeter.

Redaction vs. masking: what changes for an LLM
Why strip PII before the prompt leaves your hands
Where the redaction step belongs
What to detect
Should an LLM do the redacting?
Proving it works: testing and audit
Handling the mapping safely
Our view: the redaction layer has to live where the data lives
Running redaction inside your own perimeter
A practical rollout sequence
FAQ
Sources

Redaction vs. masking: what changes for an LLM

The two words get used interchangeably, but they behave differently once a model is involved. One vendor’s explanation of redaction versus masking puts it well: redaction replaces sensitive values with generic markers that cannot be recovered, while masking replaces them with typed placeholders that keep identity intact and can be rehydrated from an in-memory mapping.

Here is what that looks like on one sentence:

Approach	Input	What the model sees	Recoverable?
Original	Maria Lopez called from 415-555-0142 about her claim.	Same as input	n/a
Redaction	Maria Lopez called from 415-555-0142 about her claim.	[REDACTED] called from [REDACTED] about her claim.	No
Masking	Maria Lopez called from 415-555-0142 about her claim.	[PERSON_1] called from [PHONE_1] about her claim.	Yes, from a mapping you hold

Which one fits depends on the task:

Use redaction when the output never needs the original value: classification, topic extraction, training data preparation, analytics.
Use masking when the model must keep entities distinct. Summarizing a conversation between two people is the classic case. If both names become the same marker, the summary turns to mush.

In both cases the logic is the same pattern. The Science IT group at Lawrence Berkeley National Laboratory describes the standard safe pattern as detecting entities, replacing them with neutral placeholders, and optionally re-mapping the values in post-processing of the response.

Why strip PII before the prompt leaves your hands

The reason is simple: once a prompt is sent to a cloud-hosted model, you no longer control where it goes. LBNL’s guidance notes that redacting or masking PII first can help avoid violating data-handling policies, applicable regulations or individuals’ privacy expectations. The same guidance points out that once data is sanitized, you can use it with any model without further concern about that data leaving your environment.

That last point matters for architecture. Redaction is not only a privacy feature, it is what lets a team swap models freely without re-reviewing every data flow.

For regulated teams, there is also a documentation angle. The AI SAFE2 v3.1 crosswalk lists sensitive data masking and redaction as a control and maps it to NIST AI RMF, ISO/IEC 42001 and the EU AI Act. If you are building the governance side in parallel, a 30 to 90 day AI data governance plan mapped to NIST is a practical place to see how controls like this get sequenced. Our own walkthrough of operationalizing NIST AI risk management covers the same ground from a deployment angle.

Where the redaction step belongs

The most common mistake is putting redaction in the wrong place. Three locations matter.

Three redaction points across LLM workflows

Chat prompts

Users paste things. Customer emails, spreadsheets, log excerpts, contracts. The control has to inspect the final assembled prompt, not just the text the user typed, because system prompts, templates and conversation history all join the payload.

Academic work on this problem describes an intercepting layer at the inference boundary that inspects the assembled payload and applies rule-based or structured detection before transmission. Sensitive elements can then be blocked, redacted, masked, tokenized or replaced. The same paper argues that deterministic enforcement at this boundary gives reproducible, auditable, model-independent protection against sensitive-data egress.

RAG pipelines

Vector stores have document-level permissions, which helps inside your system. But retrieved chunks are then pasted into a prompt. Elasticsearch Labs makes the case that masking in RAG should happen post-retrieval and pre-inference, so documents pulled from the vector store are cleaned before they reach an external LLM. That also means you do not have to redact the whole corpus at ingestion and lose useful context for internal users who are entitled to see it.

Agents and tool calls

Agents add a third path: the model decides to call a tool, and the arguments or results may carry PII. A January 2026 NIST agentic security presentation advises against broad agent privileges or unverified third-party tools and recommends hardened inputs. In practice that means applying the same detection to tool payloads in both directions. A write-up on enforcing guardrails at the tool call makes a similar argument: the prompt is a suggestion, the tool call is where you can actually enforce policy.

We map these and other routes in six paths of enterprise AI data leakage. Redaction closes some of them, not all.

What to detect

Start with the entity types your data actually contains, not a generic list. A 2025 benchmark of redaction tools on UK medical records found names, dates, medical record numbers and telephone numbers among the common PII types. Most enterprises will add to that list:

Direct identifiers: names, email addresses, phone numbers, government ID numbers, account and card numbers.
Quasi-identifiers: dates of birth, job titles, locations and employer names, which identify someone when combined.
Domain-specific identifiers: patient IDs, policy numbers, employee IDs, internal ticket references, customer codes.
Secrets that travel with PII: API keys, passwords and connection strings pasted into prompts.

The domain-specific group is where off-the-shelf detectors fail most. A seven-digit number is a part number in one system and a member ID in another. Write the entity list with the data owners, then encode custom patterns and dictionaries for it.

Keeping the context useful

Over-redaction wrecks the answer. If every date, place and company disappears, the model cannot reason. Three habits help:

Use typed placeholders so the model knows a value is a person or an account number.
Keep placeholders consistent within a session so the same person is always the same marker.
Decide per entity type whether to redact, mask or leave alone. A company name in a public filing may not need handling at all.

One option some teams use is replacing values with realistic synthetic stand-ins, which keeps text natural. That adds a mapping you have to protect, so treat it as masking.

Should an LLM do the redacting?

It is tempting: ask a model to “remove all personal data” and return clean text. The evidence says to be careful.

The French data protection authority notes that generative models are probabilistic and can produce inaccurate but plausible results, so outputs need verification. The medical benchmark above saw the same behavior: zero-shot generalist LLMs sometimes over-redacted or hallucinated, though few-shot prompting improved some models.

There is a second problem that is easy to miss. If you send raw text to a hosted LLM so it can find the PII, the PII has already left. The redactor must run locally.

A sensible design layers the tools:

Deterministic detection first: regular expressions, checksums, dictionaries and named-entity recognition for the entity types with firm formats.
A local model second: a small model running in your environment to catch context-dependent identifiers the rules miss.
Verification and review: sampling, logging and human review for high-risk flows.

That ordering also helps with audits. Deterministic rules produce the same result on the same input, which is what a reviewer wants to see.

Proving it works: testing and audit

A redaction layer you have not measured is a hope. The LBNL guidance recommends building a representative, manually annotated test set, measuring recall and precision, testing edge cases, and revalidating after updates.

Recall and precision pull in opposite directions, and the right balance depends on the flow. Recall is the share of real PII you caught. Precision is the share of what you flagged that was actually PII. For data headed to an outside party, favor recall. For an internal assistant where over-redaction wrecks usefulness, you may accept a little less.

What published numbers look like

Published results give a sense of the range, but they are from different data sets and are not targets for your system:

Study	Setup	Reported result
Benchmarking on 3,650 UK medical records	Best tool, Azure de-identification service	F1 0.939, precision 0.928, recall 0.950
SafeGPT enterprise study (2026)	PII detection plus output filtering	92% precision, 87% recall; output filtering remediated 84% of policy violations
PromptDLP	Deterministic pre-inference egress control	99.1% leakage prevention, 99.0% F1
LLM-Redactor evaluation	Local routing, redaction and semantic rephrasing combined, 500 samples	0.6% combined leak rate on PII
Return on security controls study	NER redaction with Microsoft Presidio in a RAG system	PII leakage eliminated in that system

Two lessons stand out. Results swing with the data and the definition of a leak, so your own test set matters more than any headline figure. And layering techniques, as the LLM-Redactor work did, beats leaning on one.

An audit checklist

Log every detection event with entity type, action taken and policy version, but never the raw value.
Keep the test set and its scores under version control, and re-run it whenever you change a model, rule or dictionary.
Sample live traffic for missed entities on a schedule.
Record who can change policy, and review changes.
Pair automated scanning with human review for high-risk actions, in line with the defense-in-depth approach that OWASP-aligned guidance describes.

For teams answering to auditors, our guides on SOC 2 evidence for air-gapped AI and HIPAA AI compliance show what evidence tends to be asked for.

Handling the mapping safely

Masking creates a lookup table from placeholder to real value. That table is now the most sensitive artifact in the flow. The LLM-Redactor work keeps the reverse map in process memory and discards it after restoration, and notes that on-disk persistence would be a worse leakage channel.

A few rules follow:

Scope the mapping to one request or one session, and delete it when done.
Do not write it to logs, caches or analytics.
Restore values only in the final response path, for users entitled to see them.
Scan model output as well as input. Models can echo, invent or recombine identifiers.

Our view: the redaction layer has to live where the data lives

We are Forge AI Deployment, and we work with security teams that ask us the same question after they have designed a redaction pipeline: where does it run?

If the detector, the mapping store or the audit log sits in a third-party cloud, you have shifted trust rather than removed it. A redaction proxy is a chokepoint for your most sensitive text. It should be held to the standard of the systems that produced the data.

Our view: the redaction layer has to live where the data lives — overview diagram

Our position, shaped by more than 20 years in high-consequence and Fortune 100 environments, is that for sensitive workloads the cleanest answer is often to keep the model, the retrieval layer and the controls inside the perimeter. Redaction then becomes defense in depth rather than your only barrier. When no data has to leave, a missed entity is an internal incident, not an external disclosure.

That does not make redaction optional. Internal users still should not see every record, logs still should not hold raw identifiers, and some data should be masked even from the model. Redaction and local deployment solve different halves of the problem, and the strongest designs use both. We expand on this in our piece on sovereign AI deployment checks and on what the 83-benchmark leak means for LLM data leakage risk.

— John Ezzell, Founder

Running redaction inside your own perimeter

Forge AI Deployment designs, deploys and operates private AI systems inside infrastructure you control: enterprise data centers, edge sites and air-gapped networks. As an official webAI systems integrator, we bring webAI’s local-first platform into production, including webAI Personas, the Intelligence Delivery Network and webAI Frontline, which gives teams fast, source-backed answers from large technical document libraries, fully offline on a single device.

If you are deciding where PII controls should sit around a private model, or whether a workload should leave the perimeter at all, see our secure local and air-gapped deployment services or start from the Forge AI Deployment home page.

A practical rollout sequence

Inventory flows. List every path PII can take to a model: chat, RAG, agents, batch jobs, fine-tuning data.
Define entities and actions. For each type, choose redact, mask, block or allow, with the data owner’s sign-off.
Place controls at the boundary. Inspect the assembled payload and tool calls, after retrieval and before inference.
Build the test set. Annotate real, representative samples, including ugly edge cases such as typos, mixed formats and non-English text.
Measure and set thresholds. Record recall and precision per entity type and decide what blocks a release.
Log, monitor, revalidate. Re-test after every model, rule or dictionary change.
Decide what stays in-house. Anything you cannot redact reliably should not go to an external model.

FAQ

What is PII redaction in an LLM workflow?

It is a step that finds personal data in text headed for a model and removes or replaces it first. The target can be a chat prompt, a retrieved document chunk or an agent’s tool payload. The aim is that the model, and any provider behind it, never receives the raw identifiers.

How is PII masking different from redaction?

Redaction uses generic markers and cannot be reversed. Masking uses typed placeholders such as a person or phone tag, and keeps a mapping so the original values can be restored in the response. Choose masking when the model must tell entities apart, and redaction when the original is never needed again.

Can I just ask an LLM to redact PII?

Not safely on its own. Generative models are probabilistic, and in a medical-records benchmark zero-shot LLMs sometimes over-redacted or hallucinated. Sending raw text to a hosted model for redaction also exposes the data you meant to protect. Use deterministic detection plus a local model, and verify with a test set.

Where in a RAG system should redaction happen?

After retrieval and before the prompt goes to the model. That way documents in the vector store stay intact for authorized internal use, and only the chunks entering an external LLM are cleaned.

How do I know my redaction is accurate enough?

Build a manually annotated set of representative samples, measure recall and precision per entity type, test edge cases, and re-run after any update. Published figures vary widely by data set, so your own measurements are the ones that count.