GDPR-compliant AI

The GDPR applies to AI systems just as it does to any other software that processes personal data. The key questions: What data flows into the system? On what legal basis? Where is it processed — within the EU or in a third country? And are inputs used to train the AI models? Reputable providers answer these questions transparently and offer business terms where customer data doesn't feed into training.

In practice, GDPR-compliant AI implementation means: conclude a data processing agreement (DPA) with the AI provider, update your processing inventory, consider a data protection impact assessment for larger projects, and establish clear internal rules about which data can go into which tools — for example, no health data in general chat tools.

The most common mistakes in practice: employees use private AI accounts with customer data (shadow AI), there's no DPA with the provider, or sensitive data ends up unfiltered in prompts. The solution rarely involves banning AI altogether, but rather creating an orderly framework: vetted tools with enterprise accounts, clear usage policies, and where needed, anonymisation or pseudonymisation before processing.

For particularly sensitive data, there are alternatives: EU hosting options from major providers, European AI providers, or on-premise operation of open-source models where no data leaves your own infrastructure.

To stop data protection from blocking projects, a fixed, lean five-step review process helps. First: what data types flow through the system — only business data or also personal data, possibly special categories like health data? Second: where does the provider process — EU, third country, with what safeguards? Third: is training on your data excluded and is a DPA available? Fourth: what legal basis applies to the processing — typically contract performance or legitimate interest? Fifth: does higher risk require a data protection impact assessment?

This process typically takes just hours for standard tools with clear provider documentation — and it scales: once you've gone through it, you can reuse it as a checklist for every further tool. What matters is documenting the outcome briefly (which tool, which data, which review, which decision). This documentation is invaluable if a supervisory authority enquires — and it prevents the same questions being rehashed at the start of every new project.

The GDPR grants people whose data is processed a range of rights — access, correction, deletion and objection. These rights don't stop at the boundary with AI, and AI systems raise particular practical questions. Take the right of access: a company must be able to demonstrate on request what personal data it processes about a person — even when that data flows through an AI assistant or knowledge base. This requires knowing where data is stored and that the systems used can actually provide such information.

Special attention is required for one specific rule: Article 22 GDPR gives individuals the right not to be subject solely to automated decision-making with legal or similarly significant effect. If an AI system makes such decisions without human involvement — for example, rejecting an application — this restriction applies. The practical solution usually makes sense anyway: human review at the critical point, so AI prepares and a person decides. When you build data subject rights into your system architecture from the start — discoverable data, a deletion concept, human final decision in significant cases — you meet them in day-to-day operation with minimal effort rather than scrambling after the first request.

The GDPR requires data minimisation: only data actually necessary for the purpose may be processed. With AI systems, this means questioning prompts and inputs too. Feeding a language model complete customer records to generate simple text suggestions may process more personal data than necessary — and increases risk without adding value.

Two practical levers help: pseudonymisation before handoff — names, addresses or contract numbers are replaced with codes and reassigned only after processing — and conscious prompt design that contains only information necessary for the task. For many use cases, such as text improvement or categorisation, the content framework works fine without full names. This practice reduces data protection risk, improves answer quality in many cases, and makes compliance with purpose limitation and deletion obligations considerably easier.