Redact before the model sees it, not after

A privacy engineer at a communications company told me about a redaction step they were proud of until they thought it through. Their feature cleaned personal data out of the model’s response before showing it to the user. It looked responsible. Then someone asked the obvious question. If the goal is to keep sensitive data from spreading, why redact the output, when the input, the raw data with everything in it, had already gone to the model provider, landed in the logs, and been written to the cache. The redaction was happening at the wrong end. The horse was already out.

Redaction only protects data at the points that come after it. Redact the output, and you have protected the user’s screen while leaving everything upstream untouched. The provider saw the raw prompt. The logs stored it. The cache holds it. The one place the sensitive data was not visible is the place it was least at risk.

Redaction protects only what comes downstream of it

Think of the data’s path through your feature. It starts in your systems. It goes into the prompt. The prompt goes to the model provider. The response comes back. It gets logged, cached, and shown to the user. Redaction is a filter you place somewhere on that path, and it only cleans what flows past it after that point. Everything before the filter saw the original.

So the location of the filter is the whole decision. Put it on the output, right before the user, and you have protected the smallest, safest part of the journey. The prompt already traveled to a third party in full. The logs already captured it. Moving the filter earlier, before the data enters the prompt, protects the entire path that follows, which is where the real exposure lives.

This is easy to get backwards because the output is what the user sees, so it feels like the important surface. The important surface, for keeping data from spreading, is the input. That is the point where the data crosses out of your control.

Move redaction upstream

The fix is to redact at the earliest point the data enters the AI path, before it reaches the model at all.

In practice:

Redact or tokenize on the way in. Replace personal data with placeholders before assembling the prompt, so the provider, the logs, and the cache only ever see the masked version.
Map back only at the edge. If the user needs to see the real values, restore them at the very last step, in a place you control, after all the storage and transmission has happened on masked data.
Redact for logs separately. Even with input redaction, make sure logging captures the masked prompt, not a raw copy assembled somewhere else.
Decide what the model actually needs. Often the model can do the task without the real name or number at all, in which case the masked value is all it ever needs to see.

The principle is to protect data at the boundary it is about to cross, not after it has crossed several. Redaction on the output is a comfort. Redaction on the input is the control.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we trace where redaction sits relative to the model, the provider, the logs, and the cache. When a team tells us they redact sensitive data, we ask where, because output-side redaction leaves the entire upstream path exposed. Moving the filter earlier is usually a small change with a large effect.

Redaction only guards what comes after it. Put it before the model, and you protect the whole path. Put it after, and you have cleaned the one place that was already safe.