AI systems that handle personal data are not exempt from GDPR they are among the highest-risk systems that GDPR was written to regulate. The rules apply whether you built the AI yourself, bought it from a vendor, or integrated a third-party model. Understanding what compliance actually requires before you build is significantly cheaper than retrofitting it after.
In this article
- Why AI systems present specific GDPR challenges
- The six compliance requirements that apply to most AI systems
- UK GDPR vs EU GDPR — what changed after Brexit
- Common mistakes businesses make when building AI under GDPR
- How to approach compliance from day one of a build
The default assumption among many businesses building AI systems is that GDPR is an operational concern something the legal team handles after the system is built. In practice, GDPR compliance for AI is primarily an architectural concern. The decisions made in the first few weeks of a build, how data flows, where it is stored, how long it is retained, what the model is trained on, determine whether the system is compliant or not. Those decisions are expensive to reverse once the architecture is established.
1. Why AI systems present specific GDPR challenges
Standard software systems process personal data in relatively predictable ways they store it, retrieve it, and display it. GDPR was designed with these systems in mind and the compliance requirements are well-understood.
AI systems introduce complexity that standard software does not. They learn from data, which means personal information can become embedded in a model in ways that are not always transparent or reversible. They make decisions or recommendations that affect individuals, which triggers specific GDPR provisions around automated decision-making. And they often process large volumes of data from multiple sources simultaneously, making it difficult to track exactly what personal information the system holds and where it came from.
The specific challenge of “the right to be forgotten”
Under GDPR, individuals have the right to request deletion of their personal data. For a standard database, this is straightforward. For an AI model trained on data that includes that individual’s information, it is a genuinely hard technical problem. If your AI system learns from personal data, you need a clear answer to “how do we delete an individual’s data from the model?” before you train it not after.
2. The six compliance requirements that apply to most AI systems
01Lawful basis for processing
Every piece of personal data your AI system processes needs a lawful basis under GDPR, consent, legitimate interest, contractual necessity, or one of the other defined bases. This needs to be established and documented before processing begins, not identified retrospectively when a subject access request arrives. For AI systems that process data for training, inference, and output generation, each processing activity may require its own lawful basis.
02Data minimisation
The system should process only the personal data that is strictly necessary for the stated purpose. This is a design principle as much as a legal requirement, AI systems built without data minimisation in mind tend to collect and retain more data than they need, increasing both compliance risk and the cost of a potential breach. At the architecture stage, every data field the system collects should be justified against a specific functional need.
03Purpose limitation
Data collected for one purpose cannot be used for a different, incompatible purpose without a new lawful basis. For AI systems, this becomes relevant when a model trained on customer service data is later used for marketing personalisation, or when anonymised training data is used in a context that allows re-identification. The intended uses of the data need to be defined at the outset and the system built to enforce those boundaries.
04Automated decision-making provisions
Article 22 of GDPR gives individuals the right not to be subject to decisions based solely on automated processing when those decisions produce significant effects, credit decisions, employment screening, insurance pricing, content moderation. If your AI system makes or significantly influences these kinds of decisions, you need to provide a meaningful human review mechanism, and individuals must be informed that automated processing is being used.
05Data Processing Agreements
If your AI system uses a third-party model provider an API that processes personal data on your behalf you are the data controller and they are a data processor. GDPR requires a written Data Processing Agreement between you. This applies to any cloud AI service that your system sends personal data to, including large language model APIs used for inference. Many businesses using third-party AI APIs are operating without the DPAs that GDPR requires.
06Data Protection Impact Assessment
A DPIA is mandatory when processing is “likely to result in a high risk” to individuals which most AI systems that process personal data at scale will meet. The DPIA must be completed before the processing begins, must involve your Data Protection Officer if you have one, and must be documented. It is not a one-time exercise it should be revisited when the system changes significantly or new data sources are added.
3. UK GDPR vs EU GDPR, what changed after Brexit
The UK retained its own version of GDPR, UK GDPR which closely mirrors the EU regulation but with some differences that matter for businesses operating across both jurisdictions.
| Area | UK GDPR | EU GDPR |
|---|---|---|
| Regulator | ICO (Information Commissioner’s Office) | National DPAs per member state |
| Maximum fine | £17.5 million or 4% of global turnover | €20 million or 4% of global turnover |
| Data transfers to EU | Covered by adequacy decision — flows freely | UK transfers require appropriate safeguards |
| EU AI Act | Not directly applicable in UK | Applies to AI systems used in the EU regardless of where built |
| Core principles | Essentially identical to EU GDPR | Same lawful bases, rights, and obligations |
For businesses operating in both the UK and EU, both frameworks apply simultaneously. The EU AI Act, which came into force in stages through 2025 and 2026, adds a further layer of regulation for AI systems deployed in the EU. High-risk AI systems those used in employment, education, credit, law enforcement, and several other categories, face additional conformity requirements beyond GDPR. UK businesses deploying AI to EU users need to understand where their system sits in the EU AI Act’s risk classification.
4. Common mistakes businesses make when building AI under GDPR
✗
Treating compliance as a post-build checklist
The most expensive GDPR mistakes in AI systems are architectural, data structures that cannot support deletion requests, logging systems that capture more than they should, third-party integrations established without DPAs. These are discovered after launch and require significant rework. GDPR compliance for AI needs to be a design input, not a post-launch audit.
✗
Assuming anonymisation solves the problem
Anonymisation removes GDPR obligations, but only if the anonymisation is genuinely irreversible. In AI systems, data that appears anonymised can often be re-identified when combined with other data the system holds. Pseudonymisation reduces risk but does not remove GDPR obligations. The difference matters and needs to be assessed for each dataset.
✗
Not checking third-party AI vendors for DPA compliance
Many businesses integrate third-party AI APIs without establishing whether those vendors will sign a GDPR-compliant Data Processing Agreement. Some major AI API providers have restricted DPA terms or process data in jurisdictions that require additional safeguards. This needs to be verified before integration, not after a subject access request arrives.
✗
Missing the automated decision-making disclosure
Businesses frequently build AI systems that make or influence significant decisions without informing users that automated processing is involved or providing a mechanism for human review. This is one of the most commonly cited issues in ICO enforcement activity related to AI and one of the most straightforward to address at the design stage.
5. How to approach compliance from day one of a build
GDPR compliance for an AI system is not a legal project that runs alongside the technical build. It is a set of design requirements that shape the technical build from the start.
- Complete a DPIA before architecture is finalised. The DPIA process will surface data flows and processing activities that need to be designed around. Doing it after the architecture is set means retrofitting decisions that should have been made upfront.
- Map every data flow before writing code. Know exactly what personal data enters the system, where it goes, how long it stays, and who can access it. This map becomes both a compliance document and a technical specification.
- Establish DPAs with all third-party processors before integrating them. This includes cloud infrastructure providers, AI API vendors, and any analytics or monitoring tools that receive personal data.
- Build deletion and access request handling into the data model. The ability to locate, export, and delete an individual’s data should be a feature of the system, not something that requires manual database queries when a request arrives.
- Document the lawful basis for each processing activity. When a subject access request or ICO inquiry arrives, you need to be able to show not just what you processed but why you were entitled to process it.
At SmartWayLabs, compliance is a design input on every project that touches personal data, not a final review before launch. The DPIA, data flow mapping, and DPA review happen during discovery, before a line of production code is written. It adds time to the front end of the project and removes significantly more from the back end.
The bottom line
GDPR compliance for AI systems is more demanding than for standard software, not because the regulation treats AI differently in every respect, but because AI systems process personal data in ways that create risks the regulation was specifically written to address. Automated decision-making, the right to erasure, and purpose limitation all become significantly more complex when the system learns from the data it processes.
The businesses that handle this well are the ones that treat compliance as an architecture question rather than a legal question and answer it before the build starts, not after it finishes.
If you are planning an AI system that will handle personal data from UK or EU users and want to understand what GDPR compliance means for your specific build, the SmartWayLabs team is happy to talk it through. We build compliance in from day one, reach out and we will give you a straight answer about what your project needs.
Building an AI system that handles personal data?
SmartWayLabs designs GDPR compliance into every AI build from the architecture stage, not as a post-launch audit.Talk to the team ↗