Does Article 12 apply to internal AI assistants my employees use?

Article 12 applies when the system is high-risk under Annex III or when the deployer's intended use places the system in a high-risk category. An internal AI assistant that surfaces hiring decisions, credit decisions, or essential-service access decisions becomes high-risk by use. An internal assistant that helps with general productivity (drafting emails, summarizing documents) is not high-risk per se. The deployer's intended-use declaration drives the classification.

How long do the audit records have to be retained?

Article 12(3) sets a minimum of six months. National regulators can require longer retention, and sector-specific obligations (financial services, healthcare) often require multi-year retention. The deployer commits to the longer of the applicable retention periods. The record store has to support the retention window and prove the records were not altered during the window.

Can the natural-person identification be pseudonymous?

Article 12 says the records must allow identification of the natural persons involved. Pseudonymous identifiers are acceptable if the deployer can resolve the identifier to the natural person on lawful request. The pseudonym-to-person mapping has to be held under access controls compatible with the deployer's GDPR obligations. The audit record series carries the pseudonym at write time and the mapping is held separately.

Does the policy version of record have to be a git commit?

The policy version of record has to be reproducible. A git commit hash is a common implementation and satisfies the reproducibility requirement. Other implementations work: signed policy bundles, content-addressed policy artifacts, or versioned policy entries in a configuration database. The audit record carries the version reference and the policy store carries the policy artifact the reference resolves to. The regulator reading the record has to be able to retrieve the policy artifact that committed the decision.

What does a regulator actually ask for during an audit?

The regulator typically asks for the record series covering a specific time window or a specific data subject. The deployer queries the audit store, returns the records, and provides the policy artifacts the records reference. The regulator reads the records to verify the decision pathway, the policy in effect at the time, and the natural-person attribution. The first-party evidence regime expects the deployer to produce these on lawful request without further engineering work at the time of the request.

Compliance After the Act: The EU AI Act Mindset Shift From Documentation to Per-Decision Evidence

EU AI Act Article 12 takes effect August 2, 2026 for high-risk AI systems. The Article requires automatic event recording over the system lifetime, identification of the natural persons involved in the use of the system, and retention for at least six months. The text reads at one level of abstraction. The infrastructure to satisfy the obligation operates several levels lower. Compliance teams that came from GDPR are familiar with quarterly reviews, DPIAs, and ROPA spreadsheets. The Act asks for the moment-by-moment evidence of what an AI system did with a specific request at a specific point in time.

I want to walk through the four mindset shifts a security and compliance organization has to make before the Article 12 effective date, the regulatory text that drives each shift, and what each shift implies for the architecture of the AI request path.

From policy documents to live audit records

The GDPR record-of-processing regime asks the controller to maintain a document that describes the categories of data processed and the purposes the processing serves. The document is reviewed annually. The regulator audits the document, the policies behind the document, and the controls the documentation references.

Article 12 asks for the record series an AI system produces while it operates. Recital 71 calls these "automatically generated logs." The record series describes what the AI system did with a specific request at a specific moment: which natural person triggered the request, which data 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 shift is from the document the compliance team owns to the record series the AI request path emits. The compliance team can still own the policy that the records are evaluated against. The records themselves come from the request path. Compliance teams that try to satisfy Article 12 with a documentation-style approach (policies, control matrices, attestations) discover the gap when a regulator asks "show me the record for the August 14 decision that affected this data subject." The document regime cannot produce that answer. The record regime produces it from a query against the audit store.

From quarterly reviews to per-request decisions

GDPR Article 35 requires a DPIA for processing likely to result in high risk. The DPIA is a planning document. The compliance team performs the assessment, captures the mitigations, and revisits the document annually or whenever the processing changes materially. The cadence is quarterly to annual.

Article 26 of the EU AI Act asks the deployer of a high-risk system to ensure human oversight on the operational decisions the system commits. Article 14 (transparency and traceability) requires that the system carries information that allows the deployer to identify and address risks while the system is in use. The cadence is per request. A high-risk system that lacks per-request decision traces fails the traceability obligation regardless of how thoroughly the deployer documented the planning phase.

The shift is from the quarterly cadence the compliance team is staffed for to the per-request cadence the AI request path operates on. The compliance team does not need to read every record (the volume rules that out). The compliance team needs the records to exist, the query against the audit store to return answers, and the policy evaluation that committed each record to be reproducible.

From third-party attestation to first-party evidence

SOC 2 Type II reports rely on third-party attestation. The auditor reads the controls, samples the evidence, and issues a report. The buyer reads the report and accepts the assertion. The model is widely deployed across SaaS contracts.

Article 12 evidence is first-party. The deployer of the high-risk system owes the record series directly. A SOC 2 report on the AI vendor's controls is not a substitute for the record series the deployer's own AI request path produced. The deployer cannot subcontract the Article 12 obligation to the model vendor or the application vendor.

The shift is from the attestation regime that the buying organization is familiar with to the first-party evidence regime the Act introduces. The buying organization keeps the SOC 2 reports it collects from vendors for the vendor-side controls. The buying organization owes its own record series for the AI requests its high-risk system handles. The first-party regime is what regulators read.

From boundary controls to per-route enforcement

Existing security architectures place controls at the network boundary (firewall, DLP), the identity boundary (SSO, MFA), and the data boundary (encryption at rest, KMS). Each control sits at a layer below the AI request boundary. The TLS encryption the AI providers use travels through the network boundary as an opaque flow. The identity context that authenticated the natural person at the SSO does not propagate to the AI request the application emits on the person's behalf. The data-at-rest controls do not see the prompt content in flight.

Article 12 requires record granularity at the request level. The record has to identify the natural person, the data classifications the request touched, and the decision the policy committed. None of the boundary controls produces that record. The per-route enforcement layer at the AI request boundary produces it.

The shift is from the boundary architecture the security team has built for a decade to the per-route enforcement layer the AI request path now requires. The boundary controls keep running for the obligations they were designed for (network segmentation, identity authentication, data-at-rest protection). The per-route enforcement layer covers the AI request obligation. The two layers compose. Neither one replaces the other.

DeepInspect

DeepInspect is the per-route enforcement layer for that architecture. The product terminates the AI provider TLS, reads the AI request and response at the HTTP boundary, evaluates identity-bound policy on a per-route basis, applies a pass, modify, redact, or block decision, and commits a per-decision audit record to a tamper-evident store with hash chaining across records.

The product runs as a stateless proxy between the calling application and the upstream model. The deployer's existing SSO propagates through to the inspection layer. The policy bundles per route describe what each AI route is allowed to read, what each route is allowed to emit, and what each route owes the audit store. The record series the layer commits is the first-party Article 12 evidence the deployer owes.

If you are facing the August deadline, let's talk today.