You build the AI feature, the demo lands, everyone's happy — and then the client forwards it to their DPO. That email is where a lot of AI projects quietly die. Not because the work is wrong, but because nobody prepared answers to the questions a DPO is paid to ask.
The good news: those questions are predictable. The GDPR has not changed for AI — it just applies to it, fully, today, regardless of where the AI Act timeline lands. Walk in with these eight answers and the DPO becomes a checkbox instead of a blocker. We run this list on every build before a line of integration code ships.
A DPO never asks "is it AI?" They ask: whose data, on what basis, going where. Answer those three and you've answered most of the list.
1. What's the lawful basis for each use of personal data?
Every piece of PII your feature touches needs a lawful basis under Article 6 — and "we're building an AI" is not one of them. The two you'll usually reach for are consent and legitimate interest. If you lean on legitimate interest, the EDPB's Opinion 28/2024 spells out a three-step test: name the interest, show the processing is necessary for it, and run a balancing exercise against the individual's rights. Document that test. A DPO who asks for your basis and gets a blank look stops reading there.
2. Does this make automated decisions about people?
If your feature scores, ranks, filters or flags individuals and a decision follows with legal or similarly significant effect, you're in Article 22 territory — the right not to be subject to a purely automated decision. The CJEU's SCHUFA ruling (C-634/21, December 2023) made this concrete: producing a credit score is automated decision-making when the lender draws heavily on it, even though the agency never makes the final call. The DPO's follow-up is always the same: is there real human oversight, or a human who rubber-stamps the output? Rubber-stamping doesn't count. Oversight has to be substantive — the reviewer needs the authority and the information to actually overturn the machine.
3. Have we done a DPIA — and do we even need one?
A DPIA is mandatory under Article 35 when processing is likely to result in a high risk: large-scale profiling, systematic evaluation, or special-category data at volume. Plenty of AI features cross that line without anyone noticing. Even when it isn't strictly required, the DPO will want the input — purpose, data flows, risks, mitigations — so we produce a lightweight version by default. It's an afternoon now versus a relaunch later.
4. Where does the data physically go?
"It goes to the model" is not an answer a DPO accepts. They want the route: which vendor, which region, which country the bytes land in. The moment personal data leaves the EU you're in Chapter V transfer territory and you need a transfer mechanism — typically SCCs — plus a defensible answer on US access. This is why we settle hosting before the first prompt: an EU-hosted model (Mistral, Bedrock in an EU region, or open weights on the client's own infrastructure) makes this question a one-liner instead of a legal project.
5. Is the model vendor a processor — and what's in the contract?
When your client sends PII to an API, the client is the controller and the vendor is almost always a processor. Article 28 says you need a data processing agreement in place before that data flows. Two clauses the DPO will hunt for: does the vendor train its models on your prompts (the answer must be no, or explicitly opt-out), and who are the sub-processors sitting underneath. Get the enterprise/zero-retention terms, not the consumer tier.
6. How little data can we actually send?
Data minimisation (Article 5) is the question developers forget and DPOs never do. Does the model really need the full customer record, or a redacted slice? Are you stripping or pseudonymising PII before it leaves your system? And how long do you keep prompts and logs — because every stored prompt is retained personal data with its own basis and deletion clock. "We log everything forever for debugging" is a finding waiting to happen. Set retention deliberately and write it down.
7. How do we tell people, and how do they exercise their rights?
Transparency (Articles 13–14) means the privacy notice has to say that personal data is processed by an AI system, for what, and on what basis. And the data-subject rights still apply through the AI: access, rectification, erasure, and the right to object. The practical engineering question is whether you can honour an erasure request — if PII is baked into a fine-tuned model or a vector store, "delete my data" is a real piece of work. Design for it up front; retrofitting deletion into a RAG index is miserable.
8. Is any of this special-category or children's data?
Health, biometrics, ethnicity, political views, sexual orientation — special-category data under Article 9 — clears a much higher bar, and so does anything involving children. If your support assistant might ingest a health complaint, or your feature touches under-16s, the DPO's risk tolerance drops to near zero. Flag it early. Sometimes the right engineering answer is to keep that category out of the model's reach entirely.
The pattern under the eight
None of this is exotic. It's the same controller/processor, basis, minimisation and transparency discipline the GDPR has demanded since 2018 — pointed at a model API instead of a database. The teams that struggle are the ones who treat AI as a special case that the rules haven't caught up with. They have, and they apply now. The teams that ship treat the DPO's eight questions as part of the spec, not a gate at the end.
The longer version — with the hosting and architecture decisions behind questions 4 and 5 — lives on our EU Ready page.
FAQ
Does the AI Act mean we can stop worrying about the GDPR/AVG?
No. The GDPR applies in full and independently to any personal data your AI feature touches. The AI Act stacks on top of it; it doesn't replace it. For most client projects the GDPR is the harder, sooner test.
We only send data to an API like Claude or Mistral. Are we off the hook?
No. Your client is usually the controller and the model vendor is a processor. You need a data processing agreement, you need to know whether the vendor trains on your data, and you need to know which country the data lands in. Calling an API doesn't move the responsibility off your client.
Do we always need a DPIA for an AI feature?
Not always, but often. A DPIA is mandatory under Article 35 when processing is likely to result in a high risk — large-scale profiling, special-category data, or systematic evaluation. Even when it isn't strictly required, the DPO will ask for the input, so producing it is cheap insurance.
Is a feature that ranks or scores people "automated decision-making"?
It can be. In the SCHUFA ruling (C-634/21, December 2023) the CJEU held that producing a credit score is automated decision-making under Article 22 when a third party draws heavily on it. If your feature significantly affects someone and a human only rubber-stamps the output, Article 22 applies and real human oversight is required.
Can we use "legitimate interest" instead of asking for consent?
Sometimes. The EDPB's Opinion 28/2024 sets out a three-step test: a genuine legitimate interest, the processing being necessary for it, and a balancing exercise that the individual's rights don't override. Legitimate interest is legitimate — but only if you actually run that test and document it.
Sources: EDPB, Opinion 28/2024 on personal data in AI models · CJEU, SCHUFA judgment (C-634/21) on Article 22 · Article 83 GDPR — administrative fines (up to €20m or 4% of turnover) · ICO, guidance on automated decision-making and profiling. We're engineers, not your legal counsel — for sign-off, loop in your client's DPO and lawyers.
A client's DPO sending questions you'd rather not field alone? Plan a call — bring us into the thread, white-label.
