Redact before the model, not after

There is a design that looks responsible and is not. You send the document to the model, get a summary back, and run redaction over the summary before showing it to anyone. The output is clean. Everybody is satisfied.

The personal data still left your boundary. Redacting afterwards controls what humans see. It does nothing about what was transmitted, what was logged in transit, or what the provider’s retention terms permit. You have not built a control. You have built the appearance of one.

Where the control actually goes

Upstream of the call. Detect and mask the entities first, send the masked text, and rehydrate the placeholders locally on the way back if the output genuinely needs the real names. It is more work and it introduces its own failure mode — a detector that misses an entity is now the only thing standing between you and a disclosure — so the detector needs testing like the security control it is, not like a feature.

The part people skip

Decide what the model is allowed to see before deciding what it will do. Those are two separate design conversations and the second one is much more fun, which is exactly why it tends to happen first.

Human in the loop

Same principle. A human reviewing every suggestion before it counts is not a compliance checkbox — it is the thing that determines whether staff trust the output at all. Take review away and you have not made the system faster. You have made it something people quietly work around.