The EU AI Act Article 12 readiness guide

From August 2026, high-risk AI systems in the EU must keep automatic records of their own operation. Most organisations discover what that means the first time an auditor asks for them.

What Article 12 actually requires

Article 12 of the EU AI Act is a record-keeping obligation: high-risk AI systems must be technically capable of automatically logging events over their lifetime. The logs must be sufficient to identify situations that may present risk, support post-market monitoring, and enable traceability of the system's functioning. In operational terms, that means every inference — every prompt, every retrieval, every model response, every automated action — needs a durable, time-stamped record tied to the user, the model version and the data sources involved. A weekly export of chat titles does not meet the bar. Neither does relying on a cloud provider's usage dashboard, because that dashboard is the provider's record, not yours, and it typically records billing metadata rather than decision context.

Article 14 is the other half

Record-keeping without oversight is a diary of unsupervised decisions. Article 14 requires that high-risk systems be designed so natural persons can effectively oversee them — understand outputs, decide not to use them, and intervene or interrupt operation. Operationally, that means consequential automated actions must pass through an approval gate a human can actually exercise, and the exercise of that gate must itself be logged: who approved, who rejected, when, and what they saw. Article 15's accuracy and robustness requirements then presume you can demonstrate behaviour over time — which loops back to the logs.

What an auditor will ask for

Audit requests in this domain are becoming predictable. Expect to be asked to produce:

• The complete event record for a specific interaction on a specific date — prompt, retrieved context, model identity and version, output, and downstream actions.
• Evidence the record has not been altered since it was written — hash chains or equivalent tamper-evidence, not database timestamps alone.
• The human-oversight trail: which actions required approval, who held that authority, and each approval or rejection decision.
• Retention policy and its enforcement — including how deletion requests under GDPR Article 17 interact with your audit obligation.
• Your GDPR Article 30 record of processing activities, updated to cover AI inference as a processing operation.

A practical readiness checklist

Before August 2026, verify four things. First, that logging is per-call and automatic — not opt-in, not sampled. Second, that logs are tamper-evident: an append-only ledger whose integrity can be demonstrated, because a mutable log fails the traceability test the moment its integrity is questioned. Third, that human oversight exists as an enforced control point in the system, not a paragraph in a policy document — Article 14 asks whether a person could intervene, and the honest answer requires an approval mechanism in the execution path. Fourth, that the whole evidence chain sits inside your control. If your inference runs on shared infrastructure, your audit trail has a dependency you cannot subpoena on demand.

This is why architecture matters more than policy here. Per-call logging into an append-only ledger, with approval gates on consequential actions, maps one-to-one onto Articles 12 and 14 — and it is far easier to build that in from the start than to retrofit it into a cloud API you do not operate.

See Article 12 evidence generated live →