General Data Protection Regulation (GDPR)

Consent is the primary lawful basis for AI training on personal data — and it's broken in practice. Most AI training datasets were scraped from the web without any consent mechanism. The "legitimate interests" basis (Art 6(1)(f)) has been claimed by AI companies, but the balance test — controller's interests vs. data subject's fundamental rights — is increasingly difficult to satisfy when the data subject has no awareness their data was used, no ability to opt out of the trained model, and no benefit from the resulting AI system.

The purpose compatibility test creates a fundamental barrier for AI. Data collected for one purpose (e.g., social media posts, public records) cannot simply be repurposed for AI training without assessing compatibility. The GDPR's purpose limitation principle (Art 5(1)(b)) requires that further processing be compatible with the original collection context. Training a language model on social media data collected for content moderation is arguably incompatible — the data subject posted content for social interaction, not for algorithmic training.

"Necessary for a contract" (Art 6(1)(b)) is narrow. AI companies cannot claim that training on user data is "necessary for performance of a contract" unless the service contract explicitly requires such training. Many AI services attempt to bury training consent in Terms of Service, but courts have increasingly found that consent buried in lengthy ToS does not meet GDPR's standard of freely given, specific, informed, and unambiguous consent (Art 4(11)).

AI models infer special category data from non-special-category inputs. A language model trained on publicly available text can infer political opinions, religious beliefs, health status, and sexual orientation from writing style, word choice, and context. The GDPR prohibits processing of these categories without a valid exception — but the prohibition is triggered by the data, not the purpose. If an AI model can output inferences about a person's health or political beliefs, that constitutes processing of special category data, regardless of whether the training data was labeled as such.

The "manifestly made public" exception (Art 9(2)(e)) is the most contested. AI companies argue that data posted publicly on social media is "manifestly made public." Data protection authorities disagree — posting on a platform with privacy settings, or in a semi-public forum, does not constitute making data "manifestly" public in the GDPR sense. The European Court of Justice has indicated that "manifestly" requires a deliberate act by the data subject to make the data public to an indeterminate audience.

The scientific research exception (Art 9(2)(j)) is a potential shield — but it's conditional. AI training can be framed as "scientific research," but the exception requires Union or Member State law as a basis, proportionality, and specific safeguards. Commercial AI development for profit-driven products may not qualify as "scientific research" under the strict interpretation some DPAs advocate.

The right to erasure (Art 17) is technically impossible to fully satisfy for trained AI models. Once personal data has been used to train a neural network, that data is encoded in the model's weights as distributed representations. There is no mechanism to selectively "erase" one individual's contribution from a trained model without retraining from scratch — which may be impossible if the original training data has been modified or is no longer available. The concept of "machine unlearning" is an active research area but remains largely theoretical for production-scale models.

The right of access (Art 15) requires disclosure of "meaningful information about the logic involved." For a deep neural network with billions of parameters, "meaningful information about the logic" is a fundamental challenge. The model's decision logic is distributed across millions of weighted connections. Providing a data subject with "meaningful information" about how an AI system made a decision about them requires explainability techniques (SHAP, LIME, attention visualization) that produce approximations, not ground truth. Whether these approximations satisfy Art 15's "meaningful information" requirement is an open legal question.

Data portability (Art 20) assumes structured, machine-readable personal data. AI training data is often unstructured (text, images, audio). The data subject's right to receive their data "in a structured, commonly used, machine-readable format" presupposes the controller can identify and isolate the subject's data within a training corpus. For web-scraped training datasets, this identification may be infeasible at scale.

The training data compliance burden is enormous. To comply with Art 15-20 rights, an AI developer must be able to: (1) identify which personal data was used in training, (2) locate it within potentially petabyte-scale datasets, (3) determine whether and how it influenced the model, (4) provide meaningful information about the processing logic, and (5) potentially retrain the model to effect erasure. This creates a compliance cost that only the largest, best-resourced companies can absorb.

Art 22 is the most direct AI-relevant provision in the GDPR. It grants a right against solely automated decisions with legal or similarly significant effects. This directly covers AI systems used for credit scoring, hiring, insurance underwriting, benefits determination, and any other decision that materially affects an individual. The "solely" qualifier is critical — if there is meaningful human involvement, Art 22 may not apply. But token human review (rubber-stamping an AI recommendation) likely does not remove the "solely" character.

The right to human intervention creates an operational barrier for AI automation. If an AI system makes decisions with legal effects (e.g., loan denial, job rejection), the controller must provide a mechanism for human review. This means maintaining human reviewers for every automated decision pathway — undermining the cost savings that motivated automation. The EDPB Guidelines on Art 22 clarify that human review must be "meaningful" — the reviewer must have the authority and competence to override the decision, not merely confirm it.

The "right to explanation" debate is unresolved. Art 22 does not explicitly grant a "right to explanation" — but Art 15(1)(h) requires "meaningful information about the logic involved" in automated decision-making, and Recital 71 mentions the right to "an explanation of the decision reached." For complex AI systems (deep neural networks, large language models), providing a meaningful explanation of how the system reached a specific decision is technically challenging. The GDPR creates a legal expectation that AI systems be explainable — which is a structural barrier to deploying opaque models in regulated decision-making contexts.

The interaction with the EU AI Act is critical. The EU AI Act (Regulation 2024/1689) classifies many of the same use cases as "high-risk" (credit scoring, employment, biometric identification) and imposes additional requirements including risk management, data governance, transparency, and human oversight. Where both GDPR and the AI Act apply, controllers face overlapping obligations — see EU AI Act analysis.

Data protection by design is a proactive obligation — not a retroactive fix. AI systems must be designed from the ground up with data protection principles embedded. This means: data minimisation (don't collect more personal data than needed for training), purpose limitation (don't use training data for purposes beyond what was disclosed), and storage limitation (define retention periods for training data). For most AI companies, this requires a fundamental rethinking of how training datasets are constructed and managed.

"State of the art" is a moving target — and it moves toward privacy-preserving AI. Art 25 explicitly references "the state of the art." As privacy-preserving ML techniques mature — federated learning, differential privacy, synthetic data generation, homomorphic encryption — the "state of the art" floor rises. What was compliant in 2018 (raw data training) may not be compliant in 2025 if privacy-preserving alternatives have become commercially viable. Controllers who don't adopt these techniques may face challenges that their data protection by design measures are no longer "state of the art."

Data minimisation conflicts with AI training methodology. AI models generally benefit from more training data, not less. The GDPR's data minimisation principle — collect only what is necessary for the specified purpose — creates tension with the AI development practice of maximizing training corpus size. The resolution: AI developers must define narrow purposes for which specific data is necessary, rather than collecting broadly and hoping the model learns useful patterns.

Most AI systems processing personal data trigger DPIA requirements. Art 35(3)(a) specifically calls out "systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects." This describes the core function of many AI systems — credit scoring, hiring screening, content recommendation, risk assessment. Any AI system that processes personal data to produce decisions about individuals likely requires a DPIA before deployment.

The "new technologies" qualifier is an AI trigger. Art 35 references processing "using new technologies." AI/ML systems processing personal data are universally considered "new technologies" by DPAs. The Article 29 Working Party (now EDPB) explicitly identified AI/ML-based profiling as a DPIA-mandatory scenario in its guidelines.

DPIAs create a documentation and accountability burden that scales with model complexity. A proper DPIA for an AI system requires documenting: what personal data is used, why it's necessary, what risks it poses to individuals, and what mitigations are in place. For a large language model trained on web-scraped data, the "systematic description" of processing may require documenting billions of data points across multiple data sources. The "assessment of necessity and proportionality" requires justifying why this specific data and this specific model architecture are necessary — a question most AI developers have never formally answered.

DPIAs are a pre-deployment gate, not a post-hoc audit. The DPIA must be completed before processing begins. This means AI developers must conduct and document the assessment during the design phase — before training begins on personal data. Companies that have already trained models on personal data without a DPIA are already in violation. The DPIA is also a living document: it must be reviewed and updated when processing changes, which for adaptive AI systems may be continuously.