> Markdown version of https://agledger.ai/compliance/eu-ai-act/article-12/
> Full index of this site for AI assistants: https://agledger.ai/llms.txt

# 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, formally adopted by the European Parliament (16 June 2026) and the Council (29 June 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.

Last updated: 2026-07-16 · Statute text per [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689) · Timeline per the [Digital Omnibus (adopted 29 June 2026)](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/)

## What the statute says

Quoted from [Article 12](https://artificialintelligenceact.eu/article/12/) of the consolidated text. The [official version on EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) 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 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 (COSE_Sign1 Signed Statements; JSON, CSV, NDJSON, and OCSF projections) 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](https://agledger.ai/deployment/).

up[EU AI Act - full capability crosswalk](https://agledger.ai/compliance/eu-ai-act/)

concept[AI agent audit trail - what it is, what it must prove](https://agledger.ai/ai-agent-audit-trail/)

next[ISO/IEC 42001:2023](https://agledger.ai/compliance/iso-42001/)

install[Install locally](https://agledger.ai/docs/install/)