GDPR compliant AI: what EU law requires in practice

An AI system is GDPR compliant when every processing of personal data it performs, in training and in use, rests on a lawful basis, uses only the data the purpose needs, has been assessed with a DPIA where the risk is high, respects the limits on solely automated decisions and is explained to the people concerned. The EU AI Act (Regulation (EU) 2024/1689) does not replace any of this: it adds obligations on the system itself, by role and risk level.

Below, the five GDPR tests one by one, then where the AI Act sits on top. The references are to the GDPR (Regulation (EU) 2016/679, never amended) and to the consolidated AI Act of 27 July 2026, which includes its only amending act so far, Regulation (EU) 2026/1744.

Start here: the GDPR applies first

Article 2(7) of the AI Act settles the relationship: EU law on personal data applies to data processed in connection with the AI Act and, without prejudice to Articles 4a and 59, "this Regulation shall not affect Regulation (EU) 2016/679". Article 4a covers special categories of data for bias correction, Article 59 further processing in regulatory sandboxes.

In practice, the AI Act gives you no general legal basis to process personal data with AI. The basis still comes from the GDPR, and the AI Act obligations come on top.

Both reach beyond EU borders. The GDPR applies to controllers outside the Union that offer goods or services to people in the EU or monitor their behaviour there (Article 3(2)); the AI Act applies to providers and deployers in third countries where the system's output is used in the Union (Article 2(1)(c)). A UK or US organisation selling AI-enabled services into the EU can be in scope of both.

The five GDPR tests for an AI system

1. A lawful basis for each phase

Every processing operation needs one of the six bases in Article 6(1). Special categories of data (health, biometrics used to identify a person, ethnic origin and the others in Article 9(1)) are prohibited unless an exception in Article 9(2) applies. Training a model and using it are often separate processing operations, so check the basis for each.

The European Data Protection Board addressed this in Opinion 28/2024, adopted on 17 December 2024. In summary, there is no hierarchy between legal bases, and legitimate interest can support both the development and the deployment of an AI model if it passes a three-step test: an interest that is lawful, clearly articulated and real; processing that is necessary, with no less intrusive way; and a balancing test against the rights and reasonable expectations of the people concerned. Among its examples is improving threat detection in an information system.

2. Purpose limitation and data minimisation

Personal data are collected for specified, explicit and legitimate purposes and not further processed in an incompatible way (Article 5(1)(b)), and they are limited to what is necessary (Article 5(1)(c)). For AI this means two concrete questions: can customer data collected to deliver a service be reused to train a model, and does the model need every field you feed it? Article 25 turns the answers into design choices, such as pseudonymisation and processing by default only the data each purpose needs.

3. A DPIA where the risk is high

Article 35(1) requires the controller to assess, before processing, any processing likely to result in a high risk to people's rights and freedoms, in particular with new technologies. Article 35(3)(a) names a case many AI systems fall into: a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based. If the residual risk stays high, the controller consults the supervisory authority first (Article 36(1)). A DPIA has no start date: a system that meets these conditions needs one now.

4. Limits on solely automated decisions

Article 22(1) gives people the right not to be subject to "a decision based solely on automated processing", including profiling, with legal or similarly significant effects. Such decisions are allowed only when necessary for a contract, authorised by law or based on explicit consent (Article 22(2)), and in the contract and consent cases the controller still offers human intervention, the chance to express a point of view and to contest the decision (Article 22(3)).

A person in the loop only helps if the review is real. The Article 29 Working Party guidelines on automated decision-making (WP251rev.01, endorsed by the EDPB in May 2018) say that if someone routinely applies automatically generated profiles without any actual influence on the result, the decision is still solely automated: the reviewer needs the authority and competence to change it.

5. Transparency towards the people concerned

Where Article 22 decisions are involved, the privacy notice states their existence and gives meaningful information about the logic involved, its significance and the envisaged consequences (Articles 13(2)(f) and 14(2)(g)); the same information is part of the right of access (Article 15(1)(h)). Write it in terms the reader can use: what data the system looks at, what it produces, who reviews it.

Buying a model rather than building one

If you deploy AI from a vendor, three points apply directly:

• Roles. Whoever decides why and how personal data are processed is the controller (GDPR Article 4(7)). A vendor processing data on its behalf is a processor, chosen for sufficient guarantees and bound by an Article 28 contract.
• Where the model came from. The EDPB says a model trained on personal data cannot in all cases be considered anonymous. If personal data remain in the model, supervisory authorities will look at whether the deployer checked that it was not developed by unlawfully processing personal data, for example through the source of the data, with a depth that scales with the risk of the use.
• Records. Each AI use case maps to a processing activity in the Article 30 record, so the AI inventory and the record of processing stay one document.

Where the AI Act adds obligations

Roles and the FRIA

The AI Act asks who builds and who uses: the provider develops the system and places it on the market or puts it into service under its own name, the deployer uses it under its authority (Article 3(3) and (4)). A company using a third-party CV screening tool is usually a deployer under the AI Act and the controller under the GDPR; recruitment systems are high-risk under Annex III, point 4.

The fundamental rights impact assessment in Article 27 applies only to some deployers of high-risk systems: bodies governed by public law, private entities providing public services, and deployers of systems for creditworthiness or life and health insurance pricing. Since Regulation (EU) 2026/1744, where the DPIA already meets an obligation, the FRIA can cross-refer to it (Article 27(4)). Deployers also use the provider's instructions for use to carry out their DPIA (Article 26(9)).

Special categories of data for bias correction

Article 4a, inserted by Regulation (EU) 2026/1744, allows special categories of data to be processed exceptionally, to the extent strictly necessary to detect and correct bias, under conditions that add to the GDPR: other data, including synthetic or anonymised data, would not work; pseudonymisation and documented access controls are in place; no other party accesses the data; the data are deleted once the bias is corrected or at the end of retention; and the record of processing explains why. It applies to providers of high-risk systems and, under Article 4a(2), to deployers of high-risk systems and to providers and deployers of other AI systems and models, without creating an obligation to correct bias.

Telling people they are dealing with AI

• Systems that interact directly with people are designed so that people know they are talking to an AI system, unless it is obvious (Article 50(1)).
• Deployers of high-risk Annex III systems that make or assist decisions about people inform them that the system is used (Article 26(11)).
• A person subject to a decision taken by the deployer on the basis of the output of a high-risk Annex III system (except point 2), which produces legal effects or similarly significantly affects them in a way they consider adverse to their health, safety or fundamental rights, has a right to clear and meaningful explanations of the role of the system and the main elements of the decision, where EU law does not already provide it (Article 86). Unlike Article 22 GDPR, it is not limited to decisions based solely on automated processing.

Logs and security

Deployers of high-risk systems keep the logs under their control for at least six months, unless EU or national law, in particular on personal data, provides otherwise (Article 26(6)): set one retention period that meets this minimum and GDPR storage limitation. Article 15(5) names threats specific to AI, including data poisoning, adversarial examples and confidentiality attacks. An attack that extracts personal data from a model is also a personal data breach under the GDPR, which is why AI systems belong in the same security monitoring scope as the rest of the estate.

When it applies

The AI Act has applied in general since 2 August 2026, Article 50(1) included. The high-risk requirements, including Articles 26 and 27, apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems (Article 113, as amended by Regulation (EU) 2026/1744).

Fines on two tracks

• GDPR: up to EUR 20 million or 4 % of worldwide annual turnover, whichever is higher, for principles, legal bases and data subject rights including Article 22 (Article 83(5)); up to EUR 10 million or 2 % for obligations such as Articles 25 to 39, DPIA included (Article 83(4)).
• AI Act: up to EUR 35 million or 7 % for prohibited practices (Article 99(3)); up to EUR 15 million or 3 % for operator obligations, including deployers under Article 26 and the transparency duties of Article 50 (Article 99(4)).

What has changed and what has not

The AI Act has been amended once, by Regulation (EU) 2026/1744 (the Digital Omnibus on AI), in force since 27 July 2026: Article 4a, the revised Article 2(7) and the DPIA cross-reference in Article 27(4) come from it. The GDPR has not been amended. On 19 November 2025 the Commission proposed a Digital Omnibus, COM(2025) 837, that would add an Article 88c on legitimate interest for the development and operation of AI. As of 21 October 2026 the Publications Office records no act amending the GDPR, so today's obligations are unchanged.

Where to start

1. One inventory: every AI system linked to the processing activities in your Article 30 record.
2. Two roles per system: provider or deployer under the AI Act, controller or processor under the GDPR.
3. A lawful basis per phase: training and use checked separately, with a documented three-step test if you rely on legitimate interest.
4. A DPIA now for systems that profile people or support decisions about them, written so a future FRIA can cross-refer to it.
5. Vendor checks: Article 28 contract, data provenance of the model, instructions for use, access to logs.
6. Notices and review: transparency text that explains the logic, and a human reviewer with real authority.

To run this inside a certifiable management system, next to the one for information security, the reference is ISO/IEC 42001, which works alongside ISO/IEC 27001.

In short: GDPR compliance for AI is about the data, and it applies today to every AI system that processes personal data. The AI Act is about the system, and adds obligations by role and risk level, with the high-risk rules for Annex III systems from 2 December 2027.

If you want to check how the AI systems you use sit between the GDPR and the AI Act, talk to our team.