Many companies want to use AI but hesitate the moment the words "data protection" come up. The good news: AI and the General Data Protection Regulation (GDPR) are not mutually exclusive. Anyone who introduces AI software and AI-Agents with good judgement can combine both – powerful automation and lawful, trustworthy processing. This article explains, in plain language, what matters: from the legal basis through data processing to practical measures. One important note up front: this article is general guidance and not legal advice.
Disclaimer: This article is for general information and does not constitute legal advice. Data protection always depends on the individual case. For concrete projects you should involve your data protection officer or qualified legal counsel.
When does the GDPR apply to AI at all?
The GDPR applies as soon as personal data is processed – that is, information relating to an identified or identifiable natural person. This affects many AI applications: a chatbot answering customer enquiries, an AI-Agent reading emails and coordinating appointments, or a system evaluating applications or invoices. If, on the other hand, only anonymous or purely technical data without any link to a person is processed, the GDPR does not apply. The first step of every AI project is therefore the honest question: which personal data actually flows here – and is it really necessary?
Legal basis: no permission, no processing
Every processing of personal data needs a legal basis under Art. 6 GDPR. Three are particularly relevant for AI projects:
- Contract (Art. 6(1)(b)): processing is necessary to perform or prepare a contract – for example when an AI-Agent handles an order or processes a customer request within an existing engagement.
- Legitimate interest (Art. 6(1)(f)): the company has a legitimate interest (e.g. efficient processing, IT security) and the interests of the data subject do not override it. This requires a careful balancing test that should be documented.
- Consent (Art. 6(1)(a)): the data subject agrees voluntarily, in an informed way and for a clear purpose. It must be revocable at any time – which has to be built into AI systems technically.
Important: there is no blanket "AI permission". Every processing needs a concrete, pre-defined basis – and the chosen purpose binds later use.
The principles: more than just a legal basis
A legal basis alone is not enough. Art. 5 GDPR sets out principles that every processing – including by AI – must observe:
- Data minimisation: only the data that is genuinely required for the purpose is processed. With AI especially, the temptation to feed in "everything" is exactly the wrong approach.
- Purpose limitation: data collected for one purpose may not be reused arbitrarily for other purposes (e.g. model training).
- Transparency: data subjects must learn, in an understandable way, that and how their data is processed by AI.
- Accuracy: data must be correct. Because AI models can produce content that sounds plausible but is false, the accuracy of outputs is particularly critical.
- Storage limitation: personal data is kept only as long as it is needed – with clear deletion and retention periods.
Data processing: when AI service providers come into play
Few companies run their AI entirely in-house. As soon as an external cloud or AI provider processes personal data on your behalf, this constitutes processing on behalf of a controller under Art. 28 GDPR. This requires a data processing agreement (DPA), which governs, among other things, which data is processed for which purpose, which technical and organisational measures apply, and whether sub-processors are involved. Responsibility for lawfulness remains with your company – the provider acts on your instructions. Before choosing a provider it is therefore worth a close look: does it offer a solid DPA? Where is the data processed? Could inputs be used to train its own models?
Third-country transfers: the issue with US providers
Many well-known AI models and cloud services come from US providers. If personal data is processed outside the EU or EEA, Art. 44 et seq. GDPR applies. Such a third-country transfer is only permitted if an adequate level of protection is ensured – for example through an adequacy decision, through Standard Contractual Clauses (SCCs) as an appropriate safeguard, or through other permitted mechanisms. In practice this means: check where the data actually flows, what safeguards the provider offers and whether additional protective measures are needed. Often the simplest solution is to keep processing within the EU from the outset – more on that below.
| Topic | GDPR reference | What to watch for |
|---|---|---|
| Legal basis | Art. 6 | Contract, legitimate interest or consent – define in advance |
| Principles | Art. 5 | Data minimisation, purpose limitation, transparency, accuracy, storage limitation |
| Service providers | Art. 28 | DPA, no unwanted training, clear instructions |
| Third country | Art. 44 et seq. | Appropriate safeguards (e.g. SCCs) or EU processing |
| Risk assessment | Art. 35 | DPIA where a high risk is likely |
| Automated decisions | Art. 22 | Solely automated individual decisions generally restricted |
Data Protection Impact Assessment (DPIA)
If a processing operation is likely to result in a high risk to the rights and freedoms of data subjects, a Data Protection Impact Assessment under Art. 35 GDPR must be carried out. This is often the case with AI – for example with systematic evaluation of individuals (scoring), large-scale processing of sensitive data or novel technology. The DPIA describes the planned processing, assesses the risks and defines measures to mitigate them. It is not bureaucracy for its own sake, but a structured way to design an AI project to be data-protection-friendly from the start.
Data subject rights – and the catch with trained models
Data subjects have far-reaching rights: access, rectification, erasure ("right to be forgotten"), restriction, data portability and objection. With classic databases this is readily implementable. It becomes harder with trained models: once personal data has flowed into training, it cannot easily be "deleted" from the model weights. That is precisely why it is so important not to feed personal data into training in the first place. Architectures such as RAG (Retrieval-Augmented Generation), where the model accesses a controllable, searchable knowledge base at runtime instead of being trained on the data, make access and erasure far more practical.
Automated individual decisions (Art. 22)
Art. 22 GDPR protects people from being subject to decisions based solely on automated processing that have significant effects – such as a fully automated rejection of a loan or a job application. Such solely automated individual decisions are generally only permitted under narrow exceptions and require special safeguards, including the right to obtain human intervention. For AI-Agents this means in practice: at legally or economically consequential points, a human belongs in the loop. The agent prepares, the human decides.
Special care with sensitive data (Art. 9)
Special categories of personal data under Art. 9 GDPR – such as health data, biometric data, data on religion, trade union membership or sexual orientation – enjoy enhanced protection and may only be processed under narrow conditions. AI systems can also derive or generate such data unintentionally. Anyone using AI with health, HR or similarly sensitive data should therefore check particularly carefully whether a permissible exception applies, and secure the processing with special technical and organisational measures.
Practical measures for data-protection-compliant AI
From the legal requirements, concrete and actionable measures can be derived:
- Anonymisation & pseudonymisation: wherever possible, remove the link to a person or replace it with pseudonyms – this significantly reduces risk and effort.
- Access control: clear role and permission concepts; only those who need data see it. Logging ensures traceability.
- Processing in the EU / data sovereignty: choose providers and models that enable processing within the EU – this defuses the third-country question from the outset.
- On-premise or EU hosting: run sensitive applications locally or in European data centres instead of handing data to uncontrolled third-party services.
- RAG instead of training: make company knowledge available via a searchable knowledge base instead of training personal data into the model.
- Clear policies for employees: understandable rules on which data may be entered into which AI tools – and which may not.
Core idea: data protection is not a brake but a design principle. Anyone who plans an AI project to be data-sparing from the start, keeps processing in the EU and avoids unnecessary third-party services not only meets the GDPR but also builds the trust that makes AI viable in a company in the first place.
GDPR and the EU AI Act: two frameworks that complement each other
The GDPR is not the only relevant regulation. The EU AI Act complements it: while the GDPR governs the processing of personal data, the AI Act addresses the risks of AI systems themselves – through a risk-based approach with obligations depending on the risk class. The two frameworks interlock: an AI system can fall under the AI Act and process personal data, so both sets of requirements must be met in parallel. Anyone who considers data protection from the start is also well positioned for the requirements of the AI Act.
Conclusion
AI and the GDPR fit together – if data protection is part of the design from the start and not bolted on afterwards. Anyone who clarifies the legal basis, observes the principles, properly governs service providers and third-country transfers, carries out a DPIA where the risk is high, and relies on data-sparing, EU-based implementation can use AI lawfully and trustworthily. This data-protection-friendly approach – local or EU processing, RAG instead of training, no unnecessary third-party services – is part of how Cogitavo works. And, to be clear once more: this article offers general guidance and does not replace individual legal advice.
Sources & further reading
- Regulation (EU) 2016/679 (GDPR) – official full text, EUR-Lex
- European Data Protection Board (EDPB)
- Data Protection Authority of the Republic of Cyprus
- Cogitavo magazine: The EU AI Act 2026
Linked sources as of June 2026. This article is for general information and is not legal advice.