Handling PII in AI Pipelines Without Breaking the Product
A healthcare-adjacent client needed an LLM to summarize patient intake notes, but every note contained names, dates of birth, and sometimes insurance details that couldn't leave their environment unmasked and couldn't be sent to a third-party API in raw form. Our first approach was a blanket regex-and-NER redaction pass before anything reached the model, replacing detected PII with generic placeholders like [NAME] and [DATE].
That broke the feature in a specific way: summaries that referenced 'the patient's follow-up on [DATE]' were useless to the staff reading them, because the actual date mattered clinically. We switched to reversible tokenization instead — each piece of PII gets replaced with a consistent placeholder like [PERSON_1] or [DATE_1], the model works entirely on tokenized text, and we re-substitute the real values back into the output after generation, matching tokens rather than raw values.
This meant the model never saw real PII, but the summary it produced still read naturally to a human afterward. We had to be careful about consistency across a document — the same person needed the same token every time, or the model would treat [PERSON_1] and [PERSON_2] as different people and the substituted-back text would misattribute statements. We used a per-document entity resolution pass before tokenization to catch that.
For the client's compliance team, we also needed an audit trail showing that no raw PII crossed the boundary to the external API. We logged the tokenized payloads and the redaction map separately, with the redaction map encrypted at rest and access-controlled independently from the summary output, so we could prove what was sent without storing a plaintext copy of the sensitive data alongside it.
The general lesson: PII handling in AI pipelines isn't just a filter you bolt on before the model call. It has to preserve enough structure for the feature to still work, stay consistent across a document, and produce an auditable trail — three requirements that pull in different directions and that a naive redact-everything approach doesn't satisfy.
