Pseudonymisation and language models: using AI without exposing personal data

Every time an employee pastes a contract into an AI assistant “to save time”, that contract leaves the company. With the customers’ names, the financial terms, sometimes the bank details. The problem is not artificial intelligence: it is the way the data reaches it. In this article we look at how to separate the two things: leave the reasoning to external models and keep in-house the information that identifies people and companies.

The problem: the best models are outside the perimeter

The most capable language models are services provided by external vendors, reached through APIs. When an AI agent asks one of these models to classify an email, summarise a call or draft a reply, the text of the request travels to the vendor’s servers. If that text contains “Mario Rossi, tax code RSSMRA80A01H501U, asks for a refund of the March instalment”, the vendor receives Mario Rossi’s personal data.

This has three consequences for the company using the model.

• It is a processing of personal data under the GDPR (General Data Protection Regulation), with a third party involved. A legal basis is needed, a contract that qualifies the vendor as a processor (Art. 28), and in many cases an impact assessment.
• The security perimeter widens. An incident at the vendor, or a log retention setting left active, exposes data the company no longer controls.
• Trade secrets travel with personal data. Confidential prices, names of strategic customers, contract clauses: they are not personal data, but leaving the perimeter exposes them just the same.

That authorities watch this step closely is not a hypothesis: in December 2024 the Italian Data Protection Authority fined OpenAI 15 million euro, in a proceeding that concerned, among other things, the legal basis for processing the data used for the models and transparency towards users. The point, for a company, is not the fine imposed on a vendor: it is that data sent to an external service is data you remain responsible for.

Two routes: models in-house or data transformed before leaving

There are two possible solutions, and they are not mutually exclusive.

The first is to run the models inside your own perimeter: in the company data centre or in a private cloud. No data leaves, but you give up, at least in part, the most capable models, and you take on the infrastructure. It is the right route for the most delicate data categories (health, judicial) and for those with strict sovereignty constraints.

The second is to transform the text before it leaves, replacing every item that identifies a person or a company with a neutral placeholder, and restoring the real data when the answer comes back. The external model sees only the placeholders. It is the route that allows the best models to be used without exposing people, and it is the one the rest of this article is about.

How replacement with placeholders works

The mechanism has five steps, and each has a design choice behind it.

1. Detect

Before every call to an external model, a dedicated engine analyses the text (and attachments, after content extraction) and identifies the entities to protect. The typical categories in the Italian context are: first and last names, tax codes, VAT numbers, IBANs (International Bank Account Numbers) and card numbers, email addresses, phone numbers, postal addresses, licence plates, dates of birth, case, contract and policy numbers.

Detection combines three techniques. Regular expressions with validation for structured formats: an Italian tax code has 16 characters with a precise structure and a check character, an Italian IBAN has 27 characters and a verifiable checksum. Named entity recognition (NER) models for names of people and places, which have no format. Company dictionaries: the customer list in the CRM (Customer Relationship Management), project names, suppliers, which a generic model would not know. A solid starting point for this layer is Microsoft Presidio, an open-source framework that can be extended with custom recognisers; for Italy at least the rules on tax code, VAT number and IBAN must be added.

2. Replace

Each detected entity is replaced by a consistent, typed placeholder: [PERSON_1], [TAXCODE_1], [IBAN_1]. Consistent means that the same person mentioned three times in the text receives the same placeholder three times: this way the model understands that the same entity is being discussed and can reason correctly (“[PERSON_1] asks for a refund; [PERSON_1] has already paid the instalment”). Typed means that the placeholder says what kind of data it stands for, because the model needs to know that [IBAN_1] is a bank account even if it does not know the number.

3. Safeguard the map

The correspondence between placeholders and real data (the “map”) is the most delicate point. It must be kept only inside the company perimeter, encrypted, tied to the single processing run and deleted at the end. Whoever holds the map can re-identify people; that is why the map must never reach the model vendor, and that is why, as we will see, from the GDPR standpoint the data remains personal for the company.

4. Let the model reason

The external model receives only the text with the placeholders. It classifies, summarises, drafts, replies. In practice, for most back-office tasks (understanding what an email is about, extracting the fields of a request, preparing a draft reply) the quality of the result does not change: the model does not need to know the person’s name to understand that they are asking for a refund.

There are tasks where replacement removes useful information: for example, if the model has to check that an IBAN is formally valid, the placeholder prevents it. In these cases the check is done inside the perimeter, with traditional code, before or after the call to the model.

5. Restore

When the answer comes back, the placeholders are replaced with the real data using the map, and the result ends up in the company systems (the CRM, the ERP, Enterprise Resource Planning, the draft email). Restoration must handle the cases where the model has rephrased the placeholder (for example it wrote “Mr [PERSON_1]” or changed its form): a good implementation tolerates these variations and flags the ones it does not recognise.

Anonymisation and pseudonymisation are not the same thing

Precision is needed here, because marketing language uses “anonymised” for everything, and the GDPR does not.

The GDPR defines pseudonymisation (Art. 4(5)) as the processing of personal data in such a manner that the data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and protected. That is exactly the mechanism described above: the placeholders say nothing, the map is the additional information kept separately.

Pseudonymised data remains personal data for whoever holds the map, that is, for the company. The GDPR continues to apply, but pseudonymisation is explicitly recognised as a data protection by design measure (Art. 25) and a security measure (Art. 32). The EDPB (European Data Protection Board) guidelines on pseudonymisation, adopted for consultation in January 2025, confirm this reading and describe the conditions for the measure to be effective: separation of the additional information, access control, assessment of the re-identification risk.

Anonymisation is something else: data is anonymous when the data subject is no longer identifiable, by anyone, by reasonable means (Recital 26). Anonymous data falls outside the scope of the GDPR. But true anonymisation of free text is hard to guarantee: a detailed account can identify a person even without a name.

The practical consequence is twofold. Towards the model vendor, the text with placeholders contains no identifiers: the vendor does not receive the map and has no reasonable means of re-identification. For the company, the data remains personal and must be treated as such, with pseudonymisation as a measure that reduces the risk and that the DPO (Data Protection Officer) can document in the impact assessment. Calling it “anonymisation” in headlines is understandable; describing it that way in contracts and privacy notices is a mistake.

The limits, stated plainly

No detection system is infallible on free text. A name written in lower case, a nickname, a tax code with a typo, an indirect reference (“the owner of the company we were talking about”) can slip through. Serious design treats pseudonymisation as a measure with managed residual risk, not as an absolute guarantee, and manages it in three ways.

• Rules per data category. The most delicate categories (health, judicial, data about minors) are not pseudonymised: they are mandatorily routed to models run in-house, or not processed with AI at all.
• Cautious thresholds. When in doubt the engine replaces: a false positive (one placeholder too many) costs little; a false negative (a data item that got out) costs a lot.
• Periodic review. A sample of the requests sent is reviewed by a person to find missed cases and update rules and dictionaries. The audit log, which records for every call which categories were replaced without storing the data in clear, is the tool for this review.

What to ask an AI agent vendor

If you are evaluating a platform, these questions separate those who have tackled the problem from those who have postponed it.

1. What exactly reaches the external model for a real request? Ask to see it, before and after.
2. Where is the placeholder map stored, for how long, encrypted with which keys?
3. Which data categories are recognised, and how are ours added (project names, strategic customers)?
4. Which categories never leave, and what happens when they appear in a request?
5. Does the audit log show, for every call, which model was used and which categories were replaced?
6. Does the model vendor retain the requests? Does it use them for training? Where are the servers? Under which contract?

A vendor that answers these six questions precisely has done the work. One that answers “the data is anonymised” and nothing more has not done it yet.

In conclusion

Using external AI models without exposing personal data is possible, and the mechanism is well known: detect, replace with placeholders, safeguard the map inside the perimeter, let the model reason, restore. Under the GDPR it is pseudonymisation, that is, a recognised and documentable protection measure, not an exit from the regulation. It has limits, and they must be managed with rules per category, local models for delicate cases and periodic review. But the question to start from remains simple, and it applies to any AI tool already in use in the company: what exactly are we sending out, and to whom?