EU AI Act vs GDPR: How the Two Regimes Diverge on Record-Keeping, Identity, and the Per-Decision Trace

EU AI Act Article 12 takes effect August 2, 2026 for high-risk AI systems and requires automatic event recording over the system lifetime, identification of the natural persons involved, and retention for at least six months. GDPR Article 30 requires records of processing activities and has been in effect since May 2018. The two regimes overlap on personal-data scope and on data subject rights. They diverge on five operational axes that drive the architecture of the AI request path. Compliance teams that try to satisfy Article 12 by extending their GDPR Article 30 spreadsheet discover the gap when the AI Act auditor asks "show me the record for the August 14 decision that affected this data subject."

I want to walk through the five axes where the regimes diverge, the record formats each regulator reads, the architectural changes the AI request path needs, and how the two regimes compose under a single inspection layer.

Axis 1: Cadence of evidence

GDPR Article 30 evidence is management-level. The record of processing activities describes the categories of data the controller processes and the purposes the processing serves. The document is reviewed annually and updated when processing changes materially. The auditor reads the document, the policies behind it, and the controls the documentation references.

EU AI Act Article 12 evidence is operational-level. The record is the trace the AI system emits on each request: which natural person triggered the request, which classifications the request touched, which policy version evaluated the request, what decision the policy committed, and which model and version handled the request after the decision. The record is per request, not per quarter.

A compliance team can satisfy GDPR Article 30 with documentation that the team owns and maintains. The team cannot satisfy AI Act Article 12 the same way, because the per-request record is what the regulator reads.

Axis 2: Identity of the actor the record describes

GDPR records describe the controller and the processing activity. The data subject's identity is referenced where the activity carries personal data, but the record's primary subject is the controller's processing. The compliance owner is the entity (the controller). The record reads in the abstract.

AI Act Article 12 records describe the AI system's decisions at the moment they were committed. The record carries the natural-person identifier of the user or subject the decision affected, the AI system's identifier, the model and version that produced the inference, and the policy version that committed the decision. The compliance owner is the deployer of the high-risk system. The record reads in the specific.

The architectural consequence is that the per-request identity context (the natural person, the agent, the route) has to be carried by the AI request boundary. A request that reaches the model without propagated identity cannot produce the AI Act record. A request that satisfies the GDPR record can still fail the AI Act record on the missing-identity axis.

Axis 3: Granularity of the decision trace

GDPR Article 22 covers automated decision-making that produces legal or similarly significant effects on the data subject. The Article requires meaningful information about the logic involved and human review on request. The granularity is the decision boundary: the moment the automated system commits the decision that affects the subject.

AI Act Article 12 requires the record series across the system lifetime. The Annex IV documentation accompanying the system describes the system's intended purpose, the data sets used, the human oversight measures, and the post-market monitoring system. The two together cover the per-decision trace and the system-lifetime context the decisions sit in.

The architectural consequence is that the AI request path has to commit a per-request decision record (the operational layer) and the deployer has to maintain a system-level documentation set (the planning layer). The operational layer cannot be backfilled from the planning layer. The deployer that has the planning documentation but not the operational records still fails Article 12 at audit time.

Axis 4: Cross-border data residency

GDPR Chapter V covers transfers of personal data to third countries. The transfer mechanism (adequacy decision, standard contractual clauses, binding corporate rules) has to exist before personal data leaves the EU/EEA. The compliance focus is on the transfer's lawful basis and the safeguards in place.

AI Act Article 12 retention obligations apply to the deployer. The record store has to be available for the regulator's lawful request, which typically implies storage in the jurisdiction the deployer operates from. The Article does not separately require the record store to live in the EU, but the EU regulator can ask for records in EU-language formats and with EU-resident processing pathways. The deployer who routes high-risk system decisions through a US inference endpoint owes EU-residency consideration on the per-decision record itself.

The architectural consequence is that the inspection layer that produces the record series has to support per-route data residency. A deployment that runs the EU users' high-risk decisions on an EU-resident inference path and the US users' decisions on a US-resident path commits records in the matching jurisdiction. The route binding is the mechanism.

Axis 5: The audit posture

GDPR Article 58 lists the supervisory authority's powers, including the right to access information and the right to obtain access to personal data. The audit typically happens after a subject complaint or in response to a breach notification. The cadence is reactive.

AI Act Article 49 (notified bodies and conformity assessment) and Article 26 (deployer obligations) put a continuous monitoring obligation on the deployer. The deployer of a high-risk system has to maintain the record series and the system-level documentation during the system's operation, and the supervisory authority can ask for them at any point. The cadence is continuous.

The architectural consequence is that the deployer cannot rely on the after-the-fact reconstruction that worked under the GDPR breach-notification regime. The records have to exist at the time of the request, in the format the regulator expects, with the policy version and the identity claims attached.

How the two regimes compose

The GDPR record-of-processing and the AI Act per-decision records cover different layers. The first describes what the controller does at the activity level. The second describes what the AI system did at the request level. Both regimes apply to the same deployment when the AI system processes personal data, and the deployer owes both records.

The single inspection layer at the AI request boundary produces the operational record that satisfies both Article 12 and GDPR Article 22's right-to-explanation obligation. The activity-level RoPA continues to be maintained by the controller's privacy office. The two records compose at audit time: the auditor reads the RoPA to understand the processing in the abstract and the per-request record to verify what happened to a specific data subject at a specific moment.

DeepInspect

DeepInspect is the inspection layer that commits the per-request record series both regimes need. The product terminates the AI provider TLS, reads the AI request and response at the HTTP boundary, evaluates identity-bound policy per route, applies pass, modify, redact, or block decisions, and commits per-decision audit records to a tamper-evident store with hash chaining across records. The record format carries the natural-person identifier, the policy version, the decision outcome, and the integrity metadata that proves the record was not altered after the fact.

The product runs as a stateless proxy. The deployer's existing SSO propagates through. The policy bundles per route describe the data classifications each route handles and the residency the route enforces. The record series is the first-party evidence that satisfies AI Act Article 12 and supplies the per-decision detail GDPR Article 22 right-to-explanation requests now reach for.

If you are mapping your GDPR record-keeping onto the AI Act before August 2, let's talk today.