The EU AI Act asks what was in your training data. Make your answer tamper-evident.

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 (file bytes stay local; paths, digests, sizes and the --name are sent)
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.

FAQ