Does AI Act compliance replace any GDPR obligation?

No. The AI Act explicitly preserves GDPR. The two regimes operate in parallel. A deployment that satisfies the AI Act still owes the full set of GDPR obligations: records of processing under Article 30, data protection impact assessment under Article 35, lawful basis documentation under Article 6, subject rights under Articles 15 to 22, and the rest of the framework. The AI Act adds obligations on top of GDPR; it does not subtract from them.

Can a single penalty decision cover both regimes?

A single incident can trigger penalties under both regimes on different substantive grounds. The ne bis in idem principle limits double-jeopardy within a single substantive basis, but GDPR and the AI Act are treated as distinct substantive regimes. A breach that involves both unlawful processing of personal data (GDPR) and failure to maintain Article 12 records (AI Act) can produce penalties under both. National authorities coordinate enforcement under the AI Act framework, and the European Data Protection Board coordinates GDPR enforcement.

How does the right to explanation under GDPR Article 22 interact with AI Act transparency?

GDPR Article 22 gives data subjects affected by a solely automated decision the right to meaningful information about the logic involved. AI Act Article 13 requires the provider to make the system transparent enough for the deployer to interpret outputs. The two operate at different scopes. Article 22 applies to specific data subjects affected by specific decisions. Article 13 applies to the system as a whole and to deployers operating it. A deployer that produces Article 13 transparency to its workforce and Article 22 explanations to data subjects covers both, but the audience and the timing differ.

Do we need separate impact assessments for GDPR and the AI Act?

The GDPR data protection impact assessment under Article 35 and the AI Act fundamental rights impact assessment under Article 27 (which applies to public-sector deployers and to private deployers of certain Annex III systems) cover overlapping ground. The AI Office has indicated that a combined assessment satisfying both regimes is acceptable, provided the assessment covers the specific elements each regime requires. In practice, most deployers maintain a single assessment document with sections explicitly mapped to each regime's requirements.

What if our processing is lawful under GDPR but our AI system is non-compliant under the AI Act?

The two regimes operate independently. Lawful processing under GDPR does not cure an AI Act compliance failure. A deployer with a valid lawful basis under Article 6 of GDPR and complete records of processing under Article 30 can still fail Article 12 of the AI Act if the AI system does not produce per-decision records. The penalty exposure under the AI Act attaches on the AI Act substantive basis regardless of the GDPR posture. The reverse is also true: a deployer that satisfies the AI Act fully but fails GDPR's lawful basis test faces GDPR penalties independent of the AI Act.

EU AI Act vs GDPR: Where the Two Regimes Diverge and What That Means for Your Architecture

GDPR governs the processing of personal data. The EU AI Act governs the operation of AI systems. The two regimes apply to many of the same deployments and run in parallel after August 2, 2026, when the AI Act high-risk regime takes effect. GDPR penalties reach €20 million or 4% of global annual turnover. AI Act penalties reach €15 million or 3% under Article 99. The two penalty regimes stack: a single incident can trigger findings under both, on different substantive grounds. I see most compliance teams running GDPR work and assuming the AI Act work is a subset. It is not.

I want to walk through where the two regimes overlap, where they diverge, and what architectural pattern satisfies both at the per-decision evidence layer.

Mandate

GDPR sits on top of the AI Act in the EU legal stack. The AI Act explicitly preserves the application of GDPR alongside its own provisions. A deployment that involves personal data processing carries both sets of obligations.

What GDPR covers

GDPR applies to the processing of personal data by controllers and processors. It establishes principles (lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, confidentiality, accountability) and rights (access, rectification, erasure, restriction, portability, objection, automated-decision-making protections). It requires records of processing activities under Article 30, data protection impact assessments under Article 35, and lawful basis documentation under Article 6.

What the AI Act covers

The AI Act applies to AI systems regardless of whether personal data is involved. It establishes a tiered risk framework (prohibited, high-risk, limited-risk, minimal-risk), provider and deployer obligations, technical documentation requirements, conformity assessment procedures, and post-market monitoring. The high-risk regime under Articles 8 to 27 sets the operational obligations that drive most enterprise compliance work.

Where they overlap

Both regimes apply to AI systems that process personal data and produce decisions that affect natural persons. Both require evidence of decision logic, retention of records, and operational transparency to the data subject or affected person. Both impose penalties calculated as a percentage of global turnover. Both require accountability documentation that survives a regulator inquiry.

Where they diverge

GDPR's records of processing under Article 30 describe what data the organization processes, for what purpose, on what lawful basis, and for how long. The records sit at the management level. They are organizational artifacts.

AI Act records under Article 12 and Article 19 describe what the AI system did with a specific request at a specific moment, who initiated it, what data was involved, what policy applied, and what the outcome was. The records sit at the per-decision level. They are operational artifacts.

GDPR compliance leaves the Article 12 obligation unmet. The Article 12 records are a higher-resolution evidence layer at a granularity GDPR never required.

Compliance gap

Most compliance programs I look at have built GDPR posture and assume the AI Act work extends it. Three structural gaps recur.

Records of processing do not satisfy Article 12

A GDPR Article 30 record describes the data flows at the controller and processor level. It tells the regulator what data the organization processes. It does not tell the regulator what the AI system did with a specific prompt at a specific moment for a specific user. The AI Act requires the per-decision record. The GDPR work does not produce it.

Automated decision-making protections under GDPR Article 22 are not equivalent to AI Act human oversight

GDPR Article 22 gives data subjects the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, with specific exceptions. The right operates after the decision. AI Act Article 14 human oversight operates during or before the decision. A deployer satisfying Article 22 by offering post-decision review does not satisfy Article 14 oversight.

Data minimization and AI Act training data obligations diverge

GDPR's data minimization principle pushes deployers toward processing the minimum data necessary for the purpose. The AI Act Article 10 data governance obligations push providers toward training and validation data sets that are sufficiently representative, free of bias, and tested for accuracy across populations. The two pressures resolve at the architectural level: minimize what flows through the inference layer, while making sure the training data is representative.

The architectural pattern that satisfies both

A deployment that satisfies GDPR and the AI Act produces evidence at two layers simultaneously.

At the management layer, the GDPR Article 30 records describe what data is processed, by whom, for what purpose, on what lawful basis. The data protection impact assessment under Article 35 covers the AI processing as a high-risk activity. The lawful basis is documented per processing activity.

At the per-decision layer, the AI Act Article 12 records describe what the AI system did per request. The records include identity of the natural person, input data, output, policy version, data classification, and outcome. The records are retained per the longer of six months and any applicable sector retention period.

The two evidence layers reference each other. The GDPR records describe the categories of data flowing into the AI system. The AI Act records show what specific instances of that data the system processed and what the system did with them. A regulator inquiry under either regime can trace through the other.

DeepInspect

This is the per-decision evidence layer that satisfies the AI Act without breaking the GDPR posture. DeepInspect sits as a stateless proxy between authenticated users or agents and the LLM. Every request produces a signed per-decision record with identity, role, policy version, data classification, outcome, and timestamp. The records satisfy Article 12 and Article 19 structurally.

The same records support GDPR posture. Access rights under Article 15 are satisfied by producing the records that involved a specific data subject. The right to rectification under Article 16 is supported by the audit trail showing which decisions were based on which data. The right to erasure under Article 17 is bounded by the AI Act retention floor, which the GDPR exception for legal obligation explicitly permits. The records also support the data protection impact assessment that GDPR Article 35 requires for high-risk processing.

For the joint regime, the operational consequence is that GDPR and AI Act inquiries draw on a single evidence layer. The compliance function moves between regimes without maintaining parallel record stacks.

If you are running GDPR posture and planning to extend it to the AI Act, the extension question is whether your evidence layer produces per-decision records or only per-processing records.

Book a demo today.