GDPR safe AI: how to do it properly, and where it stops

A bookkeeper at a consultancy in Aarhus copies a customer email into a chat window and asks for a draft reply. It takes fourteen seconds and saves twenty minutes. It is also the moment the firm becomes responsible for processing personal data that nobody wrote down, with a supplier nobody has an agreement with, in a country nobody checked.

That is how almost every GDPR problem with AI begins. Not in a strategy. In a single click with good intentions behind it.

What follows is the same walk through the problem we take with clients. First what actually happened, then what it takes to make it lawful, and last the part worth being honest about: where it stops.

What happened in those fourteen seconds

The email held a name, an address and a description of a case. That is personal data. The second it was sent, three things started.

Data was transferred to a supplier, who is now processing information on the firm's behalf. A retention decision was made without anybody choosing it, because the supplier's default terms apply until you ask for something else. And a processing activity came into being that does not appear in the record required by Article 30, because nobody knew it was happening.

Four questions decide whether that was lawful. What was sent? Who processed it, and do you have a data processing agreement with them? How long does it sit there, and who can see it in the meantime? And what is the legal basis for this particular use?

Most companies can answer the first question. Very few can answer all four, and that gap is the whole difference between using AI and using AI defensibly.

What GDPR safe AI actually means

GDPR safe AI is not a product you buy. It is a chain of four decisions you can document: what gets sent, who processes it, how long it stays, and on what legal basis.

It is worth understanding why that chain cannot be replaced by a promise from the supplier. In December 2024 the European Data Protection Board published opinion 28/2024, which is the most important text in this area. It says a model trained on personal data cannot automatically be called anonymous. Two conditions must both be met before it can: the likelihood of extracting personal data from the model directly has to be insignificant, and the likelihood of obtaining it through queries has to be insignificant too. Both are judged against all the means reasonably likely to be used.

That is a high bar, and it was set high on purpose. The consequence for you is simple. You cannot move the responsibility onto the supplier by pointing at a page in their documentation.

Data protection is not a switch in a settings menu. It is a chain of decisions, and the chain is only as strong as the link nobody wrote down.

How to do it properly

Order matters here. Most of the work sits before you choose a supplier, not after.

• Describe the three or four jobs the system will actually do. Not "AI in customer service", but "draft replies to delivery questions" and "summarise a case for a colleague".
• Decide, for each job, whether personal data needs to be in the request at all. Surprisingly often the answer is no, and the rest of the discussion gets much shorter.
• Choose the supplier on the named endpoint, not on the marketing. There is a real difference between a global endpoint and an EU endpoint at the same provider, and that difference is rarely on the front page.
• Ask in writing for zero retention if the provider offers it, and find out what the exceptions are. Default terms almost always include a retention window for abuse monitoring.
• Write down the processing agreement and the list of subprocessors, then set a reminder to read that list again in six months. It changes.
• Run an impact assessment if the processing is systematic or large scale. That is Article 35, and it applies even when the supplier is large and well known.
• Tell people they are talking to a system. Article 50 of the AI Act applies from 2 August 2026, and the disclosure duty was not deferred, even though the obligations for high risk systems were. It is the same date we came to in the piece on what happens when agents talk to each other.

Back to the bookkeeper in Aarhus. The lawful version of that same fourteen second click looks like this: the email is stripped of the name and the address before it goes, the case gets a reference number instead, the reply comes back as a draft, and the bookkeeper puts the name into the message that actually gets sent. The activity is in the record, the endpoint was chosen, the retention was agreed. The time saved is identical. The difference is that somebody can answer the question afterwards.

There is a fifth option worth knowing, because it removes the transfer question entirely: run the model locally. That is what our GDPR safe assistant does. No conversations leave the machine, and the history sits in a local database only the user can read. It is not the answer for every job. For quotes with prices, contracts with client names and internal notes, it usually is.

Where it stops

This is the part most suppliers do not write down, and the part you should know before promising anything onward.

An EU region is not the same thing as EU jurisdiction. If the supplier is a US company, US law can reach the data whatever city the servers sit in. The legal basis for transfers is unsettled as well. The General Court upheld the transfer arrangement with the United States on 3 September 2025, the ruling was appealed to the Court of Justice on 31 October the same year, and that court has struck down two earlier arrangements. Do not build something that falls apart if the third one goes too.

Terms shift under you. In August 2026 Axios reported that one large provider demonstrated a way to run safety checks without keeping customer data, while another moved the opposite way and began requiring 30 days of logging from business customers on its strongest models. Both happened in the same week. A zero retention promise is a contract term, not a law of nature.

Anonymisation is harder than the word suggests. Removing the name is pseudonymisation, not anonymisation, and pseudonymised data is still personal data.

Then there is the uncomfortable one. You can delete a row in a database. You cannot delete a memory from a model that has already been trained on it. The right to erasure under Article 17 is easy to honour in your own system and hard to honour in a model. That is one reason the decision not to send the data in the first place is worth more than any delete button afterwards.

Finally, Article 22 puts a limit on what the system may decide on its own. Where the decision has legal effect or similarly significant consequences for the person, a human has to be in it. A credit assessment is not the same thing as a draft email.

What you can honestly promise your customers

The wording matters more than people expect, because it gets held up against reality the day somebody asks.

Write that customer data is stored in the EU if that is true of your database and your backups. Do not write that all data is in the EU if your model calls go to global endpoints. That kind of phrasing holds for two years and costs you your credibility in the third.

Say which suppliers are involved and keep the list current. Say that providers are blocked from training on the content if that is what you agreed, and do not promise it if it is not.

That is the honest version, and it is easier to live with. GDPR safe AI is not a state you reach and then finish with. It is four questions you can answer whenever somebody asks, and a list that gets read again every six months.