If your organisation has implemented GDPR effectively, some foundational elements of the EU AI Act are already in place. However, the overlap is less extensive than many assume, with only the underlying mechanisms carrying over, not the full coverage. Our requirement-by-requirement analysis found that only one of the forty-four links we approved was a full match. In all other cases, additional work remained, typically involving defining a new purpose boundary and maintaining records to demonstrate compliance.
This is positive for data protection teams, provided they are involved early. Addressing the gaps requires design decisions made during system development. Integrating these considerations from the start allows both regulations to be met with a single set of controls. Retrofitting privacy measures later will require additional work and may disrupt existing systems.
This report outlines our analysis, identifies where the two regulations intersect, and highlights five key decisions to address before system development begins.
Two regulations looking at the same system
GDPR asks whether you were allowed to process the data and whether you protected it while you did. The AI Act asks whether the system that used the data was built, documented and governed in a way that can be checked. Where an AI system processes personal data, both questions apply to the same pipeline, the same datasets and often the same people, yet they are answered to different authorities.
The AI Act does not replace GDPR, and it does not offer an exemption from it. Article 10(5), the clearest point where the two meet, allows providers of high-risk AI systems to process special categories of personal data for bias detection and correction, and then sets its conditions "in addition to" those in GDPR. A data protection officer who has spent years keeping health data, ethnicity and religious belief out of systems that do not need them is now reading a regulation that, under conditions, asks for exactly that data to be used.
This is why the AI Act so often lands on the privacy lead's desk. The reasoning is that the person who did GDPR is best placed to do the next regulation. It is a sound instinct, provided the organisation understands how much of the first project the second one can reuse.
What we measured
Existing GDPR measures address only a small portion of the AI Act, and usually only partially. We structured both regulations as requirements with assigned owners, checklists, and evidence expectations, each linked to its article. This approach enabled a direct, requirement-by-requirement comparison.
Our comparison followed three stages. First, we paired each GDPR requirement with each AI Act requirement, creating 47,559 pairs, and used text similarity to identify relevant matches. Second, two independent models assessed whether each GDPR requirement fully, partially, or did not satisfy the AI Act requirement, and identified any gaps. Third, an arbiter resolved any disagreements. Only validated links were retained.
The result, as it stood on 14 September 2026:
| Measure | Result |
|---|---|
| Requirement pairs compared | 47,559 |
| Contradictions found | 0 |
| Approved coverage links | 44 |
| Partial | 43 |
| Whole | 1 |
| AI Act requirements touched | 11 |
We also checked for conflicts where compliance with one regulation would prevent compliance with the other and found none. As a validation step, we applied the similarity test within GDPR, which produced closely matching pairs forty-four times more frequently. This confirms that the low overlap between the two regulations is due to their content, not the threshold we chose.
One unexpected finding was that seventeen of the forty-four overlaps related to duties the AI Act assigns to bodies other than the organisations building or using AI systems, mostly national authorities. Since text similarity does not distinguish the intended audience, confidentiality duties appeared similar regardless of the responsible party. Excluding these, the relevant overlap for organisations consists of twenty-seven links across eight AI Act requirements.
What carries across, and what does not
The mechanisms may carry over, but the scope and record-keeping requirements typically need to be expanded.
Two recurring gaps emerge. First, scope: GDPR controls apply to personal data for documented purposes, while the AI Act requires similar controls for new purposes, such as bias testing, and for non-personal data like technical documentation. Second, records: GDPR access controls limit who can access data, but the AI Act requires evidence of every access event.
The only complete match illustrates this point. GDPR Article 28(3)(b) requires authorised personnel to be bound by confidentiality. We interpret this as granting access only to individuals with documented confidentiality commitments, subject to periodic review and logging. This approach fully satisfies AI Act Article 10(5)(c), which requires strict access controls, documentation, confidentiality obligations, and access logs for bias-testing data. The alignment results from how the GDPR control was implemented, with built-in evidence.
Here, privacy by design involves ensuring each control generates a record of its use.
Where the two touch
These are the eight AI Act requirements an organisation carries that our analysis linked to GDPR work, grouped into five areas and ordered by how many GDPR requirements feed each one. In each case the requirement comes first and the article behind it.
1. Strict, logged access to the bias-testing data
Only authorised people can reach special-category data held for bias detection and correction, each of them under a confidentiality obligation, with access documented and every access logged. EU AI Act Article 10(5)(c). Thirteen GDPR requirements feed this one, more than any other.
- Already in place if you did GDPR well: role-based access, least-privilege provisioning, confidentiality agreements for staff handling personal data.
- Still open: a log of every individual access event to this dataset, not only a record of who holds access rights, and controls scoped explicitly to the bias-testing purpose.
- Evidence includes: access control configuration, access logs, the authorised user list, confidentiality agreements.
2. A technical limit on re-use
Special-category data processed for bias detection cannot be reused for anything else, enforced by the system rather than by policy, and protected with state-of-the-art security and privacy-preserving measures, pseudonymisation among them. EU AI Act Article 10(5)(b). Fed by GDPR Articles 6(4), 25(1) and 32(1)(a).
- Already in place: pseudonymisation and encryption, and an approval step before data is used for a new purpose.
- Still open: an approval step is not a technical limit. The data has to be confined to this purpose by the system itself, and the security measures have to keep pace with the state of the art rather than reflect a configuration documented once.
- Evidence includes: re-use restriction configuration, pseudonymisation records, encryption configuration.
3. No onward transfer
The bias-testing data is not transmitted, transferred or otherwise accessed by other parties. EU AI Act Article 10(5)(d). Fed by GDPR Articles 18(2) and 23(2)(d).
- Already in place: restriction-of-processing controls that block onward use of flagged records.
- Still open: GDPR's rules on restricted processing allow exceptions on stated legal grounds. Article 10(5)(d) gives none for this data, and it applies whether or not a record has been flagged.
- Evidence includes: data transfer restriction configuration, network isolation settings, third-party access audit records.
4. Impact assessments that build on each other
Deployers of high-risk systems feed the provider's transparency information into their data protection impact assessment, and where a fundamental rights impact assessment is required, it complements the DPIA rather than repeating it, with a record of which element meets which obligation. EU AI Act Articles 26(9) and 27(4). Fed by GDPR Articles 35(7), 39(1)(c) and 10.
- Already in place: a DPIA process, routed through the DPO.
- Still open: the fundamental rights assessment itself, an intake step for the provider's information about the AI system, and an element-by-element mapping between the two assessments.
- Evidence includes: a combined assessment template, the DPIA-to-FRIA mapping, completed DPIAs that reference the provider's documentation.
5. Documentation that is not about personal data
Providers and distributors keep a dossier for each high-risk AI system (technical documentation, risk management records, conformity assessment results, test data) ready to produce when a national competent authority asks, in the language that authority requires. EU AI Act Articles 16(k), 21(1) and 24(5). Fed by GDPR Article 31(1).
- Already in place: records of processing and a way to answer a supervisory authority promptly.
- Still open: almost everything in the dossier itself. The GDPR records cover personal data and answer to a data protection authority; this dossier covers the AI system and answers to a different one.
- Evidence includes: the dossier for each system, version history, a record of requests received and answered.
The decisions to make now
Each of these decisions is cost-effective during the design phase but becomes expensive after model training. They are listed in the order typically addressed during system design.
- Determine if the system will use special-category data for bias testing. If so, allocate a separate data store, access path, and deletion trigger for this purpose. Article 10(5) requires deletion once bias is corrected or the retention period ends, whichever occurs first. This is easier to implement when the dataset is separate from the outset.
- Implement access controls that record actual usage, not just permissions. A list of authorised users answers the GDPR question, while a log of access events is required by the AI Act and also supports GDPR compliance.
- Establish strict transfer boundaries for this data, allowing no exceptions. If the main data platform permits onward transfer under certain conditions, ensure bias-testing data is excluded from this rule.
- Design the DPIA template to accommodate the fundamental rights assessment. Include required sections and an intake step for provider documentation from the outset. The second assessment then builds on the first.
- Store the AI system's documentation within the same records system as GDPR records, assigning a responsible owner. Although it serves a different authority and covers distinct content, the management approach remains consistent with existing data protection practices.
How this analysis was possible
This comparison relies on structuring both regulations identically. In RuleMesh, each obligation is defined as a requirement with an owner, checklist, expected evidence, and reference to its article. This uniform structure allows direct comparison and future updates as regulations or models evolve. The figures cited are from the analysis conducted on 14 September 2026 and will be updated as the analysis is refined. Each link includes the remaining work after accounting for the GDPR control.
Ultimately, compliance validation is a human responsibility. The analysis identifies areas for review and outstanding tasks, but final decisions on control implementation rest with the team.
Where to start
Most organisations already have a foundation in place for the GDPR-related aspects of these decisions. Our Privacy by Design Framework details these requirements and serves as a practical starting point for teams extending their GDPR programmes to address the AI Act.