The EU AI Act wants your training data documented. Documentation isn't evidence.

You got the email from legal. The EU AI Act applies to your product, and someone needs to "document the training data." So you open a Google Doc, or you point them at the dataset's README, or you promise to export something from your warehouse.

Here's the problem with all of that: it's documentation, and documentation isn't evidence. A README can be edited after the fact. A warehouse export is only as trustworthy as the warehouse — and the one thing an independent auditor cannot do is trust your infrastructure. The difference between documentation and evidence is simple and unforgiving:

This post is the engineer's version of the AI Act data requirements. Not legal advice — the engineering reading. It answers one question: what concrete technical artifact satisfies the data obligations, in a way an auditor can check for themselves?

First, the timeline — because it changed

If you were told "everything is due 2 August 2026," that's now out of date. The AI Act entered into force on 1 August 2024 and became fully applicable on 2 August 2026 — but the Digital Omnibus on AI, adopted in mid-2026, deferred the high-risk obligations. The dates that matter now:

The takeaway isn't "relax." One of those clocks has already run out — if you provide a GPAI model, the training-content summary is live and enforceable now. For everyone else it's the opposite of relaxing: you have runway to build the data pipeline properly instead of assembling a compliance binder in a panic the week before a deadline. Non-compliance with high-risk obligations can draw fines up to €15M or 3% of global turnover (the €35M / 7% tier is reserved for prohibited practices under Art. 5).

What the regulation actually asks (engineer's translation)

Three articles do the work for training data:

• Article 10 — Data and data governance. Document the origin of your data, the collection and processing operations, and examine it for bias. Notably, Art. 10(5) explicitly permits processing special-category data (race, sex, health…) when necessary to detect and correct bias — so you can't dodge it by deleting the sensitive columns.
• Article 11 + Annex IV(2)(d) — Technical documentation. Your technical file must describe the datasets: provenance, scope, characteristics.
• Article 12 — Record-keeping. High-risk systems keep automatic, traceable logs across the lifecycle. Transformations must be reconstructable, not asserted.

Read together, these ask for something specific: provenance you can prove, a transformation history you can't quietly rewrite, and a description bound to the actual bytes.

Why the obvious tools fall short — as evidence

None of these are bad tools. They just don't produce evidence in the sense above.

• READMEs / data cards. Documentation with zero integrity guarantee. Fully editable after the fact; nothing ties the words to the bytes.
• Warehouse metadata. Mutable, and verifying it means trusting the producer's own infrastructure — exactly what an independent audit is not allowed to assume.
• Git LFS / DVC. Real versioning, but the auditor needs your repo and your tooling, and the transformation chain isn't sealed against rewriting.
• MLOps platforms (MLflow, W&B). Excellent internal lineage — but the record lives in a vendor database. Not portable, not offline-verifiable, gone if you switch vendors or they do.

The gap in every case is the same: the proof depends on trusting the producer or their stack.

The properties the artifact needs

Independent of any product, the artifact you hand an auditor should have:

• Cryptographic integrity — a signature over the exact bytes, not a checksum sitting next to them.
• An audit chain anchored under a signature — every transformation hash-linked, and the chain head covered by the signature. The hash-chain alone is not enough: it carries no key, so anyone with write access can recompute the whole thing and it will still look internally consistent. The signature over the head is what turns it from a log into evidence.
• Embedded provenance — inside the artifact, not in a separate system you have to trust.
• Offline, third-party verification — open source, one command, exit codes. No account, no server, no vendor.
• A portable format — it survives you switching platforms, or going out of business.

SURFRAME is one open-source implementation of that standard. Here's the whole loop on a real, public dataset.

Hands-on: from a public dataset to a verifiable evidence pack

We'll use the Adult Census Income dataset (scikit-learn/adult-census-income, CC0) — the canonical fairness/bias dataset, with race and sex columns. That makes it a realistic stand-in for an Annex III system (income/credit-style prediction) with exactly the special-category data Art. 10(5) is about.

# install
pip install surframe

# 1. get the data as CSV
python -c "from datasets import load_dataset; \
load_dataset('scikit-learn/adult-census-income', split='train').to_pandas().to_csv('adult.csv', index=False)"

# 2. pack it into a signed, queryable container
surx write adult.csv trainset.surx

# 3. encrypt the special-category columns — they stay usable for bias
#    work, but travel sealed (you'll be prompted for a passphrase)
surx encrypt trainset.surx race,sex

# 4. generate a signing key and sign the exact bytes
surx keygen
surx sign trainset.surx --key surx_signing.key --signer data-gov

# 5. export the AI Act evidence pack
surx export trainset.surx --format ai-act \
  -d "purpose=Income classification, Annex III credit-style system" \
  -d "license=CC0-1.0"

The pack contains EVIDENCE.json, a human-readable REPORT.md, VERIFY.md (instructions), ai_act_mapping.md (an explicit map onto Art. 10 / 11 / 12), an audit_chain/ directory copied verbatim, and checksums.txt. Encrypting race and sex is the point, not a side-quest: recipients query everything else without the passphrase, the sensitive columns stay available for the bias examination the regulation requires, and the side-cars are cryptographically bound so they can't be spliced between containers.

The part that makes it evidence

Flip a single byte in the container and try again:

surx verify trainset.surx     # → names the exact chunk that changed, exit 1
surx export trainset.surx --format ai-act
  ✗ Container verification FAILED — no evidence pack will be generated.

That's the whole thesis in one command. export runs verify first and refuses to produce an evidence pack for a tampered or corrupt container. It is a tool that cannot generate false evidence. A PDF generator will happily render whatever you feed it; that's why a PDF is a promise, not evidence.

Handing it to an auditor (or your own legal team)

The reassuring part: the auditor doesn't need to install anything to read the evidence. REPORT.md and ai_act_mapping.md open in any text editor. To actually check the integrity, they have two levels:

• No install: sha256sum -c checksums.txt — standard on macOS/Linux, available on Windows — confirms nothing was altered.
• Full check: pip install surframe && surx verify validates the Ed25519 signature and the complete audit chain. One open-source, Apache-2.0 command.

The "install a tool" step is the feature. It's what lets a third party confirm the result mathematically, without trusting you or a vendor's database. And you can push it left: the surx-verify-action GitHub Action gates your CI so an unsigned or tampered dataset never reaches training in the first place.

The point

The AI Act's data-governance clock for high-risk systems now runs to December 2027. Use the runway. "Documenting your data" without integrity guarantees is a promise; evidence is a promise anyone can check without trusting you. The right artifact — signed bytes, a sealed audit chain, portable and offline-verifiable — already exists, and it's open source.

If you work in compliance and think this maps the articles wrong — tell me. That feedback is worth more than another star.