Most requests to a language model do not need the personal data they contain. A support reply needs the complaint, not the customer's card number; a summary of a contract needs the clauses, not the parties' addresses. Redaction removes that data before the request leaves - each value replaced by a typed placeholder such as [EMAIL_1] or [PHONE_2] - and restores it in the answer, so the model's output reads naturally to the user while the provider never saw the originals.
Detection is the hard part and it is layered. Patterns catch the structured kinds - e-mail addresses, phone numbers in several national formats, payment card numbers that pass a checksum, national identifiers, IBANs - with care not to flag timestamps, decimals and IP addresses that look like them. Names and addresses need context or a model. The router's signals include whether a request contains personal data and which kinds, and the browser extension and desktop app run the same detection on the device so a person sees the warning before pressing send.
Redaction and routing complement each other. A data-boundary rule says: when a request contains personal data, only these targets may answer - the on-premises model, the provider with the signed agreement, the regional endpoint. Redaction says: and when it does leave, it leaves without the values. Together they let a team use a frontier model for most work while guaranteeing that regulated data stays where the policy says, and the trace records both the detection and the target that answered.
Redaction has limits worth stating. A model cannot reason about a value it cannot see - 'is this e-mail domain one of our customers' needs the address - so some tasks must stay on a trusted target unredacted. Placeholders must be consistent within a request so the model can tell two people apart. And redaction is not anonymisation: the mapping exists on your side for restoration and must be protected like the data itself.
