Your AI hiring tool passed its EU AI Act conformity assessment in June 2026. Three months later, a rejected applicant files a GDPR Article 22 complaint. She demands a human review of the decision and a meaningful explanation of the logic involved.
Your system was designed for human oversight under Art. 14 of the AI Act. A manager reviewed the algorithmic recommendations before each decision. But the manager approved 97% of them without change. Under GDPR, that probably does not count as meaningful human intervention. The Austrian Federal Administrative Court said as much in its AMS algorithm ruling of September 2025 (Case W256 2235360-1/36E), where it defined a clear line between genuine oversight and rubber-stamping. Under the AI Act, your system passed its conformity assessment.
Which law wins? Neither. Both apply independently. And in this case, they point in different directions.
The standard line about the EU AI Act and GDPR is that they “complement each other.” Osborne Clarke says it. Matproof says it. The pitch.law analysis says it. And they are roughly half right. In the areas where both regulations address the same obligation from different angles, your GDPR program gives you a genuine head start. But in at least five areas, the two laws create tensions that a harmonization checklist cannot resolve. Organizations need a conflict-resolution protocol. That is what this article provides.
Where They Actually Align
Before the contradictions, the good news. If your organization has a mature GDPR compliance program, approximately 40-50% of your AI Act work is already done.
| Shared Ground | GDPR | AI Act | What Transfers |
|---|---|---|---|
| Transparency | Arts. 13-14 | Art. 13 | Privacy notices expand to include AI system capabilities and limitations |
| Documentation | Art. 30 | Art. 11 + Annex IV | Records of processing become technical documentation. AI Act requires more detail: architecture, performance metrics, development methods |
| Risk-based approach | Art. 35 (DPIA) | Art. 9 | Risk assessment methodology transfers. GDPR is point-in-time; AI Act is continuous lifecycle |
| Data quality | Art. 5(1)(d) | Art. 10 | Accuracy obligation broadens to representativeness and bias examination |
| Privacy by design | Art. 25 | Art. 9 | Design-stage thinking extends from data protection to full risk management |
| Supervisory relationship | Art. 51 (DPAs) | Art. 70 (MSAs) | Experience engaging with regulators, responding to inquiries, managing audits |
The documentation muscles, the risk assessment processes, the regulatory liaison experience from eight years of GDPR enforcement all carry forward. The remaining 50-60% is where the pain lives.
The Five Contradictions
1. Right to Erasure vs. Model Permanence
A data subject exercises their Art. 17 GDPR right and demands deletion of their personal data. Your organization deletes it from your databases, your CRM, your analytics. But the data also trained your machine learning model. The individual’s information influenced the model’s weights during training. Removing that influence surgically is not possible without retraining from scratch.
The EDPB addressed this directly in Opinion 28/2024, adopted December 17, 2024. The Board’s position: AI models trained on personal data are not automatically anonymous. Whether a model constitutes personal data requires a case-by-case assessment under GDPR Recital 26, examining whether “all the means reasonably likely to be used” could identify individuals from the model. Both the risk of direct extraction and the risk of obtaining personal data through queries must be “insignificant.”
If the model is genuinely anonymous, GDPR obligations including erasure may not apply to the model itself. But the bar is high, and the EDPB left room for DPA-by-DPA divergence.
The AI Act is silent on this question. Art. 10 requires representative, high-quality, error-free training data. It says nothing about what happens to that data’s influence after training is complete.
What organizations need: a documented erasure protocol that specifies whether the model can regenerate training data, the feasibility of retraining, and evidence supporting any anonymization claim. EDPB Opinion 28/2024 provides the analytical framework, but until national DPAs issue enforcement decisions, the practical answer remains uncertain.
2. Bias Testing vs. Special Category Data Prohibition
You cannot test an AI system for racial bias without knowing the race of the people in your test data. But GDPR Art. 9 prohibits processing special category data, including race, ethnicity, health status, and sexual orientation, unless a specific legal exception applies.
Art. 10(5) of the AI Act creates a narrow carve-out: providers of high-risk AI systems may process special category data “to the extent that it is strictly necessary for the purposes of ensuring bias monitoring, detection and correction.” The conditions are restrictive. The data must be subject to appropriate safeguards, including pseudonymization. Processing must be proportionate. And the carve-out is limited to bias testing, not general system development.
This is already a compromise. The Digital Omnibus proposal would expand it further, introducing a new Art. 4a that extends the exception to providers and deployers of all AI systems and models, not just high-risk ones. The EDPB and EDPS, in Joint Opinion 1/2026 adopted January 20, 2026, acknowledged that bias correction can prevent discrimination. But they recommended limiting the expanded exception to situations where the risk of harm is serious, with appropriate safeguards.
The tension is real: the AI Act demands bias testing. GDPR restricts access to the data needed to perform it. Art. 10(5) is a bridge, but it is a narrow one. Organizations need documented necessity assessments for every special category dataset used in bias testing, anonymization or deletion of the test data after use, and DPO sign-off confirming the legal basis.
3. Consent Withdrawal vs. Ongoing AI Operation
GDPR Art. 7(3) gives data subjects the right to withdraw consent at any time, and withdrawal must be as easy as giving consent. This creates a specific problem for AI systems that rely on consent as their Art. 6 lawful basis and process data continuously.
If a user withdraws consent from an AI-powered service, the system must stop processing their data. But what about decisions already made? What about the model that already trained on their data before withdrawal?
EDPB Opinion 28/2024 points toward an answer, at least for the lawful basis question. The Board confirmed that legitimate interest under Art. 6(1)(f) can serve as a legal basis for AI model development and deployment. It cannot be the default, and controllers must document a three-step test: identifying the legitimate interest, assessing necessity, and conducting a balancing exercise. But for AI systems where consent withdrawal would be technically impossible to implement at the model level, legitimate interest is the more defensible foundation.
The practical recommendation: do not build AI consent architecture on GDPR consent alone. Where legitimate interest is available and defensible, use it. Where consent is the only option, ensure withdrawal is technically implementable at the system level. The AI Act does not address this tension directly. It creates obligations that assume continuous data processing but does not reconcile those obligations with GDPR’s consent framework.
4. Automated Decision Scope
This is where CJEU case law has fundamentally reshaped the landscape and no competitor article has caught up.
GDPR Art. 22 applies to decisions based “solely” on automated processing that produce legal effects or similarly significant effects. It is a binary gate: either the decision is solely automated, or it is not. If human involvement is meaningful, Art. 22 does not apply.
AI Act Art. 14 requires human oversight for all high-risk AI systems, regardless of whether individual decisions are “solely automated.” There is no binary gate. The obligation is continuous.
Two CJEU judgments define the boundaries. In C-634/21 SCHUFA (December 7, 2023), the Court ruled for the first time that credit scoring by a reference agency constitutes automated individual decision-making under Art. 22, even when a third party (the bank) makes the final lending decision, because the score “predominantly determines” the outcome. In C-203/22 CK v Magistrat der Stadt Wien (February 27, 2025), the Court confirmed that Art. 15(1)(h) requires controllers to provide meaningful information about the logic involved in automated decisions. A bare algorithm description is insufficient. The explanation must enable the data subject to understand which of their personal data were used and how their specific outcome was reached. Trade secrets cannot categorically override this disclosure obligation. A case-by-case balancing of interests is required.
The Austrian BVwG’s AMS ruling (September 1, 2025) drew the practical line. The Austrian employment service’s algorithm (AMAS) passed the Art. 22 test because employment advisors could access additional information beyond the score, were required to deviate from the algorithmic recommendation when warranted, and had technical safeguards preventing the algorithm from overriding human corrections. That is what “genuine” human oversight looks like.
The conflict for organizations: a system with nominal human oversight might satisfy AI Act Art. 14’s design requirements but still trigger GDPR Art. 22 if the human does not genuinely intervene in practice. Conversely, a system with robust human involvement may escape Art. 22 entirely but still need full Art. 14 compliance by design. The two laws measure human oversight from different directions, with different consequences for failure.
5. Impact Assessment Independence
AI Act Art. 27(4) is unambiguous: a Fundamental Rights Impact Assessment cannot replace a Data Protection Impact Assessment, and a DPIA cannot replace a FRIA. Where an AI system is both high-risk under the AI Act and processes personal data in a way that triggers GDPR Art. 35, both assessments are independently mandatory.
The two assessments overlap but serve different purposes. A DPIA examines risks to data protection rights specifically. A FRIA examines the full spectrum of fundamental rights: equality, non-discrimination, dignity, access to effective remedies, and domain-specific rights like workers’ right to fair conditions or children’s rights in educational contexts.
Art. 27(4) does allow for coordination. If a DPIA already covers some elements relevant to the FRIA, the FRIA can complement rather than duplicate those elements. But the deployer must demonstrate that both sets of requirements are fully satisfied.
As of April 2026, the AI Office has not published the official FRIA template required under Art. 27(5), despite the obligation taking effect on August 2, 2026. DPIA templates are available from every major DPA. The FRIA guidance vacuum means organizations are building their fundamental rights assessments from the FRA’s 2025 report and private-sector templates, not from any official instrument.
The practical consequence: two mandatory assessments, overlapping scope, one missing official template, and no joint EDPB-Commission guidance on how to coordinate them despite it being promised for early 2026.
The Article-by-Article Matrix
For organizations conducting a gap analysis between existing GDPR programs and new AI Act obligations, this table maps the specific provisions.
| AI Act Provision | GDPR Provision | Relationship | Compliance Action |
|---|---|---|---|
| Art. 9 (risk management) | Art. 35 (DPIA) | Supplement | Extend DPIA methodology to continuous lifecycle. Document ongoing monitoring triggers. |
| Art. 10 (data governance) | Art. 5(1)(d) (accuracy) + Art. 6 (lawful basis) | Complement | Add representativeness and bias examination to data quality processes. Document Art. 6 basis for training data per EDPB Opinion 28/2024. |
| Art. 11 (technical docs) | Art. 30 (records) | Supplement | Expand processing records with Annex IV technical documentation: architecture, metrics, development methods. |
| Art. 13 (transparency) | Arts. 13-14 (info to data subjects) | Overlap | Extend privacy notices with AI-specific disclosures: capabilities, limitations, human oversight measures. |
| Art. 14 (human oversight) | Art. 22 (automated decisions) | Conflict | Design oversight to satisfy both: meaningful intervention (AMS ruling standard), not rubber-stamping. |
| Art. 26 (deployer obligations) | Art. 28 (processor obligations) | Parallel | Map deployer obligations to existing processor agreements. Update contracts. |
| Art. 27 (FRIA) | Art. 35 (DPIA) | Complement (independent) | Conduct DPIA first (templates exist), then supplement with FRIA for non-data rights. |
| Art. 72 (post-market monitoring) | Art. 5(1)(d) (accuracy) + Art. 32 (security) | Supplement | Build structured monitoring system. GDPR accuracy and security obligations are ongoing but lack the AI Act’s formal monitoring framework. |
| Art. 86 (right to explanation) | Art. 15(1)(h) + Rec. 71 | Narrowed gap | AI Act provides explicit right for high-risk AI. CJEU C-203/22 made Art. 15(1)(h) binding: meaningful explanation of decision logic required. Art. 86 still broader in scope. |
Five Sector Scenarios
HR Screening (Annex III Area 4)
An AI system shortlists candidates from 500 applications for a marketing director role. It processes names, work history, education, and inferred demographic patterns.
GDPR applies: Art. 22 (automated decision with significant effects on employment), Art. 9(1) (inferred ethnic origin from names), Art. 35 (DPIA mandatory). AI Act applies: Annex III Area 4 (employment, worker management), Art. 14 (human oversight), Art. 27 (FRIA required for public-sector deployers). Both FRIA and DPIA are mandatory. The core tension is Contradiction 2: testing for bias requires processing the protected characteristics GDPR restricts.
Credit Scoring (Annex III Area 5b)
A fintech company uses an AI model to generate credit scores for consumer loan applications.
GDPR applies: Art. 22 (per CJEU C-634/21 SCHUFA, credit scoring is automated decision-making), Art. 6 (lawful basis required), Art. 35 (DPIA). AI Act applies: Annex III Area 5(b) (creditworthiness assessment), Art. 14 (human oversight), Art. 27 (FRIA). The binding precedent from C-203/22 means the company must provide meaningful explanations of individual scoring decisions. Trade secrets do not exempt the company from this obligation. The AI Act’s conformity assessment adds separate documentation requirements on top.
Healthcare Triage (Annex III Area 5a + MDR)
A hospital deploys an AI system that triages emergency department patients by predicted severity.
Triple regulation applies: GDPR Art. 9(1) (health data is special category), Art. 35 (DPIA); AI Act Annex III Area 5(a) (access to essential services), plus the Medical Devices Regulation (EU) 2017/745 if the system qualifies as a medical device. Under Art. 6(1) of the AI Act, safety components of medical devices are automatically high-risk. The most direct path to conformity assessment is through existing MDR notified bodies, which can assess AI Act requirements under Art. 74 conditions. Cost premium over MDR-only: approximately EUR 20-40K.
Education AI (Annex III Area 3)
A university uses an AI system to flag students at risk of dropping out and recommend interventions.
GDPR applies: Art. 8 (age-based consent for under-16s varies by Member State), Art. 9 (potential health/disability data if the model uses accommodation records), Art. 35 (DPIA). AI Act applies: Annex III Area 3 (education and vocational training), Art. 14 (human oversight), Art. 27 (FRIA for public universities). The vulnerable group element matters: students facing dropout often have intersecting disadvantages. The FRIA must examine equality and non-discrimination impacts beyond what a DPIA covers. Children’s data heightens every obligation.
Biometric Access Control (Annex III Area 1)
A corporate headquarters deploys facial recognition for building access.
GDPR applies: Art. 9(1) (biometric data is special category), Art. 35 (DPIA mandatory). AI Act applies: Annex III Area 1 (biometrics). This is the most heavily regulated scenario. Because no harmonised standards are published, biometric systems require the third-party conformity assessment path under Annex VII. A notified body must assess the system. Both FRIA and DPIA are mandatory. And certain biometric uses are outright prohibited under Art. 5 if they involve untargeted scraping or real-time remote identification.
What Your DPO Needs to Know
If your organization has a Data Protection Officer, that person is the natural first responder for AI Act compliance. Not because the DPO should own the entire program, but because the skills that GDPR built are the closest analog to what the AI Act requires.
Skills that transfer directly: impact assessment methodology, vendor due diligence processes, data subject rights management, and regulatory liaison experience. Eight years of GDPR enforcement across EUR 5.8 billion in fines means DPOs understand how European regulators think and act.
Skills that do not transfer: technical model evaluation, conformity assessment documentation to Annex IV specifications, post-market monitoring system design, and the engineering judgment required to evaluate AI system performance metrics. These require technical expertise that most DPOs were not hired for.
The recommendation: DPO leads the GDPR-side obligations and coordinates the compliance program. A technical lead or AI governance specialist handles the AI Act’s system-specific requirements. A single governance committee ensures the two streams do not conflict. For organizations considering whether to create a dedicated AI Officer role or expand the DPO’s mandate, the structural question is not “DPO or AI Officer” but “how do they work together.”
A Dual-Compliance Protocol
Not five generic steps. A conflict-resolution protocol that addresses the specific tensions between GDPR and the AI Act.
| Step | Action | Output | Timeline |
|---|---|---|---|
| 1 | Inventory all AI systems that process personal data | System register cross-referenced with GDPR Art. 30 records of processing | 2 weeks |
| 2 | Classify each system: high-risk under AI Act? Art. 22 trigger under GDPR? Both? | Decision matrix per system with legal basis documented | 1 week |
| 3 | Map contradictions: for each system triggering both, identify which of the five conflicts apply | Conflict register (erasure, bias testing, consent, oversight scope, assessment independence) | 2 weeks |
| 4 | Conduct DPIA first (templates exist from CNIL, ICO, EDPB), then supplement with FRIA for non-data fundamental rights | Joint assessment document satisfying both Art. 35 GDPR and Art. 27 AI Act | 4-8 weeks |
| 5 | Design human oversight to satisfy both Art. 14 (AI Act) and Art. 22 (GDPR) | Oversight protocol with intervention metrics, deviation tracking, escalation paths. Benchmark: the AMS ruling standard | 2-4 weeks |
| 6 | Build erasure protocol following EDPB Opinion 28/2024 framework | Documented model anonymization evidence or retraining plan per system | 2-4 weeks |
| 7 | Establish governance coordination between DPO and AI compliance functions | Governance charter, meeting cadence, escalation paths, reporting lines | 1 week |
Total estimated timeline for an organization with an existing GDPR program and 3-5 high-risk AI systems: 12-20 weeks. For organizations starting from scratch on both GDPR and AI Act compliance, double the estimate and consider external support.
The Guidance Gap
One final observation. The EDPB and European Commission promised joint guidelines on the GDPR-AI Act interplay for early 2026. As of April 2026, those guidelines have not been published. The AI Office FRIA template required by Art. 27(5) has not been published. No common specifications under Art. 41 have been issued.
What does exist: EDPB Opinion 28/2024 on AI models and personal data. The CNIL’s 13 practical how-to sheets on AI development under GDPR, published in English on January 5, 2026. CJEU case law from C-634/21 and C-203/22 that is actively reshaping Art. 22’s scope.
These are the building blocks. They are not a complete framework. Organizations building dual-compliance programs today are doing so in a guidance vacuum, four months from a deadline. The five contradictions in this article are not academic problems. They are operational decisions that compliance teams must make now, with incomplete institutional guidance, at scale.
That is the reality that “GDPR and the AI Act complement each other” does not prepare you for.
Sources
Official Sources
- EU AI Act (Regulation (EU) 2024/1689) — EUR-Lex
- General Data Protection Regulation (Regulation (EU) 2016/679) — EUR-Lex
- EDPB Opinion 28/2024 on AI models and personal data — Adopted December 17, 2024
- EDPB-EDPS Joint Opinion 1/2026 on Digital Omnibus (AI) — Adopted January 20, 2026
- CJEU C-634/21 SCHUFA Holding (Art. 22 scope) — Judgment of December 7, 2023
- CJEU C-203/22 CK v Magistrat der Stadt Wien (Art. 15(1)(h)) — Judgment of February 27, 2025
- FRA: Assessing High-risk AI — Fundamental Rights Risks — 2025
- Austrian BVwG AMS ruling, Case W256 2235360-1/36E — September 1, 2025
National DPA Guidance
- CNIL: AI System Development — Recommendations to Comply with GDPR — English version published January 5, 2026
Analysis and Commentary
- aiactblog.nl: DPIA vs FRIA Practical Comparison
- Osborne Clarke: Interplay of EU AI Act and GDPR — March 2025
- pitch.law: AI Act Meets GDPR — March 9, 2026
Last reviewed: April 8, 2026. This article reflects the regulatory landscape as of the review date. EDPB-Commission joint guidelines on GDPR-AI Act interplay and the AI Office FRIA template remain unpublished.
Disclaimer: This content is for informational purposes only and does not constitute legal advice. Organizations should consult qualified legal counsel for compliance planning. Reg Intel is not a law firm and does not provide legal services.