Article 12 of the EU AI Act (Regulation (EU) 2024/1689) requires high-risk systems to technically allow automatic event logging over their lifetime. It binds providers, not deployers. The text says the capability must exist, almost nothing about what to record, and nothing about protecting records once written. No provision requires a tamper-evident log — but a log nobody else can verify is weak evidence. So: canonical serialisation, hashing at the trust boundary, domain-separated Merkle commitment, roots witnessed by parties I do not control, write-once retention.
Ross Jones — Founder, The Hopium Lab. Last modified 21 July 2026.
I have shipped 24 products and built audit infrastructure a third party can verify without trusting me. Engineering, not legal advice: architecture supports a compliance case and never confers one, because compliance is a property of an organisation's whole quality management system, not of a logging library.
What does the record-keeping obligation actually say?
Article 12 is three paragraphs. High-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system", and those logs "shall enable the recording of events relevant for" risk identification and post-market monitoring. Read the regulation, not a vendor's paraphrase.
Capability words, calibrated to intended purpose. No field schema. The one exception is Article 12(3): minimum fields, only for Annex III point 1(a), remote biometric identification, not categorisation and not emotion recognition. Anyone telling you the Act specifies your log schema is selling you a schema.
Integrity, immutability, tamper-evidence and cryptography appear nowhere in the text. Retention sits elsewhere: Articles 19 and 26(6) impose a six-month floor on providers and on deployers for logs under their control, regulated financial institutions excepted. A floor, not an answer.
Has the compliance deadline moved?
Yes, and most published guidance has not caught up. The Digital Omnibus on AI, signed 8 July 2026, defers stand-alone Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and Annex I embedded systems from 2 August 2027 to 2 August 2028. Fixed dates as reported, not the standards-dependent trigger first proposed — though I have not read the final consolidated Article 113, and any conditionality that survived could only pull the dates earlier.
Most published guidance on AI Act record-keeping still names 2 August 2026 as the deadline. Once the Digital Omnibus amendment is in force, that date is wrong for stand-alone high-risk systems: the obligation applies from 2 December 2027.
Caveat, because I would rather be trusted than early: as of 21 July 2026 I could not confirm the amendment's Official Journal citation, and deferred dates bind only from its entry-into-force date (TFEU default: twenty days after publication). Verify that citation before planning against December 2027. And 2 August 2026 still bites — Article 50 transparency duties switch on, and enforcement machinery arrives for duties already in force, including Article 4 AI literacy, applicable since 2 February 2025.
Is there a standard that tells you how to build the log?
No. Zero AI Act harmonised standards are published and zero are cited in the Official Journal as of July 2026. ISO/IEC 24970 (AI system logging) sits at FDIS; prEN 18229-1 reached CEN-CENELEC Enquiry in early 2026 with the Annex Z mapping that would confer presumption of conformity under Article 40. CEN and CENELEC target Q4 2026, citation later. ISO/IEC 42001 certifies a management system, not a product, so it confers nothing here.
Nothing published tells you how to build the log, and nothing will for sixteen months. The compliance industry's answer to the missing mechanism is "maintain tamper-evident logs", full stop, because the people writing the guidance have never built one.
What does a verifiable record actually contain?
A verifiable record is a canonically serialised event, hashed at the boundary where it enters or leaves the system, committed into a domain-separated Merkle tree whose root is published where the writer cannot reach it.
Hash placement is the part people get backwards, and not for the usual reason. A hash commits to bytes; early or late, it never attests that those bytes truthfully describe what the system did. What placement buys is protection from your own pipeline: commit to inputs as received at the trust boundary, and to outputs at generation, before normalisation or redaction rewrites the record.
THE REPLAY TEST: Can you rebuild the answer without calling the model? If not, you don't have a system. You have a demo with a try/except around it.
My own infrastructure passes the replay test on a schedule, not by assertion: event sourcing with CQRS and idempotency keys, projectors pinned to fixed dependency versions, canonical number formatting, no clock or locale reads. W3C Data Integrity proofs — a Recommendation since 15 May 2025, so anything calling the spec a draft is stale — with eddsa-jcs-2022, where RFC 8785 canonicalisation rather than the signature is where real bugs live. did:key for portable verification, which carries no rotation and no revocation: rotation means cross-signing roots outside the DID layer, and a proof's created field is signer-asserted, not a trusted timestamp.
Article 12(2)(a) asks for runtime logging able to record events relevant to identifying a risk under Article 79(1) or a substantial modification. A pre-ship calibration harness, replaying human-reviewed records under a changed prompt and diffing the outcomes, supports that case. It does not satisfy it.
Do you need a hash chain or a Merkle tree?
Use a chain when you are the only verifier, and a tree the moment a third party must check one record without reading all of them. Crosby and Wallach set the trade-off out at USENIX Security in 2009: chains cost O(n) to verify because you replay everything, history trees O(log n). RFC 6962 bounds an inclusion proof at ceil(log2(n)) nodes, a consistency proof at ceil(log2(n)) + 1. (RFC 9162 restates it hash-agile; 6962 is not obsolete.)
| Mechanism | Proves | Does not prove |
|---|---|---|
| Per-record signature, key held outside the app | The key holder signed those bytes, unchanged since | Authorship, or that nothing was deleted — truncate the tail and every survivor verifies |
Hash chain, h_i = H(h_{i-1} ‖ e_i) | Order, append-only relative to a head someone else already witnessed | Anything if you hold the only head: rewrite entry 5, recompute forward, it verifies |
| Merkle log, RFC 6962 §2.1: inclusion (§2.1.1), consistency (§2.1.2) | One record's inclusion without revealing the rest; append-only extension of an earlier tree | That the operator showed everyone the same tree |
| RFC 3161 token over the root | The root existed no later than genTime | When the event happened, who held the data, what it said |
| Roots at several witnesses who compare what they were served | Equivocation is detectable: two roots for one log at one tree size are proof of misbehaviour | That no split view happened — publishing prevents nothing, and a witness only you feed detects nothing |
| S3 Object Lock, compliance mode: a control, not a proof | The object version survives deletion until expiry, even by account root | Truth of contents — and a plain DELETE still returns 200 via a delete marker |
Read the timestamping spec before leaning on a token. It proves a digest existed no later than genTime plus the accuracy field — an interval, not a point — and carries no requester identity, so it proves neither authorship nor possession: anyone holding the digest can buy one. Backdating is impossible for the requester, not for a compromised or colluding TSA, so the assertion collapses to trust in that TSA's key and clock. Forward-dating is trivial. Tokens decay too: RFC 4998 exists because algorithms age out.
Why not just put it on a blockchain?
Because a blockchain solves Byzantine agreement on ordering between mutually distrustful parties, and an audit log has one writer and nobody disputing the order. The useful subset — witnessed publication of a periodic root — is one line of the design. And at the oracle boundary a chain changes nothing: garbage in, immutably ordered garbage out.
How do tamper-evident audit logs fail in production?
Tamper-evident audit logs fail in a handful of recognisable ways, and cryptography is rarely the culprit. Name the failures, because unnamed risks never get budget.
- Log-after-process. Action commits, record appends, crash in between: the action happened with no evidence. Write-ahead instead.
- Marking your own homework. Verification reads the entries and the expected root from the same store, so one write credential rewrites both and verification passes.
- Truncation and deletion. Signatures cannot see a missing record, tail or middle — every survivor still verifies. Only a consistency proof against an externally witnessed root, or a sequence number a third party has already seen (the RFC 5848 pattern), catches it.
- Node-as-leaf. Without RFC 6962's 0x00/0x01 prefixes, an internal node's value — 64 bytes with a 256-bit hash — submitted as a leaf verifies against the same root: one preimage space, ambiguous encoding. Prefixing fixes it by tag, double-hashing leaves by length, sorted-pair hashing not at all.
- Non-canonical serialisation. Re-serialised JSON with different key order or float formatting hashes two ways. Hash the bytes you stored, or canonicalise with RFC 8785.
- Drop-on-backpressure. A bounded async queue discards under load, and the dropped events are the incident you will be asked about. Failing to log must fail the operation.
- Governance-mode theatre. S3 Object Lock in governance mode is bypassable by anyone holding
s3:BypassGovernanceRetention, and the console sends that header by default. - Secrets in the log. A token or free-text personal data in a WORM-locked store cannot be removed: an integrity control becomes a permanent data-protection incident.
Tamper-evident is not tamper-proof. Cryptography detects modification and never prevents it; only access control and write-once retention prevent anything.
What does a record-keeping failure cost?
Up to EUR 15,000,000 or, where the offender is an undertaking, 3% of total worldwide annual turnover for the preceding financial year, whichever is higher — the second of three tiers, under Article 99(4). Article 12 appears nowhere in the penalty article: a provider's failure reaches that tier through Article 16(a), a deployer's retention failure under Article 26(6) lands there directly.
The 35 million / 7% headline belongs exclusively to the Article 5 prohibited practices, so anyone telling you logging failures carry 7% is wrong. For SMEs, Article 99(6) inverts it: the cap becomes the lower figure. Member States set actual levels; the Act sets ceilings.
What should an Article 12 logging checklist contain?
Mechanisms, in seven groups: record construction, commitment, time, custody, storage, failure behaviour, proof. The version below is the one I run against my own systems, revised 21 July 2026. Every line is a mechanism, not a restated obligation. Copy it, fork it, argue with it.
ARTICLE 12 LOGGING — EVIDENCE ARCHITECTURE CHECKLIST — v1.0 (21 July 2026)
The Hopium Lab. Supports a conformity case. Does not confer conformity.
Not legal advice.
RECORD CONSTRUCTION
[ ] Canonical serialisation (RFC 8785 JCS) before any hash is taken
[ ] Leaf preimage from length-prefixed fields, never bare concatenation
[ ] Inputs hashed as received at the trust boundary; outputs at generation,
before normalisation or redaction
[ ] Model id, weights version, prompt hash, temperature, seed as fields
[ ] Server-assigned monotonic sequence number on every record
COMMITMENT
[ ] Leaves H(0x00 || leaf), nodes H(0x01 || left || right) — RFC 6962
[ ] Inclusion proofs checked against a published root, never the database
[ ] Consistency proofs on a schedule, paging a human on failure
TIME
[ ] Timestamps server-side; caller time kept as a separate field
[ ] Periodic RFC 3161 token over the root, from a TSA you do not operate
[ ] Re-timestamping before TSA cert or hash algorithm ages out (RFC 4998)
CUSTODY
[ ] Signing key sign-only in HSM/KMS; the application cannot export it
[ ] Writing service holds append-only credentials, no delete rights
[ ] Roots published on a fixed cadence to more than one party that is not
you, and those parties compare what they were served
[ ] Rotation cross-signs the previous key; historical roots stay verifiable
STORAGE
[ ] Object Lock in COMPLIANCE mode (governance mode is bypassable)
[ ] Versioning on, and readers handle delete markers instead of "gone"
[ ] Retention set to the period appropriate to intended purpose
[ ] No secrets, credentials or free-text personal data in the record body
FAILURE BEHAVIOUR
[ ] Write-ahead: append intent, act, append outcome
[ ] Failure to log fails the operation — no silent drop under backpressure
PROVING IT
[ ] A verifier a third party runs against an export, with no access to you
[ ] A dated procedure for producing logs on a market-surveillance request
[ ] Deterministic replay: state rebuilt from the log alone, byte-identical
Every box is buildable this quarter with libraries that already exist. The deadline moved; the exposure did not. Systems designed now will still be running in December 2027, and retrofitting evidence into a log never built to carry it is the most expensive engineering work there is.
Ross Jones, Founder, The Hopium Lab. Last modified 21 July 2026. Engineering guidance, not legal advice.