Insights · 6 min read
Pseudonymizing Data for AI Training: What It Is and What It Isn’t
Stable stand-ins keep the story of the work and hide the obvious identities. They do not turn personal data into anonymous data.
Company data is full of people. Chat messages name colleagues, commits carry email addresses, support tickets quote customers. Before any of it goes to an AI lab, someone has to deal with that. Pseudonymization is the usual method, and it is often misunderstood, so this article separates what it does from what it does not do.
Three different things people call “anonymizing”
| Method | What happens | Still personal data? | Use in AI training |
|---|---|---|---|
| Redaction | The value is removed or masked, for example replaced by a tag like NAME | Can be, if other details identify the person | Simple, but breaks links: you can no longer tell who said what |
| Pseudonymization | The value is replaced by a consistent stand-in, with any key kept elsewhere | Yes, according to EU and UK regulators, because it can be attributed back with additional information | Keeps the same person recognizable across messages, tickets and commits |
| Anonymization | Identification is no longer reasonably possible | No, but the bar is high and has to be met in fact | Hard to reach with rich, linked, free-text data |
The European Data Protection Board states that pseudonymized data which could be attributed to a person with additional information is information on an identifiable person, and is therefore personal data. It adds that this holds even when the additional information sits with someone else, and that even after all additional information is erased, the data counts as anonymous only if the conditions for anonymity are met. The UK Information Commissioner’s Office says the same in its own words: pseudonymized data is personal data in the hands of whoever holds the additional information.
Why consistency is the point
A thread’s value is in who said what. The reviewer who warned about a risk, the engineer who disagreed, the lead who made the call. If you black out every name, those relationships disappear. If every name becomes a different random tag in every file, you lose them too.
A good scheme maps each real person to one stand-in everywhere: person-14 in chat is person-14 in tickets and in commit authorship. The EDPB notes that pseudonymization lets controllers keep analyzing the data and, if they wish, merge different records relating to the same person. The BigCode team’s StarCoder project took a similar approach in GitHub issues, replacing usernames with participant counters like username_1.
Here is a short synthetic illustration (ID SYN-CHAT-01), crafted by the Bearish AI team with invented names and an invented system:
| Before | After |
|---|---|
| Priya: the retry loop hammers the billing API again. Marcus, can you review before the release? | person-07: the retry loop hammers the billing API again. person-12, can you review before the release? |
| Marcus: on it. Ping me at marcus@northwind.example if the build fails. | person-12: on it. Ping me at [email-12] if the build fails. |
Names became stable stand-ins, the email became a tag tied to the same stand-in, and a detail that could narrow down a person’s schedule was generalized. Where roles matter to the lesson, a role label such as reviewer can be added, with care: the EDPB warns that combinations like role and length of service can identify people.
What to find and replace
- Names in free text. Greetings, signatures, @-mentions, “thanks, Sam” inside a long paragraph.
- Handles and usernames. Chat handles, Git authors, ticket assignees and reviewers.
- Contact details. Emails, phone numbers, addresses, calendar entries.
- Network identifiers. IP addresses, device IDs, hostnames that map to a person or customer.
- Credentials. API keys, passwords, tokens, signed URLs. These are removed or rotated, not pseudonymized.
- Customer and partner names. Often contractually confidential even when no person is named.
- Metadata in files. Author fields in design files and documents, image metadata, voices and faces in recordings.
Detection is good, not perfect
No automated detector finds everything. The StarCoder team annotated more than 22,000 PII entities in code files and reported detector scores that varied a lot by type: emails were found reliably, while keys were much harder. A regular expression for keys scored an F1 of 6.74 percent and a trained model 70.41 percent. With a trained model, names reached about 92 percent, passwords about 82 percent and usernames only about 61 percent.
The practical answer is layers. Use patterns for structured values, language models for names in text, and a human who reads a random sample of the output and counts misses. Record those counts. They become part of your documentation and tell a buyer how much residual risk to expect.
The quiet risks: combinations and memory
Direct identifiers are the easy part. The EDPB describes quasi-identifiers: combinations of attributes such as role, length of service or working hours that can point to one person even with names removed. “The only reviewer in the Berlin office who joined in 2019” identifies someone. Free text is full of these, and so are emails and calendars. MIT Technology Review reports that personal details still show up in company emails and calendars, such as medical appointments and school pickup arrangements.
Memory is the other risk. Researchers extracting training data from GPT-2 recovered hundreds of verbatim sequences, including names, phone numbers and email addresses, some of which appeared in only one document. A rare identifier left in one message can come back out of a trained model.
Where the key goes
If you use a lookup table to map real identities to stand-ins, the EDPB is explicit that the table is itself personal data and must be protected and kept separate. Do not ship it with the dataset. Decide early who, if anyone, may ever hold it, and write that down.
Pseudonymization is a step, not a finish line
Even perfectly pseudonymized data may not be yours to license. Employment terms, customer contracts, confidentiality clauses and third-party licenses are a separate review, and so is the legal basis for any personal data that remains. Treat pseudonymization as one layer in a process that ends with a lawyer’s sign-off, and see our checklist at /insights/prepare-company-data-for-ai-labs for where it fits. To see what prepared data might be worth, try the free estimate at /estimate.
Questions we get
- Is pseudonymized data still personal data under GDPR?
- Yes in general. The EDPB’s 2025 guidelines say pseudonymized data that could be attributed to a person using additional information is personal data, even when that information is held by someone else. It can be considered anonymous only if the conditions for anonymity are met. Ask a lawyer about your case.
- What is the difference between pseudonymization and anonymization?
- Pseudonymization replaces identifiers with consistent stand-ins and keeps the possibility of attribution through separate information. Anonymization means the people can no longer be identified by means reasonably likely to be used. The first reduces risk, the second changes the legal status of the data and is much harder to achieve.
- Can AI models memorize personal data from training sets?
- Yes. Researchers extracted names, phone numbers and email addresses from GPT-2, including strings that appeared in a single training document. That is why unusual identifiers need to be removed before training, not just common ones.
- Which identifiers should I remove from chat and code before selling?
- Names, handles, emails, phone numbers, IP addresses, customer names and any credentials. Also check metadata, signatures and combinations of details that point to one person. Have both automated tools and a human review a sample.
What is your data worth?
Sources
- European Data Protection Board, “Guidelines 01/2025 on Pseudonymisation” (adopted 16 January 2025, version for public consultation)
- UK Information Commissioner’s Office, “Pseudonymisation” guidance
- Li et al., “StarCoder: may the source be with you!” (2023), PII redaction section
- Carlini et al., “Extracting Training Data from Large Language Models” (2020)
- MIT Technology Review, “AI labs are buying data from dead startups to train models” (October 2026)