Where the EU AI Act and GDPR overlap

The AI Act regulates AI systems as products: who builds them, who uses them, what risks they pose. The GDPR regulates personal data, whoever processes it and however. A team shipping an LLM feature in the EU is usually subject to both at once, with different roles, different assessments and different regulators, and the two sets of duties only partly line up.

This article sets out the AI Act timeline as amended in 2026, how its roles map onto GDPR roles, and the four places where the two laws meet most often in practice: transparency, impact assessments, automated decisions and bias testing with sensitive data. It ends with a mapping table. It is a practitioner's summary, not legal advice; the AI Act's application to a given system turns on details of its intended purpose.

The timeline, after the Digital Omnibus

The AI Act (Regulation (EU) 2024/1689) was published in the Official Journal in July 2024 and entered into force on August 1, 2024. Its obligations phase in. In 2026 the EU amended the schedule through the Digital Omnibus on AI, Regulation (EU) 2026/1744, adopted on July 8, 2026, published in the Official Journal on July 24, 2026 and in force from July 27, 2026 (the third day after publication).

The omnibus did not delay Article 50 transparency duties, which apply from August 2, 2026, apart from the four-month grace period for marking by systems already on the market. It also rewrote the AI literacy duty in Article 4: providers and deployers must now "take measures to support the development of AI literacy" of their staff, and the text says this does not require guaranteeing any specific level of literacy for any individual. And it moved the special-category data exception for bias testing out of Article 10(5) into a new Article 4a with wider scope, discussed below.

A separate Digital Omnibus proposal amending the GDPR itself, published by the Commission on November 19, 2025, would among other things address legitimate interest for AI development and the definition of personal data. The EDPB and EDPS have objected to the proposed change to the personal data definition. As of October 2026 that proposal was still in the legislative process, with no Parliament position yet (Legislative Observatory, 2025/0360(COD)); nothing in it applies yet.

Roles: provider and deployer vs controller and processor

The AI Act's two main roles are the provider, who develops an AI system or model (or has it developed) and places it on the market or puts it into service under its own name, and the deployer, who uses an AI system under its authority in a professional capacity. The GDPR's roles are controller (decides purposes and means of processing personal data) and processor (processes on the controller's behalf).

They do not map one to one. Three common setups:

• A SaaS company adds an LLM assistant to its product, built on a hosted model. Under the AI Act, the model vendor is the provider of the general-purpose AI model; the SaaS company is the provider of the AI system it builds on top and markets under its own name; its business customers are deployers. Under the GDPR, the SaaS company is usually a processor for its customers' data and a controller for its own (account data, product analytics, any training it does for itself).
• A company builds an internal LLM tool for its own staff. It is both provider (it put the system into service under its name) and deployer of that system, and the controller of the personal data processed.
• A company buys an off-the-shelf AI product and uses it. It is a deployer under the AI Act and a controller under the GDPR; the vendor is the provider and, for the customer's data, typically a processor.

Roles can shift. Under Article 25, a deployer or other third party becomes the provider of a high-risk system if it puts its name or trademark on one, makes a substantial modification, or changes the intended purpose of a non-high-risk system (including a general-purpose system) so that it becomes high-risk. Pointing a general chatbot at CV screening is the textbook example.

Transparency: Article 50 and GDPR Articles 13 to 15

Article 50 of the AI Act sets transparency duties that apply whether or not a system is high-risk:

• Art. 50(1), providers: systems that interact directly with people must be designed so people are informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant person in context.
• Art. 50(2), providers: systems generating synthetic audio, image, video or text must mark outputs in a machine-readable format detectable as artificially generated, with exceptions for assistive editing functions that do not substantially alter the input.
• Art. 50(3), deployers: people exposed to emotion recognition or biometric categorization must be informed, and the processing must comply with the GDPR.
• Art. 50(4), deployers: deepfakes must be disclosed; AI-generated text published to inform the public on matters of public interest must be disclosed unless it has undergone human review or editorial control with someone holding editorial responsibility.

The information must be given clearly at the latest at the first interaction or exposure (Art. 50(5)).

GDPR transparency is about the data, not the system: what personal data is processed, for what purposes, on what basis, shared with whom, kept for how long, and, under Articles 13(2)(f), 14(2)(g) and 15(1)(h), the existence of automated decision-making with meaningful information about the logic involved. A chatbot disclosure banner satisfies Article 50(1) but not the GDPR; a privacy notice satisfies the GDPR but is not an AI interaction disclosure. You need both, and it is efficient to write them together: the banner at the point of interaction, linked to a notice section that names the model provider as a recipient, the trace retention period, and whether conversations are used for evaluation or training.

Impact assessments: FRIA and DPIA

A DPIA under GDPR Article 35 is required where processing is likely to result in a high risk to individuals' rights and freedoms. It is the controller's duty and covers any processing, AI or not.

A fundamental rights impact assessment (FRIA) under AI Act Article 27 is narrower. It applies before deploying a high-risk system under Article 6(2) (Annex III, excluding critical infrastructure), and only for deployers that are bodies governed by public law, private entities providing public services, and deployers of Annex III point 5(b) and (c) systems (creditworthiness and credit scoring, and risk assessment and pricing for life and health insurance). It covers the deployer's processes, the period and frequency of use, affected groups, specific risks of harm, human oversight measures and what happens if risks materialize, and the results are notified to the market surveillance authority.

The two are designed to stack. Article 27(4) says that where an obligation is already met through a DPIA, the FRIA complements it. Article 26(9) tells deployers of high-risk systems to use the information the provider supplies under Article 13 (instructions for use) to carry out their DPIA. In practice, run one assessment process with a shared description of the system and data flows, and add the FRIA-specific sections (non-privacy fundamental rights such as non-discrimination, access to services, and the complaint mechanism) where Article 27 applies.

Most LLM features are not high-risk under the AI Act, so no FRIA is needed. A DPIA may still be, and is good practice anyway; see the checklist in the AI privacy guide.

Automated decisions: GDPR Article 22 and AI Act Article 86

GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significant effects, unless it is necessary for a contract, authorized by law, or based on explicit consent, and then with safeguards including the right to human intervention, to express a view and to contest the decision.

Two Court of Justice judgments shape how this applies to model-driven decisions. In SCHUFA (C-634/21, December 2023), the Court held that a credit agency's automated score can itself be a decision under Article 22 where a third party draws strongly on it to decide on a contract. In Dun & Bradstreet Austria (C-203/22, February 2025), it held that the "meaningful information about the logic involved" owed under Article 15(1)(h) means explaining the procedure and principles actually applied so the person can understand and contest the decision; handing over an algorithm is not enough.

For LLM features, the risk is drift. An assistant that drafts a recommendation for a human to approve is outside Article 22 if the human genuinely decides. If reviewers approve nearly everything without engaging, or the model output effectively determines the outcome (as with the SCHUFA score), the decision can be "based solely" on automated processing. Document what the human reviewer sees, what they can change, and how often they do.

The AI Act adds Article 86: a person subject to a decision taken by a deployer on the basis of output from an Annex III high-risk system (excluding critical infrastructure), with legal or similarly significant adverse effects, can obtain clear and meaningful explanations of the AI system's role and the main elements of the decision. It applies only where Union law does not already provide such a right. And Article 26(11) requires deployers of Annex III high-risk systems that make or assist decisions about people to tell those people they are subject to such a system.

Special-category data for bias testing

Testing a model for bias often means knowing the protected characteristics of the people in the test set, which is special-category data under GDPR Article 9 (racial or ethnic origin, health, sexual orientation and so on). Article 9 has no general exception for bias testing.

The original AI Act text addressed this in Article 10(5), allowing providers of high-risk systems to process special categories "to the extent that it is strictly necessary" for bias detection and correction, subject to conditions. The 2026 omnibus deleted Article 10(5) and replaced it with a new Article 4a, which keeps the high-risk provider permission and extends it: providers and deployers of other AI systems and models, and deployers of high-risk systems, may also exceptionally process special categories where strictly necessary to address likely biases affecting health, safety, fundamental rights or prohibited discrimination. The conditions are the same as before:

1. bias detection and correction cannot be done effectively with other data, including synthetic or anonymized data;
2. technical limits on reuse, and state-of-the-art security and privacy-preserving measures, including pseudonymization;
3. strict access controls and documented access, limited to authorized people under confidentiality obligations;
4. no transmission, transfer or access by other parties;
5. deletion once the bias is corrected or the retention period ends, whichever comes first;
6. records of processing that explain why the processing was strictly necessary and why other data would not do.

Article 4a(2) states that it creates no obligation to carry out bias detection. It is a permission, and it sits alongside the GDPR: you still need an Article 6 lawful basis, a DPIA is likely, and condition 6 is a ROPA entry you should write before the dataset exists.

Mapping table

What to do this quarter

• Classify each LLM feature. Provider or deployer? Any Annex III use? Any Article 50 duty? Write it down next to the GDPR role and lawful basis.
• Ship the Article 50 disclosures. They have applied since August 2, 2026. Chatbot disclosure is the usual one; check output marking if you generate images, audio or video, and the December 2, 2026 deadline if your generative system was already on the market.
• Re-plan high-risk work. If you were preparing for August 2026 high-risk obligations, the date for Annex III systems is now December 2, 2027. Use the time; do not drop the work.
• Merge your assessment templates. Add AI Act fields to the DPIA template so one document serves both.
• Review bias testing datasets. If you hold special-category data for fairness testing, check it against the six Article 4a conditions and the GDPR basis you rely on.

For the data-handling side of the same features, see the companion articles on prompts and traces, access and deletion requests and model provider terms.