This contribution proposes a concrete, reference example of an equivalent integrity mechanism for the tamper-evidence and independent-verifiability of automatically generated AI system logs. In scope: the integrity and operator-independent verifiability of the log record. Out of scope: automatic capture, retention duration, and the content correctness of logs, which remain the operator's responsibility.
Article 12 of the EU AI Act (Regulation (EU) 2024/1689) requires a high-risk AI system to technically allow the automatic recording of events over its lifetime. It is a capability requirement on the system. It does not, by its own terms, require the retained log to be tamper-evident or independently verifiable. Retention sits in the adjacent articles: a provider keeps the logs under Article 19, and a deployer under Article 26(6), each for at least six months.
Under Article 40, conformity with a harmonised standard whose reference is published in the Official Journal carries a presumption of conformity, so the standards drafted by CEN-CENELEC JTC 21 under mandate M/593 are where the integrity of a retained log is actually specified. Those drafts do not mandate a specific technology, and they name integrity mechanisms such as cryptographic signatures, transparency-log inclusion proofs, or equivalent mechanisms. This contribution offers one such equivalent mechanism, aimed at the highest bar the drafts contemplate: verification by a third party without relying on the operator's own systems.
The highest bar, verification without trusting the operator, is where an operator-run hash chain or an operator-run transparency log is weakest, because the operator controls that store. A mechanism anchored to a ledger the operator cannot rewrite closes this gap.
Each retained log record is canonicalized (RFC 8785) and hashed with SHA-256; records are bound in a Merkle structure and hash-chained, so each entry commits to the one before it. The head is committed to an independent, append-only substrate the operator does not control: an OpenTimestamps proof anchors it into Bitcoin block headers, and, optionally, an RFC 3161 timestamp from an accredited Time-Stamping Authority adds a format European authorities already recognize. To verify, a third party recomputes the chain from the records, checks Merkle inclusion, and checks the anchored head against a Bitcoin block header or the TSA certificate, needing nothing from the operator and nothing from any vendor. Editing any historical record breaks the chain and no longer matches the anchored head. Only the hash is ever anchored, so a log containing personal data can be integrity-proven without disclosure.
| Property | How the mechanism provides it | What stays the operator's |
|---|---|---|
| Tamper-evidence of the retained log | SHA-256 Merkle and hash chain, head anchored to a public ledger | — |
| Independent time | OpenTimestamps to Bitcoin block headers; optional RFC 3161 TSA | — |
| Verification without trusting the operator | Recompute and check against the public ledger, offline | — |
| Automatic recording of events, Art. 12(1) | — | The AI system must generate the logs |
| Retention, at least six months, Arts. 19 and 26(6) | — | The provider or deployer stores and retains them |
| Content correctness of the log | — | The operator |
A concrete, technology-neutral note the drafters could insert:
A runnable worked example builds a hash-chained agent audit trail on the ISO/IEC 24970 style event model and anchors the head, with tamper detection. It runs with the standard library, no dependencies, so a reader can reproduce every step.
JTC 21 is a nation-mediated committee. Individuals and companies do not join it directly. Technical input flows through the national standards bodies and their mirror committees, for example DIN, AFNOR, BSI, or NEN, through the public Enquiry windows when a draft is opened for comment, through recognized liaison organizations such as ANEC, or through the international track at ISO/IEC JTC 1/SC 42 under the Vienna and Frankfurt agreements. There is no direct, membership-free route for a project outside that structure, and we do not represent this contribution as writing or shaping the standard.
The honest role for an independent protocol is to be citable prior art: an open, interoperable reference a committee member can point to on the merits. That is what this page, the worked example, and the underlying open-source tool are for. We offer the mechanism for consideration alongside the integrity mechanisms the drafts already name, and we would welcome routing it through a national body during an Enquiry window.
This contribution proposes one reference mechanism for the integrity and verifiability of a log. It is not a compliance solution, it is not legal advice, and the operator remains responsible for capture, retention, and the content of the logs. It is offered openly, for consideration alongside the other integrity mechanisms the standards already name.