Redacting PII before it reaches your AI tools

Open a text field in front of someone trying to solve a problem and they will paste the problem. All of it. Not a sanitised description of the problem — the error, the credential, the path, the customer.

When we pressure-tested our own chat widget we wrote two questions in the shape real ones arrive in. The first was somebody asking why their ESP key kept failing, with the live key inline and their own work email address at the end so we could reply. The second was somebody asking why an export broke, with the full filesystem path pasted in — which carried an employee username in one segment and a client's company name in the next. Neither person would describe what they did as "submitting personal data". Both had.

That is the working list for any marketing AI surface: credentials (API keys, bearer tokens, session tokens, anything with an sk- or xox prefix), contact details (their own email, and frequently a customer's), file paths and URLs (which leak usernames, client names, and internal hostnames without anyone noticing), and long digit runs (account numbers, phone numbers, card fragments). Every one of those arrives inside an otherwise unremarkable support question.

The principle is that text gets cleaned at the earliest point you control, and the cleaned version is the only one that moves. Not cleaned on the way into the dashboard. Not cleaned when someone asks. Cleaned before it crosses the first boundary — the browser, the extension, the client SDK — so what leaves the user's machine is already the version you would be comfortable reading aloud.

Ours is deterministic regex, deliberately. No model, no heuristic anyone can argue with in a review: pattern in, placeholder out. Keys become [key], addresses become [email], paths become [path], digit runs become [number]. An LLM-based redactor is the wrong tool here — it is non-deterministic on exactly the inputs you most need it to be reliable on, and you cannot write a test that pins its behaviour.

Two details in that redactor took real debugging and generalise to anyone building one.

Order the patterns, deliberately. Keys run before URLs, and URLs before emails. A token sitting inside a query string has to die as a key; if the URL pattern fires first it swallows the whole string and the fragment can survive somewhere else in the pipeline. Whichever pattern is most destructive should go first.

Strip invisible characters before you match anything. Control characters and zero-width joiners can split a token across a pattern boundary, so a key survives the regex and reassembles perfectly wherever the value is read later. Ours removes that class of character first, then runs the rules, then caps the length.

The honest limit is worth stating out loud: names cannot be caught deterministically. Ours does not try, and our privacy page does not claim it — it names emails, URLs, paths, keys and numbers, which is exactly the set the code handles. A promise slightly narrower than the code is fine. A promise wider than the code is the thing that costs you.

The tempting version is to store the raw text and clean it on the way out — into the dashboard, the export, the LLM prompt. It reads as reversible and flexible. It is neither.

Once raw text lands in a table it also lands in the nightly backup, the read replica, the search index, and the query logs of whatever ran the INSERT. Redacting the display path leaves every one of those untouched. And the moment someone asks you to delete their data, you are hunting a string across four systems instead of confirming one column never held it.

Derived data is where this gets subtle. We wanted a normalised fingerprint of each question so themes could be clustered without an LLM pass, which raised a real question: is a derived column new collection, or does it inherit the original? The answer we settled on has three conditions, and they are the ones to copy. Derive from the stored, redacted value and never from the raw input — deriving from the pre-redaction string is new collection wearing a derived-column costume. Write the derived column in the same statement as its source, and null it in the same statement that purges the source, so it cannot outlive what it came from. And store normalised plaintext rather than a hash: a hash survives deletion of its input, functions as a membership oracle for anyone holding a guess, and cannot be inspected when someone exercises a subject-access request.

Pair the redaction with a retention window and a purge that actually runs. Ours is 90 days on chat rows, called from the same routes that write them, so the deletion path cannot rot separately from the write path. Retention discipline is the same muscle as list hygiene — data you keep past its usefulness is a liability with a storage bill attached.

We run the same rules twice: once client-side, before anything leaves the machine, and again server-side at ingest. The two implementations are kept in lockstep — same patterns, same order, same placeholders.

They do different jobs. Client-side is for the user: it is what makes "the sensitive string never left your laptop" a true sentence rather than a policy. Server-side is for you: it is what makes the guarantee hold when a client is out of date, when someone posts to the endpoint directly, or when a new surface ships without the client library wired in. Never trust the client to have run its own redactor — that is not distrust of the user, it is an acknowledgement that the client is the one component in the system whose version you do not control.

Belt-and-braces has an unglamorous second benefit. Because the server pass exists, a missed client integration degrades to "redacted a bit later than we wanted" instead of "stored a live credential". That is the difference between a bug and an incident.

Most of what marketing teams call product telemetry does not need free text at all. It needs to know that something failed, which thing, and how often.

Our tool telemetry carries an error_class validated against a closed set — timeout, auth_failed, rate_limited, not_found and a handful more — checked at the route and re-checked at the writer. It never carries the error message body, because message bodies are where the payload lives: the failing URL, the record that broke, the credential in the stack trace. A class name answers every question we actually ask of that event.

A rule that saved us a debugging session later: reject unknown values, never coerce them. The obvious shortcut is to map anything unrecognised to error and move on. Don't — an unknown string is a version-skew signal telling you a client is newer than the server, and coercion destroys the only evidence of that.

Exactly one of our event types is permitted free text, the one carrying a bad-experience description, and it is the one redacted on both sides. Everything else is enums, counts and durations. Applied to the analytics event that started this whole review, the fix was the same shape: the chat event now sends query_length, result count, and which result ranked first. Length answers "are people writing sentences or keywords". The words themselves answered nothing we were asking and put a visitor's email address in a third party's hands, in breach of their terms as much as ours.

The same instinct belongs in your customer data model. Store the fact, not the sentence — a boolean, a bucket, a count. Custom attribute design covers where that line sits in an ESP, and the CRM vs CDP decision covers who ends up holding the raw layer when you have both.

Every AI vendor writes some version of that sentence. Most mean it. It is worth nothing until it is mechanical, and mechanical means four things.

The claim is greppable.If "we never send prompt content" is true, there is a single function every outbound payload passes through and you can read it in one sitting. If the answer is "several services handle it carefully", the claim is a hope.

The schema enforces it. A field typed as an enum of twelve values cannot carry a customer's email. A field typed as TEXT can, and eventually will. Design the shape so the bad thing is unrepresentable rather than merely discouraged.

A test asserts it. Ours asserts an email address and a filesystem path do not survive the insert. Without that, the guarantee is a comment, and comments do not fail builds.

The disclosure matches the code today.This is the one that caught us. Our extension's telemetry doc said plainly that user prompts and conversation content are never sent verbatim. The extension kept that promise exactly. The website's own chat box, on the same domain that receives the extension's telemetry, stored exactly that — and the privacy page described analytics as receiving page views and device type, with free text nowhere on the list. Two surfaces, one brand, one promise, and a regulator reads the product as a whole.

The rewritten privacy copy now says the chat events carry the question's length and never its words. That sentence became true the afternoon the redactor shipped. It was not true that morning, and the gap between those two states is the entire lesson. The AI Personalisation skill covers the wider guardrail set for deploying AI inside lifecycle programs, including where model output needs a human gate before it reaches a customer.

Vendor security pages are written to survive procurement, not to answer these. Ask them directly, in a shared document, and treat a vague answer as an answer.

The second row deserves its own note, because it is where most marketing evaluations go wrong. "We don't train on your data" is a true and reassuring sentence that answers a question you did not ask. Training is one downstream use. Storage, retention, sub-processor access, support-team visibility and breach exposure are the others, and they are unaffected by a no-training commitment. Ask about storage separately, every time. The same discipline applies when you compare ESPs — the AI features shipped in 2025 and 2026 were bolted onto data models designed years before anyone was thinking about prompt logs.

None of this is a reason to keep AI out of the marketing stack. We run our own AI surfaces and intend to keep running them; the review that started this guide made ours defensible rather than shutting it down. The discipline is the same one behind personalisation that doesn't feel creepy — hold less than you could, be precise about what you hold, and make the claim you publish match what the code does today. If you want a picture of how much of this a tool handles for you before it becomes your problem, the with-and-without comparison is the honest version.

Take this into Monday: find the newest text field in your marketing stack and read the code path from that field to storage. The redactor you already own probably isn't on it.