AI and Data Protection: The Legal Challenges in Overview
Artificial intelligence runs on data; data protection law constrains it. From this tension arise concrete legal challenges – set out along the GDPR and the AI Act.
Artificial intelligence runs on data, and data protection law constrains the processing of it. That sentence contains a structural tension: AI systems deliver value the more data they process, while the GDPR demands data minimisation, purpose limitation and storage limitation. Anyone deploying AI in a business therefore operates not in a legal vacuum but at the intersection of two frameworks that apply side by side: the General Data Protection Regulation and the European AI Act. This article sets out the legal challenges along the fields in which they concretely arise – from the legal basis through training data and transparency to automated decisions and risk assessment. It does not replace case-specific legal advice but provides the orientation that should precede an internal policy or guideline.
- Two Legal Regimes, One Set of Facts
- The Legal Basis: No Processing Without Permission
- Training Data and the Myth of Anonymity
- Transparency and the Rights of Data Subjects
- Automated Decisions: Article 22
- When a Data Protection Impact Assessment Becomes Mandatory
- Processing on Behalf and Third Countries with AI Tools
- A Readiness Checklist Before Deploying AI
- Frequently Asked Questions
- Conclusion
Two Legal Regimes, One Set of Facts
The most common point of confusion concerns the relationship between the two frameworks. They pursue different protective aims and attach to different facts, yet they apply in parallel to the same AI deployment. The GDPR protects personal data and thereby the fundamental rights of the data subject; it applies as soon as such data are processed. The AI Act regulates the placing on the market and operation of AI systems by risk class and protects safety, health and fundamental rights against the risks of the technology itself. The following comparison sets out the differences:
| Dimension | GDPR | AI Act |
|---|---|---|
| Protected interest | personal data, fundamental rights of the data subject | safety, health, fundamental rights against AI systems |
| Trigger | processing of personal data | placing on the market and operation of AI systems, by risk class |
| Primary addressee | controllers and processors | providers and deployers of AI systems |
| Application | directly and technology-neutral, since 2018 | staggered since 2024/2025, depending on risk class |
| Relationship | continues to apply unchanged | complements the GDPR, does not replace it |
The AI Act entered into force in 2024 and applies in staggered phases: prohibitions of certain practices and general provisions since early 2025, obligations for general-purpose AI models and the governance structures since mid-2025, and the weighty obligations for high-risk systems last. The precise timeline for these high-risk obligations has recently been the subject of legislative adjustment; the deadlines currently in force should therefore be checked against official sources before any concrete deployment. For most businesses that do not develop AI but use it, the GDPR remains the more immediate yardstick – it applies regardless of risk class as soon as personal data are involved.
For practice, the distinction between provider and deployer is decisive. Those who develop an AI system themselves or place it on the market under their own name bear, as a provider, the more far-reaching obligations of the AI Act. Those who merely use a third-party system are deployers and face leaner but not negligible requirements – for instance regarding use in line with the intended purpose and, for high-risk systems, human oversight. In data protection terms, however, the deployer generally remains a controller within the meaning of the GDPR and thus carries the full weight of the duties set out there – regardless of how the AI Act classifies its role.
The Legal Basis: No Processing Without Permission
Every processing of personal data needs a legal basis under Article 6 GDPR – even when it is carried out by an AI system. This frames one of the most frequent questions: what legal basis supports the AI deployment? The main candidates are consent, performance of a contract and legitimate interest. Each has its pitfalls in the AI context.
Consent must be freely given, informed and for a specific purpose. Specificity in particular is difficult when the later purpose of the data within a complex model cannot be precisely named. Legitimate interest requires a three-step balancing exercise – a genuine, lawful interest, the necessity of the processing, and that interest prevailing over those of the data subject. The European Data Protection Board has confirmed that legitimate interest can, in principle, support processing in the AI context, but has made this dependent on a careful, documented assessment.
A recurring criterion in the balancing is the reasonable expectation of the data subject. Data provided for a particular purpose may not, without more, flow into an AI processing that no one had to anticipate. In the employment context this sharpens: because of the relationship of dependence between employer and employee, consent from employees is regarded as legally problematic, and the use of AI to evaluate staff additionally touches on co-determination questions. The choice of legal basis is therefore not a purely formal but a context-dependent decision.
Special categories of personal data under Article 9 GDPR – health, political opinion, religious belief and others – raise their own barrier. Their processing is in principle prohibited and permitted only under narrow exceptions. Because large datasets often contain such information unintentionally, particular caution is warranted with AI applications: a model that is inadvertently trained on or fed sensitive data may stray into territory for which there is simply no permission.
Training Data and the Myth of Anonymity
May personal data be used to train AI models? The short answer: not without a legal basis and not without observing the principles of Article 5 GDPR. This is where the tension noted at the outset shows most clearly. Purpose limitation requires that data be collected for specified purposes and not reused at will – whereas training a model aims precisely at making data usable beyond their original context. Data minimisation runs counter to the data hunger of large models.
A widespread misconception holds that the problem can be sidestepped through anonymisation. In its Opinion 28/2024 on AI models, the European Data Protection Board made clear that models trained on personal data cannot readily be regarded as anonymous. A model is to be classed as anonymous only when both the likelihood of extracting personal data from the model directly or by statistical means, and the likelihood of obtaining such data through queries, are insignificant. This threshold is high, and supervisory authorities assess anonymity claims case by case, taking into account all the means reasonably likely to be used for identification. The accountability principle of Article 5(2) further implies that the controller must be able to evidence a claimed anonymity.
There is also a knock-on effect that is easily overlooked: unlawful processing in the development phase can carry over to the later operation of the model. If a model was trained on a missing or flawed legal basis, the subsequent use is not automatically cured. A defect at the root can infect the entire processing chain – one more reason to clarify and document the legal basis before training rather than after the fact.
In practice this means: those who use data to train or enrich a model should not hastily deny the personal reference, should determine the legal basis cleanly, and should measure the processing against the principles of purpose limitation and data minimisation – not only in the event of a dispute, but as part of the design.
Transparency and the Rights of Data Subjects
The GDPR requires transparency. Under Articles 13 and 14, data subjects must be informed that and for what purpose their data are processed – including meaningful information about the logic involved in certain automated procedures. With AI systems this duty meets a practical problem: the working of complex models cannot always be explained in a way comprehensible to laypeople without either oversimplifying or touching on trade secrets. The legal requirement nonetheless stands; it calls for an intelligible account of the purpose and the essential logic, not the disclosure of the entire model.
Added to this are the rights of data subjects: access, rectification, erasure and objection. They are especially demanding in the AI context. How does one erase a single person's data from an already trained model? How does one correct an erroneous detail that has flowed into model weights? Satisfactory technical answers do not always exist, yet the legal duty is not waived because implementation is difficult. Those deploying AI must build the fulfilment of these rights in from the start – for instance by separating training and operational data, or through methods that do not permanently anchor a personal reference in the model in the first place.
Automated Decisions: Article 22
Article 22 GDPR deserves particular attention. It gives the data subject the right not to be subject to a decision based solely on automated processing – including profiling – that produces legal effects concerning them or similarly significantly affects them. So what does Article 22 govern? At its core it restricts fully automated decisions with serious consequences and permits them only in certain constellations, such as with explicit consent or on a contractual basis, and then flanked by safeguards such as the right to human intervention.
For AI deployment this is highly relevant, because many attractive use cases – credit scoring, candidate pre-selection, fraud detection – fall precisely into this area. The decisive question is whether a decision is in fact made "solely" automatically. A merely formal involvement of a human who confirms the system's suggestion without their own examination is not enough to leave the scope of the provision. Genuine, substantive human control is both a legal requirement and good practice – and it overlaps with the AI Act's requirements for human oversight of high-risk systems.
When a Data Protection Impact Assessment Becomes Mandatory
Article 35 GDPR requires a data protection impact assessment where processing is likely to result in a high risk to the rights and freedoms of natural persons – in particular where new technologies are used. AI applications that process personal data on a large scale, systematically evaluate data subjects or concern special categories of data regularly meet this threshold. So when is a data protection impact assessment needed? Whenever the risk of the specific application is high; with AI systems, much speaks for carrying one out when in doubt.
The impact assessment is not a formality but a structured process: description of the processing, assessment of necessity and proportionality, analysis of the risks and definition of remedial measures. It ideally dovetails with the risk assessment that the AI Act requires for high-risk systems – both processes examine related risks from different angles and can be aligned rather than run separately.
Processing on Behalf and Third Countries with AI Tools
Most businesses do not develop AI but use third-party services – often cloud-based tools such as large language models. From this follows a practical question: do I need a data processing agreement? As a rule, yes. As soon as an external provider processes personal data on your instructions, Article 28 GDPR requires a data processing agreement as the basis. When entering confidential or personal data into a cloud-based AI tool, it must therefore be clarified in what role the provider acts and whether it in turn uses the entered data for its own purposes – such as training.
Then there is the geographical dimension. If the data leave the European Economic Area, Articles 44 et seq. GDPR on third-country transfers apply, with the familiar requirements of an adequacy decision or appropriate safeguards. Many AI services are operated outside the EU, which is why the server location and the contractual position should be checked before use. The underlying duties for secure and compliant transfer are described in Sending Personal Data Securely: What the GDPR Requires; they apply unchanged when the destination of the transfer is an AI service.
A Readiness Checklist Before Deploying AI
The following short list sums up the data protection points to be clarified before introducing an AI tool. It does not replace a full assessment but orders the most important questions:
- Are personal data processed at all – and can the personal reference be avoided or reduced?
- What legal basis supports the processing, and is the balancing for legitimate interest documented?
- Are special categories of personal data involved, and is there an exception for them?
- Is the transparency duty met and are the rights of data subjects practically workable?
- Is there a solely automated decision within the meaning of Article 22, and is genuine human control ensured?
- Has it been checked whether a data protection impact assessment is required?
- Are a data processing agreement and a sound basis for any third-country transfer in place?
If a point remains open, it belongs resolved before the tool works productively with real data.
Frequently Asked Questions
Is the use of AI compatible with the GDPR? Yes, provided the processing rests on a legal basis, the principles of Article 5 are observed and the rights of data subjects are upheld. The GDPR does not prohibit AI but sets conditions.
May personal data be used for training? Only with a legal basis and in compliance with purpose limitation and data minimisation. Anonymity is not an easy way out, since models trained on personal data cannot readily be regarded as anonymous.
Do I need a data processing agreement for cloud-based AI tools? As a rule yes, as soon as the provider processes personal data on your instructions. It must also be checked whether the provider uses the data for its own purposes.
What does Article 22 GDPR govern? It restricts solely automated decisions with significant effect and requires safeguards in the permitted cases, in particular the right to human intervention.
When is a data protection impact assessment needed? When the processing is likely to result in a high risk, for instance with large-scale processing, systematic evaluation or new technologies – and therefore often with AI.
Does the AI Act apply in addition to the GDPR? Yes. Both frameworks apply in parallel. The AI Act complements the GDPR with a risk-class-based product regulation but does not replace it.
Conclusion
Using AI is not prohibited under data protection law, but it is conditional. The legal challenges spread across clearly nameable fields: the legal basis, the handling of training data and the question of anonymity, transparency and the rights of data subjects, the limits of automated decisions, the duty to carry out an impact assessment, and the constellations of processing on behalf and third-country transfer. Over all of this stands the relationship of two parallel regimes – the GDPR and the AI Act – that govern the same deployment from different angles.
Those who examine these fields early and systematically, rather than retrofitting them after a complaint, gain not only legal certainty but also the foundation for a responsible use of the technology. Data protection is not an obstacle to AI but the condition under which it becomes sustainable in a business.
Always up to date.
New articles on data protection, compliance and secure file sharing – delivered straight to your inbox. No spam, unsubscribe any time.
Discover all featuresGet blog updates
Sign up and never miss a new post.
By subscribing, you agree to our Privacy Policy.