The General Data Protection Regulation was not written with large language models in mind. When the European Parliament finalised GDPR in 2016, the AI systems in enterprise use were narrow classifiers and rule-based automation — not foundation models trained on billions of data points that can generate synthetic text, make inferences from unstructured data, and produce outputs that affect real people's lives.

Yet GDPR is now the primary legal framework governing how most European organisations use AI. Every AI system that processes personal data — and most of them do — falls squarely within GDPR's scope. And the regulation's principles, which were designed to be technology-neutral, create obligations that are far more demanding in AI contexts than their drafters could have envisaged.

With 18+ years of experience in AI governance, information security, and data protection — and having worked alongside DPOs navigating this intersection across financial services, healthcare, and technology sectors — I've developed a clear picture of where GDPR creates the most acute challenges for AI systems, and what genuinely good compliance looks like in practice.

This guide is written specifically for Data Protection Officers, AI governance professionals, and senior compliance leaders who need to move beyond surface-level GDPR understanding to genuinely govern AI processing in their organisations.

Why GDPR and AI Are Inseparable

The relationship between GDPR and AI is not an edge case or a specialist concern — it is the central compliance question for any organisation deploying AI that interacts with, affects, or processes information about people in the European Economic Area.

The Personal Data Definition Is Broader Than Most Organisations Realise

GDPR's definition of personal data — "any information relating to an identified or identifiable natural person" — is expansive and continues to be interpreted broadly by data protection authorities. In AI contexts, this creates scope that extends well beyond names and email addresses:

  • Inferred data — data that AI systems generate about individuals through inference (predicted creditworthiness, inferred health conditions from wearable data, inferred emotional state from voice analysis) is personal data even if it was never directly collected
  • Anonymised training data — data used to train AI models that was believed to be anonymised may retain the status of personal data if the model can be used to re-identify individuals through membership inference attacks
  • Derived data — outputs of AI systems that describe or profile individuals (customer segments, risk scores, behavioural predictions) are personal data
  • Metadata and behavioural traces — interaction data, click patterns, session metadata, and device fingerprints used as AI model inputs are personal data
⚖️
The Anonymisation Problem
One of the most significant GDPR compliance risks in AI is the assumption that anonymisation removes data from GDPR scope. The regulation requires anonymisation to be truly irreversible — meaning the data cannot be re-identified by any means reasonably likely to be used by anyone. Modern AI techniques (membership inference attacks, model inversion, linkage attacks on supposedly anonymous datasets) mean that what organisations classify as anonymised data frequently retains a higher re-identification risk than they appreciate. The ICO and EDPB have both emphasised that mere pseudonymisation does not constitute anonymisation and that AI systems trained on pseudonymised data remain in GDPR scope.

GDPR's Territorial Reach in AI Contexts

GDPR applies extraterritorially under Article 3 — it governs the processing of personal data of EU residents by organisations anywhere in the world, where that processing relates to offering goods or services to EU residents, or monitoring their behaviour within the EU. For AI systems, this means:

  • A US AI company whose model is used to assess EU customers' creditworthiness is subject to GDPR for that processing
  • An Indian technology company training AI models on datasets that include EU resident data must comply with GDPR for that training activity
  • A GDPR-compliant European organisation using a third-party AI API (even a US-based API) remains the controller for the personal data it submits to that API

Lawful Basis for AI Processing — The DPO's First Challenge

Before any AI system processing personal data can operate lawfully under GDPR, a valid lawful basis must be identified for each processing activity. In AI contexts, this is considerably more complex than most organisations initially appreciate.

The Six Lawful Bases and Their AI Applicability

Lawful BasisAI ApplicabilityKey Limitations in AI Context
Consent (Art. 6(1)(a)) Can be used for AI processing where genuinely free, specific, informed, and unambiguous Consent obtained for one AI purpose cannot be recycled for different AI uses. Difficult to obtain granular consent for complex AI inference chains. Cannot be relied upon where a power imbalance exists (employee AI monitoring).
Contract (Art. 6(1)(b)) Applies where AI processing is genuinely necessary for contract performance — e.g., fraud detection in a payment service "Necessary" is interpreted strictly — AI-powered personalisation or profiling is rarely truly necessary for contract performance. Cannot be used as a proxy for consent.
Legal Obligation (Art. 6(1)(c)) Where AI processing is required by law — e.g., AI-based AML transaction monitoring The legal obligation must be specific and clearly require the processing. Cannot manufacture legal obligation where it does not exist.
Vital Interests (Art. 6(1)(d)) Limited to life-or-death situations — e.g., AI-assisted emergency dispatch systems Very narrow scope. Cannot be used for commercial AI processing even where health-related data is involved.
Public Task (Art. 6(1)(e)) Public sector AI — e.g., AI in benefits assessment, public health monitoring Must be laid down in EU or Member State law. The AI Act imposes additional requirements on high-risk public sector AI.
Legitimate Interests (Art. 6(1)(f)) Most commonly relied upon for commercial AI — analytics, personalisation, fraud detection, recommendation systems Requires a three-part balancing test: legitimate interest exists, processing necessary for that interest, interest not overridden by data subject's rights. For AI systems that profile, monitor, or make significant inferences, the balancing test frequently does not favour the controller. Cannot be relied upon by public authorities.
⚠️
The Legitimate Interests Trap
Legitimate interests (Art. 6(1)(f)) is the most frequently misused lawful basis for AI processing. Organisations invoke it as a catch-all for AI use cases where consent would be difficult to obtain, without conducting a genuine Legitimate Interests Assessment (LIA). The EDPB and several national DPAs have been clear that legitimate interests requires a documented balancing test — and for AI systems that generate significant inferences, make automated decisions, or create detailed profiles, that test frequently does not satisfy the condition that the legitimate interest is not overridden by data subjects' fundamental rights.

Layered Processing Activities Require Layered Lawful Bases

AI systems rarely involve a single processing activity. A customer-facing AI assistant might involve: (1) collecting conversational data, (2) processing it through a language model, (3) storing interaction history for personalisation, (4) using aggregated data to improve the model, (5) sharing anonymised data with a third-party model provider. Each of these is a distinct processing activity that requires its own lawful basis. DPOs must map the full AI processing chain, not just the customer-facing interaction, to ensure each stage has a valid legal foundation.

Data Minimisation, Purpose Limitation, and AI's Appetite for Data

Two of GDPR's core data quality principles — data minimisation (Article 5(1)(c)) and purpose limitation (Article 5(1)(b)) — are placed under acute tension by AI systems' characteristic demand for large, diverse training datasets and their tendency to find unexpected uses for data collected for other purposes.

Data Minimisation in Practice

Data minimisation requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed." For AI systems, this creates a genuine tension: AI models frequently perform better with more data, and data scientists are naturally inclined to include more features and more training examples rather than fewer.

DPOs must engage with data science teams at the point of model design — before training data is assembled — to challenge whether each data field is genuinely necessary. Specific questions to ask include:

  • What is the minimum feature set that achieves acceptable model performance? Have we tested performance with a reduced feature set?
  • Are any features serving as proxies for protected characteristics (e.g., postcode as a proxy for ethnicity)?
  • Could synthetic data or privacy-preserving techniques (federated learning, differential privacy) achieve comparable performance with reduced personal data processing?
  • What is the minimum training dataset size that achieves target performance? Is the full historical dataset genuinely needed?

Purpose Limitation and AI's Secondary Uses Problem

Purpose limitation prohibits using personal data for purposes that are incompatible with the original collection purpose. AI creates a systemic secondary uses problem: data collected for customer service is used to train sentiment analysis models; data collected for fraud detection is used to build marketing propensity models; data from HR systems is used to train productivity AI. Each of these secondary uses requires either a compatible purpose determination or a fresh lawful basis.

Compatible Purpose Assessment (Art. 6(4) GDPR)
When personal data is to be used for a purpose other than that for which it was originally collected, Article 6(4) requires a compatibility assessment considering: the link between original and new purpose; the context and reasonable expectations of data subjects; the nature of the data; possible consequences of the further processing; and the existence of appropriate safeguards. For AI training on repurposed data, DPOs must conduct and document this assessment before training begins.

Conducting DPIAs for AI Systems

Article 35 GDPR requires a Data Protection Impact Assessment (DPIA) where processing is "likely to result in a high risk to the rights and freedoms of natural persons." AI systems characteristically present exactly the risk factors that trigger this requirement.

When Is a DPIA Required for AI?

The EDPB's guidelines on DPIAs (WP 248 rev.01) identify specific criteria, and most significant AI deployments meet multiple triggers:

  • Systematic and extensive profiling: AI that profiles individuals for any purpose — customer segmentation, creditworthiness, risk scoring, behavioural targeting
  • Processing of special category data at scale: AI using health, genetic, biometric, racial, political, or similar data
  • Automated decision-making with significant effects: Any AI system that makes or materially influences decisions about people — hiring, lending, insurance, healthcare, law enforcement
  • Systematic monitoring of publicly accessible areas: AI-powered video surveillance, social media monitoring, location tracking
  • Use of innovative technology: AI itself, particularly generative AI and large language models, qualifies as "innovative technology" triggering DPIA obligation
  • Data processing preventing data subjects from exercising a right or using a service: AI gatekeeping — access to platforms, services, or opportunities based on AI assessment

The AI DPIA — What It Must Address

A GDPR DPIA for an AI system must go beyond a standard DPIA template. It requires engagement with AI-specific risk dimensions that conventional DPIA processes were not designed to assess:

Step 1
Systematic Description of Processing
Describe the AI system's inputs, processing logic, outputs, and downstream effects. This must cover the full AI lifecycle — data collection, preprocessing, training, deployment, inference, feedback loops, and model updates.
  • Document all personal data inputs: source, categories, volume, retention
  • Describe model architecture at a level sufficient for a privacy professional to understand (not full technical specification, but enough to assess risks)
  • Map all outputs and how they are used — both direct outputs and derived inferences
  • Identify all entities who access the AI outputs and for what purposes
Step 2
Necessity and Proportionality Assessment
Evaluate whether the AI processing is necessary for the stated purpose and proportionate to the benefits sought. Many AI deployments fail this test when examined rigorously.
  • Confirm lawful basis for each processing activity in the AI chain
  • Demonstrate data minimisation — test and document that the personal data used is the minimum necessary
  • Assess purpose limitation — are all uses of the data consistent with the collection purpose?
  • Evaluate retention — what happens to personal data after model training? After deployment? When the model is decommissioned?
Step 3
AI-Specific Risk Assessment
Identify and assess risks that are specific to AI processing — beyond the standard security and confidentiality risks addressed in conventional DPIAs.
  • Bias and discriminatory outcomes: Has the model been tested for performance disparities across demographic groups?
  • Re-identification risk: Can the model be used to infer or reconstruct personal data about training subjects?
  • Inference of special category data: Can the model infer health, racial, political, or other special category information not explicitly provided?
  • Automated decision-making risk: Does the AI output constitute a solely automated decision with significant effect under Article 22?
  • Explainability gap: Can the AI's decisions or outputs be explained in terms meaningful to affected data subjects?
  • Feedback loop risk: Does the AI system learn from its own outputs in ways that could amplify biases or errors over time?
Step 4
Measures to Address Risks and Residual Risk Determination
Document the measures taken to mitigate each identified risk and assess whether residual risk is acceptable. If residual risk remains high, prior consultation with the supervisory authority (Article 36) is mandatory.
  • Technical measures: anonymisation, pseudonymisation, differential privacy, access controls, audit logging
  • Organisational measures: human review procedures, bias monitoring, model performance auditing, data subject rights procedures
  • Contractual measures: processor agreements, vendor AI governance requirements
  • Document residual risk and obtain DPO sign-off and management acceptance
  • If high residual risk: consult supervisory authority before deployment
🔄
DPIAs Are Living Documents for AI
A DPIA conducted at the point of AI system deployment does not remain valid indefinitely. AI systems change — models are retrained, features are added, use cases expand, adversarial techniques evolve. DPOs should establish a DPIA review trigger that requires reassessment when: the model is significantly retrained; new data sources are added; the AI system's outputs are used for new purposes; significant bias or performance disparities are detected; a personal data breach involving the AI system occurs; or relevant regulatory guidance changes. The ICO recommends treating AI DPIAs as continuous governance documents, not one-time compliance exercises.

Automated Decision-Making and Article 22 — The Critical Battleground

Article 22 GDPR is arguably the most consequential provision for AI compliance, and it is the one where regulatory enforcement has been most active. It provides data subjects with the right not to be subject to a decision based solely on automated processing — including profiling — that produces legal or similarly significant effects.

What Constitutes a "Solely Automated" Decision?

The EDPB's Guidelines on Automated Individual Decision-Making and Profiling (WP 251 rev.01) take a broad and practically significant view of what constitutes "solely automated" processing:

  • A human reviewer who simply rubber-stamps an AI recommendation without genuinely assessing the individual case is not a meaningful human intervention — the decision remains "solely automated"
  • A process where humans review AI outputs but cannot override them (or in practice never do) is effectively automated decision-making
  • A system where the AI decision is made first and human review is only available on appeal does not satisfy the human oversight requirement during initial decision-making
⚖️
The "Human in the Loop" Illusion
One of the most common GDPR compliance failures in AI deployment is the "human in the loop" illusion — where organisations design a nominal human review step to avoid the Article 22 prohibition, but in practice the human reviewer has no meaningful ability to assess the AI's decision. Regulators and courts are increasingly scrutinising whether human oversight is genuine. In the Schufa credit scoring cases before the Court of Justice of the EU (2023), the CJEU ruled that automated credit scoring that decisively influences a human decision constitutes automated decision-making under Article 22 — even where a human takes the final action. DPOs must assess whether their human review processes are genuinely meaningful or merely decorative.

When Article 22 Applies — and When It Doesn't

Article 22(1) prohibits solely automated decisions producing "legal or similarly significant effects." Understanding the scope is critical:

  • Legal effects: AI decisions that affect legal rights — contract formation, insurance coverage, visa applications, loan approvals, legal aid eligibility
  • Similarly significant effects: AI decisions that "significantly affect" an individual — hiring or job shortlisting, credit scoring, insurance premium determination, medical diagnosis assistance, parole decisions, child welfare risk scoring
  • Not in scope: Low-stakes personalisation (recommendation engines, content curation without significant effects), spam filtering, minor user experience adjustments

The Three Exemptions Under Article 22(2)

Solely automated decisions are only permitted under three exceptions. DPOs must confirm which exception applies and ensure the associated safeguards are in place:

  1. Contract necessity (Art. 22(2)(a)): The decision is necessary for entering into or performance of a contract with the data subject — and safeguards including the right to obtain human intervention, express views, and contest the decision are implemented
  2. Legal authorisation (Art. 22(2)(b)): Authorised by EU or Member State law, with appropriate safeguards
  3. Explicit consent (Art. 22(2)(c)): The data subject has given explicit consent — and the same safeguards (human intervention, right to express views, right to contest) are implemented

Note that the first and third exceptions require suitable safeguards including at minimum: the right to obtain human intervention; the right to express the data subject's point of view; and the right to contest the decision. Many organisations implementing AI decisions under these exceptions fail to operationalise these safeguards in a meaningful way.

Transparency and Explainability in AI Systems

GDPR's transparency requirements — Articles 13, 14, and 15 — require controllers to provide meaningful information about automated decision-making, including "meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing" for the data subject.

The Explainability Gap

The "meaningful information about the logic involved" requirement is where GDPR creates the most acute tension with complex AI systems. Neural networks, gradient boosting ensembles, and large language models are not inherently explainable in terms that are meaningful to a non-technical data subject. This creates a fundamental conflict between model complexity (which often improves performance) and GDPR transparency obligations.

The EDPB and national DPAs have been clear that "meaningful information" does not require full technical disclosure of model weights or architecture — but it does require more than generic statements like "an automated system assessed your application." Meaningful information must be:

  • Specific to the individual's situation, not just a generic description of the AI system
  • Sufficient for the data subject to understand why the decision was reached
  • Comprehensible to a non-technical person
  • Actionable — i.e., it gives the data subject information they could use to contest the decision or improve their outcome

Practical Explainability Approaches for DPOs

DPOs should engage with data science teams to ensure that explainability capabilities are built into AI systems at design time — not retrofitted after deployment. Workable approaches include:

  • Local explanations using SHAP or LIME: Generate individual-level explanations showing which features most influenced the model's output for a specific individual — expressible in plain language ("Your application was assessed based primarily on your payment history (40%), income-to-debt ratio (25%), and length of credit history (20%)")
  • Counterfactual explanations: Explain what would have needed to be different for a different outcome — highly actionable for data subjects ("Your application would have been approved if your outstanding debt had been below £15,000")
  • Simplified model surrogates: Train an interpretable model (decision tree, linear model) to approximate the complex model's decisions — enabling rule-based explanations for individual cases
  • Human-readable decision factors: For high-risk AI systems, require data scientists to define the top factors for each decision and express them in plain language in the output

Data Subject Rights in AI Environments

Every GDPR data subject right creates specific operational challenges in AI environments that go beyond their implementation in conventional data systems.

RightAI-Specific ChallengeDPO Action Required
Right of Access (Art. 15) Data subjects are entitled to a copy of their personal data — but what does "their data" mean for an AI system that processed it and generated inferences? The AI's outputs (scores, predictions, categories) about the individual are also their personal data and must be disclosed. Ensure Subject Access Request processes capture not just raw input data but all AI-generated inferences, scores, predictions, and profiles about the individual. System architecture must support this retrieval.
Right to Erasure (Art. 17) "Right to be forgotten" in AI contexts raises fundamental questions: if an individual's data was used in model training, can they be erased from a trained model? Machine unlearning is computationally expensive and not always fully effective. Implement technical measures to identify individuals' data in training sets; assess machine unlearning feasibility; document retention policy for training data; ensure trained model outputs referencing identifiable individuals can be deleted from storage.
Right to Rectification (Art. 16) If inaccurate data was used in AI training, rectification of the stored data does not change the model trained on the inaccurate version. Inaccurate inferences generated by AI about an individual are also subject to rectification. Establish processes to correct input data in storage AND flag or retrain models where correction affects their outputs. Document how AI-generated inferences are updated when underlying data is corrected.
Right to Object (Art. 21) Where legitimate interests is the lawful basis for AI processing, data subjects can object to processing of their personal data. The controller must cease processing unless it can demonstrate compelling legitimate grounds that override the individual's interests. Maintain a register of data subjects who have exercised their right to object; ensure AI systems can exclude opted-out individuals from processing; document the compelling legitimate grounds assessment for each case where objection is overridden.
Right to Explanation (Art. 22(3)) Where an automated decision falls under Article 22, data subjects have the right to obtain human intervention, express their point of view, and contest the decision. This requires operational procedures, not just a policy statement. Implement accessible, timely procedures for human review requests; train staff who conduct reviews to genuinely assess cases independently; document outcomes of human review challenges and use them to improve AI system accuracy.
Right to Data Portability (Art. 20) Data subjects can request their data in a structured, commonly used, machine-readable format where processing is based on consent or contract and carried out by automated means. This includes AI-generated profiles and outputs. Ensure AI system architecture supports export of individual data and AI-generated outputs in structured format; define what constitutes "personal data processed by AI" for portability purposes in your RoPA.

Special Category Data in AI Training and Inference

Article 9 GDPR imposes significantly higher standards for processing special category data — health, genetic, biometric, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sexual orientation or sex life data. AI creates two distinct special category risks: explicit processing (using special category data as training inputs) and inference risk (where AI systems infer special category data from non-special category inputs).

Explicit Special Category Processing in AI

Many high-value AI use cases necessarily involve special category data: medical diagnosis AI, clinical decision support, insurance underwriting AI using health data, HR AI using disability information, recruitment AI that may process photographs (which can infer racial origin and health conditions). For these systems:

  • One of the Article 9(2) conditions must be met — commonly explicit consent (9(2)(a)), vital interests (9(2)(c)), medical purposes (9(2)(h)), or public interest in public health (9(2)(i))
  • Many Article 9(2) conditions require additional safeguards: professional secrecy obligations, national law authorisation, or binding internal rules
  • A DPIA is almost always required — special category data is one of the explicit triggers for mandatory DPIA under EDPB guidance

AI Inference Risk — The Hidden Special Category Problem

A more insidious risk arises when AI systems infer special category data from non-special category inputs. Research and regulatory guidance have identified numerous examples:

  • Voice analysis AI that infers health conditions (Parkinson's disease, depression, anxiety) from speech patterns — with no health data explicitly provided
  • Facial recognition AI that can infer racial or ethnic origin, age, and potentially health conditions from images
  • Purchase history AI that infers pregnancy, health conditions, or religious dietary requirements from buying patterns
  • Location data AI that infers religious beliefs from attendance at places of worship
  • Social media analysis AI that infers political views or sexual orientation from content interactions

DPOs must assess not just what data goes into AI systems, but what special category inferences the AI's outputs effectively constitute — and whether appropriate Article 9 grounds exist for those inferences.

Governing Third-Party AI — Processor Agreements and Vendor Risk

Most organisations do not build their own AI systems from scratch. They use third-party AI APIs (OpenAI, Anthropic, Google Gemini, Azure OpenAI), AI-embedded SaaS platforms (Salesforce Einstein, ServiceNow AI, HubSpot AI), and AI tools purchased from specialist vendors. The GDPR controller/processor framework applies — and creates specific obligations.

Controller vs. Processor in Third-Party AI

Determining whether a third-party AI provider is a processor (acting under the controller's instructions) or an independent controller (processing for its own purposes) is one of the most practically important and frequently misunderstood questions in AI GDPR compliance:

  • Processor: An AI vendor that processes personal data only to provide services to the customer and does not use it for its own purposes (model training, product improvement, data monetisation) is a processor. A Data Processing Agreement (DPA) under Article 28 is mandatory.
  • Controller: If the AI vendor also processes the submitted data for its own purposes — model training, service improvement, safety evaluation, aggregated analytics — it is processing as a controller for those additional purposes. The DPA covers the processor relationship; the vendor's own processing requires its own lawful basis.
  • Joint controllers: Where both parties determine the purposes and means of processing — for example, where a joint AI model is trained on both parties' data for mutual benefit — joint controllership under Article 26 may apply, requiring a documented joint controller arrangement.
🤝
The AI API Data Processing Agreement — What DPOs Must Check
When deploying AI APIs, DPOs should verify that vendor DPAs explicitly address: (1) Prohibition on using submitted personal data for model training without explicit opt-in consent from the controller; (2) Data residency — where personal data is processed and stored; (3) Sub-processor chain — which third parties the AI vendor further shares data with; (4) Deletion obligations — when submitted data is deleted (during inference? after some retention period?); (5) Security measures appropriate to the sensitivity of the personal data submitted; (6) Breach notification timelines; (7) Audit rights for the controller to verify compliance. Most AI API vendors have DPAs — but many have terms that permit broad use of submitted data for model improvement, which may conflict with GDPR obligations.

International Transfers in AI Processing

Using AI APIs from US-based vendors (OpenAI, Anthropic, Google, Microsoft Azure in non-EU regions) involves international transfers of personal data. These require a valid transfer mechanism under Chapter V GDPR:

  • Adequacy decision: The EU-US Data Privacy Framework (2023) provides an adequacy basis for transfers to certified US organisations. Verify vendor certification at the DPF website before relying on this basis.
  • Standard Contractual Clauses (SCCs): The 2021 SCCs are included in most major AI vendor DPAs — but must be paired with a Transfer Impact Assessment (TIA) evaluating whether the destination country's laws undermine the protection the SCCs provide.
  • Binding Corporate Rules (BCRs): For transfers within a corporate group, BCRs may provide the transfer mechanism.

GDPR and the EU AI Act — Navigating the Overlap

The EU AI Act entered into force in 2024 and is progressively applying through 2027. DPOs now operate in an environment where two major EU regulatory instruments apply simultaneously to many AI systems — and their requirements interact in ways that create both compliance synergies and potential tensions.

Where They Overlap

AreaGDPR RequirementEU AI Act RequirementIntegrated Approach
Risk Assessment DPIA for high-risk processing (Art. 35) Risk management system for high-risk AI (Art. 9) Design a combined AI Impact Assessment that satisfies both DPIA and AI Act risk management requirements in a single exercise
Transparency Meaningful information on automated decisions (Art. 13–15, 22) Technical documentation and instructions for use; transparency for limited-risk AI (Art. 13) Unified transparency framework covering both data subject information (GDPR) and technical disclosure (AI Act)
Human Oversight Human intervention for Article 22 automated decisions Human oversight measures for high-risk AI (Art. 14) Design human oversight that satisfies Art. 22 GDPR safeguards AND Art. 14 AI Act requirements simultaneously
Data Governance Data quality, minimisation, accuracy principles (Art. 5) Data governance for training, validation, testing datasets (Art. 10) Single data governance framework covering GDPR data quality principles and AI Act dataset requirements
Fundamental Rights Balancing test for legitimate interests; prohibition on discriminatory processing Fundamental Rights Impact Assessment (FRIA) for public sector high-risk AI (Art. 27) Combined assessment addressing both GDPR legitimate interests balancing and AI Act fundamental rights impact

Where They Differ — and Can Create Tension

  • Biometric data: GDPR prohibits processing biometric data for identification purposes unless an Article 9(2) exception applies. The EU AI Act also prohibits certain real-time biometric identification in public spaces — but permits others with authorisation. Compliance with the AI Act does not automatically satisfy GDPR's stricter Article 9 requirements.
  • AI Act "new purpose" exception: Article 84 AI Act permits DPAs to take AI Act obligations into account when assessing GDPR violations — but does not override GDPR requirements. An AI system compliant with the AI Act can still violate GDPR.
  • Enforcement bodies: The EU AI Act is enforced by new national market surveillance authorities, not DPAs. DPOs must manage relationships with two distinct enforcement bodies that may take different views of the same AI system.

Enforcement Lessons — What Regulators Have Signalled

DPA enforcement against AI-related GDPR violations has been escalating since 2020. The following cases illustrate the specific AI processing risks that regulators have prioritised — and the compliance approaches they expect.

🏦
Clearview AI — Multiple DPA Decisions
France (CNIL), Italy (Garante), UK (ICO), Greece, Sweden · 2022–2023
€20M+ Combined Fines Biometric Data · Web Scraping · No Lawful Basis
What Happened
Clearview AI scraped billions of images from the public internet to train a facial recognition AI database, which it sold to law enforcement and commercial clients. Multiple European DPAs found comprehensive GDPR violations: processing biometric data without any valid Article 9(2) condition; no lawful basis for scraping and processing images; failure to provide information to data subjects; failure to respond to access requests; no valid basis for international transfers.
Key Compliance Lessons
  • Public availability of data does not constitute consent or legitimate interest for AI training on facial images — the "scraping is lawful" assumption is false
  • Facial recognition AI processing biometric data requires an Article 9(2) condition — no commercial purpose satisfies this requirement without explicit consent
  • Data subjects' rights (access, erasure, objection) must be operationally implementable — not just stated in a privacy policy
  • Enforcement is coordinated across EU DPAs through the EDPB's consistency mechanism — violations of AI systems affecting multiple EU countries can attract multiple simultaneous fines
⚖️
Schufa / Automated Credit Scoring — CJEU Ruling
Court of Justice of the European Union · December 2023
Landmark Ruling Article 22 · Automated Decision-Making Credit Scoring · Profiling
What Happened
The Court of Justice of the EU ruled in joined cases (C-634/21; C-26/22 and C-64/22) that automated credit scoring by credit reference agencies constitutes automated decision-making under Article 22 GDPR — even where the final credit decision is taken by a human at the bank, if that score decisively influences the credit decision. The ruling has profound implications for any organisation relying on AI scores, risk ratings, or automated assessments that are then used by a human decision-maker.
Key Compliance Lessons
  • Article 22 applies where an AI score "decisively influences" a human decision — the human in the loop does not escape GDPR Article 22 obligations if they routinely act on AI outputs without independent assessment
  • Credit scoring, risk scoring, and AI-generated assessments passed to human decision-makers must satisfy Article 22 requirements: lawful basis, safeguards (human intervention, right to express views, right to contest)
  • Meaningful human review means genuine independent assessment — not validation of an AI recommendation
  • Any AI scoring or profiling that decisively influences significant decisions about individuals now requires explicit compliance with Article 22 safeguards
🤖
ChatGPT / OpenAI — Italian Garante Temporary Ban
Italy (Garante) · 2023 · Multiple EU DPAs Ongoing Investigation
Temporary Ban Imposed Generative AI · No Lawful Basis · Age Verification LLM Training Data
What Happened
Italy's data protection authority (Garante) imposed a temporary ban on ChatGPT in March 2023, citing: lack of lawful basis for training data collection; no age verification mechanism to protect minors; insufficient transparency about training data and AI processing; and inadequate information provided to users. OpenAI engaged with the Garante and implemented changes — the ban was lifted in April 2023 — but investigations by multiple European DPAs continue. The case triggered the EDPB's establishment of a dedicated ChatGPT task force coordinating EU-wide investigation.
Key Compliance Lessons
  • Lawful basis for LLM training data is not automatically established by "publicly available" status — each category of training data requires analysis
  • Generative AI must implement age verification or appropriate safeguards where services may be accessed by minors
  • The EDPB's coordinated enforcement approach means that generative AI compliance issues in one EU country can trigger simultaneous multi-country investigation
  • Responding promptly and substantively to DPA inquiries — and implementing changes — is recognised as a mitigating factor in enforcement outcomes
🏢
Meta — EDPB Binding Decision on Behavioural Advertising AI
Ireland (DPC) / EDPB · 2023 · €1.3 Billion Fine
€1.3 Billion Fine International Transfer · AI Profiling · SCCs Largest GDPR Fine in History
What Happened
The Irish Data Protection Commission, acting on an EDPB binding decision, imposed a €1.3 billion fine on Meta for transferring personal data of EU users to the US without adequate safeguards — relying on Standard Contractual Clauses (SCCs) despite the Schrems II ruling having invalidated the Privacy Shield and raised fundamental questions about SCC adequacy for US transfers. While this case is primarily a transfer mechanism case, it has direct relevance to AI: Meta's AI systems (content recommendation, behavioural advertising, content moderation) process EU personal data and the transfer of that processing to US infrastructure was the subject of enforcement.
Key Compliance Lessons
  • SCCs for international AI processing require a documented Transfer Impact Assessment — SCCs alone are insufficient where receiving country surveillance laws undermine the protection provided
  • The DPF (EU-US Data Privacy Framework, 2023) provides a current adequacy basis for certified US organisations — verify certification before relying on it
  • AI systems that process EU personal data on US infrastructure must have a valid, documented international transfer mechanism
  • EDPB binding decisions apply to the entire EU — DPAs in all member states are bound by EDPB consistency mechanism decisions
💰
Fine: €1.3 billion — the largest GDPR fine ever imposed. Demonstrates that GDPR enforcement against data processing that underpins AI systems is not merely theoretical. The international transfer dimension affects every organisation using US-based AI infrastructure for EU personal data.

GDPR Obligations by Role — Who Does What in an AI Environment

Effective AI GDPR compliance requires coordinated effort across multiple roles. The following matrix clarifies the primary GDPR obligations and AI-specific responsibilities for each key function.

Data Protection Officer (DPO)
The GDPR compliance lead
GDPR Responsibilities
  • Advise on all AI processing activities' GDPR compliance
  • Review and sign off DPIAs for all high-risk AI
  • Monitor compliance with GDPR across AI deployments
  • Act as contact point with DPA
  • Maintain Records of Processing Activities (RoPA) covering AI
AI-Specific Actions
  • Assess lawful basis and DPIA requirements at AI design stage
  • Review AI vendor DPAs for adequacy
  • Advise on Article 22 applicability for each AI system
  • Track DPA AI enforcement guidance and precedent
  • Provide early warning on AI governance gaps
AI Governance Manager
AI risk & governance lead
GDPR Interface
  • Coordinate with DPO on DPIA for each AI system
  • Ensure AI Impact Assessments address GDPR risks
  • Include GDPR requirements in AI governance policies
AI-Specific Actions
  • Integrate GDPR lawful basis check into AI system approval process
  • Ensure transparency requirements are addressed in AI design
  • Maintain AI system inventory with GDPR risk classification
  • Align ISO 42001 AIMS with GDPR obligations
Data Scientist / ML Engineer
AI builder
GDPR Interface
  • Implement data minimisation in feature selection
  • Support DPIA with technical documentation
  • Build explainability capabilities into models
AI-Specific Actions
  • Document training data sources, provenance, and retention
  • Implement bias testing and document results
  • Build SHAP/LIME or counterfactual explanation into model outputs
  • Support deletion/unlearning requests technically
Legal / Compliance
Regulatory interface
GDPR Interface
  • Confirm lawful basis for each AI processing activity
  • Review AI vendor contracts and DPAs
  • Advise on cross-border transfer mechanisms
AI-Specific Actions
  • Advise on EU AI Act / GDPR intersection and joint compliance
  • Negotiate AI API terms to ensure GDPR-compliant processing
  • Support regulatory engagement on AI-related queries
  • Draft AI-specific privacy notices and data subject rights procedures
CISO / Security Team
Technical protection
GDPR Interface
  • Implement technical measures for AI data security (Art. 32)
  • Manage breach notification for AI-related incidents
  • Conduct security assessments of AI vendor infrastructure
AI-Specific Actions
  • Address AI-specific attack vectors: model inversion, membership inference, adversarial inputs
  • Implement Zero Trust controls for AI workloads and data pipelines
  • Assess international transfer security implications for AI APIs

The DPO's AI Governance Action Plan

For DPOs who need to move from awareness to operational action, the following phased plan reflects the priority sequence I recommend based on 18+ years of experience supporting DPOs across complex AI deployments.

Immediate
AI Processing Inventory — Know What You Have
You cannot govern what you cannot see. An accurate inventory of all AI systems processing personal data is the prerequisite for everything else.
  • Survey all business units for AI tools, AI APIs, and AI-embedded SaaS platforms in use — including shadow AI
  • For each AI system, identify: categories of personal data processed; lawful basis claimed; whether outputs constitute automated decisions under Art. 22; whether a DPIA has been conducted
  • Maintain the AI inventory as a living section of your RoPA
  • Flag all AI systems with no documented lawful basis or DPIA as immediate priority items
30–60 Days
Lawful Basis Review and DPIA Gap Assessment
For each AI system identified in the inventory, formally assess and document the lawful basis and determine whether a DPIA is required.
  • Conduct Legitimate Interests Assessments (LIAs) for AI systems relying on Art. 6(1)(f)
  • Assess all AI systems processing special category data for Art. 9(2) compliance
  • Identify all AI systems requiring a DPIA — use EDPB WP 248 rev.01 criteria
  • Prioritise DPIAs for deployed high-risk AI systems (credit scoring, hiring AI, medical AI)
60–120 Days
Article 22 Audit — Human Oversight Reality Check
Assess every AI system making or influencing significant decisions to determine whether Article 22 applies and whether safeguards are genuinely adequate.
  • Map all AI systems producing outputs used in significant decisions affecting individuals
  • For each: assess whether the AI "decisively influences" the decision (applying CJEU Schufa guidance)
  • Audit human review processes — are they genuine independent assessments or rubber-stamping?
  • Implement or improve data subject rights procedures (right to human intervention, to express views, to contest)
Ongoing
Vendor Governance, Explainability, and Continuous Monitoring
Embed AI GDPR compliance into ongoing operations — vendor management, privacy notice updates, data subject rights handling, and DPIA review cycles.
  • Review all AI vendor DPAs and ensure they address the key points in the DPA checklist above
  • Update privacy notices to include specific information about AI processing and automated decisions
  • Implement DPIA review triggers for AI systems (retraining, new data sources, new use cases)
  • Establish explainability requirements as a standard AI procurement criterion
  • Track EDPB AI guidance, DPA enforcement decisions, and CJEU rulings for emerging obligations

Key Takeaways

GDPR in the Age of AI — The DPO's Essential Reference
GDPR applies to almost all AI systems processing personal data. The definition of personal data is broad — inferred data, AI-generated profiles, and scores about individuals are personal data, not just raw input data.
Each AI processing activity needs a valid lawful basis. Legitimate interests requires a documented balancing test — not an assumption. For AI systems that profile, infer, or make significant decisions, this test frequently does not favour the controller.
DPIAs are mandatory for most significant AI deployments. Profiling, special category data, automated decisions, and innovative technology are all explicit DPIA triggers — and most AI systems qualify on multiple grounds.
Article 22 applies more broadly than most organisations realise. Following the CJEU Schufa ruling, AI scores that "decisively influence" human decisions are subject to Article 22 — nominal human review is not sufficient.
The "human in the loop" illusion is a compliance risk. Regulators are scrutinising whether human oversight is genuine. Document how human reviewers are trained, empowered, and actually operate in practice.
AI inference risk is a hidden special category problem. AI systems that infer health, racial, political, or other special category data from non-special category inputs may be processing special category data without Article 9 grounds.
Third-party AI processing requires DPAs that address AI-specific risks. Check vendor DPAs explicitly for training data use, sub-processors, deletion timelines, and international transfer mechanisms — do not assume standard SaaS DPAs cover these points.
GDPR and the EU AI Act are complementary — but distinct. An AI system compliant with the EU AI Act can still violate GDPR. DPOs must assess GDPR compliance independently of EU AI Act compliance.
Enforcement is active, escalating, and coordinated across the EU. The Clearview, Schufa, ChatGPT, and Meta enforcement actions signal the enforcement priorities DPAs will apply to AI — build your compliance program with enforcement-readiness in mind.
Start with the AI processing inventory. Every compliance action in this guide depends on knowing what AI systems process personal data in your organisation. The inventory is the prerequisite — build it first.
JK
Written by Juno David K
Strategic Delivery Leader with 18+ years of experience in AI governance, information security, and data protection program delivery. I've supported DPOs and governance teams across financial services, healthcare, and technology sectors in building GDPR compliance programs that genuinely manage AI processing risk — not just paper compliance.
Discuss GDPR & AI → More Articles