Tokenise Before the Model Sees It: How We Run GenAI on Sensitive Data

Pseudonymise first, reason second.

The single most common reason a GenAI project in a regulated organisation never reaches production is not accuracy. It is not cost. It is not infrastructure. 🚫

It is that nobody could get comfortable sending the data to a model.

And the conversation almost always gets stuck in the wrong place. It becomes a debate about the model provider. Where it runs. What it retains. What the contract says. Whether the region is right. All legitimate questions, and every one of them is an attempt to make sending sensitive data acceptable.

The simpler unlock is to stop sending it. 🔄

Pseudonymise first, reason second. In most use cases the model does not need the real identifiers at all. It needs the structure, the language and the relationships, and those survive tokenisation intact.

🧠 Why this works better than people expect

The intuition that blocks this is that a model needs real data to be useful. For a large share of enterprise use cases that turns out to be false, and it is worth being specific about why.

Consider a support ticket:

"Customer Anna Müller, account 4471-8823, cannot complete a transfer to IBAN DE89..., error appears after 2FA."

What does the model actually need in order to classify, summarise or draft a reply? The failure mode. The step in the journey. The error context. The language.

The name and the account number contribute nothing to the reasoning. Replace them with stable tokens and the model performs identically. We have measured this, and the accuracy delta generally sits inside the noise band of the eval itself. 📊

The cases where real values genuinely matter are narrow and identifiable:

• the identifier itself must appear in the output
• an external lookup on the raw value is required
• the analysis is specifically about the identifier's structure

Those cases exist. They are a minority. And knowing which ones they are is most of the work. 🔍

🏗️ Where tokenisation has to happen

This is where implementations go wrong, and the failure is almost always the same one.

Tokenise at ingestion, not at the point of model invocation. ⚡

Late tokenisation feels sufficient and is not, because by the time the data reaches the model call it has usually already been written somewhere. Application logs. A cache. A message queue. A nightly backup. A monitoring trace with request bodies switched on by a well meaning engineer during an incident in March. 🗄️

Each of those is a copy of a regulated value sitting in a system that was never assessed for holding it. Tokenising at the model boundary protects the model call and leaves the copies in place, and the copies are what appears in the incident report.

Getting this right in practice:

• Tokenise at the edge of the platform, before persistence and before logging. 🚪
• Keep the mapping in a single vault with its own access controls, its own audit trail and its own owner. The vault is now the crown jewel, and the entire security posture concentrates there. That is a feature, because concentrated risk is manageable risk.
• Preserve the properties downstream needs: referential integrity, format, cardinality. 🔗 A token that breaks a join will be worked around, and every workaround we have found in the wild reintroduced the real value.
• Make re-identification a separate, authorised, logged operation. Not a library function anyone can call. A governed step with a purpose attached.

🔒 What this does to your compliance position

The reason we push this pattern so hard is that it changes the shape of the argument rather than merely strengthening it.

Scope shrinks. 📉 Systems that only ever hold tokens are largely outside the scope of the controls you would otherwise have to apply, document and audit. That is not a loophole. It is the intended effect of pseudonymisation as a technical measure.

The DPO conversation changes character. 📝 "The model reasons over pseudonymised structures, and re-identification is a separately controlled and logged step" is a sentence a data protection officer will engage with. "We send records to a model, but the contract is good" is one they will push back on, and rightly.

Provider choice stops being existential. 🌍 Once the payload carries no identifiers, the deployment question becomes an engineering trade-off about latency, cost and sovereignty rather than a regulatory blocker.

On-premises and sovereign options get easier, not harder. 🇪🇺 Combining tokenisation with on-premises or sovereign processing gives you two independent controls rather than one, and independent controls are what survive a supervisory review.

⚠️ Where it gets hard, and we would rather say so

Structured identifiers are straightforward. Free text is not.

A support ticket body, a clinical note or an email thread contains names, account references and addresses in prose, and detecting them reliably is a genuine engineering problem. Approaches exist. Entity recognition with human review on low confidence. Restricting free-text fields to a narrower pipeline. Tightening what gets captured in the first place. None of them are free.

We raise this early rather than late, because a tokenisation programme that quietly excludes free text has not solved the problem it claimed to solve. 🔍

🧪 Four questions for your own GenAI programme

1. Does the model actually need the real values, or just a consistent reference? Has anyone asked that per use case?
2. Where does tokenisation happen: at ingestion, or just before the model call?
3. Is re-identification a governed, logged operation, or a function anyone can invoke?
4. What is your plan for free-text fields, and does the programme depend on that plan working?

📅 Talk to us

Book a 30-minute review. We will tell you which of your use cases can run on tokens today and which genuinely cannot.

Data privacy, GenAI and advisory: mejuvante.ai/enquiry-1