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. Where Article 12 applies, Article 113(c) of the consolidated Act sets its application dates to 2 December 2027 for systems under Article 6(2) (Annex III), and 2 August 2028 for systems under Article 6(1) (Annex I). This page quotes Article 12 and maps its logging requirements to deployed receipt capabilities.

Receipts preserve submitted records and support review of these obligations. Whether a system is high-risk, whether its logging covers the required events, and whether a deployment complies require assessment of that deployment and the applicable law.

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

Article 113(c) of the consolidated EU AI Act applies Chapter III, Sections 1 to 3, except Article 6(5), from 2 December 2027 to high-risk systems under Article 6(2) (Annex III), and from 2 August 2028 to systems under Article 6(1) (Annex I). These dates include Article 12. They do not defer every obligation in the Act. Article 50 transparency obligations apply from 2 August 2026. The Commission's Article 50 guidance describes a limited grace period until 2 December 2026 for marking and detection requirements on systems placed on the market before 2 August 2026. That grace period does not apply to all Article 50 duties. GPAI model obligations under Articles 51 to 56 apply from 2 August 2025, subject to the Act's transitional provisions.

This mapping follows the regulation text. It does not establish conformity with a harmonised technical standard.

The mapping

"Automatic recording of events (logs)"

Successful signing creates a receipt with the agent identity, issue time and decision. Payload-mode receipts include action_type; hash-mode receipts preserve a digest and metadata retained after filtering instead. A refused or unavailable signing request may produce no receipt. An SDK integration can submit records from the call site, supporting automatic recording under Article 12(1). The integration determines which events are submitted, and the receipt does not prove that an asserted action happened at its stated time.

"Over the lifetime of the system"

A receipt can commit to its predecessor, allowing a holder of both records to check the link. Removing a record between retained neighbours leaves a detectable gap. The Replay API retrieves recorded sequences, and the open verifier can check a supplied predecessor offline. These checks do not detect actions that were never recorded or prove that the retained sequence includes its original beginning and end.

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)

Export receipts with their signed bytes and retain the trusted public-key material, verifier and its dependencies needed to check them. Preserve applicable anchor proofs and trust material as well. Those retained materials support offline checks after hosted retention ends; keeping an export alone does not guarantee future verification or satisfy every retention obligation.

What receipts add that the article does not ask for

A signature lets a reader check whether the signed bytes match a record issued under a trusted key. In the hosted service, Asqav controls the platform signing key separately from the customer submitting records. That separation makes alteration detectable by a holder of the signed bytes and trusted key material. It does not establish the truth or completeness of submitted events, or independently prove their asserted times. Platform Logs vs Independent Evidence explains the custody distinction.

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