Teams running an AI system that processes personal data in the EU face two regulations that ask overlapping questions in different words, and most organisations answer them twice in two documents that never meet. The GDPR governs the personal data; the EU AI Act (Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744) governs the AI system as a product. Article 2(7) of the AI Act states that it does not affect the GDPR, so both apply in full. This guide is an overlap map, not a summary of either law: it sets the DPIA beside the fundamental rights impact assessment (FRIA), Article 10 data governance beside lawful basis and special category rules, GDPR Article 22 beside AI Act Article 14 oversight, and ends with a combined evidence workflow. It is for privacy, AI governance and security leads who want one assessment trail that satisfies both. Status was checked on 13 November 2026.
Key takeaways
- Both apply, neither replaces the other. Article 2(7) keeps the GDPR intact, and the AI Act's own personal data provisions (Articles 4a and 59) work alongside it. A compliant conformity assessment is not a lawful basis, and a lawful basis is not a conformity assessment.
- The FRIA is built to reuse the DPIA. Article 27(4) lets a deployer cross-reference a GDPR Article 35 DPIA where it already covers FRIA elements, and Article 26(9) tells deployers to use the provider's Article 13 information for the DPIA. Run them as one workflow with two outputs.
- Article 10 sets data quality, not permission. Representative, error-free training data is an AI Act duty; the right to process that data still comes from GDPR Articles 6 and 9. Special category data for bias correction is allowed only under the Article 4a conditions.
- Article 14 oversight and Article 22 human intervention are different humans doing different jobs. Article 14 is designed-in control over the system; Article 22(3) is a right of the individual to have a person reconsider their case. One reviewer can do both only with the authority and information each requires.
- Combined evidence saves effort only if roles are mapped first. A provider is often a GDPR processor or a separate controller, and a deployer is usually the controller. Assign each artefact to the party the law puts the duty on.
Status and the short answer
| Item | EU AI Act | GDPR |
|---|---|---|
| Instrument | Regulation (EU) 2024/1689, amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744 | Regulation (EU) 2016/679, in force since 24 May 2016 and applying since 25 May 2018 |
| What it regulates | AI systems and general-purpose AI models placed on the market, put into service or used | Processing of personal data |
| Key dates for this comparison | High-risk obligations: 2 December 2027 for Annex III systems, 2 August 2028 for Annex I systems (Article 113, as amended) | Applies now |
| Pending change | None affecting this map as of the check date | The Digital Omnibus proposal COM(2025) 837, procedure 2025/0360(COD), would amend the GDPR; the European Parliament procedure file shows it awaiting committee decision with no adoption recorded |
The short answer: the GDPR asks whether you may process this personal data and how you protect the people it describes; the AI Act asks whether this AI system is safe and rights-respecting enough to place on the market and use. Where a system is high-risk and processes personal data, the questions converge on four seams: impact assessment, training data, human involvement and transparency. Both carry fines for the same system: up to EUR 15 million or 3% for AI Act operator obligations (Article 99(4)), and up to EUR 20 million or 4% under GDPR Article 83(5).
Roles: provider and deployer vs controller and processor
| Situation | AI Act role | Typical GDPR role | Consequence |
|---|---|---|---|
| Vendor trains a model on its own collected data and sells the system | Provider | Controller for training | Vendor owns Article 10 and the lawful basis for training |
| Customer uses the vendor's system on its own customers' data | Deployer | Controller for use | Customer owns the DPIA, Article 22 safeguards and, where it applies, the FRIA |
| Vendor hosts the system and processes customer data only on instructions | Provider | Processor (Article 28 contract) | Vendor supplies Article 13 information that feeds the customer's DPIA |
| Vendor reuses customer inputs to improve its model | Provider | Controller for that reuse | Vendor needs its own lawful basis; a processor contract alone does not cover it |
| Organisation builds and uses its own system | Provider and deployer | Controller | One organisation holds every artefact; the easiest case for a single workflow |
The two role models do not map one to one. GDPR Article 4(7) makes the controller whoever determines the purposes and means of processing; the AI Act provider is whoever develops a system and places it on the market or puts it into service under its own name. The EU AI Act Provider vs Deployer Obligations Guide and the GDPR Article 28 Processor Guide cover each side.
The overlap map
| Seam | EU AI Act | GDPR | Relationship | Combined evidence |
|---|---|---|---|---|
| Impact assessment | FRIA by certain deployers before first use (Article 27); provider risk management (Article 9) | DPIA where processing is likely to result in a high risk (Article 35) | Overlap; explicit cross-reference allowed (Article 27(4)) | One assessment record with DPIA and FRIA sections |
| Training data | Quality, representativeness, bias examination (Article 10) | Lawful basis (Article 6), special categories (Article 9), minimisation and purpose limitation (Article 5) | Complementary; possible tension between representativeness and minimisation | Dataset record holding both the Article 10 datasheet and the lawful basis analysis |
| Bias data | Special category data for bias detection and correction only if strictly necessary, under Article 4a(1)(a) to (f) | Article 9 prohibition with listed exceptions | Article 4a applies alongside the GDPR; conditions stack | Article 4a(1)(f) necessity record doubles as Article 30 processing record entry |
| Human involvement | Human oversight by design (Article 14) and assigned by the deployer (Article 26(2)) | Right not to be subject to solely automated decisions, with human intervention (Article 22) | Different purposes; can share staff | Oversight role description and review log fields that serve both |
| Transparency to individuals | Inform persons subject to Annex III systems (Article 26(11)); right to explanation (Article 86) | Information on automated decision-making and its logic (Articles 13(2)(f), 14(2)(g), 15(1)(h)) | Article 86 applies only where Union law does not already provide the right | One notice layer and one explanation template |
| Logs | Automatic logs (Article 12); deployers keep them at least six months unless other law, including data protection law, says otherwise (Article 26(6)) | Storage limitation (Article 5(1)(e)); security of processing (Article 32) | Tension managed by the Article 26(6) carve-out | Retention schedule that names the legal basis for each log class |
DPIA vs FRIA
The DPIA and FRIA answer related questions about the same deployment, so they are best run together. They are not interchangeable: a DPIA looks at risks arising from processing personal data, while a FRIA looks at the risks the AI system's use poses to the fundamental rights of affected groups, whether or not personal data is the cause.
| Element | DPIA (GDPR Article 35) | FRIA (AI Act Article 27) |
|---|---|---|
| Who | Controller | Deployers that are bodies governed by public law, private entities providing public services, and deployers of Annex III 5(b) credit scoring and 5(c) life and health insurance systems |
| Trigger | Processing likely to result in a high risk; always for systematic and extensive evaluation including profiling with legal or similarly significant effects, large-scale special category processing, and large-scale monitoring of public areas (Article 35(3)) | Before deploying an Annex III high-risk system covered by Article 6(2), except critical infrastructure (Annex III point 2) |
| Core content | Description and purposes; necessity and proportionality; risks to rights and freedoms; measures (Article 35(7)) | Deployer processes; period and frequency of use; affected categories; specific risks of harm using provider information; oversight measures; actions if risks materialise, including governance and complaints (Article 27(1)) |
| Stakeholders | Seek views of data subjects or representatives where appropriate (Article 35(9)); DPO advice | No equivalent consultation duty in Article 27 |
| Who receives it | Supervisory authority only through prior consultation where high residual risk remains (Article 36(1)) | Market surveillance authority is notified of the results using the AI Office template (Article 27(3), (5)) |
| Reuse | Uses provider Article 13 information (AI Act Article 26(9)) | Cross-references the DPIA where it already meets FRIA obligations (Article 27(4)) |
| Updates | Review when the risk changes | Update when any element changes or becomes outdated (Article 27(2)) |
- What the DPIA covers that the FRIA does not: lawful basis, necessity of each data item, security of processing and transfers.
- What the FRIA covers that the DPIA often misses: harms to groups that do not depend on the data being personal, such as exclusion from a benefit because the system performs poorly for a population, and the deployer's complaint and governance mechanism.
- Practical rule: write the DPIA first, then add the FRIA's group-harm and oversight sections and cross-reference. See the DPIA Guide and the EU AI Act Fundamental Rights Impact Assessment.
Article 10 data governance vs lawful basis
Article 10 tells a provider what good training, validation and testing data looks like: governance practices covering design choices, collection, preparation, examination for bias and gap identification (Article 10(2)), and data that is relevant, sufficiently representative, as free of errors as possible and complete (Article 10(3)), suited to the setting of use (Article 10(4)). None of that confers permission to use the data. The lawful basis, purpose compatibility and special category exceptions come from the GDPR.
Where the two pull in different directions
- Representativeness vs minimisation: Article 10(3) pushes towards broader data to cover the population of use; GDPR Article 5(1)(c) limits data to what is necessary. Resolve it by recording why each attribute is needed for representativeness or bias testing, which is both the Article 10(2) design record and the GDPR necessity argument.
- Bias testing vs Article 9: testing for discrimination often needs ethnicity, health or other special category data. The Digital Omnibus deleted Article 10(5) and added Article 4a. Providers of high-risk systems may process special category data where strictly necessary for bias detection and correction under Article 10(2)(f) and (g), and Article 4a(2) extends a similar permission to deployers of high-risk systems and to providers and deployers of other systems, without creating a duty to test. Every Article 4a(1) condition applies: other data, including synthetic or anonymised data, cannot do the job; technical limits on reuse and pseudonymisation; strict, documented access; no transfer to other parties; deletion once the bias is corrected or the retention period ends; and a record of why the processing was strictly necessary. Article 4a applies alongside the GDPR, so the Article 9(2) analysis is still needed. See the EU AI Act Article 10 Data and Data Governance Guide.
- Repurposing data: outside a regulatory sandbox, reusing customer data for training is a GDPR purpose compatibility question. Inside a sandbox, Article 59 allows further processing for public-interest AI only under cumulative conditions, including that anonymised or synthetic data cannot meet the requirement and that the processing leads to no measures or decisions about data subjects.
- Anonymity of models: the EDPB adopted Opinion 28/2024 on data protection aspects of processing personal data in the context of AI models on 18 December 2024. Treat any claim that a trained model is anonymous, and therefore outside the GDPR, as a position to document and test, not an assumption.
Article 22 vs Article 14 oversight
A human "in the loop" for Article 14 does not by itself take decisions out of Article 22: the two provisions protect different things.
| Question | GDPR Article 22 | AI Act Article 14 (with Article 26(2)) |
|---|---|---|
| Whose protection | The individual data subject | Health, safety and fundamental rights generally, including foreseeable misuse |
| Trigger | A decision based solely on automated processing, including profiling, with legal or similarly significant effects | Any high-risk AI system, whatever the decision model |
| What the human does | On request, intervenes in the individual case; the person can express a view and contest (Article 22(3)) | Understands capabilities and limits, monitors for anomalies, stays aware of automation bias, interprets output, decides not to use, overrides or reverses, and can halt the system (Article 14(4)(a) to (e)) |
| Who designs it | Controller | Provider builds oversight measures in or specifies them; deployer assigns competent people with authority and support |
| When it bites | Per decision | Continuously, across the system's operation |
| Special data | Solely automated decisions on special category data only under Article 9(2)(a) or (g) with safeguards (Article 22(4)) | Two-person verification for remote biometric identification results (Article 14(5)), with listed exceptions |
- Scoring by one party, deciding by another: in Case C-634/21 SCHUFA (7 December 2023) the Court of Justice ruled that the automated establishment of a probability value by a credit information agency is automated individual decision-making under Article 22(1) where a third party to which it is transmitted draws strongly on it to establish, implement or terminate a contractual relationship. An AI provider that only produces a score can therefore be inside Article 22, not just the lender.
- Automation bias is the shared failure: Article 14(4)(b) names it. A reviewer who accepts nearly every recommendation provides oversight on paper only, and regulators applying Article 22 look at whether review is meaningful. The same evidence (override rates, time spent, information available to the reviewer) answers both.
- Explanation: Article 86 gives a right to a clear and meaningful explanation of the AI system's role and the main elements of a decision for Annex III systems (except point 2), but only where Union law does not already provide it. Where GDPR Articles 13 to 15 and 22 already supply meaningful information about the logic, build one explanation template and map it to both. See the EU AI Act Article 14 Guide.
Combined assessment workflow
- Inventory and classify: for each AI system record whether it processes personal data, whether it is high-risk (Annex III area, Article 6(3) derogation decision, noting that profiling blocks the derogation) and whether Article 27 applies to the deployer. Use the AI Register and AI Inventory Template.
- Map roles: AI Act role and GDPR role per party, per processing stage (training, hosting, inference, model improvement), and put Article 28 terms or joint controller arrangements in place.
- Collect provider inputs: Article 13 instructions for use, accuracy metrics, known limitations and oversight measures. Under Article 26(9) these feed the DPIA.
- Run the DPIA: processing description, lawful basis, Article 9 route, necessity, Article 22 classification of each output, security under Article 32, residual risk and whether Article 36 prior consultation is needed.
- Extend into the FRIA where required: add affected groups, group-level harms, oversight implementation and complaint mechanisms, cross-referencing DPIA sections under Article 27(4), and notify the market surveillance authority.
- Record data governance: link the Article 10 dataset documentation and any Article 4a necessity record to the DPIA's data inventory.
- Test before go-live: pilot with oversight staff, measure override rates and explanation quality, and confirm that individuals can request human intervention and an explanation.
- Review on change: a model update, a new data source or a new affected population triggers review of both outputs together; keep one change log.
Worked scenario: a CV screening tool in a European employer
An employer licenses an AI tool that ranks job applicants and flags the top 20% for interview; recruiters rarely look below the cut.
- AI Act: recruitment and screening is Annex III 4(a), so the system is high-risk from 2 December 2027. The vendor is the provider. The employer is the deployer and must assign oversight (Article 26(2)), inform workers' representatives and affected workers before use (Article 26(7)), inform applicants that they are subject to the system (Article 26(11)) and keep logs. As a private employer not providing a public service, it is not within Article 27, so no FRIA is mandatory.
- GDPR: the employer is controller. Ranking applicants is systematic evaluation of personal aspects, so a DPIA is required under Article 35(3)(a). Because recruiters rarely look below the cut, rejection of lower-ranked applicants is very close to a solely automated decision with similarly significant effects, which brings Article 22 into play.
- Combined fix: the DPIA uses the vendor's Article 13 information; recruiters review a sample below the cut each week and record overrides, which is both Article 14 oversight evidence and the Article 22 meaningful review argument; one applicant notice covers Article 13(2)(f) and Article 26(11); and the employer voluntarily adds FRIA-style group harm analysis to the DPIA for gender and age, using Article 4a only if the vendor cannot supply bias test results.
- Identity angle: the integration between the applicant tracking system and the vendor's model runs on an API credential. Scope it to the screening dataset, give it its own identity, and record which identity and model version produced each ranking so logs serve Article 12 and the DPIA's security section. See the EU AI Act for AI Agents.
Common failure patterns
- Two assessments that disagree: the DPIA calls the system advisory while the FRIA or Article 14 documentation describes reliance on its output. Regulators can read both.
- Treating Article 10 as a lawful basis: a well-documented dataset with no GDPR basis for its original collection or reuse.
- Using Article 4a as a general licence: processing special category data for bias work without the strict necessity record, the deletion trigger or the access log.
- Rubber-stamp review: an oversight role that never overrides, which fails Article 14's automation bias aim and weakens any argument that the decision is not solely automated.
- Retention conflict left unresolved: logs deleted early to satisfy storage limitation, or kept indefinitely "for the AI Act", with no documented basis for either.
- Wrong party holding the duty: a vendor processor drafting the customer's DPIA, or a customer assuming the vendor's conformity assessment covers its own Article 26 duties.
Detection and measurement
- Assessment linkage: percentage of high-risk systems processing personal data with a DPIA that cross-references the FRIA or Article 9 record.
- Override rate: share of AI recommendations changed by reviewers, tracked per system; persistent rates near zero warrant review.
- Explanation turnaround: time from an access or explanation request to response, against the GDPR one-month baseline in Article 12(3).
- Article 4a hygiene: special category datasets used for bias work with a necessity record, an access log and a scheduled deletion date.
Framework mapping
| Framework | Reference | Supports |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 | Legal, regulatory and privacy obligations understood and managed |
| NIST CSF 2.0 | ID.AM-07 | Data inventories and metadata for training and inference datasets |
| NIST SP 800-53 Rev 5 | RA-8 | Privacy impact assessment, the base of the combined DPIA and FRIA |
| NIST SP 800-53 Rev 5 | PT-2, PT-3 | Authority to process and purpose specification, the lawful basis analogue |
| NIST SP 800-53 Rev 5 | PM-25 | Minimising personal data used in testing, training and research |
| NIST SP 800-53 Rev 5 | SI-12, AU-11 | Retention of information and audit records, for the log retention seam |
For a management-system view, see EU AI Act vs ISO/IEC 42001.
Practitioner checklist
- Record AI Act and GDPR roles per party and per processing stage for every AI system that touches personal data.
- Run one assessment workflow: DPIA first, FRIA sections added and cross-referenced under Article 27(4) where Article 27 applies.
- Obtain provider Article 13 information before the DPIA and cite it.
- Keep the Article 10 dataset record and the lawful basis analysis in one dataset file.
- Use Article 4a only with a written strict necessity record, pseudonymisation, access logs and a deletion trigger, alongside an Article 9(2) route.
- Classify each output against Article 22, taking account of SCHUFA where scores are passed to another party.
- Give oversight staff authority to override and measure their override rate.
- Set a retention schedule for logs that states the AI Act and GDPR basis for each period.
Standards and references
- EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
- European Commission AI Act Service Desk: Article 27, Fundamental rights impact assessment
- European Commission AI Act Service Desk: Article 4a, Processing of special categories of personal data
- European Commission AI Act Service Desk: Article 14, Human oversight
- European Commission AI Act Service Desk: Article 26, Obligations of deployers of high-risk AI systems
- Court of Justice of the EU: Case C-634/21 SCHUFA Holding (Scoring)
- EDPB: Opinion 28/2024 on data protection aspects of AI models
- European Parliament Legislative Observatory: Digital Omnibus, 2025/0360(COD)
Related NHI Mgmt Group resources: AI and GDPR Guide · EU AI Act Compliance Guide · EU AI Act Fundamental Rights Impact Assessment · AI Risk Assessment vs AI Impact Assessment. This guide summarises the overlap between the EU AI Act and the GDPR as of 13 November 2026 and is not legal advice.