The model should never see what it doesn't need to see

Data classification tells you what doesn't go to the model. This lesson tells you how to get it out of the text before it arrives.

PII detection isn't magic. It's a classic NLP problem the industry has solved, badly, several times. Hex has already seen the three main mistakes:

• The team that trusted regex alone. Covered 80% of the obvious cases and was surprised when a user typed "my address is the third door left of hangar 7, contact me through Bruno" and the regex caught neither the address nor the name.
• The team that piped everything to an LLM. The system worked fine until the vendor bill arrived. and they realized they were sending raw text (with PII) to a third-party model to "detect PII".
• The team that asked the user to mark. Honest users forgot. Hostile ones didn't mark on purpose. Both cases ended the same.

The pattern that holds

Three layers, ordered by cost:

1. Deterministic regex. Email, phone, credit card (with Luhn check), fixed-format IDs. Cheap, fast, high precision on these cases.
2. Small contextual model. Names, free-form addresses, dates-of-birth, things that need context. Only runs on text the regex let through. Bounded cost.
3. Audit log. Every match recorded with the assigned placeholder, never the original datum. Gives you paper trail for incidents.

After scrubbing, the text that reaches the main model has stable placeholders: [EMAIL_1], [NAME_2], [ADDRESS_3]. The system keeps the mapping table on the trusted side. If the model's response needs to re-include the real datum, the system de-anonymizes it on serve.

The rule: the model operates on references, never on real data. The less PII reaches the model, the less PII it can leak. Unreachable is invulnerable.

On the right: five implementations of the scrub_pii_before_prompt tool. Pick the one that holds.