Protecting Personal Data in AI Tools: Anonymization, Pseudonymization, and Your GDPR Obligations
Personal data frequently ends up in AI prompts in companies, even when the organization is unaware of it. The answer is tools that anonymize or pseudonymize data before it reaches the model. These two terms are often confused, though the GDPR attaches different obligations to each, and the choice between them has direct legal consequences.
TL;DR
Under the GDPR, data sent to an AI model stays personal as long as it can be traced back to a specific person. With pseudonymization that link survives, so the data remains personal and the company is still responsible for it. Anonymization, provided it is truly irreversible, takes the data outside the regulation entirely. Either way, no tool catches everything, particularly data written in country-specific formats or details that only identify someone in context. Companies should therefore assess the risk, match the tool to the task, and be prepared to show that the choice was deliberate.
Companies now use AI for a wide range of tasks, and there is a good chance that personal data sits somewhere in what employees type into these tools. A company may not realize this is happening, yet it remains responsible for that data.
In organizations that have not given employees their own AI tools and clear rules for using them, this kind of processing is part of the wider problem of shadow AI. But companies that already run their own solution, or are considering one, still need to settle the question of who answers for the data passing through it.
Anonymization and pseudonymization are one answer to that question. The two terms are often used as if they meant the same thing, but they describe different situations, and the GDPR treats them differently. This article explains how they differ, what each means under the GDPR, what the organization is responsible for, and how local identifiers change the picture.
Anonymization vs. Pseudonymization Under the GDPR
Under Article 4(5) of the GDPR, pseudonymization means processing personal data so that it can no longer be attributed to a specific person without additional information. That additional information must be kept separately and protected by technical and organizational measures that prevent it from being linked back to an individual.
Pseudonymized data is still personal data. Under the GDPR, it counts as information about an identifiable person, because the separate piece of information can still connect it to someone. The organization therefore remains a controller, with every obligation that role carries.
The Court of Justice of the European Union reached the same conclusion in a judgment of September 4, 2025. A company that keeps the link needed to restore the data remains the controller and stays fully responsible for it, even when it sends the model only a version stripped of that link. The Court held at the same time that for a recipient who cannot identify the individual, the same data may no longer be personal data. That is what makes pseudonymizing a prompt before it is sent worthwhile, though it does not change the company’s obligations. Pseudonymization remains a security measure.
Anonymization is different. Once the people the data refers to can no longer be identified, the GDPR ceases to apply. This is what makes anonymization irreversible by definition. If the link to a person could be reconstructed, the data would still identify that person, and nothing would have changed.
An organization therefore has to consider how it actually needs to use AI and the data that goes into it. When a system is meant to replace a piece of personal data with a fictitious substitute and then restore the real value once the response returns, the organization has to store the information that connects the two, and it remains the controller of personal data.
The GDPR names pseudonymization as one of the technical measures for protecting data, so applying it is itself a way of meeting the regulation’s requirements. Anonymization suits tasks where personal data is present in the material but is not needed to complete the request. So when choosing a tool, check whether it can both reverse the substitution when the data has to come back and delete it permanently when there is no need to recover it, because that, rather than the name given to the feature, is what determines the legal outcome.
Two Ways to Protect the Data in a Prompt
By now it is clear that personal data in a prompt can be protected through either anonymization or pseudonymization, and that what separates the two is whether the change can be undone.
Consider an example. Someone in HR wants a language model to draft a reply to a leave request. The request contains a first name, a last name, and a job title. Before the prompt leaves the company, a layer comes between it and the model, detecting personal data and replacing it with other values.
The reply has to reach the same person, so the real data needs to appear in the model’s response. This calls for a reversible method: the tool records that it replaced the name with a fictitious value, and once the response arrives, it reverses the substitution. That stored link between the real value and the fictitious one is the additional information named in the definition of pseudonymization. The model never sees the real data, and the reply still reads correctly.
Other tasks do not need the data back. If a company only wants to count how many requests concern a given type of leave, the names serve no purpose. An irreversible method is enough here: the tool removes the data or replaces it with an empty label and retains nothing. The text sent to the model is anonymized at that point, so it no longer contains personal data.
In both cases, the methods only reach personal data that is detected first. Detection is usually handled by a named entity recognition (NER) model, trained to identify names, surnames, addresses, and numbers in text. Anything it fails to recognize reaches the model unchanged. So the whole approach is only as good as the NER layer’s ability to detect personal data in the first place.
Do Local Identifiers Count as Personal Data?
The data that gives an NER model the most difficulty is the kind written the way a particular language or country writes it. National ID numbers are the clearest example. A detection model trained mainly on English-language material recognizes a US Social Security number or a UK tax reference, but a Polish PESEL or tax number may mean nothing to it, and the same applies to the national formats of any other country.
Poland is a useful illustration. The PESEL is an eleven-digit number that encodes a date of birth, a marker for sex, and a check digit that confirms the number is valid. Such a number identifies a person even with no name attached, because it carries the date of birth and sex on its own, which makes it personal data under the GDPR.
The other numbers are less clear-cut, because not all of them refer to an individual. A tax number can belong to a company as readily as to a sole trader, and the digits alone will not tell you which. When the number belongs to a person, it is their personal data; when it points to a company, it is not, because the GDPR does not cover legal persons. A business registry number, by contrast, refers only to organizations recorded in the court register, such as companies and foundations, and a sole trader never appears there, so it identifies no individual. Even so, the tool should still detect numbers belonging to companies, so that information covered by trade secrecy is not exposed.
For a company operating in any given country, the detection layer therefore has to recognize each of these formats on its own terms, because it cannot know in advance whether a number it encounters belongs to a person or a company, or whether it even counts as personal data in a particular text. A model built for local conditions recognizes these numbers by their characteristic structure, including the check digit that a model trained on foreign data never examines.
How to Show Your Data Is Under Control
A tool built to protect personal data can recognize anything in a fixed format, such as a national ID number, a tax number, or an address. Some information, though, identifies a person through the content itself.
An employee might give an AI tool some background to frame a request, noting for example that it concerns a manager at the branch in a particular city, in their fifties, on sick leave for the past three months. Individually, none of these is a standard piece of personal data, but together they can point to one specific person, especially at a small branch. The GDPR also treats information that identifies someone indirectly, from a combination of characteristics, as personal data, so a description like this still falls under the regulation, even if the protective layer let it through. Some personal data can therefore leave the company even with the tool in place.
Because the tool does not remove all the risk, the organization has to be ready to show that it protected the data regardless. The GDPR requires a controller to demonstrate that it follows the principles of processing properly, recognizes the risk involved in sending data to AI models, and has a response to it.
This is the purpose of a data protection impact assessment: a document in which the controller sets out the risks and how it limits them. Data protection authorities count the innovative use of technology among the circumstances that may call for one. Deploying a tool with a protective layer does not remove that obligation, precisely because of the limits described above. The more serious the potential impact on the people whose data reaches the model, the more thoroughly it has to be documented.
A sound assessment requires knowing what the tool does with the data: how it recognizes it, whether the substitution is reversible, and where the information that would restore the original is kept. A controller cannot work all of this out alone. So when choosing the right tool, check whether it fits the organization’s circumstances on this point as well, and whether it can provide everything needed to make demonstrating compliance easier.
Technology and Who Answers for Personal Data
When a company uses AI, personal data reaches the models, and it has to be protected. Tools with anonymization and pseudonymization identify that data and, depending on the task, either remove it or replace it in a way that can be reversed later. This lets a company use the models without its data leaving in its original form.
Such tools reduce the risk of a leak considerably, but they do not eliminate it. Some personal data becomes identifiable only in context, and the tool may miss it. Even so, the responsibility the GDPR places on the company stays the same. The company has to assess the risk in advance, match the right tool to what it processes, and be able to show that it did so deliberately. That is what allows it to use AI without losing control of its data, and within the rules.
FAQ
Who Is the Data Controller When Using an External AI Model?
The company that decided to send the data remains the controller, and the responsibility toward the people the data concerns rests with it. The model’s provider usually acts as a processor, meaning it handles the data on the controller’s behalf and on its instructions. That arrangement should be governed by a data processing agreement that sets out what the provider may do with the data. Using an external model does not transfer the responsibility to its provider.
Is Pseudonymized Data Personal Data?
Yes, as long as information exists that can restore the original. The record linking the fictitious value to the real one, which lets the tool restore the data in its response, is the additional information referred to in the definition of pseudonymization. It can be used to attribute the data to a specific person, so it is protected in its own right and has to be kept separate and secured. Treating it as an ordinary technical file is a common source of breaches.
Does Banning AI at the Company Protect Against GDPR Violations?
A ban in the internal rules is an organizational measure, but on its own it does not stop data from being sent if employees use these tools anyway. The company still answers for the processing that actually takes place, not for the version described in its policy. This is why a ban works better alongside a technical solution that controls what data leaves the organization, rather than relying on employee discipline alone.
Do the AI Act, DORA, and NIS2 Regulate the Anonymization of Personal Data?
None of these acts introduces its own definitions of anonymization or pseudonymization, and none sets out separate rules for them. The AI Act uses the terms in connection with training data and regulatory sandboxes, but it refers back to data protection under the general rules. DORA and NIS2 impose obligations concerning security and resilience, and on personal data they defer to the GDPR. The reference point for anonymization therefore remains the GDPR, whichever of these acts applies to a given organization.
Sources
1. Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), Art. 4(5), Art. 25(1), 2016 – https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
2. European Commission, When Is a Data Protection Impact Assessment (DPIA) Required?, 2024 – https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en
3. Extentum AI, Shadow AI: Why Employees Feed Company Data Into ChatGPT, 2026 – https://extentum.ai/shadow-ai-gdpr-risks-data-leaks/
4. Extentum AI, Platform, 2026 – https://extentum.ai/platform/
5. Court of Justice of the European Union, Judgment of 4 September 2025, C-413/23 P, EDPS v SRB, 2025 – https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:62023CJ0413
6. Bird & Bird, The SRB Decision: A New Era for Personal Data and Data Processing Agreements, 2025 – https://www.twobirds.com/en/insights/2025/eu-the-srb-decision-a-new-era-for-personal-data-and-data-processing-agreements
