EU AI Act vs GDPR overlap: how the two regimes interact in 2026

The GDPR (Regulation (EU) 2016/679) regulates the processing of personal data of individuals in the EU, regardless of where the controller or processor is located. Its obligations attach to controllers and processors, are organised around lawful bases, data-subject rights, transparency, security, transfers, accountability and impact assessment, and are enforced by national supervisory authorities under the European Data Protection Board's coordination.

The EU AI Act (Regulation (EU) 2024/1689) regulates AI systems and general-purpose AI models placed on the market or put into service in the EU. Its obligations attach to providers, deployers, importers and distributors, are organised around four risk classes (prohibited, high-risk, limited-risk, minimal-risk) plus general-purpose AI obligations, and are enforced by national competent authorities and the European Commission's AI Office [1].

Six concrete overlaps. First, impact assessments: GDPR Article 35 requires a DPIA for high-risk processing of personal data; AI Act Article 27 requires a Fundamental Rights Impact Assessment for certain high-risk AI deployers. The two assessments share substantial content but are not identical, and Article 27 explicitly says it does not replace the DPIA [2]. Second, transparency: GDPR Articles 13-15 require information to data subjects; AI Act Articles 13 and 50 require information to deployers and to natural persons interacting with AI systems. Third, automated decisions: GDPR Article 22 governs solely automated decisions with significant effects; AI Act Article 14 governs human oversight of high-risk systems.

Fourth, data governance: GDPR Articles 5 and 6 set the lawful-basis and quality principles; AI Act Article 10 sets training-data quality, bias-mitigation and special-category-handling rules. Fifth, accountability and records: GDPR Article 30 records of processing meet AI Act Article 11 technical documentation in practice but use different templates. Sixth, security: GDPR Article 32 meets AI Act Article 15 (accuracy, robustness, cybersecurity) on the security strand.

The first divergence is scope. GDPR applies to any processing of personal data; the AI Act applies to AI systems regardless of whether they process personal data. A purely synthetic-data AI system can be in scope of the AI Act and out of scope of GDPR. A non-AI personal-data process is in scope of GDPR and out of scope of the AI Act. The intersection is where most enterprise AI sits.

The second divergence is the operative entity. GDPR's central role is the controller; the AI Act's central role is the provider. The same legal entity is often both, but not always. A bank deploying a vendor-built credit-scoring system is the GDPR controller and the AI Act deployer, while the vendor is the processor and the provider. The contract has to allocate both sets of obligations cleanly. Third, supervision. GDPR is supervised by data-protection authorities; the AI Act is supervised by national competent authorities (often different bodies) and the AI Office. Coordination mechanisms exist but are still maturing.

Fourth, fines. GDPR caps at EUR 20 million or 4% of global annual turnover. The AI Act caps at EUR 35 million or 7% of global annual turnover for prohibited-practice infringements, EUR 15 million or 3% for high-risk obligation breaches, and EUR 7.5 million or 1% for documentation failures. The risk profile for high-impact AI is therefore materially higher under the AI Act than under GDPR alone [1].

The pragmatic sequence is risk-classify first, then document once for both. Step one: classify the AI system under the AI Act risk taxonomy (prohibited / high-risk / limited / minimal / GPAI). Step two: assess whether personal data is processed and identify the GDPR roles (controller / processor / joint controllers). Step three: run a single combined assessment that produces the Article 35 DPIA and the AI Act Article 27 FRIA in one documented exercise, with the personal-data parts feeding the DPIA and the fundamental-rights parts feeding the FRIA. Step four: build the technical documentation pack to satisfy both Article 30 GDPR and Annex IV of the AI Act, structured so each clause is named to one or both.

Step five: design human oversight to meet the higher of Article 14 AI Act and Article 22 GDPR (in practice, Article 14 sets the higher bar). Step six: integrate post-market monitoring (AI Act Article 72) with the GDPR breach-notification and supervisory cooperation processes. Step seven: align the contractual stack - DPA, master services agreement, AI Act provider/deployer obligations - on a single template. The European Data Protection Board's guidelines on Article 22 and the upcoming joint EDPB/AI Office guidance will be the canonical references for the boundary [3].

Five recurring traps. First, treating the AI Act as a "GDPR for AI" - it is structured very differently and does not replace any GDPR obligation. Second, running the DPIA and FRIA as separate workstreams instead of one combined assessment, doubling the work and producing inconsistent documentation. Third, missing the role distinction: the GDPR controller is not always the AI Act provider, and the contract has to allocate both. Fourth, defaulting to "consent" as the GDPR lawful basis for AI training when contract performance, legitimate interests, or specific legal basis would be more defensible and more sustainable. Fifth, treating ISO/IEC 42001 as proof of AI Act compliance - it is the management-system layer, not the conformity-assessment layer [4].

The Bank for International Settlements' 2024 paper on generative AI in finance is a useful cross-reference for sequencing under sector regulation, where DORA, MiFID II and similar regimes layer on top of GDPR and the AI Act [5].

Impetora's TRACE methodology was built for the dual-regime reality. Trust covers the GDPR-on-AI baseline: residency, processing register, DPA stack, lawful-basis design, transfer mechanisms. Readiness produces the combined DPIA/FRIA in a single exercise per system. Architecture builds the technical documentation pack to satisfy Annex IV of the AI Act and Article 30 of the GDPR from one source. Citations and Evidence delivers the per-decision traceability that makes Article 15(1)(h) GDPR access requests and AI Act Article 13 transparency obligations operationally satisfiable.

The practical procurement test for buyers is to ask the vendor for a sample combined DPIA/FRIA from a comparable past project. A vendor that has done dual-regime work can produce one. A vendor that hands back a separate DPIA template and a separate FRIA template has not yet integrated the two regimes operationally.