EU AI Act Records of Processing: What the Article 12 + 19 Record Has to Contain Beyond GDPR Article 30
GDPR Article 30 records of processing describe what data the organization processes. EU AI Act Article 12 plus Article 19 records describe what the AI system did with a specific request at a specific moment. The two record series carry different fields at different granularities. This piece walks through the GDPR baseline, the Article 12 plus Article 19 fields, where they sit operationally, and what the audit expects on each.
GDPR Article 30 records of processing describe the data the organization processes at an organizational level: what categories of personal data, what processing purposes, which recipients, which transfer destinations, how long the data is retained, and what security measures protect it. EU AI Act Article 12 plus Article 19 records describe something else: what a specific AI system did with a specific request at a specific moment. The two record series sit at different layers of abstraction and answer different audit questions. The Article 12 + 19 records are not a GDPR Article 30 record extended; they are a per-decision operational record series.
I want to walk through where each record series sits, what fields each one carries, and why a program that already has Article 30 records still has to build the Article 12 + 19 series at the request boundary.
What GDPR Article 30 records carry
GDPR Article 30 records describe processing activities at the controller-and-processor level. The required fields:
The record is a description of what the organization processes, not a record of each processing event. A bank's Article 30 record might describe credit-scoring processing as one entry: the data subjects are loan applicants, the data is application data plus credit bureau pulls, the purpose is credit decisioning, the recipients are internal underwriting plus regulators, the retention is seven years after the credit decision. The Article 30 entry describes the activity. It does not describe the specific decision on a specific application.
What EU AI Act Article 12 and 19 records carry
Article 12 requires automatic recording of events over the lifetime of the system sufficient to ensure traceability. Article 19 specifies what the records carry:
The granularity is per-decision. Each AI request produces a record. The records are the operational artifact that lets the auditor reconstruct what the AI system did with a specific decision on a specific date. The series spans the lifetime of the system, with a minimum retention under Article 26(6) of six months for the deployer.
How the two series differ operationally
The Article 30 record lives in the GDPR documentation: typically a structured record in the privacy team's compliance platform, refreshed annually or when processing changes. The Article 12 + 19 record lives in the operational record store: a per-decision audit log emitted at the moment the AI request crosses the inspection boundary, retained for at least six months, sampled by the auditor against specific time windows or specific decision categories.
A program that already has the Article 30 record does not automatically have the Article 12 + 19 record. The Article 30 record describes that the credit-scoring system processes loan applications. The Article 12 + 19 record carries the prompt content of application 9876, the natural-person identity who initiated the decision (the underwriter), the classification labels on the input data, the policy version at the moment of the decision, and the decision the system returned. The two answer different questions.
Where the Article 12 + 19 record sits
The placement is the AI request boundary. The record carries fields that come from three different surfaces: identity (from the IdP), prompt content and classification (from the inspection layer), and decision and policy state (from the enforcement layer). The only placement that holds all three on the same surface at the same moment is the HTTP proxy between authenticated users or agents and the LLM endpoint.
A network-side record carries the timestamp and the endpoint but not the prompt content (the body is encrypted to the model). An application-side record carries the prompt but not the verified identity unless the application is wired against the IdP. A model-provider-side record carries the prompt and the API caller identity but not the natural-person identity behind the application session.
The Article 26(6) retention period
Article 26(6) requires the deployer to keep the automatically generated logs for at least six months after the moment of generation. The retention period applies to the per-decision records produced under Article 12 + 19. The deployer cannot rotate or purge the records before six months without a documented legal basis.
The retention is the floor. National regulators in some Member States expect longer retention for specific high-risk categories. Financial services regulators often expect three to seven years for credit-related records. The Article 12 + 19 series benchmarks against the existing financial-services audit log retention, not a fresh six-month policy.
What the auditor samples
The auditor samples the record series the way they sample any audit log: against specific time windows, specific decision categories, or specific individuals. The sample reconstructs what the AI system did at the moment of the decision. The fields the auditor looks for:
A record that omits any of these fields collapses under the sample. The auditor's follow-up question (why is this field missing) does not have a defensible answer because the regulation explicitly lists the field.
Where Article 30 and Article 12 + 19 intersect
The two records cross-reference in practice. The Article 30 record describes the processing the AI system performs and points at the Article 12 + 19 series as the evidence base. The Article 12 + 19 record carries the system identifier that maps back to the Article 30 entry. The auditor moves between the two: starting at Article 30 to understand the processing activity, then moving to the Article 12 + 19 sample to inspect specific decisions.
A program that has both records and explicit cross-references between them presents a stronger audit position than a program that has either record alone or has them as disconnected documents.
What the operational stack has to produce
The operational stack for the Article 12 + 19 record series:
The stack runs as the HTTP proxy in front of the LLM endpoints. The records flow into the SIEM, the compliance data lake, or a dedicated audit store. The records are queryable by timestamp, identity, system identifier, classification, decision, and policy version.
DeepInspect
DeepInspect is the record-producing layer for the Article 12 + 19 series. The proxy authenticates the caller against the corporate IdP, classifies the prompt content, evaluates policy against identity and classification, and commits a per-decision audit record before the response returns. The records carry the timestamp, the natural-person identity, the prompt content (with optional redaction), the classification labels and scores, the policy version, the decision, and an integrity signature on a tamper-evident series.
For organizations cross-referencing Article 30 records against Article 12 + 19 obligations, the proxy supplies the per-decision evidence the Article 30 entry points at. The placement at the request boundary is what makes the record consistent across multiple LLM providers and multiple application teams.
If you are facing the August deadline, let's talk.
Frequently asked questions
- Can the Article 30 record reference the Article 12 + 19 series instead of duplicating fields?
Yes. Article 30 records describe processing activities at the controller level; the Article 12 + 19 series produces operational evidence. The Article 30 entry for an AI system can reference the Article 12 + 19 record series by location and retention policy. The cross-reference reduces duplication and gives the auditor a single map between the two evidence shapes.
- Does the Article 12 + 19 series count as a "log" under the GDPR Article 32 security obligation?
The Article 12 + 19 records carry personal data (the prompt content and the natural-person identity), so they are themselves subject to GDPR security obligations including Article 32. The series has to be encrypted at rest, access-controlled to the operations team handling audit review, and retained per the AI Act and GDPR requirements (the Article 26(6) six-month minimum, the GDPR storage-limitation principle on the longer side).
- What is the relationship between Article 12 + 19 and Article 26(6)?
Article 12 + 19 specifies what the system produces. Article 26(6) specifies the deployer's retention obligation on those records (at least six months). The two work together: the system has to produce the records and the deployer has to retain them.
- Does the Article 12 + 19 obligation apply when the AI system runs on top of a SaaS LLM API?
Yes. The Article 12 + 19 obligation applies to the high-risk AI system the deployer operates, regardless of whether the underlying model is self-hosted or accessed through a SaaS API. The deployer's stack has to produce the record at the AI request boundary, which is the same boundary regardless of the model hosting model.
- How does the record series interact with the data subject's right to access under GDPR Article 15?
The Article 12 + 19 records can contain personal data (the prompt content and the natural-person identity behind the request). Data subjects can exercise Article 15 access rights against those records when the records relate to them. The records are operational evidence and personal data at the same time, which means the access and erasure obligations apply on top of the AI Act retention obligation.