What the GDPR requires when AI touches personal data

You want to run customer data through a model, and somebody has asked whether that is allowed. The answer is almost always yes, with conditions, and the conditions are less exotic than the question suggests.

The GDPR has no opinion about artificial intelligence. It asks the same things it asks of a spreadsheet: what are you doing, why, on what basis, with how much data, for how long, and who else can see it. A model is just another processing step. What makes it feel different is that people send far more data into a prompt than they would ever type into a form.

The six questions that decide it

1. Is it personal data at all? The definition is wider than most people assume. A name, an email address, an order number that can be traced to a person, an IP address, a voice recording, a free text field where a colleague described a customer. Stripping the name rarely helps, because the rest of the record still identifies someone. Pseudonymised data is still personal data.

2. What is the purpose, written down before you start? Purpose limitation is the principle that catches AI projects. Data collected to deliver an order was not collected to train or evaluate a model, and reusing it for that is a new purpose that needs its own justification. Write the purpose as one sentence you would be comfortable showing the customer.

3. What is the lawful basis? For most business automation it is performance of a contract or legitimate interest. Legitimate interest is available and it is not a free pass: it requires a balancing test, written down, weighing your interest against what the person would reasonably expect. Consent is the weakest option in a business context and almost never the right one for employees, because consent given to an employer is rarely freely given.

4. Does the person know? Transparency means your privacy statement describes what actually happens, in language a customer can follow. If a model drafts replies to their messages or scores their application, that belongs in the statement. Nobody has ever been fined for describing their processing too clearly.

5. How much data are you actually sending? Data minimisation applies to every prompt. The default habit of pasting an entire record because it is easier than selecting fields is the single most common failure we see, and it is also the easiest to fix: send the three fields the task needs.

6. How long does it live, at every hop? Your database, your logs, the provider's abuse monitoring, your error tracker, the analytics tool, the backup. Retention is a property of the whole path, not of the table you thought about.

The paperwork this creates

Four documents, none of them long.

• An entry in your Article 30 record. The processing register is the first thing a supervisory authority asks for, and an AI workflow is an entry like any other: purpose, categories of data, recipients, retention, security measures.
• A data processing agreement with the provider. Article 28 requires it whenever someone processes personal data on your behalf. Consumer accounts do not come with one, which is the practical problem described in where your data goes when your team uses ChatGPT.
• A transfer mechanism if any hop sits outside the EEA. That is a contract clause, not a prohibition, and it is a good reason to know exactly where your workloads run.
• A DPIA, when the processing is likely to be high risk. Large-scale profiling, systematic monitoring of people, special category data such as health, and decisions that have a legal or similarly significant effect all point that way. Most internal automation does not, and writing two lines explaining why not is itself worth doing.

Clearing one use case in an afternoon

Do this per use case rather than per tool. A tool is not compliant or non-compliant, a use is.

1. Write the purpose in one sentence.
2. List every field that will be sent. Actually list them, from the payload, not from memory.
3. Strike the fields the task does not need. This is usually a third of them.
4. Pick the lawful basis and, for legitimate interest, write the three-paragraph balancing test.
5. Check the provider: is a DPA signed, what is the subprocessor list, where does processing happen, what is retained and for how long.
6. Decide your own retention and logging. Decide it for the logs too, which is the step people skip.
7. Write the register entry and, if the triggers are there, start the DPIA.
8. Tell the team what is now allowed, in one paragraph, so the decision is usable.

An afternoon per use case, and the second one takes an hour because steps four to six repeat.

Where people actually get caught

Not in the model. In the logging. A debugging system that stores full prompts and responses turns every processed record into a second copy in a system nobody wrote a retention policy for, often with wider access than the source. When a subject access request arrives, that copy has to be found too.

Three more that recur. Production personal data copied into a test environment, where the controls are weaker and the deletion never happens. Employee monitoring introduced as a quality feature, consented to in a contract nobody could refuse. And the "anonymised" dataset where the names were removed but the free text still says who the customer is and what they complained about.

The limits of getting the paperwork right

A completed DPIA on a system nobody monitors is a document, not a control. If the answer to "what happens when this produces a wrong result" is silence, the register entry does not help you, and the right response is a better system rather than a better file.

There is also a large class of work this article does not touch. Moving invoice lines, reconciling stock, summarising public documents: no personal data, no obligations beyond ordinary security. If a process has no personal data in it, saying so in one sentence should be the end of the conversation, and letting it stall for a month is its own kind of failure.

The uncomfortable version, from a consultancy that could bill for the opposite: most of what gets sold as AI compliance is paperwork about systems that were never risky. The work worth paying for is deciding which of your processes actually touch people, and building those few properly. That is what an AI Readiness Audit is for, and the rest of the compliance guides go a level deeper on the individual questions.

Frequently asked questions

Do we need consent to use AI on customer data?

Usually not. Most business processing runs on contract or legitimate interest, and consent is the weaker basis because it can be withdrawn and must be freely given. Pick the basis that matches what you are actually doing, and document why.

Does the GDPR ban sending data to a US provider?

No. It requires a valid transfer mechanism and a processing agreement. The practical questions are which subprocessors are involved, what they retain, and whether an EU region is available, not whether transfers are permitted at all.

When do we need a DPIA for an AI system?

When the processing is likely to be high risk: large-scale profiling, systematic monitoring, special category data, or decisions with a legal or similarly significant effect on someone. If none of those apply, record briefly why you concluded that, so the decision is visible later.

Is pseudonymised data outside the GDPR?

No. Pseudonymised data is still personal data, because it can be linked back to a person. Only genuinely anonymised data falls outside, and that bar is high: if any combination of fields still singles someone out, it is not anonymous.