What the Act actually requires of training data
Regulation (EU) 2024/1689 — the AI Act — turns training-data documentation from good practice into a legal duty, on a phased timeline:
- Already in force. Since 2 August 2025, providers of general-purpose AI models must draw up and publish a sufficiently detailed summary of the content used for training, using the European Commission's AI Office template (Article 53(1)(d)). Models placed on the market before that date must comply by 2 August 2027.
- From 2 August 2026. The Commission's enforcement powers over general-purpose AI providers begin: documentation requests, model evaluations, and fines of up to €15 million or 3% of worldwide annual turnover.
- From 2 December 2027 (under the amending regulation the EU institutions adopted in June 2026), providers of high-risk AI systems must meet Article 10: documented data-governance practices covering data collection processes and the origin of data, labelling, cleaning, and bias examination — plus Annex IV technical documentation describing the training data sets, "their provenance, scope and main characteristics; how the data was obtained and selected." AI embedded in regulated products follows by 2 August 2028.
- For a decade. Article 18 requires providers of high-risk systems to keep that technical documentation at the disposal of authorities for 10 years after the system is placed on the market.
The problem with ordinary documentation
A datasheet, an acquisition log, or a license folder that can be edited after the fact is indistinguishable from one written at the time. When the question arrives — from a regulator exercising Article 91 powers, an auditor, an enterprise customer's due-diligence team, or opposing counsel in a copyright dispute — the value of your documentation depends on being able to show this is what the record said then, and it has not changed since. A shared drive cannot show that. A spreadsheet cannot show that.
What anchoring adds
Orphograph binds a dataset bundle — the data, the license and consent documents, and the acquisition log — into a single Merkle tree, hashed entirely on your machine, and anchors the root to the Bitcoin blockchain. You get a dated receipt and a hosted provenance certificate where anyone you authorize can verify, in their own browser, that a specific file belonged to the certified set. Three properties matter for the Act's documentation duties:
- Dated. The bundle provably existed, in exactly this form, by the time of a specific Bitcoin block. A record anchored before a model run cannot have been written after the questions started.
- Tamper-evident. Change any byte of any file — relabel an image, swap a license, edit the log — and the root no longer matches the receipt.
- Durable for the retention window. The proof is an open format that outlives any vendor: the manifest, the OpenTimestamps files, and the public chain are all a verifier needs, ten years from now, whether or not Orphograph is still here. The verifier is open source.
What this is not
Honesty is the product, so the scope is narrow and stated plainly. A dataset receipt is not a conformity assessment, not the AI Office's training-content template, and not proof that data was lawfully sourced, licensed, or owned. It does not make a provider "AI Act compliant." It makes the documentation the Act requires you to create and retain tamper-evident and independently datable — which is what turns documentation into evidence. Whether that evidence suffices in any particular proceeding is a question for that forum and your counsel. Nothing on this page is legal advice; timeline per the amending regulation adopted June 2026.
Run it as a pipeline step
The reference CLI anchors a bundle as a build step — a training run's data manifest becomes a dated, verifiable artifact alongside the model weights.
# Anchor a dataset bundle (only fingerprints leave the machine)
python3 provenance.py anchor --bundle ./my-dataset --name "My Dataset v1"
# Air-gapped: build the receipt + certificate, anchor nothing
python3 provenance.py anchor --bundle ./my-dataset --name "My Dataset v1" --offline
# Re-verify any time — rebuild the root from disk, compare to the certificate
python3 provenance.py verify --cert out/certificate.json --bundle ./my-dataset
The full workflow — bundle layout, certificate anatomy, per-file inclusion proofs — is on the dataset provenance page.
Anchor a training set this week, not next quarter
Assemble the bundle you already have — data, licenses, acquisition log — and anchor it. The receipt is dated from the day you do it; documentation anchored early is worth more than documentation reconstructed later.
FAQ
Does anchoring a dataset make us EU AI Act compliant?
No. Compliance turns on your full quality-management system, conformity assessment, bias analysis, and the rest of the Act's obligations. A dataset receipt is evidence, not a conformity assessment: it proves the documentation you are required to keep existed in an exact form by a date and has not changed since. It supports Article 10, Annex IV, and Article 53 documentation — it does not substitute for any of them.
Does our training data leave our environment?
No. Every file is hashed locally with SHA-256 and combined into a Merkle tree on your machine. Only the manifest — relative paths, digests, and the root — is sent to be anchored. An air-gapped mode builds the receipt and certificate without sending anything at all.
The Act requires keeping documentation for 10 years. What if Orphograph is gone by then?
The receipt is an open format: an RFC 6962-style Merkle manifest plus OpenTimestamps proofs committed to the Bitcoin blockchain. Verification needs only the manifest, the .ots files, and the public chain — none of which depend on Orphograph existing. An MIT-licensed verifier is published for exactly this reason.
Which obligations does a dataset receipt support?
Tamper-evident, independently datable records supporting Article 10 data-governance documentation (data collection processes and the origin of data), Annex IV datasheets (provenance, scope, and main characteristics of the training data sets), the record-keeping behind an Article 53(1)(d) training-content summary, and the 10-year retention duty of Article 18.