GDPR and AI: what to review before you put personal data into a model

When a company calls us about GDPR compliance and artificial intelligence, it's almost always late and almost always the same sentence: "we have a tool running and someone has asked whether this is legal." It isn't a comfortable place to be, but it's rarely the disaster people fear. Most of what we find isn't textbook illegality: it's processing with no legal basis written down, processor contracts nobody read, and data that reached a system it should never have reached. All of that can be fixed, and it's cheaper to fix before you scale than after.

This guide is the order in which we review things. It doesn't replace your lawyers — and if you have a data protection officer, the conversation starts with them — but it does give you the map: what to ask, what to document, and what to demand from suppliers before you connect personal data to a model.

What does a GDPR review look at when AI is involved?

First, and it sounds dull: whether there is actually personal data. It's striking how many projects stall out of fear when the data is aggregated, and how many advance quietly when the data is a ticket history full of names, phone numbers and customers' medical comments.

The GDPR has no AI chapter. What it does is apply the same long-standing obligations to a new kind of processing, and five of them fire almost every time:

• Legal basis and purpose (art. 6). Why you may process that data and for exactly what. Data collected to issue invoices doesn't automatically cover training a propensity model.
• Minimisation (art. 5). The model should see the fields it needs, not the whole table because exporting it was easier.
• Record of processing activities (art. 30). If AI is new processing, or changes existing processing, it belongs there. It's the first document a supervisory authority asks for.
• Security (art. 32). Who accesses the data, how it travels, where it sits when the project ends.
• Automated decisions (art. 22). If the system decides about people without meaningful human involvement, the bar rises sharply.

Our first session in a review like this isn't about models. It's about flows: where the data comes from, how many systems it crosses, who sees it on the way, and what stays stored at each stop. Drawn honestly, that diagram already answers half the questions.

The problem is rarely "using AI with personal data". The problem is not being able to explain in writing which data, for what, and with what safeguards.

What legal basis do you need to use personal data in a model?

This is where nearly everything is decided, and where most shortcuts get taken. Three bases show up in practice:

| Legal basis | When it fits | What it demands in practice | Typical risk | |---|---|---|---| | Performance of a contract | The processing is necessary to deliver the contracted service | It must be necessary, not convenient. Fraud detection on a payment, yes; commercial profiling, no | Stretching "necessary" until it breaks | | Legitimate interest | Internal improvement, security, aggregate analysis | A written balancing test between your interest and the impact on the individual, plus a real objection channel | Writing the balancing test after the inspection | | Consent | Uses the person wouldn't reasonably expect | Freely given, specific, informed and revocable. And if they revoke it, you have to be able to honour that | Consent bundled into one generic checkbox |

Consent looks like the safe option and is usually the worst: if 30% withdraw it, your training set changes and you must be able to prove you've stopped using that data. Legitimate interest is the real workhorse for internal projects, and it works if you do the balancing properly: what you gain, what it exposes the person to, and which safeguards you've put in place to reduce that exposure. Half a page argued well beats ten pages of template.

Two cautions that get expensive:

Change of purpose. You have ten years of case files collected to manage the customer relationship and you want to train a churn model. That isn't automatic. You have to assess compatibility with the original purpose, and sometimes the honest answer is that the history can't be used as it is, but can be used anonymised. We go deeper in data anonymisation.

Special categories (art. 9). Health, biometrics, trade union membership, political views, ethnic origin. They change the game: reinforced legal basis, high risk by default and, almost always, an impact assessment. And they sneak in through the back door: a free-text customer service field can hold health data without anyone designing it that way.

When do you need a data protection impact assessment?

A DPIA (art. 35) is mandatory when processing is likely to result in a high risk to people's rights. In AI projects it fires more often than people assume. Clear signals you need one:

• There is systematic evaluation or profiling of people with meaningful effects: credit scoring, CV screening, case prioritisation.
• You process data at large scale, or special category data.
• There is systematic monitoring of publicly accessible areas, such as in-store video analytics.
• You combine datasets from different origins in a way the individual wouldn't expect.
• You apply new technology to processing that used to be manual.

With two of those signals, do it. Not as ritual: a well-made DPIA is the most useful document in the project, because it forces you to write down what can go wrong and what you've put in place to stop it. The minimum structure that works: description of the processing, necessity and proportionality, concrete risks to people, mitigation measures, and the residual risk accepted — signed by whoever accepts it.

One point of timing almost nobody respects: the DPIA goes before the processing, not after the pilot. If the model is already live and you write it now, still write it, but accept that it's a remediation exercise and that it may force you to switch something off.

What should you demand when a third party supplies the model?

Almost no company trains its own models from scratch, and this is where most contracts break. If the supplier processes personal data on your behalf, they are a processor and you need an Article 28 contract. With this inside it:

• Documented instructions: they process the data only for what you tell them, and nothing else.
• No use for their own purposes: in writing, that your data is not used to train or improve their general models. If the clause isn't there, don't assume it; in many services the default is the opposite.
• Sub-processors: a list, an obligation to notify additions, and a right to object.
• Location and transfers: where processing happens. If it leaves the European Economic Area, which mechanism covers it and what supplementary measures exist.
• Retention: how long they keep prompts, inputs and outputs. Many services keep logs for weeks "for abuse monitoring"; that is processing and it has to be stated.
• Return and deletion at termination, with certification.
• Breach notification on a timeline compatible with your 72 hours.

A practical detail: ask for the supplier's data flow diagram, not just their certificate. A certificate tells you they have processes; the diagram tells you where your data goes. If they can't produce it, you already have an answer. This is also one of the hard points when choosing a supplier, which we cover from the other side in how to choose an AI consultancy.

Which technical controls actually reduce the risk?

Compliance is written on paper but held up by architecture. These are the controls that remove the most risk per unit of effort, ordered roughly by what we implement first:

| Control | What it prevents | Effort | |---|---|---| | Field filtering at source | The model seeing columns it doesn't need | Low | | Pseudonymisation before data leaves the system | An incident exposing direct identities | Medium | | Separate test environment with synthetic data | Using production "just to try it" | Medium | | Access and prompt logging | Being unable to reconstruct what happened after an incident | Low | | Documented human review in decisions about people | Falling under Article 22 without noticing | Low | | Retention enforced per system, not by agreement | Eternal copies in intermediate folders | Medium | | Detection of personal data in free-text fields | Health data slipping into comments | High |

Two warnings about pseudonymisation, because it's misread daily: pseudonymised data is still personal data and stays under the GDPR; it reduces risk, not obligations. And true anonymisation — irreversible, resistant to re-identification — is harder than any name-substitution script promises.

The pure security side overlaps with what we cover in AI and cybersecurity, and the scaffolding of responsibilities and data owners is exactly data governance. Without that scaffolding, every project re-argues the same points from zero.

What mistakes repeat in companies already using AI?

The same ones, across very different sectors:

• The shadow pilot. Someone in the business pastes customer data into a tool they expensed on a personal card. It isn't bad faith, it's the absence of an approved alternative. The fix isn't a prohibition memo: it's an official, easy path.
• Confusing the AI regulation with the GDPR. They are two distinct, cumulative rules. Complying with one doesn't exempt you from the other; we separate them in the EU AI Act for SMEs.
• Informing in the wrong place. You update the website privacy policy and assume that covers it. If the processing affects employees, or customers through another channel, the information has to be given there, in their language and at their moment.
• Being unable to answer an erasure request. It sounds theoretical until the first request arrives and you discover the data sits in the source, the intermediate warehouse, the training set and the supplier's logs.
• Documenting the model and not the processing. You keep accuracy metrics and no note about purpose, legal basis or the people affected. The first interests your technical team; the second is what you'll be asked for.
• Leaving compliance until the end. It's the pattern that kills most pilots, and not only for legal reasons — we saw it when analysing why AI pilots fail.

How do you turn this into a realistic plan?

For a mid-sized company that already has something running, an order that works across roughly six weeks of distributed effort:

| Week | What happens | How it closes | |---|---|---| | 1 | Inventory of real AI uses, including unofficial ones | List of use cases with an owner and the data they consume | | 2 | Classification: which touch personal data, and of what type | Flow map per use case | | 3 | Legal basis and purpose per case, with the balancing written | Updated processing records | | 4 | Review of supplier contracts and transfers | Addenda requested, or supplier dropped | | 5 | DPIA on the high-risk cases | Document with signed residual risk | | 6 | Technical controls and retention policy | Changes implemented and record of processing up to date |

You don't have to do it for everything at once. Start with the use case that touches the most personal data and the one the most people use; they're usually different, and they're usually the two that matter.

Frequently asked questions

Can you use customer data to train your own model?

Yes, if you have a valid legal basis for that specific purpose and you document it. What doesn't work is assuming that data collected to deliver the service automatically covers training. When the original purpose doesn't cover the use, the usual routes are prior anonymisation or a properly balanced legitimate interest with a real option to object.

What's the difference between the GDPR and the EU AI Act?

The GDPR protects personal data; the AI Act regulates AI systems by risk level, whether or not personal data is involved. They stack: a system can be high risk under the AI rules and also process personal data, in which case you comply with both. Neither replaces nor excuses the other.

Do I need a data protection officer just because I use AI?

Using AI alone doesn't trigger it. The role is mandatory if you're a public authority, if your core activity requires regular and systematic monitoring at large scale, or if you process special category data at large scale. That said, if your AI project pushes you into one of those situations, the answer can change because of the project.

Is a certified supplier enough?

No. A certification shows processes exist, not that your specific processing is covered. What protects you is the processor contract with documented instructions, the processing location, the declared retention period and an explicit ban on reusing your data to train the supplier's own models.

If you're at the "we have something running and we don't know whether it survives a review" stage, the cheap first step is to map it before touching anything: which uses exist, what data they consume, and what's missing in writing. That's part of what comes out of the audit, with the list of fixes prioritised by real risk rather than by alarm. And if you'd rather test your specific case in half an hour before moving, let's talk.