Hashing and pseudonymisation: what to send to an LLM
Distinguish removal, aggregation, hashing and pseudonymisation when preparing LLM data. Minimize context and control keys, destinations and logs.
Hashing an email address does not automatically make a dataset anonymous. If an identifier still links records or lets someone test candidate identities, identification risks can remain. Before transforming a field, decide whether the task needs it at all.
Four ways to reduce context
| Need | Design option | Limitation to assess |
|---|---|---|
| The identifier adds no value | Remove it | Other fields may identify someone indirectly |
| Only totals are needed | Aggregate | Small groups may disclose individuals |
| Events must be linked | Token or pseudonymous identifier | Protect the mapping table |
| A stable derived identifier is needed | HMAC with a protected key | Define scope, rotation and key access |
These options require validation against the use case and risk. They do not guarantee anonymity or legal compliance.
Example: margin versus repeat purchases
Explaining a channel’s gross margin requires a period, currency, revenue and cost. The model does not need a customer identifier.
Analyzing repeat purchases may require linking events from the same customer. A pseudonymous identifier can preserve that relationship without placing the email address in context. Keep identity fields and the ability to resolve the mapping outside the model.
Plain hashing versus HMAC
A deterministic email hash can be compared against hashes of candidate addresses. HMAC uses a secret key in addition to a hash function. NIST’s HMAC reference describes the cryptographic construction; applying it does not by itself make a dataset anonymous.
Keep the key out of prompts and logs. Decide whether identifiers should remain stable across periods, systems or tenants. Excessively broad scope can enable unnecessary linking. Plan key rotation around any historical relationships that must be preserved.
Check indirect identifiers
An unusual job title, exact date or combination of location and purchase can identify a person without a name. The ICO’s pseudonymisation guidance distinguishes these transformations from anonymisation. Assess the whole dataset and access to additional information.
Apply the same reasoning to logs, exports and caches. Review the specific model service’s retention and data-use terms too; do not assume identical terms across providers or products.
Make the design testable
For each question, document the required fields, transformation, permissions and destination. Inspect what the model actually receives. A semantic layer can provide shared definitions; authorization before the prompt must prevent users from bypassing minimization by requesting another field or tool.