Skip to main content
Praxikon

GDPR and AI Act side by side

Where the GDPR and the AI Act meet, and where they do not

An organisation that uses AI with personal data has to deal with both laws. They look alike but serve a different purpose: the GDPR protects people when their data is used, the AI Act sets requirements for AI systems themselves. Per theme you see the provisions side by side, what they share, how they differ, how to combine them, and a question to test yourself.

Reference date of this layer: 15 September 2026. Every item was checked against its source; the date per item is shown. Anything after the reference date is not yet here.

Transparency: informing people

GDPR

AI Act

What they share
Both laws want people to know what is happening to them, at the moment it matters. The GDPR requires the controller, in Article 13(1) and (2) and Article 14(1) and (2), to inform the data subject about, among other things, the purpose, the legal basis and the existence of automated decision-making. The AI Act requires, in Article 26(11), the deployer of a high-risk AI system listed in Annex III that makes or assists in making decisions related to natural persons to inform those persons that they are subject to its use; Article 50(1) requires the provider to design a system intended for direct interaction so that people are informed they are interacting with AI, and Article 50(3) and (4) require the deployer to inform people of the operation of an emotion recognition or biometric categorisation system and to disclose that content is a deep fake. Both also set rules on form: concise, intelligible and in clear and plain language (GDPR Article 12(1)), and clear and distinguishable, at the latest at the first interaction or exposure (AI Act Article 50(5)).
The essential difference
The GDPR is triggered by the processing of personal data and always places the duty on the controller, with a long list of required items and fixed deadlines, such as within one month at the latest when the data were not obtained from the data subject (Article 14(3)(a)). The AI Act is triggered by the type of AI system and by role: Article 50(1) falls on the provider, who must design the system so that people know they are interacting with AI, while Article 50(3) and (4) and Article 26(11) fall on the deployer. In substance the AI Act requires a notice that AI is being used, supplemented for emotion recognition and biometric categorisation by information on the operation of the system (Article 50(3)), but not the full list of information the GDPR demands. The dates also differ: Article 50 has applied since 2 August 2026, Article 26(11) only from 2 December 2027.
How to combine them
Add the AI notices to the privacy information you already provide, so that the data subject reads in one place what you use the data for, whether there is automated decision-making referred to in Article 22(1) and (4) and, in those cases, meaningful information about the logic involved and the envisaged consequences (GDPR Article 13(2)(f) and Article 14(2)(g)). In addition, show a short notice directly in the interaction itself, for example at the start of a chat, because Article 50(5) requires the information at the latest at the first interaction. Record per system who supplies which text: the provider for the design under Article 50(1), and the deployer and controller for the notices under Article 50(3) and (4), Article 26(11) and the GDPR.
Test yourself: Your organisation uses a chatbot for customer questions and records names and customer numbers along the way. Which two information duties apply here, and who bears them?

Under AI Act Article 50(1), the provider must design the chatbot so that people know they are interacting with an AI system, unless this is obvious from the point of view of a reasonably well-informed, observant and circumspect person, taking into account the circumstances and the context of use. Under GDPR Article 13(1) and (2), your organisation as controller must inform the customer, when the data are collected, about among other things the purpose, the legal basis and the retention period. One notice does not replace the other: Article 50(6) expressly leaves other transparency obligations unaffected.

Connections

What connects to this theme

Case law

Guidelines

Enforcement and fines

Assessing risks in advance: DPIA and FRIA

GDPR

AI Act

What they share
Both laws require you to write down, before you start, which risks an application poses to people and which measures you take against them: the GDPR in Article 35(1) and (7), the AI Act in Article 27(1), points (a) to (f). In both cases this is not a one-off exercise: where necessary you review whether processing is performed in accordance with the DPIA, at least when the risk changes (Article 35(11) GDPR), and you update the FRIA information when any element has changed or is no longer up to date (Article 27(2) AI Act). The AI Act makes the link itself: under Article 27(4) you may cross-refer to parts of a DPIA already carried out, and under Article 26(9) you use the provider's information from Article 13 to carry out your DPIA.
The essential difference
The DPIA rests on the controller and is required for any processing of personal data that is likely to result in a high risk (Article 35(1) and (3) GDPR); where the DPIA indicates that the processing would result in a high risk in the absence of measures taken to mitigate the risk, you consult the supervisory authority beforehand (Article 36(1)). The FRIA rests on the deployer and only applies to high-risk AI systems under Article 6(2), and then only to bodies governed by public law, private entities providing public services and deployers of systems in Annex III, point 5(b) and (c), with the exception of Annex III, point 2 (Article 27(1)). The FRIA covers the impact on fundamental rights that the use may produce (Article 27(1)) and the DPIA covers the impact on the protection of personal data and the risks to the rights and freedoms of data subjects (Article 35(1) and (7)(c)); you notify the FRIA results to the market surveillance authority, save in the case referred to in Article 46(1) (Article 27(3)), whereas the DPIA only goes to the supervisory authority in a prior consultation (Article 36(3)(e)). The DPIA has applied since the GDPR became applicable; under the Digital Omnibus (Regulation (EU) 2026/1744) the FRIA applies from 2 December 2027, and separately the provider runs the ongoing risk management of Article 9.
How to combine them
Start with one assessment per AI application in which you first complete the DPIA elements of Article 35(7) GDPR and then add only the extra FRIA elements of Article 27(1), using cross-references as Article 27(4) allows. Ask the provider early for the information under Article 13: you use it for your DPIA (Article 26(9)) and for the risks in your FRIA (Article 27(1)(d)), and in similar cases you may also rely on existing impact assessments carried out by the provider for the FRIA (Article 27(2)). Set one moment at which you review both assessments together, for example when the system or its use changes.
Test yourself: A private employer will use a high-risk AI system from Annex III to assess job applicants. Does it have to carry out a DPIA, a FRIA, or both?

A DPIA is likely required if the employer carries out a systematic and extensive automated evaluation of applicants and bases decisions on it that significantly affect them (Article 35(1) and (3)(a) GDPR). Article 27(1) only requires a FRIA from bodies governed by public law, private entities providing public services and deployers of systems in Annex III, point 5(b) and (c); an employer that does not fall into one of those groups does not have that obligation. For its DPIA it uses, where applicable, the provider's information under Article 13 (Article 26(9)).

Connections

What connects to this theme

Guidelines8 of 9

Legislation in motion

Automated decisions and human oversight

GDPR

AI Act

What they share
Both laws aim to prevent a system from deciding about people without a human who can really step in. In the cases referred to in Article 22(2)(a) and (c), Article 22(3) requires the controller to provide at least the right to obtain human intervention, the data subject's right to express their point of view and the right to contest the decision. The AI Act requires in Article 14(4)(d) that the person overseeing the system can disregard, override or reverse its output, and in Article 26(2) that the deployer assigns that oversight to people with the necessary competence, training and authority. Both laws also give a right to information about the decision: Article 15(1)(h) GDPR to meaningful information about the logic involved, its significance and envisaged consequences, and Article 86(1) AI Act to an explanation of the role of the AI system and the main elements of the decision.
The essential difference
The GDPR starts from the data subject: Article 22(1) gives the right not to be subject to a decision based solely on automated processing, and Article 22(3) places the safeguards with the controller. The AI Act starts from the system: Article 14 applies only to high-risk AI systems, places the design of oversight with the provider (paragraphs 1 and 3) and its execution with the deployer (Article 26(2)), even when a human ultimately decides on the basis of the output (Article 14(4)(b)). The right to explanation in Article 86(1) covers only systems listed in Annex III, except point 2, and under paragraph 3 applies only to the extent other Union law does not already provide that right. The obligations in Articles 14 and 26 apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028.
How to combine them
Set up one review process that covers both human intervention under Article 22(3) GDPR and oversight under Articles 14(4) and 26(2) AI Act: the same trained reviewers, a documented authority to depart from the output and a record of those departures, so oversight does not become a formality. Build one information and explanation route that combines the notice under Article 13(2)(f) GDPR and Article 26(11) AI Act, and handles requests under Article 15(1)(h) GDPR and Article 86(1) AI Act together. Where applicable, use the provider information referred to in Article 26(9) AI Act in the data protection impact assessment, which Article 35(3)(a) GDPR requires for a systematic and extensive automated evaluation of personal aspects on which decisions with legal or similarly significant effects are based.
Test yourself: A bank uses a high-risk AI system to assess creditworthiness, and an employee takes the decision based on the score. Does Article 22 GDPR apply, and what does the AI Act require?

If the employee genuinely assesses the case, the decision is not based solely on automated processing and Article 22(1) GDPR does not apply; if that review is only a formality, the outcome may be different. The AI Act applies either way, for Annex III systems from 2 December 2027: under Article 26(2) the employee must then have the necessary competence and authority, and under Article 14(4) must be able to disregard or override the score. The customer may also have a right under Article 86(1) to an explanation of the role the system played in the decision, if the decision produces legal effects or similarly significantly affects them, and under paragraph 3 only to the extent other Union law does not already provide that right.

Connections

What connects to this theme

Case law

Guidelines8 of 12

Enforcement and fines

Legislation in motion6 of 8

Data quality, minimisation and data governance

GDPR

AI Act

What they share
Both laws require data to fit the purpose for which you use it. The GDPR requires in Article 5(1)(c) and (d) that personal data are adequate, relevant, limited to what is necessary and accurate; the AI Act requires in Article 10(3) that training, validation and testing data sets are relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. Article 10(2)(b) expressly asks, for personal data, about the original purpose of the data collection, which links to purpose limitation in Article 5(1)(b) and the test for further processing in Article 6(4) GDPR. Both also rely on documented choices: the accountability duty in Article 5(2) GDPR and the data governance and management practices in Article 10(2) AI Act.
The essential difference
The GDPR applies to every controller processing personal data and protects the data subject; the starting point is as little data as necessary (Article 5(1)(c)). Article 10 AI Act covers all data in data sets for high-risk AI systems, including data that is not personal data, and the provider must ensure the system complies (Article 16(a)); the data sets must suit the intended purpose of the system, with an examination of possible biases likely to affect health, safety or fundamental rights or lead to prohibited discrimination, and measures against them (Article 10(2)(f) and (g)). As a result the AI Act can call for more or richer data (sufficiently representative, paragraph 3) while the GDPR sets limits, and anyone using, for example, data on ethnic origin or health for such an examination runs into the prohibition in Article 9(1) GDPR unless an exception in paragraph 2 applies. Article 4a(1) AI Act allows providers of high-risk AI systems exceptionally to process such data to the extent strictly necessary for bias detection and correction, subject to the conditions in that paragraph and in addition to the GDPR. The timing also differs: the GDPR already applies, while Article 10 applies to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028.
How to combine them
Keep one description per data set that answers both sets of questions at once: origin and original purpose, legal basis and any exception for sensitive data, and why the chosen amount and composition is necessary and sufficiently representative. Record the checks on accuracy and bias in the same place, so you have one file for the accountability duty in Article 5(2) GDPR and the data governance practices in Article 10(2) AI Act. If you use special categories of personal data for bias detection, record in the records of processing activities why this was strictly necessary and why other data would not suffice (Article 4a(1)(f) AI Act). Involve privacy staff and developers already at the design choices stage, because that is where minimisation and representativeness clash first.
Test yourself: A provider of a high-risk AI system under Annex III wants to add health data to its training data to detect bias. Which rules must it weigh side by side?

Article 10(2)(f) and (g) and Article 10(3) AI Act require an examination of possible biases and sufficiently representative data. At the same time, health data is a special category: Article 9(1) GDPR prohibits processing it unless an exception in paragraph 2 applies, and Article 5(1)(c) still requires that no more data is used than necessary. In addition, Article 4a(1) AI Act exceptionally permits such processing, but only to the extent strictly necessary, where bias detection cannot be effectively fulfilled with other data (point (a)), and subject to safeguards such as pseudonymisation (point (b)) and deletion once the bias is corrected (point (e)); these conditions apply in addition to the GDPR.

Connections

What connects to this theme

Case law8 of 12

Guidelines8 of 11

Enforcement and fines8 of 11

Legislation in motion6 of 8

Using special categories of personal data to detect bias

GDPR

AI Act

What they share
Both laws treat special categories of personal data strictly. GDPR Article 9(1) prohibits processing data such as ethnic origin, health and sexual orientation, unless an exception in paragraph 2 applies. The AI Act, in Article 4a(1) and (2), only exceptionally allows these data to be used to detect and correct bias, and only where strictly necessary. The conditions apply in addition to the GDPR (Article 4a(1) AI Act), and Union data protection law continues to apply (Article 2(7), first sentence, AI Act). Both laws use the record of processing activities as evidence: GDPR Article 30(1), and AI Act Article 4a(1)(f), which requires the record to state why the processing was strictly necessary and why other data were not enough.
The essential difference
The GDPR is aimed at the controller and requires a valid exception under Article 9(2) for every processing operation, such as explicit consent or a substantial public interest based on law. Article 4a AI Act only covers detecting and correcting bias, but sets its own conditions in Article 4a(1)(a) to (f), including: checking whether other data, such as synthetic or anonymised data, are enough; pseudonymisation; strict access controls; no passing the data to others; and deletion once the bias has been corrected or the retention period ends, if earlier. For providers of high-risk AI systems, bias detection is part of the data duty in Article 10(2)(f) and (g), which applies to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028; for other providers and for deployers, Article 4a(2) makes it an option, not a duty. The former Article 10(5) was deleted by the Digital Omnibus (Regulation (EU) 2026/1744) and replaced by Article 4a, which has applied since 27 July 2026.
How to combine them
Treat a bias test with special categories of data as one file: record why the processing is strictly necessary and why other data, such as synthetic or anonymised data, are not enough (AI Act Article 4a(1)(a) and (f)) and which exception in GDPR Article 9(2) you rely on. Put both reasons in the same record of processing activities (GDPR Article 30), so the privacy team and the AI team work from one piece of evidence. Link the deletion duty in Article 4a(1)(e) to the moment the correction is done, and include that in your retention periods.
Test yourself: A deployer of a high-risk AI system wants to use health data to test whether the system disadvantages certain groups. Is this required, and what must the processing meet?

It is not required: AI Act Article 4a(2) exceptionally allows it, but states expressly that it creates no obligation. It is only allowed where strictly necessary and all conditions of Article 4a(1) are applied, such as pseudonymisation, no passing the data to others, and deletion once the bias has been corrected or the retention period ends, if earlier. The GDPR also still applies (Article 2(7), first sentence, AI Act), so you also test the processing against GDPR Article 9.

Connections

What connects to this theme

Case law

Guidelines

Legislation in motion

Security and robustness

GDPR

AI Act

What they share
Both laws require a level of security that fits the risk, not a fixed list of measures. Article 32(1) GDPR requires appropriate technical and organisational measures, including the ability to ensure the confidentiality, integrity, availability and resilience of systems (point b) and to restore the availability of and access to personal data in a timely manner after a physical or technical incident (point c). Article 15(1) of the AI Act requires an appropriate level of accuracy, robustness and cybersecurity, and paragraphs 4 and 5 require resilience against errors and against attacks by unauthorised third parties. Paragraph 4 requires technical and organisational measures for this and names backup or fail-safe plans as a possible solution.
The essential difference
The GDPR protects personal data, places the duty on the controller and the processor (Article 32(1)), and has applied since 25 May 2018 to all processing of personal data within the scope of the GDPR. Article 15 of the AI Act sets requirements for the AI system itself (accuracy, robustness and cybersecurity), applies only to high-risk AI systems, and through Article 16(a) falls on the provider, who must design and develop the system that way. The AI Act also names AI-specific threats the GDPR does not, such as data poisoning, model poisoning, adversarial examples and feedback loops in systems that keep learning (Article 15(4) and (5)). Article 15 applies from 2 December 2027 for Annex III systems and from 2 August 2028 for systems covered by Annex I.
How to combine them
An organisation subject to both can set up one risk analysis and one set of security measures covering the AI system and the personal data in it, and add the AI-specific threats from Article 15(5). The process for regularly testing, assessing and evaluating security measures referred to in Article 32(1)(d) GDPR can then also check the accuracy and robustness of the system. Record for each measure which role you hold (controller, processor, provider or deployer), so it is clear which obligation the measure fulfils.
Test yourself: A provider secures the personal data in its high-risk AI system well. Does that automatically mean it complies with Article 15 of the AI Act?

No. Article 32 GDPR is about securing personal data, but Article 15 also requires the system to be accurate and robust and resilient against errors and attacks such as data poisoning or adversarial examples, and, for systems that keep learning, limits feedback loops (paragraphs 1, 4 and 5). Those requirements apply even when the system processes no personal data.

Connections

What connects to this theme

Case law

Guidelines

Enforcement and fines

Who is responsible: roles in both laws

GDPR

AI Act

What they share
Both laws link obligations to a role, not to whoever builds or owns the technology. The GDPR has the controller, who determines the purposes and means of the processing (Article 4 point 7), and the processor, who processes on the controller's behalf (Article 4 point 8). The AI Act has the provider, who develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark (Article 3 point 3), and the deployer, who uses the system under its own authority (Article 3 point 4). In both laws your role can shift because of what you actually do: a processor that infringes the GDPR by determining the purposes and means of processing is considered a controller in respect of that processing (GDPR Article 28(10)), and anyone who puts their name or trademark on a high-risk AI system, makes a substantial modification to it, or changes the intended purpose so that it becomes high-risk is treated as the provider (AI Act Article 25(1)).
The essential difference
The main responsibility sits with a different party. Under the GDPR the controller must implement appropriate measures and be able to demonstrate that every processing operation complies (Article 24(1)), while Article 16 (points (a) to (l)) of the AI Act places a series of obligations on the provider and the AI Act gives the deployer mainly obligations on use in line with the instructions for use, human oversight, monitoring and keeping logs (Article 26(1), (2), (5) and (6)). The threshold and timing also differ: the GDPR roles apply as soon as you process personal data, but Articles 16 and 26 apply to high-risk AI systems and Article 25(1) determines when someone becomes the provider of such a system; these provisions apply, after the Digital Omnibus (Regulation (EU) 2026/1744), from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems. Note that the roles do not map one to one: under the contract a processor processes only on documented instructions from the controller (GDPR Article 28(3)(a)), whereas a deployer uses the system under its own authority.
How to combine them
For each AI application, record in one overview which GDPR role you have per processing operation and which AI Act role per system, because the same organisation can be both controller and deployer while its supplier can be both processor and provider. Where you must carry out a data protection impact assessment under GDPR Article 35, use the information the provider supplies under Article 13 of the AI Act, as Article 26(9) requires; in addition, include the arrangements with the supplier in the written contract that GDPR Article 28(3) and (9) already require. Whenever the system or its purpose changes, check again whether AI Act Article 25(1) makes you a provider, and whether the supplier, by determining purposes and means itself, becomes a controller for that processing under GDPR Article 28(10).
Test yourself: Your organisation uses a high-risk AI system from a supplier. The supplier developed the system and places it on the market under its own name. You decide why and how the personal data are processed; the supplier processes them on its own servers, but only on your instructions. What role do you and the supplier have under each law?

Under the GDPR you are the controller, because you determine the purposes and means (Article 4 point 7), and the supplier is the processor, because it processes on your behalf (Article 4 point 8 and Article 28). Under the AI Act the supplier is the provider (Article 3 point 3 and Article 16) and you are the deployer (Article 3 point 4 and Article 26). If you put your name or trademark on the system, or make a substantial modification to it in such a way that it remains a high-risk AI system, Article 25(1)(a) or (b) makes you the provider yourself.

Connections

What connects to this theme

Case law8 of 9

Guidelines8 of 10

Enforcement and fines

Legislation in motion6 of 8

Privacy by design and risk management by design

GDPR

AI Act

What they share
Both laws want you to deal with risks in the design stage, not only afterwards. Article 25(1) GDPR requires appropriate technical and organisational measures, both when the means of processing are determined and during the processing itself, matched to the risks to people's rights and freedoms. Article 9(5)(a) AI Act requires risks to be eliminated or reduced as far as technically feasible through adequate design and development of the high-risk AI system; in both cases you take account of the state of the art or technical feasibility. The means of demonstration differ: under Article 25(3) GDPR an approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance, while Article 11(1) AI Act requires technical documentation that demonstrates the system complies with the requirements.
The essential difference
The duty holder and the scope differ. Article 25 GDPR is addressed to the controller and is not limited to a particular kind of technology, and paragraph 2 adds a separate duty: by default, process only the data needed for each purpose. Article 9 AI Act applies only to high-risk AI systems, targets risks to health, safety and fundamental rights, and is a continuous process over the whole lifecycle with testing against prior defined metrics (paragraphs 2 and 8); paragraphs 9 and 10 refer to the provider. Article 25 GDPR already applies since the GDPR became applicable, while Articles 9 and 11 AI Act apply to Annex III systems only from 2 December 2027 and to Annex I systems from 2 August 2028.
How to combine them
An organisation building a high-risk AI system that processes personal data can set up one design process in which each design choice is checked both against the data protection principles and against the risks to health, safety and fundamental rights. Record those choices, such as pseudonymisation or collecting less data, once and use that record both as support under Article 25 GDPR and as a building block of the technical documentation under Article 11 AI Act. Do keep track of your role under each law, because the controller and the provider are not always the same party.
Test yourself: A hospital uses a high-risk AI system that an external party developed and placed on the market. Who must set up the risk management system under Article 9 AI Act, and does Article 25 GDPR also apply to the hospital?

The risk management system under Article 9 AI Act must be set up by the provider: Article 16, point (a), requires providers to ensure their high-risk AI system complies with the requirements of Section 2, which includes Article 9. Under Article 3, point 3, the provider is whoever develops the system or has it developed and places it on the market or puts it into service under its own name or trademark; as long as that is the external party, the hospital as deployer does not carry this duty. Article 25 GDPR does apply to the hospital as soon as it processes personal data as a controller, so it must take appropriate measures itself and, by default, process only the data that is needed, even though it did not build the AI.

Connections

What connects to this theme

Case law

Guidelines

Legislation in motion

Keeping records: record of processing, technical documentation and logs

GDPR

AI Act

What they share
Both laws require you to put in writing what you do, so that a supervisory authority can check it later. The GDPR requires a record of processing activities in writing, including in electronic form, which you make available to the supervisory authority on request (Article 30(1), (3) and (4)), and makes the controller responsible for demonstrating compliance (Article 5(2)). The AI Act requires technical documentation showing that a high-risk AI system meets the requirements (Article 11(1)), which the provider keeps at the disposal of the national competent authorities (Article 18(1)). On logs the two laws meet directly: Article 19(1) and Article 26(6) say the minimum retention period of six months gives way where Union law on the protection of personal data provides otherwise.
The essential difference
The GDPR places the record on the controller (per processing activity) and on the processor (per category of processing activities), with an exemption for organisations employing fewer than 250 persons unless the processing is likely to result in a risk to the rights and freedoms of data subjects, is not occasional or includes special categories of data or personal data relating to criminal convictions and offences (Article 30(1), (2) and (5)). The AI Act places the duty per high-risk AI system: the technical documentation is drawn up before the system is placed on the market or put into service and kept up to date (Article 11(1)), and the provider keeps it at the disposal of the national competent authorities for 10 years (Article 18(1)); SMEs and SMCs get no exemption but a simplified form (Article 11(1)). In addition the system must technically allow automatic recording of logs (Article 12(1)), which the provider and the deployer each keep to the extent the logs are under their control, for at least six months (Article 19(1) and Article 26(6)). The GDPR sets no fixed period and instead asks you not to keep personal data longer than necessary (Article 5(1)(e)); the AI Act duties apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028.
How to combine them
Add every high-risk AI system that processes personal data to your record as a processing activity and refer to the instructions for use and other information you receive from the provider, so that purpose, categories of data and security can be found in one place. Set one retention period for logs with a short justification that takes into account both the minimum in Article 26(6) or Article 19(1) and the storage limitation in Article 5(1)(e). That way the justification for the accountability duty in Article 5(2) and for keeping logs under the AI Act sits in one place.
Test yourself: An employer with 120 staff uses, as a deployer, a high-risk AI system from Annex III to assess job applicants. Which record-keeping duties from both laws should the employer keep in mind?

Under the AI Act, from 2 December 2027 the employer keeps the automatically generated logs under its control for at least six months, unless data protection law provides otherwise (Article 26(6)); the technical documentation in Articles 11 and 18 is a duty of the provider. Under the GDPR the 250 persons threshold probably does not help the employer, because the exemption in Article 30(5) does not apply where the processing is not occasional or is likely to result in a risk, which can be the case with ongoing recruitment. The retention period for the logs must also fit the storage limitation in Article 5(1)(e).

Connections

What connects to this theme

Case law8 of 10

Guidelines

Enforcement and fines8 of 10

Legislation in motion

Reporting: data breaches and serious incidents

GDPR

AI Act

What they share
Both laws require a report to an authority within a period that runs from awareness: without undue delay and, where feasible, within 72 hours for a personal data breach (Article 33(1) GDPR), and immediately and in any event no later than 15 days for a serious incident (Article 73(2) AI Act). Both allow you to submit an incomplete first report and complete it later (Article 33(4) GDPR, Article 73(5) AI Act). Both also use a reporting chain: the processor informs the controller (Article 33(2) GDPR) and the deployer first informs the provider (Article 26(5) AI Act).
The essential difference
The GDPR places the reporting duty on the controller and covers a personal data breach that poses a risk to people's rights and freedoms; where a high risk is likely, you must in principle also inform the data subjects (Article 34(1), with exceptions in paragraph 3). The AI Act places the reporting duty on the provider of a high-risk AI system (Article 73(1)) and covers a serious incident: an incident or malfunctioning of an AI system that directly or indirectly leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment (Article 3, point 49), even when no personal data is involved. The deadlines differ by type of incident: no later than 15 days, 10 days in case of death, and 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure (Article 73(2) to (4)). The GDPR duty already applies, while the rules for high-risk AI systems (Chapter III, Sections 1 to 3) apply from 2 December 2027 (Annex III) or 2 August 2028 (Annex I).
How to combine them
Set up one reporting process in which the first assessment asks two questions: is there a personal data breach (then assess the notification duty under Article 33 GDPR) and is this a serious incident involving a high-risk AI system (then Article 26(5) and Article 73 AI Act apply). Record in agreements with processors and AI providers who informs whom and how quickly. Logs you keep under Article 26(6) AI Act can help record the facts; the documentation required by Article 33(5) GDPR also covers the effects and the remedial action taken.
Test yourself: Your organisation uses a high-risk AI system to select job applicants. You discover that the system systematically rejects candidates of a certain origin. Under the AI Act, whom must you inform first, and does this fact alone create a reporting duty under Article 33 GDPR?

An infringement of obligations under Union law intended to protect fundamental rights can be a serious incident (Article 3, point 49(c) AI Act). As deployer you then immediately inform first the provider, and then the importer or distributor and the market surveillance authority (Article 26(5)); the provider reports immediately and in any event no later than 15 days after the provider or deployer becomes aware, or no later than two days in the case of a widespread infringement (Article 73(2) and (3)). Article 33 GDPR concerns a personal data breach, so whether a report is also needed there is something you assess separately.

Connections

What connects to this theme

Case law

Guidelines

Legislation in motion

Rights of people: access and explanation of decisions

GDPR

AI Act

What they share
Both laws give a person the right to understand how a decision about them was made. Under Article 15(1)(h) GDPR, the data subject receives meaningful information about the logic involved, the significance and the envisaged consequences of automated decision-making. Under Article 86(1) AI Act, the affected person receives a clear and meaningful explanation of the role of the AI system and the main elements of the decision. Both rights concern decisions that produce legal effects or similarly significantly affect someone (Article 22(1) GDPR and Article 86(1) AI Act); Article 86(1) also requires that the person considers the decision to have an adverse impact on their health, safety or fundamental rights.
The essential difference
The GDPR places the duty on the controller, the AI Act on the deployer of a high-risk AI system listed in Annex III, except point 2 of that Annex. Article 22 GDPR concerns decisions based solely on automated processing, and Article 15(1)(h) requires information about the logic at least for those decisions, while Article 86(1) AI Act also applies when the deployer takes the decision on the basis of the system's output. Article 22(3) GDPR also requires the controller, in the cases referred to in points (a) and (c) of paragraph 2, to implement suitable measures, at least the right to obtain human intervention, to express one's point of view and to contest the decision; Article 86 AI Act only grants a right to an explanation. Under Article 86(3), the AI Act right also applies only to the extent that it is not otherwise provided for under Union law; whether other Union law, for example the GDPR, does so has to be checked case by case.
How to combine them
An organisation can set up one procedure for requests for access and explanation, and for each request first check whether it concerns a decision based solely on automated processing (Article 22 GDPR), a decision supported by a high-risk AI system listed in Annex III (Article 86 AI Act), or both. For each system, record what role the output plays in the decision and which factors weigh heavily, so the same explanation can serve Article 15(1)(h) GDPR and Article 86(1) AI Act. The notice telling people that a high-risk AI system is used on them (Article 26(11) AI Act, for Annex III from 2 December 2027) can be combined with the information the organisation already provides under the GDPR.
Test yourself: An employee assesses an application and takes the decision personally, but uses the score from a high-risk AI system listed in Annex III. The applicant is rejected and asks for an explanation. Which law gives a right to an explanation here?

Article 22 GDPR concerns decisions based solely on automated processing, and here a person takes the decision; Article 15(1)(h) requires information about the logic at least for such decisions. Article 86(1) AI Act can apply here, because the decision is taken on the basis of the output of a high-risk system listed in Annex III, provided the decision produces legal effects or similarly significantly affects the applicant in a way they consider to have an adverse impact on their health, safety or fundamental rights, and no exception (paragraph 2) or other Union law (paragraph 3) applies. The deployer must then explain what role the system played and what the main elements of the decision were.

Connections

What connects to this theme

Case law

Guidelines

Enforcement and fines

Legislation in motion

Biometrics and emotion recognition

GDPR

AI Act

What they share
Both laws treat biometric data as personal data resulting from specific technical processing of physical, physiological or behavioural characteristics, such as facial images or fingerprints (GDPR Article 4(14), AI Act Article 3(34)). The GDPR prohibits processing biometric data to uniquely identify a person in Article 9(1), and the AI Act prohibits in Article 5(1)(g) biometric categorisation that infers race, political opinions, religion or sexual orientation, among others: characteristics that also appear among the special categories in Article 9(1) GDPR. Article 5(1) AI Act states, in the subparagraph following point (h), that point (h) is without prejudice to Article 9 GDPR for biometric processing for purposes other than law enforcement, and Article 50(3) requires deployers to process personal data in accordance with the GDPR, as applicable.
The essential difference
The GDPR only speaks of biometric data when it allows or confirms unique identification (Article 4(14)), while the definition in Article 3(34) AI Act lacks that condition; emotion recognition based on biometric data (Article 3(39)) therefore falls under the AI Act even when the purpose is not unique identification as Article 9(1) GDPR requires. The GDPR prohibits the processing itself in Article 9(1) and allows exceptions, such as explicit consent in Article 9(2)(a), while the AI Act looks at role and use: emotion recognition in the workplace and in education has been prohibited since 2 February 2025 except for medical or safety reasons (Article 5(1)(f)), with no exception for consent. The deployer of an emotion recognition or biometric categorisation system has had to inform exposed persons of the operation of the system since 2 August 2026, except for systems permitted by law to detect, prevent or investigate criminal offences (Article 50(3)), and the high-risk requirements for biometrics in Annex III point 1 only apply through Article 6(2) from 2 December 2027.
How to combine them
Assess every system that analyses faces, voices or behaviour against both laws in one go: first whether it falls under a prohibition in Article 5(1) AI Act, then whether Article 9 GDPR prohibits the processing and which exception in paragraph 2 might apply. Record in the same file which role you have under the AI Act and which under the GDPR; you can combine the explanation of the operation of the system required by Article 50(3) AI Act with the information you provide to data subjects under the GDPR. Take into account any additional national rules that Article 9(4) GDPR allows.
Test yourself: A school wants to use cameras and an AI system to measure pupils' emotions during lessons and asks parents for explicit consent. Does that make the system permitted?

No. Consent can be an exception under Article 9(2)(a) GDPR, but Article 5(1)(f) AI Act prohibits the use of AI systems to infer emotions of persons in education institutions, except where the use is intended for medical or safety reasons. That prohibition has applied since 2 February 2025 and has no exception for consent.

Connections

What connects to this theme

Case law8 of 10

Guidelines8 of 10

Legislation in motion6 of 10

Supervision and fines

GDPR

AI Act

What they share
Both laws require each Member State to designate independent authorities: the GDPR a supervisory authority in Article 51(1), the AI Act at least one notifying authority and one market surveillance authority acting independently in Article 70(1). That authority can demand information and access: under the GDPR through Article 58(1)(a), (e) and (f), while under the AI Act the market surveillance authority gets access to documentation and data sets of high-risk systems (Article 74(12)) and, under conditions, to source code (Article 74(13)). In both laws fines must be effective, proportionate and dissuasive (Article 83(1) GDPR and Article 99(1) AI Act). The factors for setting the amount are very similar, such as the gravity and duration of the infringement, intent or negligence and the degree of cooperation with the authority (Article 83(2) GDPR and Article 99(7) AI Act).
The essential difference
The GDPR sets the fines itself in two tiers: up to EUR 10 million or 2% of worldwide annual turnover (Article 83(4)) and up to EUR 20 million or 4% (Article 83(5)), while the AI Act leaves the penalty rules to Member States and uses three tiers: EUR 35 million or 7% for prohibited practices, EUR 15 million or 3% for, among others, obligations of providers and deployers, and EUR 7.5 million or 1% for incorrect information (Article 99(1), (3), (4) and (5)). For undertakings both laws apply whichever is higher of the amount or the percentage, but the AI Act makes an exception for SMEs, including start-ups, where the lower one applies (Article 99(6)); for small mid-caps the same applies to the fines in paragraphs 4 and 5 (Article 99(6a)). The GDPR fines, among others, the controller and the processor (Article 83(4) and (5)), the AI Act fines operators such as the provider, importer, distributor and deployer (Article 99(4)). Supervision under the AI Act is market surveillance that can be spread over several authorities, and for some high-risk systems in Annex III the data protection authority or an authority meeting the same conditions is designated (Article 74(8)).
How to combine them
Keep one file that holds the processing records for the data protection authority and, if you are the provider of a high-risk AI system, also the documentation and data sets for the market surveillance authority, so you can answer a request under Article 58(1) GDPR or a request for access under Article 74(12) AI Act quickly and correctly. Because both laws take into account whether you cooperate, report an infringement yourself and limit harm (Article 83(2) GDPR and Article 99(7) AI Act), a single joint procedure for incidents and contact with authorities pays off. Record which role you have under each law, because that determines which obligations apply to you; the fine category follows from the provision infringed (Article 83(4) and (5) GDPR and Article 99(3) to (5) AI Act).
Test yourself: A start-up that places an AI system on the market as a provider breaches an obligation under Article 16 of the AI Act. Is the maximum fine the higher or the lower of EUR 15 million and 3% of turnover, and how does that work under the GDPR?

Under the AI Act, for SMEs including start-ups the lower of the amount or the percentage applies (Article 99(4) and (6)). The GDPR has no such exception: for an undertaking the higher of the amount or the percentage always applies (Article 83(4) and (5)). The same organisation can therefore face a very different fine ceiling under each law.

Connections

What connects to this theme

Case law

Guidelines

Enforcement and fines

Legislation in motion

Knowledge in the organisation: data protection officer and AI literacy

GDPR

AI Act

What they share
Both laws address knowledge within the organisation. Under the GDPR the data protection officer advises the employees who carry out processing on their obligations and monitors awareness-raising and training of staff involved in processing operations (Article 39(1), points (a) and (b)), and the organisation must help the officer maintain his or her expert knowledge (Article 38(2)). Article 4(1) of the AI Act requires providers and deployers to take measures that support the AI literacy of their staff. In both cases the approach depends on the situation: under the GDPR the risk, nature, scope, context and purposes of processing (Article 39(2)), under the AI Act the knowledge and experience of the people involved, the context of use and the persons on whom the system is used (Article 4(1)).
The essential difference
The GDPR assigns the knowledge to a designated officer: the controller or processor must designate a data protection officer in the cases of Article 37(1) (public authorities, and organisations whose core activities consist of large-scale regular and systematic monitoring or large-scale processing of special categories or criminal offence data), based on expert knowledge (Article 37(5)), and that officer works independently and reports to the highest management level (Article 38(3)). Article 4(1) of the AI Act has no threshold and no fixed role: it applies to every provider and deployer and targets the staff and other persons who deal with AI systems on their behalf. It is an obligation to take measures, and the text states expressly that it does not require a specific level of AI literacy to be guaranteed for any individual. Article 4 has applied since 2 February 2025 and has had this wording since 27 July 2026 through the Digital Omnibus (Regulation (EU) 2026/1744).
How to combine them
An organisation can extend the awareness-raising and training that the data protection officer already monitors (Article 39(1), point (b)) with role-based AI topics, so that employees who work with AI systems and personal data follow one coherent programme. Record per role which AI literacy measures have been taken; Article 4 does not prescribe this, but it shows that measures have been taken for staff and other persons involved. If the data protection officer takes on AI tasks as well, make sure those tasks do not lead to a conflict of interests (Article 38(6)).
Test yourself: A company has designated a data protection officer and uses an AI system. Does that on its own satisfy Article 4 of the AI Act?

No, not automatically. Article 4(1) requires the deployer to take measures that support the AI literacy of its staff and other persons dealing with AI systems on its behalf, tailored to their knowledge and the context of use. The data protection officer under Articles 37 to 39 of the GDPR can help with this, but the officer's legal task concerns data protection and not the AI knowledge of all employees.

Connections

What connects to this theme

Legislation in motion