{"id":111165,"date":"2026-06-15T12:00:00","date_gmt":"2026-06-15T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=111165"},"modified":"2026-06-12T09:37:01","modified_gmt":"2026-06-12T09:37:01","slug":"how-to-anonymize-pii-in-llm-pipelines-5-key-techniques-explained","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/security-and-compliance\/how-to-anonymize-pii-in-llm-pipelines-5-key-techniques-explained\/","title":{"rendered":"How to anonymize PII in LLM pipelines (5 key techniques explained)"},"content":{"rendered":"\n

Large language models (LLMs) and the agents built on top of them ingest everything they are given, including personally-identifiable information (PII)<\/a>. In workflows where PII is inevitable, proper measures should exist for data sanitization.<\/strong><\/p>\n\n\n\n

Data can leak through model outputs, embeddings or even logs. Given that you have to use LLMs in your pipeline, in this article I will cover the anonymization techniques you can utilize in an LLM flow to minimize PII exposure vectors. <\/strong><\/p>\n\n\n\n

Before we get started – in case you are undecided on whether to include an LLM or not,\u00a0this article is a good read to help solve this dilemma.<\/a><\/p>\n\n\n\n

Where does sensitive data enter the pipeline?<\/h2>\n\n\n\n

Before making any architectural decisions, let’s see where the personally identifiable data enters the processing pipeline, long<\/em> before it touches any LLM.<\/p>\n\n\n\n

\"A<\/figure>\n\n\n\n

<\/a>Source databases<\/h3>\n\n\n\n

<\/a>Starting with where the data lives, source databases are posing the highest risk. Luckily, they are the most traceable point, so it’s easy to find the data point of entry.<\/p>\n\n\n\n

Production database tables are often used for the RAG (retrieval-augmented generation)<\/a> corpus, fine-tuning a model, or one-shot examples.<\/p>\n\n\n\n

Retrieval corpus (vector store)<\/h3>\n\n\n\n

<\/a>PII starts as plain text. Somewhere in the pipeline it gets embedded in a vector store<\/a>. At that moment, PII is no longer plain old text, and there’s no going back. Still, this does not mean it is\u00a0completely<\/em>\u00a0gone. A vector embedding<\/a> will preserve the semantic content of the derived text.<\/p>\n\n\n\n

Access controls on the vector store are a must, but they don’t solve the problem completely; rather, they are one step towards complete PII isolation.<\/p>\n\n\n\n

Prompt context<\/h3>\n\n\n\n

<\/a>Dynamic prompt<\/a> assembly is where PII can crawl and find its way to exposure. A typical RAG flow pulls retrieved chunks<\/a> – possibly containing PII – and injects them directly into a system prompt.<\/p>\n\n\n\n

Anonymization techniques (and when to apply them)<\/h2>\n\n\n\n

With entry vectors out of the way, how do we protect this PII – or rather, how do we anonymize<\/em> certain data<\/a>, and when you should use a certain method? Let’s look at five different anonymization techniques.<\/p>\n\n\n\n

Format-preserving masking<\/h3>\n\n\n\n

<\/a>With format-preserving masking, you replace values with seemingly (structurally) identical fake values.<\/p>\n\n\n\n

For example,\u00a0john.doe@example.com<\/code>\u00a0turns into\u00a0a7x2.k9m@domain-mask.com<\/code>. This is useful when prompt logic parses the field (for example, extracts domain from an email).<\/p>\n\n\n\n

Example<\/strong>: john.doe@example.com<\/code> -> a7x2.k9m@domain-mask.com<\/code><\/p>\n\n\n\n

Best for<\/strong>: Fields where downstream logic parses structure (emails, phone numbers).<\/p>\n\n\n\n

Limitations<\/strong>: No referential integrity across documents.<\/p>\n\n\n\n

\n
\n\n

What is referential integrity?<\/strong>
Referential integrity means keeping related information connected correctly. In this case, if the same value is hidden differently each time, the system may not recognize it as the same thing and could lose those connections.<\/p>\n\n<\/div>\n<\/div> \n\n\n

Pseudonymization via consistent token substitution<\/h3>\n\n\n\n

<\/a>This one sounds like science fiction, but in short, human terms: pseudonymization via consistent token substitution means that you replace identifiers with a predictable token derived from a keyed hash<\/a>.<\/strong> <\/p>\n\n\n\n

That keyed hash can be an\u00a0HMAC-SHA256<\/code>, for example. The same input always produces the same token. This allows for cross-document references.<\/strong><\/p>\n\n\n\n

Example<\/strong>:\u00a0patient_id: 00369<\/code>\u00a0->\u00a0pid_3f9a2c1b<\/code>\u00a0(same input always yields the same token via HMAC-SHA256 and a secret key).<\/p>\n\n\n\n

Best for<\/strong>: In cases where the model needs to correlate the same entity across multiple documents or chunks, without exposing the real identifier.<\/p>\n\n\n\n

Limitations<\/strong>: If the signing key<\/a> is compromised, the method is reversible – thus exposing the PII.<\/p>\n\n\n\n

\n
\n
\n
\n

Enjoying this article? Subscribe to the Simple Talk newsletter<\/h3>\n
\n Get selected articles, event information, podcasts and other industry content delivered straight to your inbox. <\/div>\n <\/div>\n Subscribe now<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

<\/a>Generalization<\/h3>\n\n\n\n

<\/a>With the generalization method, you replace specific (or identifiable) pieces of information with ranges or categories.<\/strong><\/p>\n\n\n\n

For example, a specific age\u00a0age: 34<\/code>, can be turned into\u00a0age_range: 30-39<\/code>, and a full post code can be sized down to a district, etc.<\/p>\n\n\n\n

Example<\/strong>: age: 34<\/code> -> age_range: 30-39<\/code>; postcode: EC1A 1BB<\/code> -> district: EC1A<\/code>; salary: 69,300<\/code> -> bracket: 50-100k<\/code><\/p>\n\n\n\n

Best for<\/strong>: Demographic or statistical data injected into prompts that personalize the query experience where the model needs context, but would not really benefit from an exact value.<\/p>\n\n\n\n

Limitations<\/strong>: Reduced precision. Poorly chosen bucket boundaries can still allow re-identification attacks.<\/p>\n\n\n\n

Nulling (redaction)<\/h3>\n\n\n\n

<\/a>Nulling consists of replacing an actual value with a placeholder\u00a0[REDACTED]<\/code>\u00a0or\u00a0NULL<\/code>. Simple and fast. Great for free-text fields like notes and comments, which contain incidental PII that adds zero semantic value to a retrieval query.<\/strong><\/p>\n\n\n\n

Example<\/strong>: notes: \"Patient John Doe has supraventricular tachycardia and secondary hypertension\"<\/code> -> notes: \"[REDACTED]\"<\/code><\/p>\n\n\n\n

Best for<\/strong>: Free-text fields, like clinical notes, support transcripts or internal docs.<\/p>\n\n\n\n

Limitations<\/strong>: The value is null entirely, which is great for PII redaction, but comes at a cost of degraded retrieval quality.<\/p>\n\n\n\n

Synthetic data generation<\/h3>\n\n\n\n

Synthetic data generation creates statistically plausible data, but with no real records containing PII.<\/strong><\/p>\n\n\n\n

Tools that can generate synthetic data include Copulas<\/a>, Faker<\/a>, and Gretel<\/a>.<\/p>\n\n\n\n

Example<\/strong>: A real row\u00a0name: \"Michael Smith\", dob: 1987-03-13, diagnosis: \"D55\"<\/code>\u00a0is replaced with this seemingly real, yet entirely fabricated, row:\u00a0name: \"John Doe\", dob: 1985-11-02, diagnosis: \"D55\"<\/code>.<\/p>\n\n\n\n

Best for<\/strong>: Evaluation datasets and fine-tuning sets were you need realistic data volume and variety without<\/em> using production records.<\/p>\n\n\n\n

Limitations<\/strong>: Generation fidelity is hard to verify. Low-quality synthetic data skews evaluation results and produces misleading benchmark scores.<\/p>\n\n\n\n

How to anonymize the database layer (and why it’s important)<\/h2>\n\n\n\n

Why anonymize at the database layer as opposed to somewhere else? If PII is masked right at this layer, the PII data cannot<\/strong> appear downstream – regardless of how the pipeline is built, or how the data gets processed.<\/p>\n\n\n\n

This way, you’re not relying on developers to remember to sanitize the data at ingestion time. This is privacy by design<\/a>, as stated by the GDPR Article 25<\/a>, and is the most auditable control point.<\/p>\n\n\n\n

With tooling like Redgate’s\u00a0Data Masker<\/a>, an anonymizing sequence looks like this:<\/p>\n\n\n

\n