EU AI Act vs GDPR: Key Differences in 2026

Key Takeaways

• GDPR and the EU AI Act are independent regulations. Neither one replaces or lowers the other, and compliance with one doesn't automatically satisfy the other.
• Both can apply to the same AI system, but not automatically — it depends on each law's own applicability test being separately met, not just on AI being involved.
• A DPIA (GDPR Article 35) and a FRIA (AI Act Article 27) are different assessments. The FRIA obligation is also narrower than most guides suggest: it only applies to public-law bodies, private public-service providers, and private deployers using AI for credit scoring or insurance pricing — not every high-risk deployer.
• GDPR Article 22 (a reactive right to contest automated decisions) and AI Act Article 14 (a proactive human-oversight design requirement) are related but not interchangeable.
• Pseudonymized data is still personal data under GDPR. Only true anonymization removes data from GDPR's scope.
• The "Digital Omnibus on AI" (in force since July 27, 2026) pushed most high-risk AI Act deadlines to December 2027 — but left prohibited-practice rules, GPAI obligations, and transparency requirements on their original timeline.

EU AI Act vs GDPR: What's the Difference?

GDPR (Regulation (EU) 2016/679) has applied since May 2018. It governs any processing of personal data belonging to people in the EU, regardless of the technology used. Its logic is rights-based: individuals have specific rights — access, correction, erasure, objection, and protection from purely automated decisions — and organizations processing their data (controllers and processors) have corresponding obligations, regardless of whether an AI system is involved.

The EU AI Act (Regulation (EU) 2024/1689) entered into force in August 2024. It governs the AI systems themselves — how they're built, tested, documented, and deployed — regardless of whether personal data is involved. Its logic is risk-based: obligations scale with the AI system's risk tier (unacceptable, high, limited, or minimal), and different obligations fall on providers (who build or place systems on the market) versus deployers (who use them).

A useful way to think about it: GDPR asks "is this data being handled lawfully and fairly?" The AI Act asks "is this AI system safe, transparent, and accountable?" An AI-powered hiring tool that scores candidates has to answer both questions — GDPR governs the candidate data feeding the model, and the AI Act governs the model's classification, documentation, and oversight requirements as a high-risk employment system under Annex III.

Neither law defers to the other. There's no legal hierarchy where AI Act compliance substitutes for GDPR compliance or vice versa — they're independent obligations that happen to converge on the same systems.

Do GDPR and the EU AI Act Apply at the Same Time?

Yes — but only when the specific conditions of each law are independently met, not automatically just because AI is involved.

GDPR applies whenever personal data is processed, whether or not an AI system is anywhere near it. The AI Act applies whenever a system meets the legal definition of an "AI system" under Article 3(1) and falls within the Act's territorial and material scope, whether or not personal data is involved. The overlap isn't automatic — it's a product of two separate tests both being satisfied.

In practice, this means:

• An AI system that never touches personal data (say, a model optimizing industrial equipment maintenance schedules using sensor data) can be fully in scope of the AI Act without GDPR applying at all.
• A purely manual, non-AI process that handles personal data is subject to GDPR with no AI Act exposure whatsoever.
• An AI system that scores loan applicants, screens job candidates, or personalizes healthcare recommendations using identifiable data typically triggers both — GDPR because personal data is processed, and the AI Act because the system is likely to fall into a high-risk category under Annex III.

It's inaccurate to claim that every AI system processing personal data is automatically high-risk under the AI Act, or that GDPR and the AI Act always apply together. Applicability under each law has to be assessed on its own terms, system by system.

Does the EU AI Act Replace GDPR?

No. The AI Act does not replace, override, or lower the standard set by GDPR. Article 2(7) of the AI Act explicitly states that the Regulation applies without prejudice to existing EU data protection law, and that obligations on controllers and processors under GDPR remain unaffected.

The two regulations were designed to layer, not substitute. GDPR compliance is generally a precondition for lawful AI deployment — you can't build a legally sound high-risk AI system on top of personal data that was collected or processed unlawfully in the first place. But satisfying GDPR does not, by itself, satisfy AI Act obligations like technical documentation, conformity assessment, or logging, and satisfying the AI Act does not exempt an organization from GDPR's lawful basis, transparency, or data subject rights requirements.

How GDPR and the EU AI Act Work Together

The cleanest way to see the relationship is through the functions each law governs, since they map onto different — but connected — parts of the same AI system's lifecycle.

Data protection and AI governance meet at the input layer: GDPR governs what data can be collected and why; the AI Act governs what that data must look like once it enters a high-risk model (Article 10 requires training, validation, and testing data to be relevant, representative, and free of errors "to the best extent possible").

Risk management runs on parallel tracks. GDPR's DPIA process assesses risk to individuals from a specific processing activity. The AI Act's risk classification and post-market monitoring (Article 72) assess risk from the AI system as a product. Where the same system processes personal data, these risk assessments should reference each other rather than run as isolated exercises.

Transparency obligations overlap substantially. GDPR Articles 13–15 require disclosure about how personal data is used; AI Act Articles 13 and 50 require disclosure about how the AI system functions and that a person is interacting with AI. A well-designed layered notice can satisfy both without duplicating text.

Human oversight and automated decision-making are related but not identical concepts (covered in detail below) — GDPR gives individuals a reactive right to contest automated decisions; the AI Act imposes a proactive design obligation on high-risk system providers and deployers.

Data quality and accountability connect GDPR's accuracy and minimization principles (Article 5) to the AI Act's data governance requirements (Article 10) and documentation obligations (Article 11). A data set that's poorly minimized under GDPR is also likely to fail the AI Act's data quality bar.

5 Key Areas Where GDPR and the EU AI Act Overlap

These are the places where the two frameworks most commonly create duplicated work, gaps, or genuine tension in enterprise AI programs.

1. DPIA vs. FRIA. GDPR's Article 35 impact assessment and the AI Act's Article 27 impact assessment cover related but distinct ground, are submitted through different channels, and — critically — don't apply to the same population of organizations. See the dedicated section below.

2. Logging and data minimization. AI Act Article 12 requires high-risk systems to automatically log events for traceability. Those logs frequently capture user inputs, interaction records, or decision parameters that qualify as personal data under GDPR — creating minimization, retention, and potential erasure obligations on records you're legally required to keep. The fix is architectural: anonymize or pseudonymize log data at the point of capture wherever the traceability purpose doesn't strictly require identifiable data, and set a defined retention period rather than keeping logs indefinitely.

3. Bias detection and special-category data. AI Act Article 10(5) creates a narrow, conditional allowance for providers of high-risk systems to process special-category data (health, biometric, ethnicity, and similar) strictly to detect and correct bias. This does not stand alone — GDPR Article 9's prohibition on processing special-category data still applies, and a lawful Article 9(2) basis (commonly Article 9(2)(g), substantial public interest, which itself requires a basis in national law) is still required. Article 10(5) adds conditions on top of GDPR; it doesn't substitute for a GDPR basis.

4. Incident response and regulatory coordination. A serious incident involving an AI system that processes personal data can trigger two parallel regulatory notifications: a personal data breach report to a Data Protection Authority within 72 hours under GDPR Article 33, and a serious incident report to a market surveillance authority under AI Act Article 73 (generally 15 days, with shorter windows for incidents involving critical infrastructure or widespread harm). These run on different clocks, under different legal tests, and don't assume the same conclusion. A single incident response protocol that maps both notification paths in advance avoids scrambling to interpret two regulations mid-incident.

5. Human oversight and automated decision-making. GDPR Article 22 and AI Act Article 14 both deal with keeping humans in the loop, but they are not interchangeable — one is a reactive individual right, the other is a proactive system design requirement. Covered in full below.

DPIA vs FRIA: What's the Difference?

A Data Protection Impact Assessment (DPIA), required under GDPR Article 35, is a documented AI risk assessment for any processing operation likely to result in a high risk to individuals' rights and freedoms — for example, large-scale profiling, systematic monitoring, or processing special-category data at scale. It's triggered by the nature of the processing activity, and any controller can be required to complete one, AI-related or not.

A Fundamental Rights Impact Assessment (FRIA), required under AI Act Article 27, is a pre-deployment assessment of how a high-risk AI system affects fundamental rights — non-discrimination, privacy, access to justice, and related rights protected under the EU Charter of Fundamental Rights. Unlike the DPIA, the FRIA obligation does not apply to every deployer of every Annex III high-risk system. Article 27 limits the obligation to specific categories of deployers:

• Bodies governed by public law
• Private entities providing public services (education, healthcare, social services, housing, and similar functions, per Recital 96)
• Private deployers using high-risk AI specifically for creditworthiness assessment (credit scoring) or for risk assessment and pricing in life and health insurance

A private company deploying a high-risk AI system outside those categories — for instance, a manufacturer using an AI-based quality inspection system — is not automatically subject to Article 27's FRIA obligation, even though the system is high-risk. Always confirm your organization's deployer category before assuming a FRIA is required.

Where they differ in substance: a DPIA is centered on data protection risk. A FRIA is broader — it looks at fundamental rights impacts that may have nothing to do with personal data at all, alongside the ones that do.

Where they overlap: both require you to describe the processing or system, identify affected individuals, assess risk of harm, and document mitigation measures. AI Act Article 27(4) explicitly allows deployers to draw on an existing DPIA to inform the FRIA where the two assessments cover the same ground — the FRIA can complement and reference the DPIA rather than duplicate it from scratch. To avoid running two disconnected assessment processes, build a single combined template with clearly labeled sections mapping to each legal basis, so one exercise can produce evidence for both obligations where your organization is genuinely subject to both.

GDPR Article 22 vs EU AI Act Human Oversight

These two provisions are often treated as equivalent. They aren't, and conflating them is one of the more common compliance gaps.

GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing, including profiling, where that decision produces legal effects or similarly significantly affects them — with limited exceptions (contractual necessity, authorization under EU or member state law, or explicit consent). Where an exception applies, the individual still retains the right to obtain human intervention, express their point of view, and contest the decision. It is fundamentally a reactive, individual-triggered right: it activates when a specific person invokes it, or when the decision itself is fully automated with no human involvement at all.

AI Act Article 14 requires high-risk AI systems to be designed and built so that natural persons can effectively oversee them during operation — including the ability to understand the system's capabilities and limitations, correctly interpret its output, decide not to use it, or intervene in or halt its operation. It is a proactive, architectural design requirement that applies regardless of whether any individual ever objects, and regardless of whether the decision is "solely automated" in the GDPR sense.

The practical gap: a hiring system with a human reviewer who can override the AI's shortlist "on request" may satisfy Article 22 (a human review mechanism exists) while still failing Article 14, if that oversight isn't functionally built into the system's operation — for example, if the reviewer has no meaningful ability to interpret the model's reasoning, or no real authority to override it before the decision takes effect. Article 14 compliance generally requires a defined mechanism (a halt or override control) assigned to a specific, competent, and authorized person — not just an available complaints channel.

Data Minimization, AI Training Data and the EU AI Act

GDPR's data minimization principle (Article 5(1)(c)) requires that personal data be adequate, relevant, and limited to what's necessary for the purpose. Every use of personal data in AI training or inference needs a lawful basis under Article 6 — consent, contract, legitimate interest, and so on — and that basis has to hold up against the AI Act's own data governance rules, particularly Article 10's requirement that training, validation, and testing data sets be relevant, sufficiently representative, and, to the best extent possible, free of errors given the system's intended purpose.

Purpose limitation is where many AI projects run into trouble: data collected for one purpose (say, customer service records) frequently gets repurposed for model training or fine-tuning without the original lawful basis covering that new use. That gap doesn't disappear because the AI Act separately requires data quality — the two obligations are additive, not substitutable.

Special-category data (health, biometric, genetic, ethnicity, political opinions, and similar, under GDPR Article 9) requires its own lawful condition before it can be used in training data, on top of whatever AI Act data governance requirements apply.

On pseudonymization and anonymization — these are not the same thing, and the difference matters legally. Pseudonymized data — where direct identifiers are replaced with tokens but re-identification remains possible using additional information held separately — is still personal data under GDPR and remains fully subject to the Regulation's obligations. Pseudonymization is a valuable security and risk-reduction measure: it can lower the likelihood and severity of harm from a breach, support minimization by limiting what the AI model itself needs to process, and help satisfy the AI Act's reinforced security expectations for sensitive data processing under Article 10(5). But it does not remove the data from GDPR's scope, and it does not, by itself, eliminate the need for a lawful basis, a DPIA where one is otherwise required, or data subject rights.

True anonymization — where re-identification is not reasonably possible for anyone, using any means reasonably likely to be used — does take data outside GDPR's scope, per Recital 26. In practice, genuine anonymization of the kind of rich, high-dimensional data typically used to train AI models is difficult to achieve and verify. Treat any claim of "anonymized AI training data" with scrutiny, and document the specific technical and organizational measures that support the anonymization claim rather than assuming pseudonymization is sufficient.

AI Act + GDPR Compliance for Enterprise AI

A workable dual-compliance program treats GDPR and the AI Act as inputs into a single AI governance process, not two separate checklists. In practice, that means:

• Build and maintain an AI system inventory. You can't classify or assess what you haven't catalogued. Include shadow AI and vendor-embedded AI features, not just internally built models.
• Map data flows into and out of each system. Identify what personal data, if any, each system processes, its source, its lawful basis, and where it's stored or logged.
• Classify each AI system under the AI Act's risk tiers (prohibited, high-risk, limited, minimal) and confirm your role — provider, deployer, importer, or distributor — for each one.
• Determine your legal basis under GDPR Article 6 (and Article 9, where relevant) for any personal data feeding the system.
• Run a DPIA for processing likely to result in high risk, and a FRIA where your organization falls into one of Article 27's specific deployer categories.
• Assess vendors and third-party AI providers. Confirm what data protection and AI Act documentation they can provide — you can't simply rely on a vendor's conformity assessment to satisfy your own deployer obligations.
• Maintain technical documentation (Article 11) and Records of Processing Activities (Article 30) with clearly labeled sections showing which content satisfies which obligation.
• Design logging (Article 12) with minimization built in — capture what traceability genuinely requires, pseudonymize where possible, and define retention limits.
• Build human oversight into system design, not just into policy documents — a named, authorized person with a functional override mechanism.
• Write layered transparency notices that cover both GDPR processing information and AI Act system-function disclosures.
• Establish security measures proportionate to risk, covering both GDPR Article 32 and the AI Act's cybersecurity expectations for high-risk systems.
• Build a joint incident response protocol that maps GDPR's 72-hour breach clock against the AI Act's serious-incident reporting windows.
• Assign clear governance ownership — who owns AI Act classification decisions, who owns GDPR lawful-basis decisions, and where those roles intersect.
• Keep evidence, not just policies. Regulators under both frameworks expect documented decisions, not retrospective justifications.

For organizations building this out, a structured AI audit process is generally the fastest way to surface where GDPR and AI Act obligations actually intersect in your specific system inventory, rather than working from generic assumptions.

For small and medium-sized enterprises and startups, both regulations apply the lower of the fixed amount or the percentage figure, rather than the higher — a meaningful distinction from how the ceiling is calculated for larger organizations.

As of mid-2026, enforcement activity under the AI Act is still in an early phase. Prohibited-practice rules have applied since February 2025 and GPAI obligations since August 2025, but at the time of writing, no public monetary penalties have been issued under the AI Act, and a number of member states had not yet fully designated their national market surveillance authorities. That doesn't reduce legal exposure — it reflects a regulatory framework still standing up its enforcement infrastructure. GDPR enforcement, by contrast, is mature, with an established track record of significant fines from Data Protection Authorities across the EU.

What Changes for GDPR + AI Act Compliance in 2026?

Current law: GDPR remains unchanged and fully in force. Under the EU AI Act, prohibited AI practices (Article 5) have applied since 2 February 2025, and obligations for general-purpose AI (GPAI) models have applied since 2 August 2025. AI Act transparency obligations — including chatbot disclosure and AI-generated content labeling under Article 50 — took effect and became enforceable on 2 August 2026.

A significant, already-adopted change: the "Digital Omnibus on AI" (formally Regulation (EU) 2026/1744) was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It amends the AI Act's implementation timeline and deferred the compliance deadline for most high-risk (Annex III) AI systems from 2 August 2026 to 2 December 2027, with high-risk AI-embedded products under Annex I pushed to August 2028. National AI regulatory sandboxes, originally due by August 2026, were pushed to August 2027 to align with the new timeline. The Omnibus also added two new prohibited-practice categories — AI systems generating non-consensual intimate imagery ("nudifier" tools) and AI-generated child sexual abuse material — with associated technical-safeguard obligations phasing in by 2 December 2026, and extended the Article 50(2) AI-content labeling deadline to 2 February 2027 for systems already on the market before August 2026.

Importantly, this deferral applies to the high-risk conformity-assessment obligations under Annex III specifically. It does not defer the AI Act's prohibited-practice rules, GPAI obligations, or transparency requirements, all of which remain on their original enforcement timeline. Organizations sometimes read the Omnibus as a broad delay of "AI Act compliance" — it isn't. It relieves the single largest near-term workstream (Annex III conformity assessment) while leaving the rest of the framework, including FRIA obligations tied to Article 27 for the specific deployer categories described above, on its existing track pending further clarification as implementation guidance develops.

A proposed, not-yet-adopted change: a separate "Data Omnibus" package, covering amendments to GDPR, the ePrivacy Directive, NIS2, and the Data Act, was proposed by the European Commission on 19 November 2025. It remains under negotiation between the Parliament and Council as of this writing, and had not reached political agreement. Reported elements under discussion include clarifying the definition of personal data, streamlining consent requirements (including for cookies), and simplifying breach and incident reporting across overlapping frameworks. None of this is binding law yet. Treat any specific provision described in press coverage of the Data Omnibus as a proposal, not a current legal requirement, until it is formally adopted and published in the Official Journal.

What this means practically: organizations with Annex III high-risk systems now have a longer runway to complete conformity assessments, but the underlying substantive obligations — risk management, data governance, technical documentation, human oversight, post-market monitoring — are unchanged, only the applicable dates have moved. The additional time is better spent on system classification and GDPR/AI Act mapping than treated as a reason to pause AI governance work. Given how actively both frameworks are being amended in 2026, verify current deadlines against EUR-Lex or European Commission guidance before finalizing a compliance calendar.

GDPR AI Act Compliance Checklist

• Inventory every AI system in use, including vendor and embedded tools
• Map personal data flows into and out of each system
• Classify each system's AI Act risk tier and confirm your provider/deployer role
• Confirm the GDPR lawful basis (Article 6, and Article 9 where relevant) for any personal data involved
• Run a DPIA for high-risk processing activities
• Determine whether Article 27's FRIA obligation applies to your organization's specific deployer category — don't assume it does by default
• Review vendor and third-party AI documentation and contractual data protection terms
• Maintain technical documentation (Article 11) and Records of Processing Activities (Article 30) in a single cross-referenced set
• Design logging to minimize personal data capture and set defined retention limits
• Build a functional human oversight mechanism into system design, with a named responsible person
• Draft layered transparency notices covering both data processing and AI system disclosures
• Confirm anonymization claims are technically verified, not assumed from pseudonymization
• Build a joint incident response protocol mapping GDPR and AI Act notification timelines
• Assign clear internal ownership for GDPR and AI Act decisions, with defined escalation points
• Track Digital Omnibus developments against your compliance calendar and revisit deadlines quarterly

Frequently Asked Questions

What is the difference between GDPR and the EU AI Act?

GDPR regulates the processing of personal data and protects individual data rights, regardless of the technology used. The EU AI Act regulates AI systems based on their risk level and function, regardless of whether personal data is involved. They're independent laws that frequently apply to the same AI system.

Does the EU AI Act replace GDPR?

No. Article 2(7) of the AI Act confirms it applies without prejudice to existing EU data protection law. GDPR obligations remain fully in force alongside the AI Act.

Do GDPR and the EU AI Act apply at the same time?

They can, whenever an AI system that falls within the AI Act's scope also processes personal data. This isn't automatic for every AI system — it depends on each law's own applicability test being independently satisfied.

Does GDPR apply to AI systems?

Yes, whenever an AI system processes personal data. GDPR is technology-neutral — it applies to the processing activity itself, whether it's performed by a human, a spreadsheet, or a machine learning model.

Is GDPR compliance enough for EU AI Act compliance?

No. GDPR compliance addresses data protection but doesn't cover AI Act-specific obligations like risk classification, technical documentation, conformity assessment, or system-level human oversight design.

How does the EU AI Act affect GDPR compliance?

The AI Act doesn't change GDPR's requirements, but it adds obligations — like Article 12 logging and Article 10 data governance — that generate new GDPR considerations, such as minimizing personal data captured in system logs.

What happens when an AI system processes personal data?

Both frameworks can apply. GDPR governs the lawful basis, minimization, and rights around that personal data. If the system also meets the AI Act's definition of a high-risk (or otherwise regulated) AI system, the AI Act's documentation, oversight, and risk-management obligations apply in parallel.

What is the relationship between GDPR and the EU AI Act?

They're complementary, non-hierarchical regulations that govern different aspects of the same technology stack — GDPR governs the data, the AI Act governs the system — and compliance with one does not substitute for compliance with the other.

What is the difference between a DPIA and an FRIA?

A DPIA (GDPR Article 35) assesses data protection risk for high-risk processing activities and applies broadly to any controller. A FRIA (AI Act Article 27) assesses fundamental rights impact for specific high-risk AI deployments, but only for public-law bodies, private entities providing public services, and private deployers using AI for credit scoring or insurance pricing — not every high-risk AI deployer.

Does pseudonymization make AI data exempt from GDPR?

No. Pseudonymized data is still personal data under GDPR and remains subject to its obligations, because re-identification remains possible with additional information. Only true anonymization, where re-identification isn't reasonably possible for anyone, takes data outside GDPR's scope.

Who enforces GDPR?

National Data Protection Authorities in each EU member state, coordinated through the European Data Protection Board (EDPB).

Who enforces the EU AI Act?

National market surveillance authorities enforce most obligations, while the EU AI Office enforces rules specific to general-purpose AI models. Both operate alongside, not instead of, national Data Protection Authorities.

The Bottom Line

GDPR and the EU AI Act are built to work together, not to compete. The organizations handling this well in 2026 aren't running two separate compliance programs — they're mapping GDPR obligations and AI Act obligations onto a single system inventory, using shared documentation where the two frameworks genuinely overlap (technical documentation and RoPA, DPIA and FRIA, transparency notices), and keeping the parts that don't overlap — like AI Act conformity assessment or GDPR's data subject rights processes — properly separated rather than blurred together. Getting the boundary right, system by system, is what turns dual compliance from a duplicated burden into a defensible, auditable program. Questa AI helps enterprises get that boundary right at the source: data anonymization and privacy firewalls that reduce sensitive data exposure before it reaches an AI system address both frameworks' core concern at the same point in the pipeline — before the data becomes a downstream liability under either law.