EU AI Act Article 12: record-keeping and AER-1 fields
Last updated: 2026-09-27
This page places the original Article 12 record-keeping language alongside only the receipt fields defined by AER-1. A matching timestamp or execution record is not the same as coverage of every Article 12 requirement.
Try the Zambo demo · Explore Zambo
Informational technical mapping only — not legal advice, a legal interpretation, or a certification of compliance with any law.
Article 12 quotations and field-by-field comparison
Each left-column quotation is from Regulation (EU) 2024/1689, Article 12. The right column uses the AER-1 core receipt fields described in the cited IETF Internet-Draft, version -01. “—” means AER-1 defines no field equivalent to the quoted record-keeping element; it is not an assertion that an implementation could never store other data.
| Regulation (EU) 2024/1689, Article 12 — original text | AER-1 receipt field | Plain-language mapping note |
|---|---|---|
High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.Regulation (EU) 2024/1689, Article 12(1), EUR-Lex |
— | AER-1 defines a portable receipt record, including created_at, but does not define a field for automatic logging capability or completeness across a system’s lifetime. |
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:Regulation (EU) 2024/1689, Article 12(2), EUR-Lex |
— | AER-1 receipts identify and make an individual recorded execution checkable; the core schema has no field describing the purpose-specific event-logging capability of a high-risk AI system. |
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;Regulation (EU) 2024/1689, Article 12(2)(a), EUR-Lex |
— | No AER-1 core field classifies a logged event as a risk situation or substantial modification. |
facilitating the post-market monitoring referred to in Article 72; andRegulation (EU) 2024/1689, Article 12(2)(b), EUR-Lex |
— | The receipt identity, timestamp, tool, and output commitment may make a recorded call reviewable, but the draft defines no field for post-market monitoring under Article 72. |
monitoring the operation of high-risk AI systems referred to in Article 26(5).Regulation (EU) 2024/1689, Article 12(2)(c), EUR-Lex |
— | tool names a tool, version, and caller scope; it is not a field for monitoring operation of the high-risk AI system described in Article 26(5). |
For high-risk AI systems referred to in point 1 (a), of Annex III, the logging capabilities shall provide, at a minimum:Regulation (EU) 2024/1689, Article 12(3), EUR-Lex |
— | AER-1’s core receipt schema does not identify an AI system’s Annex III category or declare that these minimum logging capabilities are present. |
recording of the period of each use of the system (start date and time and end date and time of each use);Regulation (EU) 2024/1689, Article 12(3)(a), EUR-Lex |
created_at (non-equivalent; partial time information only) |
created_at is the RFC 3339 timestamp of receipt-record creation. AER-1 does not define use start time, end time, or duration, so this is not a record of the period of each system use. |
the reference database against which input data has been checked by the system;Regulation (EU) 2024/1689, Article 12(3)(b), EUR-Lex |
— | No AER-1 core field identifies a reference database used to check input data. |
the input data for which the search has led to a match;Regulation (EU) 2024/1689, Article 12(3)(c), EUR-Lex |
— | canonical_bytes is the exact UTF-8 byte sequence committed to by the output hash; it is not a defined field for matching input data. |
the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5).Regulation (EU) 2024/1689, Article 12(3)(d), EUR-Lex |
— | tool includes caller scope, and provenance_class describes how an action was recorded. Neither is a field identifying the natural persons who verified results. |
How to read the comparison
AER-1 specifies core fields including id, receipt_schema_version, created_at, tool, provenance_class, canonical_bytes, output_hash, and verification_status. Its created_at field is the record creation time; the draft does not equate it with the start or end of a system use. The comparison therefore marks elements without an equivalent defined field with “—” rather than treating nearby receipt data as a substitute.
AER-1 describes a receipt format for a recorded tool-call execution. This table does not assess whether a system, provider, or deployer meets any legal obligation.
Sources
- Regulation (EU) 2024/1689, Article 12 (“Record-keeping”), official EUR-Lex text.
- IETF Internet-Draft draft-zambo-aer1-01, “AER-1: A Portable Execution Receipt for AI Agent Tool Calls” (field definitions, Section 3). It is an Internet-Draft, not a finalized standard.
- IETF Datatracker HTML for draft-zambo-aer1-01.
Article 12 quotations above were checked against the live EUR-Lex text. The receipt-field names and meanings above were checked against the live -01 IETF draft.