Lawful Bases for AI Processing Under GDPR

The development and deployment of Artificial Intelligence (AI) systems within the European Union operates under a strict legal dualism. On one hand, the desire to foster innovation and adopt transformative technologies drives policy; on the other, the fundamental right to data protection, enshrined in the Charter of Fundamental Rights of the EU, acts as a non-negotiable boundary. For engineers, data scientists, legal counsel, and compliance officers, the intersection of AI and the General Data Protection Regulation (GDPR) is not merely a theoretical exercise—it is the operational reality of the European digital market. The core of this reality is the concept of lawful basis. Before a single byte of personal data is used to train, fine-tune, or infer from an AI model, there must be a valid legal justification for that processing activity.

Understanding lawful bases is not simply about ticking a box on a consent form. It requires a deep analysis of the data lifecycle, the nature of the data subjects, the specific purpose of the processing, and the technical architecture of the AI system. The GDPR provides six lawful bases in Article 6, but for AI systems, the landscape is dominated by two primary contenders: Consent and Legitimate Interest. However, the application of these bases to the unique characteristics of machine learning—specifically the ingestion of vast, unstructured datasets and the generation of predictive outputs—creates complex compliance hurdles that differ significantly across Member States and supervisory authorities.

The Hierarchy and Nature of Lawful Bases

It is a common misconception that the six lawful bases in Article 6(1) GDPR are interchangeable. The regulation establishes a hierarchy, though it is not strictly ranked by preference. The most critical distinction is that the lawful basis must be chosen at the time of the *initial* processing determination. For AI developers, this means that before scraping data, before purchasing a dataset, or before asking users to upload documents for analysis, the specific legal ground must be identified and documented.

The six bases are:

1. Consent: The data subject has given clear, affirmative agreement.
2. Contract: Processing is necessary to fulfill a contract with the data subject or to take steps at their request prior to entering into a contract.
3. Legal Obligation: Processing is necessary to comply with a legal obligation (e.g., tax laws).
4. Vital Interests: Necessary to protect the life of the data subject.
5. Public Task: Necessary for the performance of a task carried out in the public interest or in the exercise of official authority.
6. Legitimate Interests: Necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject.

For AI systems, Contract is often too narrow, Legal Obligation is rare, and Vital Interests or Public Task are context-specific. Therefore, the vast majority of commercial AI processing relies on either Consent or Legitimate Interest. The choice between them dictates the scope of the AI system, the data sources permissible, and the rights of the data subject.

Consent: The High Bar of Voluntariness

When relying on consent under Article 6(1)(a), the standard set by the European Data Protection Board (EDPB) is exceptionally high. For AI systems, this is often the most difficult basis to justify, yet it is frequently the first one considered by marketing teams.

Specificity and Granularity

Consent must be specific to a particular processing purpose. In the context of AI, this creates a significant friction with the technology’s nature. Machine learning models often ingest data to learn general patterns, rather than to perform a single, defined task. If a user consents to “improving our services,” is that sufficient to cover the ingestion of their emails to train a Large Language Model (LLM)? The prevailing guidance suggests it is not. The consent must be granular enough to allow the data subject to understand exactly what data is being used for what AI-driven outcome.

Furthermore, the purpose limitation principle intersects here. Data collected for one purpose (e.g., customer support chat logs) cannot simply be repurposed for a different AI model (e.g., sentiment analysis for sales) without renewed consent, unless the new purpose is compatible with the original one—a determination that is rarely straightforward in AI development.

Freely Given and Withdrawable

Consent is invalid if there is a “clear imbalance” between the data subject and the controller, or if the consent is a condition for accessing a service. For AI systems used in employment contexts or essential public services, relying on consent is legally precarious. The EDPB has clarified that consent must be as easy to withdraw as it was to give. For an AI model that has already been trained on personal data, withdrawing consent poses a technical paradox: you cannot “untrain” a model. This necessitates technical measures to exclude the data subject’s data from future inferences or retraining cycles, which adds architectural complexity.

Legitimate Interest: The Flexible but Risky Alternative

Article 6(1)(f) allows processing if it is necessary for the legitimate interests of the controller or a third party. This is often the most appropriate basis for AI development, particularly for internal R&D, fraud detection, or network security. However, it is not a blanket exemption. It requires a rigorous Legitimate Interest Assessment (LIA), often referred to as a three-part test.

1. The Purpose Test

The interest pursued must be legitimate. For AI, this is usually easy to establish: improving service efficiency, detecting fraudulent patterns, or optimizing logistics are recognized legitimate interests.

2. The Necessity Test

Is the processing necessary to achieve that purpose? This is where AI practitioners often stumble. If you can achieve the same result with less invasive means (e.g., using anonymized data or synthetic data), processing personal data is not “necessary.” Regulators will ask: Why do you need personal data to train this model? If the model is predicting house prices, why does it need the names and addresses of previous buyers? If the AI is detecting fraud, why does it need to retain the full text of non-fraudulent emails indefinitely? The necessity test forces a minimization of data that often conflicts with the “more data is better” mindset of data science.

3. The Balancing Test (The Rights and Interests Assessment)

This is the most contentious part of the LIA. The controller must weigh their interests against the data subject’s fundamental rights and freedoms. If the data subject would not reasonably expect their data to be used in this way, the balancing test often fails.

Expectation: In the context of AI, this is a critical concept. If a user posts on a public forum, they expect the public to read it. Do they expect it to be scraped to train a commercial chatbot? The Google Spain and Facebook rulings indicate that individuals generally do not expect their data to be used for complex profiling or AI training unless explicitly informed. Therefore, controllers relying on legitimate interest must provide transparent information about the AI processing, often triggering the obligation to conduct a Data Protection Impact Assessment (DPIA).

Specific Challenges in AI Data Processing

AI systems introduce technical nuances that standard data processing scenarios do not. The lawful basis chosen must accommodate the lifecycle of the data within the model.

Training Data vs. Inference Data

It is vital to distinguish between data used to train a model (the dataset) and data used to make inferences (the user query).

For training data, the lawful basis must cover the ingestion and storage of that data. If using public web scraping to train an LLM, the controller often relies on Legitimate Interest. However, as seen in the Meta cases regarding the use of public data for AI training, regulators are increasingly skeptical. The “publicly available” nature does not automatically equate to “fair game” for AI training.

For inference data, the lawful basis for processing the user’s input to generate an output is usually Contract (if the user is using the AI service) or Consent (if the processing is optional). However, controllers often want to use inference data to further train the model (a process called “fine-tuning”). This requires a separate lawful basis for that specific retention and processing activity. Relying on the “Contract” basis to use a user’s query to improve the model for future users is legally tenuous; the EDPB suggests this requires Consent or Legitimate Interest, accompanied by a transparent opt-out.

Profiling and Automated Decision-Making

While lawful basis covers the “why” of processing, Article 22 GDPR governs the “how.” If an AI system makes decisions that produce legal effects or significantly affect individuals (e.g., credit scoring, hiring algorithms), the lawful basis of Consent or Contract is generally insufficient to justify the automated decision-making itself. The controller must have a specific legal authorization (often found in national laws) or provide safeguards like human intervention. Relying solely on Legitimate Interest to make significant automated decisions is rarely acceptable under the GDPR.

Documentation and Accountability

Choosing a lawful basis is not enough; it must be proven. The GDPR is a regulation of accountability. If a supervisory authority (SA) investigates, the burden of proof lies with the controller to demonstrate compliance.

Records of Processing Activities (RoPA)

Every AI processing activity must be documented in the RoPA (Article 30). This document must specify the purposes of processing and the legal basis (Article 6). A common pitfall is vague descriptions. Writing “AI Development” is insufficient. It should be specific: “Training of a natural language processing model to categorize customer support tickets using data from Case IDs 100-500 based on legitimate interest (fraud prevention).”

Legitimate Interest Assessments (LIA)

If relying on Article 6(1)(f), the LIA must be documented. This is not a formal document required by the text of the GDPR, but it is the standard expectation of regulators like the CNIL (France) or the ICO (UK). The documentation should show:

• The specific interest pursued.
• The necessity assessment (why personal data is needed).
• The balancing test (why the individual’s rights do not override the interest).

For AI, this documentation often needs to be model-specific. A generic LIA for “all AI development” will likely be rejected.

Data Protection Impact Assessments (DPIA)

Under Article 35, a DPIA is mandatory when processing is likely to result in a high risk to the rights and freedoms of natural persons. The EDPB lists AI systems as a technology requiring a DPIA. Therefore, if you are processing personal data for AI, you almost certainly need a DPIA. The DPIA goes deeper than the LIA, analyzing the proportionality, risks, and mitigation measures (e.g., anonymization, differential privacy). The lawful basis determination is a prerequisite for the DPIA, but the DPIA may actually force a change in the lawful basis if the risks of processing are deemed too high for the chosen basis.

Comparative Approaches Across Europe

While the GDPR is a harmonized regulation, its application varies. Understanding these nuances is crucial for multinational organizations.

The French Approach (CNIL)

The Commission Nationale de l’Informatique et des Libertés (CNIL) is arguably the most active regulator regarding AI. They have issued specific guidance on the use of cookies and trackers, which serves as a proxy for data scraping. The CNIL takes a strict view on Legitimate Interest for advertising and analytics. Regarding AI, they emphasize the purpose limitation heavily. The CNIL has published specific recommendations for generative AI, emphasizing that training on personal data requires a solid legal basis, and that “public data” is not a free-for-all. They are particularly vigilant about the rights of individuals to object to the processing of their public data for AI training.

The German Approach (DSK)

The German data protection authorities, coordinated by the German Data Protection Conference (DSK), are known for their rigorous technical interpretations. In Germany, the concept of Profiling is viewed with extreme caution. German authorities often require very detailed transparency information when AI is used. If relying on Legitimate Interest, the privacy notice must explicitly state the existence of the processing and the logic involved, allowing the data subject to effectively exercise their right to object. The German approach often emphasizes the “data minimization” principle, pushing developers to prove why they cannot use anonymized data for training.

The Irish Approach (DPC)

The Office of the Data Protection Commission (DPC) in Ireland is the lead supervisory authority for many of the world’s largest tech companies. Consequently, their guidance and enforcement actions often set the tone for the EU. The DPC focuses heavily on the transparency of lawful bases. They have issued guidance emphasizing that the “legitimate interests” basis cannot be used if the processing is unexpected. For AI, this means that if a user interacts with a chatbot, the controller cannot later claim Legitimate Interest to train a separate model on that conversation without clear, upfront transparency. The DPC is also very active in cross-border cooperation, often leading inquiries that affect the entire EU market.

Practical Pitfalls and Remediation

In practice, organizations often encounter specific pitfalls when applying lawful bases to AI. Identifying these early can prevent enforcement actions and costly remediation.

Pitfall 1: The “Consent-Legitimate Interest” Hybrid

It is legally impossible to rely on both Consent and Legitimate Interest for the *same* processing activity. You cannot ask for consent and then, if the user refuses, switch to legitimate interest. This is known as “consent washing.” If a user objects to processing based on legitimate interest, the controller must stop, unless they can demonstrate compelling legitimate grounds that override the objection. However, if the basis is Consent, an objection (withdrawal) is absolute regarding that specific processing.

Pitfall 2: Legacy Data and “Data Debt”

Many organizations have accumulated vast archives of data before the GDPR was enforced or before they considered AI. Relying on this “legacy data” for AI training is a minefield. If the original collection lacked a lawful basis compatible with AI training, the data cannot be used. Organizations often try to rely on Legitimate Interest for this legacy data, but the “Expectation” test usually fails. The data subject never expected their data from 2015 to be used to train a 2024 generative model. The only viable path for legacy data is often a new Consent campaign, which is difficult to execute.

Pitfall 3: The “Necessity” Trap

Data scientists often argue that “more data is always better.” However, the GDPR requires that processing be *necessary*. If a model achieves 95% accuracy with 10,000 records, but 98% accuracy with 1 million records, the additional 990,000 records are not strictly “necessary” for the stated purpose of the processing. Regulators are increasingly challenging the “necessity” of massive datasets, arguing that the marginal gain in performance does not justify the intrusion into privacy rights. This is a fundamental clash between AI engineering best practices and GDPR legal requirements.

Pitfall 4: Ignoring the Right to Object

Under Article 21, data subjects have an absolute right to object to processing based on Legitimate Interest. Many AI systems are designed without a mechanism to handle these objections. If a user objects, the controller must have a technical workflow to flag their data so it is excluded from future training or inference sets. Failing to implement this technical capability renders the reliance on Legitimate Interest unlawful.

Conclusion: The Path Forward

Navigating lawful bases for AI processing requires a multidisciplinary approach. It is not enough to have a legal team draft a privacy policy; the engineering team must build the system to respect the chosen basis, and the product team must design the user interface to support it. The choice between Consent and Legitimate Interest is not a preference but a strategic decision that defines the boundaries of the AI system.

As supervisory authorities refine their guidance, the trend is clear: the “wild west” era of data scraping for AI training is ending. The future of compliant AI in Europe lies in rigorous documentation, a conservative approach to data minimization, and a technical architecture that respects the data subject’s rights from the very first line of code. For professionals in the field, mastering the nuances of Article 6 is not just a compliance task—it is a prerequisite for the sustainable and ethical development of Artificial Intelligence.