EU AI Act vs GDPR: differences and overlap
This guide maps Regulation (EU) 2024/1689 against Regulation (EU) 2016/679, the GDPR, point by point: roles, legal basis, special-category data under Art. 10 and Art. 4a, impact assessments under Art. 27, automated decisions, transparency, records, authorities, penalties and individual rights. The decision sequence follows the scope and cross-reference steps of PR-27-FRIA v1.0, whose record structure comes from ISO/IEC 42005:2025Published, a published ISO/IEC standard listed on the standards page. At the end the reader holds a crosswalk with the article on each side and a list of open elements per regulation.
What the obligation asks for
Art. 2(7) of Regulation (EU) 2024/1689 states that Union law on the protection of personal data applies to personal data processed in connection with the rights and obligations laid down in the Regulation, and that the Regulation does not affect Regulation (EU) 2016/679. The two regulations therefore run side by side on the same system, and no duty under one is discharged by a record made under the other. Two obligations of the Act refer to the GDPR by name. Art. 10 requires the provider's data governance practices to cover, for personal data, the original purpose of the data collection under Art. 10(2)(b), and the legal basis for processing special categories of personal data for bias detection and correction sits in Art. 4a, the provision that Regulation (EU) 2026/1744 moved from the former Art. 10(5). The obligation record lists one testable element under that provision, the special-category data handling check under Art. 4a(1)(b), (c) and (d), and one documentation element, the record of the reasons why the processing was strictly necessary under Art. 4a(1)(a) and (f). Art. 27 requires the deployers it names to perform a fundamental rights impact assessment before first use, and Art. 27(4) lets that assessment cross-reference or include the relevant parts of a data protection impact assessment under Art. 35 of Regulation (EU) 2016/679. The obligation record lists the cross-reference check as a testable element: each cross-reference resolves to a section that meets the Art. 27(1) element it is cited for. The high-risk duties on the Act side apply from the Annex III application date Deferred; the GDPR side is already in force in full.
Art. 4a(1) sets the necessity threshold for the special-category data basis in words, and the threshold is an unsettled point. This guide takes no reading of its own; it shows both readings as recorded and refers the question to the provider and its counsel.
Inputs
The list follows the Inputs section of the protocol page, reduced to the documents the crosswalk needs.
- The system name, version and provider identity from the instructions for use, with the intended purpose.
- The deployer's determination of its role under Art. 3(3) and 3(4) of Regulation (EU) 2024/1689 and under Art. 4(7) and 4(8) of Regulation (EU) 2016/679, with the counsel reference behind each.
- The records of processing activities under Art. 30 of Regulation (EU) 2016/679 that cover the system, with the legal basis per purpose.
- The data protection impact assessment, where one exists, with section numbering.
- The provider's information under Art. 13 of Regulation (EU) 2024/1689: instructions for use, oversight measures and the accuracy, limitation and residual-risk declarations.
- The log schema and retention policy for the logs under Art. 12 of Regulation (EU) 2024/1689, where the deployer controls the logs.
- The privacy notice and the complaint channels in use for the system.
- A Python environment with PyYAML, for the crosswalk check in the last step.
Procedure
The sequence decides, for each comparison point, which regulation reaches the system and what record answers each side. Steps 4, 5, 9 and 11 are steps of PR-27-FRIA; the others derive from the articles named in the citation.
Record the organisation's role under each regulation: provider or deployer under the Act, controller or processor under the GDPR.
Record Role register, one row per system with the role under each regulation and the counsel reference
[Regulation (EU) 2024/1689, Art. 3(3), 3(4) and 25(1); Regulation (EU) 2016/679, Art. 4(7) and 4(8)]
Record whether the system processes personal data at training, testing and inference, per data flow.
Record Processing determination with the personal data test per data flow
[Regulation (EU) 2024/1689, Art. 2(7); Regulation (EU) 2016/679, Art. 4(1)]
Record the Art. 6(1) basis per purpose. For special categories, record the Art. 9(2) condition and the Art. 4a(1) conditions.
Record Legal basis record per purpose, with the Art. 4a(1)(f) reasons for bias detection where special categories are processed
[Regulation (EU) 2016/679, Art. 6(1) and 9(2); Regulation (EU) 2024/1689, Art. 4a(1)]
Record whether a FRIA is due under Art. 27(1) and whether a DPIA is due under Art. 35(1).
Record Scope record with the deployer category, the DPIA trigger and the counsel reference for each
[Regulation (EU) 2024/1689, Art. 27(1) (PR-27-FRIA steps 2 and 3); Regulation (EU) 2016/679, Art. 35(1) and 35(3)(a)]
Where both are due, map each Art. 27(1) element to the DPIA section that meets it, or mark the element open.
Record Data protection impact assessment cross-reference map, element coverage per Art. 27(1) point
[Regulation (EU) 2024/1689, Art. 27(4) and 26(9) (PR-27-FRIA steps 6 and 33)]
Record which Art. 14(4) measure and Art. 26(2) assignment implements each Art. 22(3) safeguard for decisions under Art. 22(1).
Record Oversight measures list with the Art. 22(3) safeguard each measure implements and the assigned natural person per measure
[Regulation (EU) 2016/679, Art. 22(1) to 22(3); Regulation (EU) 2024/1689, Art. 14(4) and 26(2)]
Map each information duty to its addressee: deployer, natural person or data subject, with the document that meets it.
Record Information duty map, one row per addressee with the article and the document that meets it
[Regulation (EU) 2024/1689, Art. 13(3), 26(11) and 50; Regulation (EU) 2016/679, Art. 13(2)(f), 14(2)(g) and 15(1)(h)]
Record the Art. 12 logs and the Art. 30 register as two records, each with its retention period.
Record Records map with the object, the owner and the retention period per record
[Regulation (EU) 2024/1689, Art. 12(1), 19(1) and 26(6); Regulation (EU) 2016/679, Art. 30(1) and 5(1)(e)]
Map each individual right and each complaint route to the channel that receives it.
Record Rights and complaint route map, one row per right with the channel that receives it
[Regulation (EU) 2024/1689, Art. 86(1) and 85 (PR-27-FRIA steps 26 and 27); Regulation (EU) 2016/679, Chapter III and Art. 77]
Record the market surveillance authority and the supervisory authority for the system, and whether they are one body.
Record Authority register with the market surveillance authority and the supervisory authority for the system, and whether they are one body
[Regulation (EU) 2024/1689, Art. 70(1) and 74(8); Regulation (EU) 2016/679, Art. 51(1)]
Record one review trigger per element on each side, including a revision under the other regulation.
Record Review trigger list, one trigger per element on each side
[Regulation (EU) 2024/1689, Art. 27(2) (PR-27-FRIA step 34); Regulation (EU) 2016/679, Art. 35(11)]
Run the crosswalk check and record the open elements per side.
Record Crosswalk with the open elements per side
[AIAssuranceLabs procedure]
The table below is the mapping the steps fill in, one row per comparison point, each cell with its article. Where one regulation has no equivalent, the cell says so.
| Point | Regulation (EU) 2024/1689 | Regulation (EU) 2016/679 | Where the two meet |
|---|---|---|---|
| Roles | Provider (Art. 3(3)) and deployer (Art. 3(4)) are defined by the system; a deployer becomes a provider under Art. 25(1) by rebranding, substantial modification or a change of intended purpose | Controller (Art. 4(7)) and processor (Art. 4(8)) are defined by who determines the purposes and means of the processing; joint controllers under Art. 26 and processors under Art. 28 | One organisation holds one role under each regulation at the same time, and the roles are determined separately (Art. 2(7)) |
| Legal basis | No legal basis is required to use an AI system; Art. 5 prohibits the listed practices regardless of any basis | Every processing of personal data rests on one basis under Art. 6(1)(a) to (f) | The Act creates no basis for ordinary processing; the GDPR basis is recorded per purpose, including the original purpose of collection under Art. 10(2)(b) of the Act |
| Special-category data | Art. 4a(1) permits processing for bias detection and correction to the extent strictly necessary, under conditions (a) to (f); Art. 4a(2) extends the permission to deployers and to providers of other systems and creates no duty to run bias detection | Art. 9(1) prohibits processing; Art. 9(2)(a) to (j) lists the exceptions | Art. 4a(1) states that the processing meets Regulation (EU) 2016/679, and recital 70 of the Act as adopted frames it as substantial public interest within the meaning of Art. 9(2)(g); the strict-necessity reasons go into the Art. 30 records under Art. 4a(1)(f) |
| Impact assessment | Art. 27(1) requires a fundamental rights impact assessment before first use by the deployers it names; six elements under Art. 27(1)(a) to (f) | Art. 35(1) requires a data protection impact assessment by the controller before high-risk processing; content under Art. 35(7)(a) to (d); prior consultation under Art. 36 | Art. 27(4): the FRIA may cross-reference or include parts of the DPIA and complements it; Art. 26(9): the deployer uses the provider's Art. 13 information in the DPIA |
| Automated decisions | Art. 14(4)(a) to (e) require the provider to design the system so the overseer can understand, stay aware of automation bias, interpret, override and interrupt; Art. 26(2) requires the deployer to assign oversight to competent natural persons | Art. 22(1) gives the data subject a right not to be subject to a decision based solely on automated processing with legal or similarly significant effects; Art. 22(2) lists the exceptions; Art. 22(3) requires human intervention, a view and a contest as safeguards | An Art. 14 oversight measure can be the Art. 22(3) safeguard, and the record names which measure implements which safeguard |
| Transparency | Art. 13(1) and 13(3) require the provider to inform the deployer through the instructions for use; Art. 26(11) requires the deployer to inform natural persons subject to an Annex III system; Art. 50 requires disclosure to natural persons for the four cases it lists In force | Art. 13(2)(f) and 14(2)(g) require information on the existence of automated decision-making, the logic involved and the consequences; Art. 15(1)(h) repeats it for the access right | The Act informs the deployer and the interacting person; the GDPR informs the data subject; the addressees differ and one notice does not meet both without a check per addressee |
| Records | Art. 12(1) requires the system to record events over its lifetime; Art. 19(1) and Art. 26(6) require the provider and the deployer to keep those logs for at least six months unless Union or national law provides otherwise, in particular data protection law | Art. 30(1) and 30(2) require a record of processing activities per controller and per processor; Art. 5(1)(e) limits storage to what the purpose needs | The log records events; the register describes processing; Art. 26(6) defers the retention period to data protection law where it provides otherwise |
| Authorities and penalties | Art. 70(1) requires a market surveillance authority per Member State; Art. 79(2) requires it to order corrective action, withdrawal or recall; Art. 99(4)(e) places deployer duties under Art. 26 in a fine tier, imposed under the national rules of Art. 99(1) | Art. 51(1) requires a supervisory authority per Member State; Art. 58(2) lists its corrective powers; Art. 83(4) and 83(5) set the fine tiers | Art. 74(8) lets a Member State designate the data protection supervisory authority as market surveillance authority for the Annex III systems it lists; one authority can then act under both regulations |
| Individual rights | Art. 86(1) gives an affected person the right to an explanation of the role of an Annex III system in a decision with legal or similarly significant effects; Art. 85 gives any person a complaint route to the market surveillance authority; no other right is created | Chapter III: access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20), objection (Art. 21), automated decisions (Art. 22), complaint (Art. 77), compensation (Art. 82) | Art. 86(3) applies the explanation right only where Union law does not otherwise provide it, so the Art. 15(1)(h) and Art. 22(3) routes are checked first |
Example for steps 1 to 11: a crosswalk that encodes the table. The file is a synthetic example; the evidence keys in the second block refer to its point values.
# synthetic example: crosswalk.yaml, one entry per comparison point with the article on each side
# an empty article list means the regulation has no equivalent for that point
crosswalk:
- point: roles
ai_act: { articles: ["Art. 3(3)", "Art. 3(4)", "Art. 25(1)"], attaches_to: "the AI system" }
gdpr: { articles: ["Art. 4(7)", "Art. 4(8)", "Art. 26", "Art. 28"], attaches_to: "the processing" }
- point: legal_basis
ai_act: { articles: [], note: "no basis needed to use a system; Art. 5 prohibits listed practices" }
gdpr: { articles: ["Art. 6(1)"], note: "one basis per purpose" }
- point: special_category_data
ai_act: { articles: ["Art. 4a(1)", "Art. 4a(2)"], note: "bias detection only, strictly necessary, conditions (a) to (f)" }
gdpr: { articles: ["Art. 9(1)", "Art. 9(2)"], note: "prohibition with listed exceptions" }
- point: impact_assessment
ai_act: { articles: ["Art. 27(1)", "Art. 27(4)", "Art. 26(9)"] }
gdpr: { articles: ["Art. 35(1)", "Art. 35(3)(a)", "Art. 35(7)", "Art. 36"] }
- point: automated_decisions
ai_act: { articles: ["Art. 14(4)", "Art. 26(2)", "Art. 26(11)"], note: "design and assignment duties" }
gdpr: { articles: ["Art. 22(1)", "Art. 22(2)", "Art. 22(3)"], note: "data subject right with safeguards" }
- point: transparency
ai_act: { articles: ["Art. 13(1)", "Art. 13(3)", "Art. 50(1)", "Art. 50(2)", "Art. 50(4)"] }
gdpr: { articles: ["Art. 13(2)(f)", "Art. 14(2)(g)", "Art. 15(1)(h)"] }
- point: records
ai_act: { articles: ["Art. 12(1)", "Art. 19(1)", "Art. 26(6)"], object: "events over the lifetime of the system" }
gdpr: { articles: ["Art. 30(1)", "Art. 30(2)", "Art. 5(1)(e)"], object: "processing activities" }
- point: authorities_and_penalties
ai_act: { articles: ["Art. 70(1)", "Art. 74(8)", "Art. 79(2)", "Art. 99(4)"] }
gdpr: { articles: ["Art. 51(1)", "Art. 58(2)", "Art. 83(4)", "Art. 83(5)"] }
- point: individual_rights
ai_act: { articles: ["Art. 86(1)", "Art. 85"], note: "one explanation right and one complaint route" }
gdpr: { articles: ["Art. 15", "Art. 16", "Art. 17", "Art. 18", "Art. 20", "Art. 21", "Art. 22", "Art. 77", "Art. 82"] }
Example for step 12. The system record is a synthetic example embedded in the script; in use it is the role register and the evidence references from steps 1 to 11.
# synthetic example: list the crosswalk points with no evidence reference on a side
import yaml
crosswalk = yaml.safe_load(open("crosswalk.yaml"))["crosswalk"]
record = { # synthetic system record: evidence ids per point and per side
"system": "synthetic-recruitment-screening",
"evidence": {
"roles": {"ai_act": ["role-register-v1"], "gdpr": ["role-register-v1"]},
"legal_basis": {"gdpr": ["ropa-entry-14"]},
"special_category_data": {"gdpr": ["ropa-entry-14"]},
"impact_assessment": {"gdpr": ["dpia-2"]},
"records": {"ai_act": ["log-schema-v3"], "gdpr": ["ropa-entry-14"]},
},
}
for entry in crosswalk:
point = entry["point"]
for side in ("ai_act", "gdpr"):
expected = entry[side]["articles"]
held = record["evidence"].get(point, {}).get(side, [])
if not expected:
print(f"NONE {point:26s} {side:6s} no equivalent in this regulation")
elif not held:
print(f"OPEN {point:26s} {side:6s} {', '.join(expected)}")
else:
print(f"HELD {point:26s} {side:6s} {', '.join(held)}")
An excerpt of the output for the synthetic record. The lines are outputs of the example and carry no meaning outside it.
HELD roles ai_act role-register-v1
HELD roles gdpr role-register-v1
NONE legal_basis ai_act no equivalent in this regulation
HELD legal_basis gdpr ropa-entry-14
OPEN special_category_data ai_act Art. 4a(1), Art. 4a(2)
HELD special_category_data gdpr ropa-entry-14
OPEN impact_assessment ai_act Art. 27(1), Art. 27(4), Art. 26(9)
HELD impact_assessment gdpr dpia-2
The special_category_data line is the case the unsettled point above governs: the synthetic record holds an Art. 9(2) condition in its register entry and no Art. 4a(1) record, so the strict-necessity reasons under Art. 4a(1)(f) and the safeguards under Art. 4a(1)(b) to (e) are open on the Act side. The subgroup disaggregation guide shows the examination that the basis is used for. The impact_assessment line is the case the FRIA vs DPIA scenario works through: a DPIA exists and the Art. 27 record does not.
A pitfall that vendor documentation omits
Control libraries that map both regulations onto one control set place the two special-category provisions on one line, and the line reads as if one record answers both. The two provisions point in opposite directions. Art. 9(1) of Regulation (EU) 2016/679 is a prohibition with exceptions in Art. 9(2); Art. 4a(1) of Regulation (EU) 2024/1689 is a permission with conditions in points (a) to (f). A register entry that names an Art. 9(2) condition does not show that the bias detection could not be effectively fulfilled with other data, including synthetic or anonymised data, under Art. 4a(1)(a), and Art. 4a(1)(f) requires those reasons to be written into the records of processing activities. In the other direction, Art. 4a(1) does not displace the GDPR: the paragraph states that the processing meets Regulation (EU) 2016/679, so an Art. 6(1) basis and an Art. 9(2) condition are recorded on the GDPR side of the crosswalk as well. The obligation record for Art. 10 names the bias detection legal-basis record under Art. 4a(1)(f) as a separate artifact for that reason, and how strict the necessity test is remains the unsettled point shown above.
The second confusion sits in the automated-decisions row. Art. 22(1) of Regulation (EU) 2016/679 is a right of the data subject that attaches to a decision based solely on automated processing with legal or similarly significant effects; a human who reviews the output before the decision takes the decision outside Art. 22(1). Art. 14(4) of Regulation (EU) 2024/1689 is a design duty on the provider for every high-risk system, whether or not a human decides, and Art. 14(4)(b) asks for a measure against the tendency to over-rely on the output. A review step that takes a decision outside Art. 22(1) is therefore not by itself the evidence for Art. 14(4)(b), and the oversight measures list in step 6 records each measure against the provision it implements. The Limitations section of PR-27-FRIA v1.0 states the boundary from the other side: the protocol records the deployer's determination of its role and the counsel reference, and it does not assess the DPIA against its own legal basis.
What the result shows and what it does not
The crosswalk shows, for each comparison point, which article on each side reaches the system and which record the organisation holds against it; it does not show that a record is correct in substance. The Limitations section of PR-27-FRIA v1.0 sets the boundary for the assessment rows: the protocol cannot show that the deployer is within Art. 27(1) or that the system is high-risk under Art. 6(2), the cross-reference check at step 30 shows that a cited DPIA section holds the content of the Art. 27(1) element it is cited for, and the protocol does not assess the DPIA against Art. 35 of Regulation (EU) 2016/679. The GDPR side of the crosswalk is a map of articles to records made from the documents the organisation supplies; no step of this guide tests a GDPR obligation, and the determination of controller or processor status stays with the organisation and its counsel. The Act-side records follow the specifications on the deliverables page, where the FRIA record specification carries the cross-reference section. The FRIA facilitation and evidence structuring service runs the full protocol, within the limits stated on what we cannot do.
Related pages
The two obligations, the protocol, the related guides and the hubs for the two roles this guide serves are listed below; every protocol on the site is on the methodology index.
- Protocols
- Related guides
- ICP hubs
Questions
What is the difference between the EU AI Act and the GDPR?
Regulation (EU) 2024/1689 regulates AI systems by risk class and places duties on providers and deployers, defined by the system under Art. 3(3) and 3(4). Regulation (EU) 2016/679 regulates the processing of personal data and places duties on controllers and processors, defined by the processing under Art. 4(7) and 4(8). Art. 2(7) of the Act keeps the GDPR in place. The Act creates one individual right, the Art. 86 explanation; the GDPR creates the Chapter III rights and the Art. 6 legal basis requirement, which the Act does not have.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.