RunVouch and the EU AI Act
Article 12 wants automatic records of what an AI system did. Article 26 makes the organisation using it keep those records for at least six months. This page says exactly which part of that a RunVouch run record covers, and which part it does not.
The obligations for the systems in Annex III apply since 2 August 2026. The technical standards that will say how to satisfy Article 12 are still drafts (prEN 18229-1, ISO/IEC DIS 24970), so what exists in the meantime is the text of the regulation and whatever your records can actually show.
What a run record contains
| The regulation asks for | What RunVouch records, automatically |
|---|---|
| Automatic logging over the lifetime of the system, not documentation written by hand (Art. 12(1)) | Every run reports itself: the client wraps the command, or the job calls a ping URL. Nothing is typed by a person. |
| The period of each use: start and end date and time (Art. 12(2), for the systems where that list applies) | started and ended per run, to the second, plus the exit status and the duration. |
| Data for operational monitoring by the deployer (Art. 12(2)(c)) | Cost, token count, tool calls, output size, and the evidence verdict: whether the file, URL or assertion the run promised was actually there. |
| Records a deployer keeps under its own control (Art. 26(6)) | Export of every run as CSV or JSON on the Team plan, so the record lives in your systems and not only in ours. |
| Records that can be relied on afterwards | The part no log file has: each finished run is hashed into a daily Merkle root, chained to the day before and anchored in Bitcoin. A record cannot be edited after the fact, by you or by us, and anyone can recompute it. Try it on a real run. |
What it does not cover
Being straight about this is the whole point of a page like this.
- Not the content of the work. RunVouch never stores prompts, model outputs, or the contents of the files a run reads or writes. It stores that they happened, their sizes and their hashes. Where Article 12 asks for input data or a reference database for a specific class of system, a run record does not give you that.
- Not a conformity assessment. No tool makes a system compliant. This is a record of execution, one input to whatever your assessment needs.
- Not six months by default. Full run records are kept 7 days on Free and 90 days on Solo and Team. If you need to hold six months or more, export them: Team gives CSV and JSON of every run, and the per-run hash stays in the public proof chain permanently, so an exported record can still be proved unaltered years later, after we no longer hold the detail ourselves.
- Not legal advice. Whether your system falls under Annex III, and what your records must contain, is a question for your own counsel.
Why the hash matters here
A log file proves what a system wrote down. It does not prove that nobody changed it afterwards, and a record that can be edited is worth what the auditor thinks of the person holding it. RunVouch seals each day of runs into a Merkle root, chains that root to the previous day, and stamps it with OpenTimestamps into the Bitcoin blockchain. To alter one run after the fact you would have to alter every day since, and the anchor makes even that visible.
Nothing in that chain requires trusting us: the day files are public, the rules are 90 lines of standard-library Python, and the verification runs in your browser with no account.
Where to start
Take a free key, wrap one scheduled job, and look at what the record contains before you decide it is useful: get a free key. The mechanism is on docs/proof, a live fleet is on a real fleet, and our own 30-day numbers are on in numbers.
Sources: Article 12, record-keeping and Article 26, obligations of deployers. Read them yourself; this page is a description of a product, not of the law.