Regulation, plainly
Article 12 is two sentences of law that quietly reshape how high-risk AI systems have to be built. Here is what it says, what it doesn't say, the difference between a log and a record an auditor can believe — and a practical checklist for getting there.
The obligation is on the system's design, not just its operation.
Stripped of cross-references, Article 12 of the EU AI Act requires that high-risk AI systems technically allow the automatic recording of events — "logs" — over the lifetime of the system. Not "the operator should keep notes." The system itself must be capable of writing the record, automatically, for as long as it runs.
The logging has to provide a level of traceability appropriate to the system's intended purpose — specifically, enough to identify situations that may present a risk, to support the post-market monitoring the Act requires elsewhere, and to let deployers monitor the system's operation. For certain biometric systems the Act goes further and names minimum contents: the period of each use, the reference database checked, the input data that led to a match, and the identification of the people who verified the result.
Two companion provisions carry the duty forward: providers and deployers must keep the logs under their control — for a period appropriate to the system's purpose and at least six months, unless other EU or national law says longer. And the timing is no longer hypothetical: the high-risk obligations began phasing in for new systems in August 2026, with product-embedded systems following. Which date applies to a given system depends on its classification — a question for counsel, not a website.
Most systems already log. Almost none of those logs would survive a hostile audit.
A conventional application log asserts that something happened and asks to be believed. Whoever operates the logging system can usually edit it, and there is no way for an outsider to tell. That is the uncomfortable truth under most "we log everything" answers: the record and the party being audited are the same thing.
Traceability — the word Article 12 actually uses — implies something stronger. A market-surveillance authority, an auditor, or an opposing expert reading your logs two years after the fact needs to know three things a plain log cannot tell them:
Tamper-evidence: any alteration after the fact must be detectable by the reader, not just promised by the writer.
Independent time anchoring: a timestamp issued by the system being audited proves nothing. One signed by an authority with no stake in the outcome does.
Reproducibility: given the same inputs, a third party can recompute the same result — including, honestly, the cases where the system declined to decide.
That is the distinction between a system that records and a system whose records prove. Article 12's text requires the first; anyone relying on those logs in front of a regulator will want the second.
Seven properties, each one checkable by someone who doesn't trust you.
Work backwards from the reader: an auditor who trusts neither the vendor nor the operator. A record that satisfies them is automatic (written by the system, not reconstructed later), lifetime (from first deployment to decommissioning), tamper-evident (sealed so edits show), independently time-anchored, attributable (which engine, which version, which evidence, which humans), reproducible, and honest about refusals — the moments the system abstained are part of the operating record, not an embarrassment to be dropped.
This is the shape of record Corobate produces: each decision becomes a sealed receipt — evidence graded by provenance, a confidence number capped by the weakest required input, a verdict that can honestly be withheld, the whole thing hash-chained and anchored to an RFC 3161 public timestamp authority that has nothing to do with us. Anyone can verify one in a browser, offline, without asking Corobate or the operator for permission — which is precisely the property an Article 12 reader needs.
Six questions that surface most of the work.
Inventory the decisions, not the log lines: approvals, denials, escalations, abstentions, human overrides. If a decision matters enough to defend, it matters enough to record.
A logging path that engineers can disable, or that fails silently, fails the "technically allow automatic recording" test at exactly the wrong moment.
If yes, the record is testimony, not evidence. Seal it — hash chains are cheap; rebuilding credibility isn't.
If the answer is "we do," anchor to an independent authority. RFC 3161 exists for this; public TSAs cost nothing.
Six months is the statutory floor. Limitation periods, sector rules, and product-passport regimes usually mean product-lifetime-plus. Our technicians' guide covers retention sizing.
The final exam. If verification requires your servers, your goodwill, or your continued existence, it will be discounted precisely when it matters most.
We use your address to follow up once about the checklist — no list, no drip. Prefer not to share it? Download directly.
Every term explained simply — provenance classes, gated confidence, honest abstention, the seal, the anchor — with a live demo you can break.
Every input, every actor, every number in a receipt, worked end to end.
Verify a sample receipt in your browser right now — offline, nothing uploaded, RFC 3161 checked against a public authority.
Attestation receipt, verifiable audit trail, trusted timestamp and five more — defined in a paragraph each.
Putting a defensible number on what verifiable records are worth.