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. Under the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), the obligations apply to standalone high-risk Annex III systems from 2 December 2027, and to high-risk AI embedded in regulated products from 2 August 2028.
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.
Statute text per Regulation (EU) 2024/1689 · Timeline per the Digital Omnibus, Regulation (EU) 2026/1744
What the statute says
Quoted from Article 12 of the consolidated text. The official version on EUR-Lex is authoritative; this page is a reading of it, not a substitute for it.
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 high-risk AI systems referred to in point 1 (a), of Annex III, the logging capabilities shall provide, at a minimum: (a) recording of the period of each use of the system (start date and time and end date and time of each use); (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match; (d) the identification of the natural persons involved in the verification of the results, as referred to in 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 post-market monitoring under Article 72, for serious-incident reporting under Article 73, 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. 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 from hop to hop 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, with BEFORE TRUNCATE triggers on the vault and checkpoint tables, blocks out-of-band wipes | Setting and operating the retention period |
| Art. 72 / 73 - post-market monitoring and serious-incident reporting | Signed audit export (COSE_Sign1 Signed Statements; JSON, CSV, NDJSON, and COSE formats) verifiable offline by a third party against published keys, so the monitoring system under Article 72 and an incident file under Article 73 draw on one signed source | Incident determination, authority notification, and the filing obligation |
Where AGLedger sits under the Act
AGLedger is not an AI system under Article 3(1) and is not classified under any risk tier of the Act. It is an accountability-evidence layer: deployer- and provider-facing tooling that produces the records the high-risk obligations call for, in a form a regulator or counterparty can verify offline.
It records, and control stays with the systems that run the agent. Article 14(4)(e) contemplates a human who can interrupt the system; that interrupt lives in your orchestration, and AGLedger records that a halt was requested. The product has no halt state and no halt endpoint, so the Article 14 control is met elsewhere in the deployment.
Accuracy under Article 15 is measured by your evaluation; verdicts record acceptance against the criteria you set. The evidence layer validates the structure of the evidence and leaves business data, prompts, and model outputs unread, and an encrypted record's payload is unreadable to it by construction.
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, and Articles 19 and 26(6) both give way to Union law on the protection of personal data where it provides otherwise. 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.