Redact, mask, or block: three ways to handle PII in AI output

When a guardrail catches PII in an AI response, you have three choices: replace the sensitive value with a placeholder (redact), hide part of it (mask), or refuse to deliver the response at all (block). Getting this wrong costs you either user experience or compliance.

Redaction: replace it with a label

Redaction swaps out the sensitive value with a type marker. "Please contact anna@example.com" becomes "Please contact [EMAIL_ADDRESS]." The reader knows there was an email there; they just can't see it.

This is the right call when the model has picked up PII from the prompt and echoed it back unnecessarily. The downstream user doesn't need the specific value — they just need the instruction. Replacing it with a label preserves the meaning without exposing the data.

Redaction is also useful when you want an audit trail. The label tells you what was there without keeping the actual data in the log.

Masking: hide part of it

Masking is more surgical. Instead of replacing the whole value, you show enough of it to be recognisable but not enough to be usable. An IBAN goes from NL91ABNA0417164300 to NL91ABNA••••••4300. A phone number goes from +31612345678 to +316•••••678.

This is right when the user legitimately needs to verify which piece of data is being referenced without seeing the full value. Think of a banking assistant confirming "I found a transaction on your card ending in 4300." The partial value provides enough context; the rest stays hidden.

Blocking: stop the response entirely

Some responses should not be delivered at all. If your model produces output containing medical record numbers, full passport numbers, or any category of data under GDPR Article 9 (special categories), you may need to block the response rather than try to patch it.

Blocking is also the right call when the pattern of what's in the response suggests something has gone badly wrong — the model has been jailbroken, or the RAG pipeline has retrieved documents it shouldn't have. In those cases, you want to fail closed and alert, not try to scrub your way to a safe response.

How to decide

• If the specific value isn't needed to answer the question → redact
• If partial visibility is legitimate and useful → mask
• If the presence of the data suggests a pipeline failure → block
• If you're in a HIPAA or Article 9 context → default to block until you're sure

Custom rules in Guarrix

Guarrix lets you configure custom entity rules per tenant. You can define a regex or keyword pattern, choose whether to redact, mask (with a custom replacement), or block, and set which direction it applies — inbound (prompt), outbound (response), or both.

The defaults cover the Presidio entity set: names, emails, phone numbers, IBANs, BSNs, credit card numbers, and more. Custom rules let you layer on top — a healthcare tenant might add a rule that blocks any response mentioning a medication name alongside a patient context.

The key is that these decisions are yours to make. A guardrail should give you the controls, not make the call for you.