Data Protection & GDPR for AI

Under the GDPR, every use of personal data needs a lawful basis. Article 6 sets out six: consent, performance of a contract, a legal obligation, vital interests, a public-interest task, and legitimate interests. The exposure for AI products is usually not "do we have a policy" but "what is our basis for each use of personal data — collection, training, inference — and can we evidence it."

• Map how personal data moves through your product and model, and attach a lawful basis to each distinct use.
• Where you process special-category data (Article 9) — health, biometrics, and similar — you need an Article 9 condition on top of your Article 6 basis.
• The basis you rely on for training can differ from the one for inference or deployment; treat them separately.

The data behind your models needs sourcing, consent where relevant, and documentation you can stand behind. This has become one of the most scrutinised areas in AI data protection.

In December 2024 the European Data Protection Board (EDPB) issued Opinion 28/2024 on processing personal data in the context of AI models. Three points from it are worth building around:

• Model anonymity isn’t automatic. Whether a trained model is “anonymous” is assessed case by case, and the threshold is high — you’d need to show the likelihood of extracting personal data about individuals from the model (directly or through queries) is insignificant.
• Legitimate interest can be a valid basis for development and deployment, but only via a structured three-step test: a genuine legitimate interest, the necessity of the processing for it, and a balancing against the rights and reasonable expectations of the people whose data is used.
• Mitigations strengthen the balance — measures like pseudonymisation, genuine transparency about data sources, and an opt-out all weigh in your favour in that assessment.

Where your product makes or supports decisions about people, additional GDPR obligations attach. Article 22 gives individuals the right not to be subject to a decision based solely on automated processing — including profiling — that produces legal effects or similarly significantly affects them, save in defined circumstances and with safeguards.

• Identify where your system makes or materially drives decisions about individuals (credit, eligibility, employment-related screening, and the like).
• Where Article 22 is engaged, build in the transparency, the meaningful information about the logic involved, and the safeguards — such as human review — that the GDPR requires.
• Tie this to your transparency notices under Articles 13–14, which are where individuals learn that such processing happens.

Two sets of documents do real work here, and neither should be lifted from a generic SaaS template:

• Privacy notices (Articles 13–14) — user-facing information written for how your AI product actually uses data, including, where you rely on it, the enhanced transparency the EDPB associates with a legitimate-interest basis for AI models.
• Data-processing agreements (Article 28) — the contracts your enterprise customers and vendors will require, governing processing carried out on their behalf. Enterprise buyers increasingly won’t sign without a DPA that fits an AI use case.

Where processing is likely to result in a high risk to individuals — often the case for AI involving large-scale or sensitive data, or automated decisions — the GDPR requires a Data Protection Impact Assessment (Article 35) before you start. It’s both an obligation and a useful forcing function for the analysis in steps 01–03.

Finally, keep the two regimes aligned. The EU AI Act governs the AI system; the GDPR governs the personal data that system uses. They overlap but aren’t the same, and AI products usually need both — so the smart move is to make your AI-governance and data-protection workstreams consistent rather than running them in separate silos that contradict each other.