Solutions
The GDPR's AI amendments are still a proposal. The rules below apply today.
Data Protection & GDPR for AI
Your model processes personal data. GDPR has questions — and the answers are being renegotiated in real time.
The five questions every AI product eventually gets asked
Data protection for AI isn't a privacy policy problem. It's five hard questions, and they arrive from regulators, enterprise customers and users in roughly this order:
1. What's your lawful basis for training? Consent doesn't scale to model training; contract rarely fits; so most AI development runs on legitimate interest — which is available, but only with the assessment done and documented. The European Data Protection Board's opinion on AI models confirms legitimate interest can work, through its three-step test: a real, lawful interest; necessity (could you achieve it with less data?); and a balancing of the data subjects' rights — including whether people could reasonably expect their data to be used this way.
2. Is your model itself personal data? The EDPB's answer is deliberately uncomfortable: an AI model trained on personal data is not automatically anonymous. Anonymity is assessed case by case — whether personal data can be extracted or regurgitated with reasonable means. If the model isn't anonymous, GDPR follows it: into fine-tuning, into deployment, into the hands of whoever you license it to. And a model trained unlawfully can contaminate the lawfulness of its later use — a point with direct consequences for anyone buying or building on third-party models.
3. What did you tell the people in the training data? Transparency duties don't disappear because data was scraped from the public web. Where data isn't collected from the person directly, the GDPR's notice duties apply with limited exceptions — and "it was public" is not one of them. What you must say, where, and when is a design question we answer per source.
4. Does Article 22 catch your product? If your system makes decisions with legal or similarly significant effects on people — credit, hiring, insurance, access to services — the automated-decision rules bite, and the Court of Justice has read them broadly: in its SCHUFA judgment, even producing a credit score that a bank then relies on was itself an automated decision. If that's your product category, you need the human-involvement design, the meaningful explanation, and the contest path — engineered, not asserted.
5. What happens when someone asks you to delete them from the model? Data-subject rights don't stop at your database. Access, rectification and erasure requests colliding with model weights are the hardest operational problem in AI privacy — and the answer is a documented playbook (what you can do, what you demonstrably cannot, and what you do instead), prepared before the first request, not after.
If your product touches the EU, these questions carry GDPR's full enforcement weight — administrative fines up to €20 million or 4% of worldwide turnover at the top tier.
Two laws, one product: GDPR and the AI Act
They overlap but aren't the same, and AI products usually need both.
EU AI Act
The AI Act governs the system — its risk class, documentation, oversight.
GDPR
GDPR governs the personal data the system touches — basis, transparency, rights.
What applies today — and what's being renegotiated
Applies todaySettled law. Build on this now.
Today's rules are settled enough to build on. The GDPR text, the EDPB's AI-model opinion, and the Court's case law (SCHUFA on automated decisions; the relative approach to pseudonymised data) give a workable, documented path for training, deploying and selling AI in Europe. That's the layer we build to.
- The GDPR text
- The EDPB's AI-model opinion
- The Court's case law
Not lawProposal, in negotiation. Track it, don’t rely on it.
And the layer above it is moving. The Commission's Digital Omnibus came in two files. The AI file — moving the AI Act's high-risk deadlines — is adopted. The data file is still a proposal in negotiation, and it would amend the GDPR itself for AI:
- PROPOSEDA dedicated legal basis for AI training(proposed) — an explicit legitimate-interest footing for developing and operating AI models, paired with an unconditional right to object.
- PROPOSEDA special-category carve-out for bias detection(proposed) — permitting processing of sensitive data specifically to detect and correct bias, under safeguards.
- PROPOSED, CONTESTEDA sharpened, entity-relative definition of personal data(proposed, contested) — building on the Court's pseudonymisation case law; the data-protection authorities have formally pushed back, and the negotiating texts keep shifting.
The EDPB and EDPS issued a joint opinion criticising several of these proposals, and adoption isn't expected before late 2026 at the earliest.
Our position for clients is practical: build on today's rules — everything above remains necessary either way — and track the amendments so nothing surprises you. (Tracking them is literally what our Regulatory Change Monitoring product does.)
What we build
The deliverable set, per product rather than per template:
- Data-flow map & records of processing — how personal data actually moves through your product and models: collection, training, fine-tuning, inference, improvement, logging.
- Lawful-basis memo per purpose — training, fine-tuning on user data, inference, product improvement — each with its basis and reasoning, because "we rely on legitimate interest" without the assessment is a finding waiting to happen.
- Legitimate-interest assessment (LIA) — the three-step test, documented to the standard the EDPB opinion describes, including the reasonable-expectations analysis and mitigations.
- DPIA — and FRIA alignment — the impact assessment innovative-technology processing typically requires, structured so an AI Act fundamental-rights impact assessment can build on it rather than duplicate it.
- Training-data governance file — sourcing, licences, consent trails where relevant, web-scraping transparency approach, filtering and minimisation measures — consistent with your AI Act Article 10 documentation.
- Privacy notices written for an AI product — what the model does with data, in words users and regulators both accept; not a SaaS template with "AI" pasted in.
- Automated-decision design (Article 22) — where your product decides or scores: the human-involvement model, the meaningful-information disclosures, and the contest path, engineered with your team.
- Data-subject-rights playbook — access, objection, rectification and erasure against databases and models: what you do, what you demonstrably can't, and the documented alternative.
- DPAs and the vendor stack — the data-processing agreement your enterprise customers will send you (or the one you send first), sub-processor terms for your model and cloud providers, and international-transfer mechanics.
- Retention & deletion schedule — including training corpora, checkpoints and logs, where "we keep everything forever" quietly became the default.
Our approach
- 1Lawful-basis & data-flow assessmentHow personal data moves through your product and models, and the basis you rely on for each use — found, tested, documented.
- 2Training-data governanceSourcing, consent, transparency and documentation for the data behind your models — aligned with your AI Act data-governance file.
- 3DPIA and automated-decision reviewThe impact assessment, and where your product makes or supports decisions about people, the Article 22 design: human involvement, explanation, contest path.
- 4Privacy policy & noticesUser-facing documents written for an AI product, not lifted from a generic SaaS template.
- 5DPAs and vendor stackThe contracts your enterprise customers and vendors will ask for, sub-processors and transfers included.
- 6The moving layerA short brief on the proposed GDPR amendments as they affect you, and monitoring wired in so when the rules change, your documents change with them.
Who it's for
- AI-native products training on user data— where the lawful-basis and model-anonymity questions decide what's buildable.
- Companies fine-tuning or deploying third-party models— who inherit the training-lawfulness question whether they know it or not.
- Products that score or decide— credit, hiring, insurance, access — squarely in Article 22 territory after SCHUFA.
- Teams facing enterprise procurement— where the DPA, the DPIA and the sub-processor list are asked for before the demo.
- SaaS adding AI features— whose existing privacy stack was written for a product that no longer exists.
FAQ
A policy is one piece. The harder questions are your lawful basis for using personal data in training and inference, and how you handle automated decisions — which is where most AI products are exposed. The policy describes; the basis, the DPIA and the Article 22 design are what regulators and enterprise customers actually test.
They overlap but aren't the same. The AI Act governs the system; GDPR governs the personal data it uses. Roles differ too — provider/deployer versus controller/processor — and the documents interlock: a FRIA can build on a DPIA, and your training-data records should serve both. AI products usually need both; we make sure they're consistent.
Often yes — the EDPB's opinion on AI models confirms legitimate interest is available for AI development, through its three-step test: real interest, necessity, and a balancing that includes people's reasonable expectations. The basis works when the assessment is genuinely done and documented, with mitigations. That LIA document is precisely what we build.
If you're using innovative technology to process personal data at scale, or scoring and evaluating people — very likely yes. And if the AI Act's fundamental-rights impact assessment also applies to you, we structure the two so one builds on the other instead of duplicating it.
"It was public" is not a lawful basis and doesn't switch off transparency duties. Scraped training data needs the legitimate-interest assessment, the notice approach for data not collected from the person, and documented filtering and minimisation — the package the EDPB's opinion and supervisory practice expect.
They can ask; what's technically and legally owed is more nuanced — and it depends on whether the model itself still contains extractable personal data. What you need is a documented playbook: what you can do (and do), what you demonstrably cannot, and the alternative measures — prepared before the first request arrives.
No. The Digital Omnibus came in two files — the AI Act file is adopted; the data file amending the GDPR (the proposed AI-training legal basis, the bias-detection carve-out, the personal-data definition) is still in negotiation, with the data-protection authorities formally critical and adoption not expected before late 2026 at the earliest. We build to today's rules and track the proposals for you.
Get your data protection in order
Tell us what your model does with personal data. You'll get the basis, the assessments and the documents that hold up — to a regulator, to procurement, and to the rules as they change.
Book a ConsultationGeneral information about data-protection requirements for AI products, not legal advice. The obligations described are those of the GDPR as it applies today, read with the EDPB’s opinion on AI models and the Court of Justice’s case law. The GDPR amendments for AI described above are a proposal still in negotiation and are not law. Nothing here is a prediction of how any regulator or court will decide a particular case.