EU AI Act Article 12, mapped to AER-1 receipt fields

Article 12 of the EU AI Act (Regulation (EU) 2024/1689) is the record-keeping article: a high-risk AI system must record what it did, automatically, in a form that stays checkable for the system's lifetime. AER-1 (IETF Internet-Draft draft-zambo-aer1-26) is an open receipt format for AI agent tool calls: one receipt per call, carrying the exact saved output bytes and their SHA-256 digest, resolvable by anyone at a stable public URL. This page maps Article 12 onto AER-1 field by field, so a team building its logging story can see which receipt fields answer which paragraph of the article, and which parts of the article no record format can answer for them.

The requirement, in the regulation's own words

Article 12(1): "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(2) sets the purpose: logging capabilities shall enable the recording of events relevant for identifying risk situations, facilitating post-market monitoring, and monitoring the operation of the system. Article 12(3) adds a minimum content list for the biometric identification systems in Annex III point 1(a). Retention sits one article away: Article 19(1) requires providers to keep the logs "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months", and Article 26(6) sets the same floor for deployers, for logs under their control. The high-risk requirements apply in stages under Article 113; as amended by the Digital Omnibus (Regulation (EU) 2026/1744), the Annex III high-risk duties apply from 2 December 2027, and the duties for Annex I product-legislation systems from 2 August 2028. Full text: Regulation (EU) 2024/1689 on EUR-Lex.

The mapping

Article 12 element	What the article asks for	AER-1 fields that carry it	How the fields answer it
Article 12(1)	"the automatic recording of events (logs) over the lifetime of the system"	One receipt per tool call: id, created_at, receipt_schema_version (draft Section 3, Table 1). Workflow receipts (Section 8) and job timelines (Section 7) accumulate the receipts.	Recording is part of the call itself, not a separate logging step a developer can forget: in the reference implementation every tool call issues its receipt when it runs, including calls that are rejected. The receipt id is a stable, unique identifier for that one event, and created_at is an RFC 3339 timestamp, so the log is a sequence of individually addressable events across the system's whole life.
Article 12(2), traceability	"a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose"	canonical_bytes and output_hash (Sections 3 and 4); metadata_hash (Section 3.1); verification_status and the verification procedure (Section 6); resolution at a stable public URL (Section 9).	output_hash is the SHA-256 digest of the exact saved output bytes, so a checker recomputes the digest from canonical_bytes and compares: the record either matches what was saved or it does not. metadata_hash binds the receipt id, timestamp, tool, and provenance into a second digest, so a metadata field swapped after the fact also fails the check. Any party (provider, deployer, auditor, authority) can run the Section 6 procedure against the public URL with no account, so traceability does not depend on the operator's own dashboard.
Article 12(2)(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"	Step status on each receipt; execution_context.readback with its mismatch flag (Section 3.2); supersedes (Section 9); per-anchor outcomes including "not checked" (Section 6).	Failures and disagreements are recorded as first-class outcomes, not filtered out of the log: a readback whose fresh read disagrees with the intended change is recorded with mismatch set to true, corrections are issued as new receipts that name the receipt they supersede, and an anchor a verifier did not evaluate is reported as "not checked", never dressed up as an evaluated result. The risky moments are the ones the record makes easiest to find.
Article 12(2)(b)	"facilitating the post-market monitoring referred to in Article 72"	Workflow receipts (Section 8): the ordered step receipt ids bound to one goal under a single Merkle root (Section 8.1), plus hash-chained job timelines (Section 7, with seq and prev_digest on each entry).	Post-market monitoring needs the record of a whole job or a whole period, not a pile of unrelated lines. A workflow receipt binds every step of one job to one root, so a reviewer checks the job as a unit and spots a missing or reordered step. Timelines chain receipts across time, so a later edit to one entry breaks the chain at that point. Both stay retrievable at their public URLs for the review that happens months later.
Article 12(2)(c)	"monitoring the operation of high-risk AI systems referred to in Article 26(5)"	tool (name, version, scope) and provenance_class (Sections 3 and 5) on every receipt; execution_context (Section 3.2) naming the model, framework, source system, and environment; the caller record and session trail on deployed receipts.	Each event names the tool that ran, its version, the caller's scope, and who ran or reported the action (the provenance class separates what the system executed from what a caller merely reported). Where the producer records it, execution_context adds the model name and version behind the call and the environment it ran in, which is the context an operator needs to monitor behaviour across versions.
Article 12(3)(a)	"recording of the period of each use of the system (start date and time and end date and time of each use)"	created_at on every receipt (RFC 3339, a real calendar date and time; Section 3); started_at and completed_at on the step records of deployed receipts.	Timestamps are part of the committed record, not display metadata: created_at sits inside the metadata block that metadata_hash binds, so a backdated or edited timestamp fails verification.
Article 12(3)(b)	"the reference database against which input data has been checked by the system"	execution_context.source (Section 3.2); input_hash (Section 3.3).	source names the specific external system the call acted upon (a database, a repository, an API endpoint). input_hash commits to the recorded input, with its published byte layout stating the ordering rule it applies, so the check that was run can be tied to the source it was run against.
Article 12(3)(c)	"the input data for which the search has led to a match"	input_hash (Section 3.3); the evidence references on deployed receipts, which resolve the captured evidence bytes by their own digest.	The input that produced the outcome is committed by digest at the moment of the call, and the captured evidence behind a result is stored content-addressed: the evidence bytes either hash to the recorded digest or they are not the bytes that were saved.
Article 12(3)(d)	"the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5)"	Partial, and named as such: provenance_class (Section 5) records who ran or reported each action, and the reference implementation records accept and flag decisions on handovers. The AER-1 core does not itself name natural persons.	This row belongs to the deployment, not the format. A system in scope for Article 12(3) records its human reviewers in its own records; AER-1 gives those records something solid to attach to, since each verification decision can cite the receipt id it was made against, and that receipt still verifies. Any mapping that claims a log format alone satisfies 12(3)(d) is overselling, including this one if it said otherwise.
Retention: Article 19(1) and Article 26(6)	Logs kept "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months"	Stable public URL per receipt (Section 9); the external anchor (Section 10): an envelope binding the receipt id, output hash, and evidence hash, published outside the operator's own store (SCITT and RFC 3161 anchors are also permitted).	The retention period itself is an operator duty, and the format does not set it. What AER-1 adds is that a kept record stays provable for as long as it is kept: because the digest binding also lives in an anchor the operator does not control, a record quietly edited during its retention period fails the Section 6 check instead of passing as the original.

What this mapping does not do

It does not classify anything. Whether a system is high-risk is a legal determination under Articles 6 and 7 and Annexes I and III. AER-1 has no opinion on it.
It does not replace the rest of Section 2. Technical documentation (Article 11), the quality management system (Article 17), human oversight design (Article 14), and accuracy and robustness work (Article 15) are their own obligations. Article 12 is the logging slice, and this page maps only that slice.
A verified receipt proves the record, not the work. Verification shows the saved result was not changed since it was saved. It does not show the result was right, safe, or compliant. That judgment stays with the provider, the deployer, and the authorities, who now make it against a record they can check instead of a printout they have to trust.
This page is an engineering map, not legal advice and not a conformity claim for any specific system.

Running Article 12 logging today

Zambo is the reference implementation of AER-1, run as one hosted MCP endpoint at https://zambo.dev/mcp with 153 tools. Work your AI runs through Zambo is receipted as it runs: every call gets its AER-1 receipt at a public https://zambo.dev/run/ page, sessions close into workflow receipts under one Merkle root, and anyone can check any receipt at zambo.dev/verify with no account. The free tier is 20 calls and 1 wrap-up free every day, and picking up in another AI is always free; the Day Pass is $0.99 for unlimited use for 24 hours. If your agents' tool calls are part of a high-risk system's story, this is what their event log looks like when it is built to be checked.

Go deeper

AER-1, the receipt format: the standard itself, its conformance corpus, and its verifiers.
The agent execution receipt standard: why the format is shared, and what it deliberately leaves out.
AI agent compliance evidence: what a compliance review can actually check, receipt by receipt.
AI agent logging for compliance: the logging pattern behind this mapping.
EU AI Act Article 12 logging for AI agents: the practical companion to this page, with the per-event checklist and a filled sample receipt.

Sources: Regulation (EU) 2024/1689 of 13 June 2024, Articles 12, 19, and 26, EUR-Lex (eur-lex.europa.eu/eli/reg/2024/1689/oj/eng); draft-zambo-aer1-26, datatracker.ietf.org/doc/draft-zambo-aer1/26/.