The EU AI Act is in force. For high-risk AI systems it does something most teams have not priced in: it makes the record of what the system did a legal artefact, not an operational nicety. You must be able to produce logs of what happened — and keep them.
Almost everyone reads that as "turn on logging and set a retention policy." That clears the letter of the requirement for now. It does not survive the first incident, audit, or dispute — because a log you keep yourself is not evidence.
What the Act actually asks for.
Three obligations matter for the record itself.
- Article 12 — record-keeping. High-risk AI systems must technically allow for the automatic recording of events (logs) over the lifetime of the system, sufficient to identify risk situations and support post-market monitoring.
- Article 19 — retention. Providers must keep those automatically generated logs for a period appropriate to the purpose, at least six months, unless other law says longer.
- Article 50 — transparency. AI-generated content must be marked in a machine-readable, detectable format.
On timing: under the original schedule the high-risk duties applied from August 2026. A May 2026 simplification ("Omnibus") agreement moves the main stand-alone high-risk (Annex III) deadline to December 2027 — confirm against the Official Journal, as publication was still pending at the time of writing. Article 50 (content marking, August 2026) and the GPAI obligations (August 2025) are not delayed. Penalties for the high-risk obligations reach €15M or 3% of global turnover. This is not legal advice — but the direction is not ambiguous: regulators are treating automated decisions as auditable artefacts.
A log you keep yourself is not evidence.
Here is the gap the Act will expose. The party that made the decision also holds the log. It lives in a database that party controls. It can be edited, re-ordered, or back-dated, and nothing in the log itself says otherwise. To an auditor, a regulator, or a counterparty, that is a claim — not proof.
Compliance that rests on "trust our logs" fails the first time someone has a reason not to. What an auditor actually wants is a record they can verify independently: one they can confirm has not been altered, and that demonstrably existed at the time it claims to — without taking the deciding party's word for any of it.
"We kept the logs" is a claim. "Here is a record anyone can verify, anchored in time" is evidence.
Verifiable Decision Records.
A Verifiable Decision Record (VDR) is an open, vendor-neutral format for one automated decision, built so that anyone can verify it with only mathematics and public infrastructure — never the reputation of the party that produced it, and never ours. It carries two properties an internal log cannot:
- Integrity. The record's contents hash to a stable digest. Recompute it and a single altered byte is exposed. This is instant and needs no one's permission.
- Existence in time. That digest can be anchored to public infrastructure, so its existence at a point in time is provable and cannot be back-dated.
And it is private by construction: only the digest is ever published. The decision payload — which often contains personal data or trade secrets — never leaves your environment. That matters, because the AI Act does not arrive alone; the GDPR is still in the room.
The mapping.
How the obligations line up with the format:
Article 12 — automatic record-keeping
Each decision becomes a structured VDR at the moment it happens. That is precisely the "automatic recording of events" the Act says a high-risk system must technically allow — except the record is portable and self-describing, not trapped in a vendor console.
Article 19 — provable retention
Retention is not just storage; it is being able to show a record existed and was unaltered across the retention window. Anchoring the record's digest gives you existence-at-a-time you can prove, not merely assert. A mutable database row, however well backed up, cannot.
Article 50 — content marking
The record binds a digest to the output that was produced — a machine-readable handle to "what this system generated," available to support detectable marking rather than bolted on after the fact.
Post-market monitoring (Article 72)
When a market-surveillance authority asks for the record behind a decision, you hand over a self-contained artefact they can verify themselves — not an export from a system they would otherwise have to trust.
What this is — and is not.
A VDR is the verifiable record layer: the evidence. It is not your whole compliance programme. It will not classify your system, write your risk assessment, or stand in for a data-protection impact assessment. What it does is make the records themselves auditable, tamper-evident, and independently verifiable — the part that is hardest to retrofit and easiest to get caught without.
The format is an open standard (draft v0) with a reference implementation you can use today: wrap your client, capture a record, verify it in your own shell. A managed evidence layer for compliance teams sits on the roadmap on top of the same records.
If you operate AI in production and the words "prove what it did" are starting to appear in your roadmap, the format is open and the implementation is real. Verify a record yourself, read the spec, or get in touch.