EU AI Act Article 12: Record-Keeping Mapped to Receipts

Article 12 of Regulation (EU) 2024/1689, the EU AI Act, is the record-keeping article for high-risk AI systems. It is short and technical, and for the high-risk systems listed in Annex III the application date is pending a Digital Omnibus amendment. The European Parliament approved the amendment on 16 June 2026, which would defer standalone Annex III obligations to 2 December 2027 and Annex I (embedded safety component) obligations to 2 August 2028. Formal Council adoption and Official Journal publication are still pending, so treat the deferred dates as proposed rather than settled. This page quotes the article and maps each part to a deployed Asqav capability.

One wording note before the mapping. Receipts support these obligations and provide verifiable evidence of agent activity. Whether a given system is high-risk, and whether a given deployment complies, are legal determinations for the provider and its counsel. Asqav documents capability, not classification.

What Article 12 says

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)

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).

Regulation (EU) 2024/1689, Article 12(2)

Article 12(3) adds minimum log content for remote biometric identification systems: the period of each use, the reference database checked, the input data that led to a match, and the identity of the humans who verified the results.

Two retention rules sit next to Article 12. Article 19 requires providers to keep the Article 12(1) logs, to the extent the logs are under their control, for at least six months. Article 26(6) puts the same floor on 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, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data.

Regulation (EU) 2024/1689, Article 26(6)

When it applies

The original obligations for high-risk systems listed in Annex III named 2 August 2026. A Digital Omnibus amendment, the subject of a provisional political agreement on 7 May 2026 and approved by the European Parliament on 16 June 2026 (423 votes in favour, 57 against, 174 abstentions), would defer the Annex III standalone application date to 2 December 2027 and the Annex I embedded safety-component application date to 2 August 2028. At the time of writing these revised dates are pending formal Council adoption and Official Journal publication, so treat them as proposed rather than settled. GPAI model obligations under Articles 51-56 were not deferred and remain in force from 2 August 2025.

There is no finalised harmonised technical standard for Article 12 logging yet. The two candidates, prEN 18229-1 (logging, transparency and human oversight) and ISO/IEC 24970 (AI system logging), were both still drafts in June 2026. Teams that need Article 12-shaped records are building against the regulation text itself, which is what the mapping below does.

The mapping

"Automatic recording of events (logs)"

Every agent action signed through Asqav produces a receipt at the time of the action: the agent identity, the action_type, the timestamp, and the policy decision attached to that action. The SDK emits receipts from the call site, so recording happens per event without a manual step. This supports the automatic-recording requirement in Article 12(1).

"Over the lifetime of the system"

Receipts form a tamper-evident chain: a record removed from the middle of the trail leaves a detectable break rather than silence. The Replay API reconstructs the sequence for any window, and the open verifier rechecks the chain offline.

Article 12(2)(a): identifying risk situations

Receipts carry the policy decision for each action, and risk-rule evaluations and emergency halt events are themselves recorded. When someone later asks which actions presented a risk and what the system did about them, the answer is in the record with evidence attached, not reconstructed from memory.

Article 12(2)(b): post-market monitoring

Audit export in CSV and JSON, OpenTelemetry span export, and the EU AI Act audit pack assemble the record for a period into one reviewable artifact. The pack endpoint is POST /agents/{id}/compliance/eu-ai-act and is available on every plan.

Article 12(2)(c): monitoring operation

Receipts stream to SIEM tooling and surface in monitoring views, so the deployer-side monitoring that Article 26(5) describes reads from the same signed record the auditor will read later.

Retention under Articles 19 and 26(6)

The audit pack export produces an offline file that verifies against the published public key after export. A six-month or longer retention window is a matter of holding the exported pack; checking it later does not depend on Asqav being reachable, or existing, at audit time.

What receipts add that the article does not ask for

Article 12 requires logs. It says nothing about why a reader outside the operator should believe them. Asqav signs each record server-side with keys held by an operator unaffiliated with the agent's operator, so the recorded party cannot edit or backdate its own record. That is the difference between keeping a log and holding verifiable evidence that the log is what it claims to be. Platform Logs vs Independent Evidence covers this distinction in full.

Verify the capabilities yourself

The capabilities named on this page are listed in the public discovery document, no account needed:

curl https://api.asqav.com/.well-known/governance.json

Look for sign, audit_export_csv, audit_export_json, audit_trail_replay, policy_enforcement, risk_rules, emergency_halt, and otel_span_export in the capabilities array.

Related pages