The AI Act and the GDPR: where do they overlap, and where do they clash?
The AI Act and the GDPR often apply at the same time, but address different aspects of AI. Learn where transparency, oversight and risk assessment meet, where data rules can pull in different directions, and how to approach them in practice.
Two rules with different aims
The AI Act mainly governs how AI systems are designed, offered, used and managed according to risk. The GDPR governs how organisations process personal data, from collection and use to retention and deletion. When an AI system uses personal data, both sets of rules may apply. They overlap on topics such as transparency, human oversight, data quality and risk assessment. At times they can pull in different directions, for example when development or operation seems to call for a large amount of data while personal data must be limited to what is necessary.
You therefore need to consider the rules together. An assessment that asks only whether the AI system is appropriately controlled may miss whether its processing of personal data is lawful and responsible. Conversely, a GDPR assessment alone does not cover all the risks of the AI system or the controls needed to manage them. The precise requirements depend on the system, its purpose, the data and your organisation’s role. For more on personal data, see AI and the GDPR; for the wider AI rules, read the AI Act for small businesses.
Roles can overlap
The AI Act distinguishes between roles such as provider and deployer. A provider develops an AI system, has it developed, or places it on the market or into service under its own name. A deployer uses the system within its organisation. Under the GDPR, relevant roles include the controller, which determines the purposes and means of processing, and the processor, which handles personal data on another party’s behalf.
These roles do not automatically correspond. A business that builds an AI application and supplies it to customers may be the provider of that application. If it also uses personal data to deliver its own service, it may separately be a controller for that processing. A customer using the application may be a deployer under the AI Act and a controller under the GDPR. A supplier that processes data only on that customer’s instructions may be a processor. The actual activities and arrangements matter; a role label in a contract does not settle the question by itself.
For each processing activity and part of the AI service, map who makes which choices, who can access the data, and who is responsible for security, information to individuals and handling requests. Record who reports incidents and who reviews changes. This helps prevent tasks from falling between supplier and customer.
Where the requirements reinforce each other
Transparency is a clear area of overlap. In relevant situations, people should be able to understand that they are interacting with AI, how the application is used at a high level and what its possible effects are. The GDPR also requires understandable information about the processing of personal data. One clear explanation can support both aims, as long as it covers the specific information people need.
Human oversight is another shared concern. Staff should know when a review is needed, what signals call for intervention and how an outcome can be corrected. A formal approval button is not enough if the person reviewing the result lacks the time, information or authority to challenge it. Documentation helps show how the system is used, what data flows exist, which limitations are known and who makes decisions.
Risk assessment and a DPIA can also complement each other. An AI risk assessment looks at risks from the system and its use, such as incorrect outputs, discrimination or inadequate human oversight. A DPIA examines the effects of a planned personal data processing activity on people’s rights and freedoms. They have areas in common, but do not answer exactly the same questions. Depending on the processing, a DPIA may be required alongside other assessments. Read more in DPIAs for AI.
Where data rules can pull in different directions
AI systems need data for development, testing or use. More data is not automatically better or permitted. The GDPR requires purpose limitation and data minimisation: collect and use data for a defined purpose, and limit it to what is necessary for that purpose. This calls for a justification for each data category, rather than an assumption that all available data is suitable.
At the same time, a well-functioning system needs data that is relevant, sufficiently representative and, where appropriate, current. Poor or one-sided data can lead to errors or unequal outcomes. The answer is not to pursue quality by collecting data without limits. Examine what data is needed, whether it can be used for this purpose, how you will detect errors and bias, and whether less intrusive data or techniques would work. The right balance varies by system and use case.
Automated decision-making needs particular attention. A system may, for example, rank applications or make a recommendation, without making the final decision itself. But if its output determines the outcome without meaningful human review, additional requirements and safeguards may be relevant. Look at what happens in practice, not just how the workflow is described. Decide who can explain, review and correct the outcome.
A workable approach for your business
A small business does not need to create a separate file for each set of rules. Keep one overview of AI applications and their related personal data processing. For each application, record its purpose, data, supplier, internal owner, roles and main risks. A shared register can help reveal gaps; it does not replace a separate assessment where one is needed for a particular situation.
Then carry out a joint risk analysis with people from the teams that select, manage and use the application. Include risks from both the AI system and the data processing. Check whether a DPIA is needed, and record the resulting measures, who will carry them out and when the assessment will be reviewed. An earlier assessment may no longer hold if the purpose, data, supplier or use changes.
Agree with suppliers which data they receive, the purposes for which they use it, whether they share it further, how long it is kept and how deletion works. Also discuss security, support for requests from individuals, incidents, documentation and system changes. Check whether the supplier provides enough information for you to carry out your own assessment and oversight. A contract can clarify responsibilities, but it does not change your actual role.
Use this checklist as a starting point:
- Is the purpose of the AI application specific and recorded internally?
- Which personal data goes into it, and is that data necessary for this purpose?
- Who is the provider or deployer, and who is the controller or processor?
- Are information, human oversight and ways to correct outcomes in place in practice?
- Have data quality, origin and possible bias been assessed?
- Have you decided whether a DPIA is needed alongside the broader risk analysis?
- Are supplier agreements and responsibilities for changes clear?
Have it reviewed legally
This article provides general information and is not legal advice. How the AI Act and the GDPR apply depends on your situation, the system and the processing involved. Ask a lawyer or data protection officer to assess what applies to your organisation.