EU AI Act · Regulation (EU) 2024/1689

Your auditor asks where the data came from. Answer with math.

Two obligations ask you to account for training data: Art. 53(1)(d) for GPAI model providers, enforceable from 2 August 2026, and Art. 10–12 for high-risk Annex III systems, from 2 December 2027. Both come down to the same question — which exact bytes, from where. SURFRAME turns your training sets into signed, tamper-evident containers, and exports the evidence pack in one command.

surx export data.surx --format ai-act · copy

Apache-2.0 · verification is free, forever · read the threat model

Enforcement begins

2 Aug 2026

If you provide a GPAI model, your clock already started. Those obligations have applied since 2 August 2025 and the Digital Omnibus did not touch them. From this date the AI Office can verify compliance and issue corrective measures — including Art. 53(1)(d), the public summary of training content on a mandatory template, required even of open-weight models. Fines reach €15M or 3% of global turnover.

SURFRAME does not write that summary for you, and no tool honestly can. What it does is make the claim behind it checkable: when you state what went into a model, you can hand over evidence instead of an assertion.

High-risk data obligations

2 Dec 2027

If you build a high-risk Annex III system — recruitment, credit scoring, education, biometrics, border control — Art. 10–12 apply from this date, deferred from 2026 by the Omnibus. The Act becomes fully applicable on 2 August 2026.

That is runway, not relief. Art. 10 asks where your data came from, and that answer has to be built into the pipeline while it runs — it cannot be reconstructed in the week before an audit. Documentation without integrity guarantees is a promise, not evidence.

Three articles. One artifact.

An evidence pack maps directly onto the data requirements a notified body or internal auditor will check. It states what the evidence proves — never more.

AI Act requirement	What the evidence pack contains
Art. 10(2) — data governance: origin, collection and processing operations	Producer declarations (purpose, sources, licensing) plus every transformation event in the container's audit_chain/, hash-linked and signature-anchored
Art. 12 — automatic, traceable record-keeping across the lifecycle	A verbatim copy of the append-only audit log. Events present when the container was signed are covered by the Ed25519 signature, so rewriting that history is caught. Events appended after signing are chain-consistent but not authenticated — verify counts them separately and fails closed by default
Art. 11 / Annex IV(2)(d) — technical documentation of the datasets	EVIDENCE.json: schema, row counts, partitions, SHA-256 of the exact bytes, signer identity and signing time
Art. 53(1)(d) — public summary of training content, GPAI providers	Not the summary itself — that is a public document you write, on the Commission's template. What you get is the per-dataset record you draw it from: declared sources and licensing, and a signed hash of the exact bytes, so a disclosure can be tied to a specific artifact instead of a folder name
Third-party verifiability	VERIFY.md — auditor instructions. Offline, open source, exit-code based. No access to your infrastructure required.

From dataset to evidence in three commands.

The pack refuses to generate if verification fails. This tool cannot produce evidence for tampered data — that's the point.

# 1 · sign the container you already ship
surx sign trainset.surx --key team.key --signer data-gov

# 2 · export the evidence pack
surx export trainset.surx --format ai-act \
  -d "purpose=Training data, credit scoring model v3" \
  -d "license=CC-BY-4.0" -d "contact=data-gov@company.com"

# 3 · what the auditor runs — no account, no server, no trust
surx verify trainset.surx --pubkey team.pub   # exit 0 = intact
sha256sum -c evidence_pack/checksums.txt      # every file OK

Why documentation alone fails the audit.

Data cards & READMEs

Editable after the fact, by anyone, without trace. They describe the dataset — they cannot prove the description matches the bytes that trained the model.

Warehouse metadata & MLOps lineage

Lives inside your infrastructure. Verifying it means trusting your database — which is exactly what an independent audit cannot do.

A signed .surx container

The evidence is the artifact itself. Ed25519 signature over every entry, append-only audit chain, offline verification that names the exact file that changed.

What we will not tell you: that this makes you "AI Act compliant". Conformity is a property of your whole system and process. SURFRAME produces the verifiable technical evidence for the data requirements — every generated document says exactly that, and nothing more.