The Five Conflict Points Nobody Maps Clearly
Conflict 1: DPIA vs. FRIA — Double Assessment Burden
GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) before processing likely to result in high risk to individuals — which covers most Annex III AI systems.
AI Act Article 27 requires a Fundamental Rights Impact Assessment (FRIA) before deploying certain high-risk Annex III systems.
These are not the same document. The FRIA must complement any DPIA already conducted — it does not replace it. In practice, organizations
must manage two overlapping assessment processes that cover some of the same ground (risk to individual rights) under different frameworks, with different templates, submitted to different authorities.
What to do: build a combined DPIA/FRIA template that satisfies bot requirements from a single assessment exercise, documenting which sections satisfy which obligation. Neither authority requires separate physical documents — but both require their specific content to be demonstrably present.
Conflict 2: The Logging Paradox
AI Act Article 12 mandates automatic logging of high-risk AI system operations to ensure traceability and enable post-market monitoring.
GDPR Articles 5 and 17 require data minimization (don't collect more than necessary) and the right to erasure (delete personal data on request).
The conflict: logs generated to satisfy AI Act Article 12 may contain personal data — user inputs, interaction records, decision parameters — that you didn't intend to collect as a separate dataset. Those logs are now personal data under GDPR, creating storage limitation, minimization, and potential erasure obligations on records you are legally required to keep for AI Act compliance purposes.
What to do: anonymize or pseudonymize log data at the point of capture where possible. Where personal data in logs is strictly necessary for traceability, document the legal basis under GDPR Article 6 and define a retention period proportionate to the AI Act's traceability purpose. The Article 12 obligation doesn't mandate indefinite retention — define the minimum period and delete beyond it.
Conflict 3: The Bias Detection Exception
AI Act Article 10(5) creates a narrow exception allowing providers of high-risk AI systems to process special category data (health, biometric, ethnicity) for the purpose of ensuring bias detection and correction.
GDPR Article 9 prohibits processing special category data except under specific, enumerated conditions.
These two exceptions are not the same list. Article 10(5) AI Act supplements GDPR Article 9 — it adds conditions on top of GDPR, it does not replace them. Both sets of conditions must be satisfied simultaneously. The most common mistake: treating the AI Act exception as its own standalone permission to process sensitive data for bias testing. It isn't. You still need a GDPR Article 9 basis.
What to do: map your Article 9 basis before relying on Article 10(5). The most relevant GDPR Article 9 basis for bias testing is likely Article 9(2)(g) — substantial public interest — which requires a domestic law basis in the relevant member state. Check national implementing legislation.
Conflict 4: Two Regulators, One Incident
When a serious incident occurs involving an AI system that processes personal data, two separate regulatory investigations may open simultaneously:
A Data Protection Authority investigating the GDPR angle (was personal data involved? was it processed lawfully? were rights affected?)
A National Market Surveillance Authority investigating the AI Act angle (did the system fail? was it a serious incident? was logging adequate?)
These bodies operate under different frameworks, have different timelines (GDPR: 72-hour breach notification; AI Act: 15-day serious incident report, 2 days for critical infrastructure), and may reach different conclusions about the same event.
What to do: establish a single incident response protocol that maps GDPR and AI Act notification obligations in parallel. The 72-hour GDPR clock is tighter than the AI Act's 15-day window — but the AI Act's 2-day window for critical infrastructure is tighter still. Identify which threshold applies to each system in advance, not during an incident.
Conflict 5: Human Oversight — Same Principle, Different Mechanics
GDPR Article 22 gives individuals the right not to be subject to solely automated decisions with significant effects — they can request human review.
AI Act Article 14 requires that high-risk AI systems be designed to enable effective human oversight during operation — a proactive design requirement, not just a reactive right.
The GDPR right is triggered by the data subject. The AI Act obligation is triggered by deployment. An organization can satisfy Article 22 by having a human review process available on request — and still fail Article 14 if that oversight mechanism isn't built into the system's design and actively functional during operation.
What to do: Article 14 compliance requires a physical mechanism — a halt/override control assigned to a named responsible person with defined authority. A policy document or an "available on request" process satisfies Article 22 but not Article 14.
Technical Resilience: Implementation Strategies
Moving toward a compliant future requires a shift in engineering culture. It is no longer enough for a model to be accurate; it must be auditable. This involves creating "technical passports" for every AI model, documenting its training data, its limitations, and its intended use case.
Effective eu ai act implementation requires robust data governance. This means cleaning datasets of prohibited content and ensuring that the "training, validation, and testing" phases are strictly separated and documented. When these processes are automated, compliance becomes a background task rather than an annual crisis.
Where They Align — Use Compliance Synergies
Not all interactions are conflicts. These five areas satisfy both frameworks simultaneously:
1. Data minimization / Article 10 AI Act training data quality GDPR's data minimization principle (Art. 5(1)(c)) aligns directly with AI Act Article 10's requirement that training, validation, and testing datasets be relevant, representative, and as free of errors as possible. Cleaning and minimizing training data satisfies both obligations at once.
2. Pseudonymization as a dual compliance tool The AI Act explicitly references pseudonymization as a reinforced security measure for sensitive data processing (INTA analysis confirms it adds "nontransmission" requirements). GDPR treats pseudonymization as a risk-reduction measure that may remove or reduce the requirement for some safeguards. Implementing pseudonymization before AI processing satisfies both frameworks simultaneously — and it's the most efficient single architectural decision available.
3. Technical documentation + Records of Processing Activities GDPR Article 30 requires Records of Processing Activities (RoPA). AI Act Article 11 requires technical documentation. These overlap substantially for AI systems — build one master document that satisfies both, with clearly labeled sections for each obligation.
4. Transparency obligations GDPR Articles 13–15 require transparency about how personal data is processed. AI Act Articles 11–13 require transparency about how AI systems function. For AI systems processing personal data, these requirements can be met through a single layered disclosure — AI system disclosure that incorporates GDPR processing information.
5. Risk assessment lifecycle Both frameworks require ongoing risk assessment — GDPR through continuous DPIA review, AI Act through post-market monitoring (Art. 72). Build a single continuous risk review process that covers both frameworks rather than maintaining two separate risk management cycles.
The Practical Architecture — Pseudonymization as the Bridge
The compliance frameworks converge on one architectural choice that satisfies more dual obligations than any other: pseudonymization before AI processing.
What it does for GDPR:
- Reduces the risk profile of the processing (lower likelihood of harm from a breach)
- Supports data minimization (the AI processes pseudonymized context, not identity)
- May reduce DPIA requirements or lower required safeguard intensity
- Limits erasure conflicts (pseudonymized data is not directly personal data — erasure of the re-identification key effectively anonymizes it)
What it does for the AI Act:
- Satisfies the reinforced security requirement for sensitive data processing under Article 10(5) (the Act explicitly references pseudonymization and nontransmission)
- Reduces the personal data content of Article 12 logs (logs capture pseudonymized inputs, not identifiable ones)
- Supports the data governance requirements of Article 10 (training data relevant, representative, minimized)
Implementation: a local pseudonymization layer sits between your data pipeline and any AI system. Before data enters the model, identifiers are replaced with stable pseudonyms. The re-identification mapping is held in a separate, access-controlled store. The AI processes relationships and context without processing identity. Both the GDPR processing record and the AI Act technical documentation reference this layer as the primary data protection measure.
Frequently Asked Questions
Do the EU AI Act and GDPR apply to the same AI system at the same time?
Yes, wherever an AI system processes personal data. Both apply simultaneously and neither supersedes the other. A high-risk AI system used in employment decisions must satisfy both: GDPR's lawful basis, data subject rights, and Article 22 obligations, and AI Act's Annex III high-risk requirements including technical documentation, logging, human oversight, and conformity assessment.
What is the difference between a DPIA and a FRIA?
A DPIA (Data Protection Impact Assessment) is required under GDPR Article 35 before processing likely to create high risk to individuals. A FRIA (Fundamental Rights Impact Assessment) is required under AI Act Article 27 before deploying certain Annex III high-risk systems. They cover overlapping ground but are distinct documents submitted to different authorities. Where you've already conducted a DPIA, the FRIA must complement it under Article 27(4) — it does not replace it. Both may be required for the same system.
Can AI Act Article 10(5) override GDPR Article 9's restrictions on sensitive data?
No. Article 10(5) of the AI Act creates a narrow additional exception allowing processing of special category data for bias detection and correction — but it supplements GDPR Article 9, it does not replace it. You still need a GDPR Article 9 basis for the same processing. Both sets of conditions must be satisfied simultaneously.
Which regulator handles an AI-related data breach — the DPA or the Market Surveillance Authority?
Potentially both, simultaneously. A DPA investigates the GDPR angle; a National Market Surveillance Authority investigates the AI Act angle. They operate under different timelines — GDPR requires breach notification within 72 hours; the AI Act requires serious incident reporting within 15 days (2 days for critical infrastructure incidents). Both clocks may run at the same time for the same event.
Does GDPR Article 22 satisfy the AI Act's Article 14 human oversight requirement?
Not on its own. GDPR Article 22 gives individuals a right to request human review of automated decisions — it's reactive, triggered by the data subject. AI Act Article 14 requires that human oversight be designed into the system and actively functional during operation — it's proactive and architectural. A process available on request satisfies Article 22 but not Article 14. Article 14 requires a physical mechanism: a halt/override control assigned to a named person with defined authority.
Conclusion
The EU AI Act and GDPR are not two separate compliance projects. For any AI system that processes personal data — which is most enterprise AI — they're two lenses on the same system, enforced by different bodies, on different timelines, with different but overlapping obligations.
The organizations navigating this well in 2026 aren't running two compliance programs in parallel. They're building systems where a single architectural decision — pseudonymize before processing, log minimally, document once for both frameworks — satisfies both simultaneously. The organizations running two separate programs are doubling their effort and still creating gaps at the intersections.
The five conflict points above are where the gaps live. The alignment points are where the efficiency gains are. Map both before your next AI system deployment, not after your first regulatory inquiry.
