EU AI Act Article 12 — record-keeping and logging requirements
Article 12 is the record-keeping obligation for high-risk AI systems: the system must technically allow the automatic recording of events — logs — over its lifetime. Articles 19 and 26(6) then require providers and deployers to keep those logs for at least six months. The obligations apply to high-risk systems from 2 August 2026.
This page gives you the statute text verbatim, what each requirement means in engineering terms, a gap checklist, and the one question the statute leaves open — integrity — that determines whether the records are worth keeping at all.
Last updated: 2026-06-05 · Statute text per Regulation (EU) 2024/1689
What the statute says
Article 12 — Record-keeping
12(1)“High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”
12(2)“In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5).”
12(3)For remote biometric identification systems (Annex III, point 1(a)), logging shall provide at a minimum: the period of each use (start and end date and time), the reference database checked, the input data that led to a match, and the identification of the natural persons involved in verifying the results per Article 14(5).
Article 19 — Automatically generated logs (providers)
“Providers of high-risk AI systems shall keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control. Without prejudice to applicable Union or national law, the logs shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data.”
Article 26(6) — Automatically generated logs (deployers)
“Deployers of high-risk AI systems shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months.”
Note the vocabulary: the statute says record-keeping, automatic recording of events (logs), and traceability. It never says “audit trail” and never says “tamper-evident.” Both gaps matter below.
Do ordinary application logs satisfy Article 12?
Sometimes on paper. Rarely under challenge.
Article 12 specifies what to record: automatic, lifetime, traceability-relevant events. It is silent on how to make the record credible. A conventional logging pipeline — application logs shipped to a centralized store — can capture the right events and still fail at the only moment the records matter: when someone questions them. Mutable logs can be altered or truncated by anyone with write access to the store, and nothing in the log itself proves completeness. When a market-surveillance authority, an auditor, or a counterparty challenges a record, a mutable log can only be vouched for. It cannot be verified.
That is the gap between logging and record-keeping. The statute's own word is the stronger one: records are kept to be relied on — for Article 72 incident reconstruction, for post-market monitoring, for the regulator's file request. A record-keeping implementation that is hash-chained, signed at write time, and verifiable offline turns the same events into evidence: deletion becomes detectable, each entry is bound to the key that wrote it, and a third party can confirm integrity without trusting the operator.
Record-keeping gap checklist
1.Automatic capture
Events are recorded by the system itself as they happen — not assembled afterward from application logs, tickets, or memory. Article 12(1): "automatic recording of events (logs)."
2.Lifetime coverage
Recording runs "over the lifetime of the system" — from first deployment through decommissioning, including after upgrades and migrations. A logging pipeline that was reconfigured mid-year has a coverage gap to explain.
3.Risk-relevant traceability
The events recorded must be the ones that matter under Article 12(2): situations that may present an Article 79(1) risk or a substantial modification, post-market monitoring inputs, and the operational signals deployers monitor under Article 26(5).
4.Retention ≥ 6 months, by control
Providers keep the logs under their control (Article 19); deployers keep the logs under theirs (Article 26(6)). Six months is the floor, not the target — "appropriate to the intended purpose" governs.
5.Integrity and tamper-evidence
The statute is silent here, and this is where most implementations are weakest. A record that can be silently altered or deleted by anyone with store access proves nothing under challenge. Hash-chaining and signatures make completeness and authenticity demonstrable.
6.Attribution
Who acted, and on whose authority. For biometric systems Article 12(3)(d) makes this explicit — the natural persons who verified results must be identified. For automated and agent-driven systems the same question arrives at incident time regardless.
7.Export for authorities
Article 72 post-market monitoring and market-surveillance requests assume the records can leave the system in usable, machine-readable form — without the operator curating what the regulator sees.
Obligation-to-capability crosswalk
A capability mapping, not a compliance certificate. AGLedger provides the evidence pattern; your program provides the scoping, the policy, and the decisions.
| Obligation | AGLedger provides | You own |
|---|---|---|
| Art. 12(1) — automatic recording of events | Every record, completion, verdict, and state change is written to the append-only audit vault automatically, at the moment it happens — signed Ed25519 and hash-chained | Determining which events are in scope for your system |
| Art. 12(2) — traceability appropriate to purpose | Records carry intent, action, outcome, and authority; delegation chains preserve attribution across handoffs via parent record references | Defining what traceability your intended purpose requires |
| Art. 19 / 26(6) — retention ≥ 6 months | Records live in your PostgreSQL under your retention policy; append-only enforcement at the database layer prevents silent truncation | Setting and operating the retention period |
| Art. 72 — post-market monitoring and incident reconstruction | Signed audit export (JSON, CSV, NDJSON, OCSF, DSSE bundle) verifiable offline by a third party against published keys | Incident determination and the filing obligation |
Article 12 logs are themselves data: GDPR residency and international-transfer analysis applies to the records as much as to the system that produced them — Article 19 says so explicitly. Self-hosting keeps that analysis short. The logs live in your PostgreSQL, in the jurisdiction you choose, with no processor relationship introduced by the evidence layer. Data sovereignty is a property of the deployment model.