What a file format can and cannot do for EU AI Act Article 10
By Dylan Wolpe
The short version
- Article 10's obligations split cleanly into two kinds: claims about bytes (which dataset, unaltered, what it is composed of) and judgements about the world (relevance, representativeness, bias).
- A file format can make the first kind provable — a sealed dataset with a stable content hash turns 'we think it was this data' into documentary evidence.
- It can do nothing at all about the second kind. Whether a dataset represents its target population is a judgement no hashing scheme can produce.
- Any vendor whose product claims to deliver Article 10 compliance is selling the half they cannot do alongside the half they can.
Every few weeks something arrives promising EU AI Act compliance as a product. It is worth being precise about which parts of the regulation are technical problems and which are not, because the boundary runs straight through the middle of Article 10 and most of the marketing pretends it isn’t there.
The two kinds of obligation
Article 10 governs the data used to train, validate and test high-risk AI systems. Read it as an engineer and the requirements fall into two piles that behave completely differently.
| Claims about bytes | Judgements about the world |
|---|---|
| Which exact dataset trained this model | Is the data relevant to the purpose |
| That it has not been altered since | Is it sufficiently representative |
| Where each part came from | Has bias been properly examined |
| How much of it is synthetic | Are the gaps material for this use |
The left column is a solved problem that most organisations have not applied. The right column is genuinely hard, irreducibly human, and no format will ever touch it.
What sealing the bytes actually buys you
The gap it closes is narrower than “compliance” and more useful than it sounds. Ask a team which data trained a model in production and the honest answer is often a Slack thread, a path on a decommissioned bucket, and a strong feeling. That is not a documentation failure so much as an absence of any mechanism that would have made a precise answer possible.
Seal the dataset — bind its contents to a hash, record that hash with the model version — and four things become checkable rather than asserted:
- Identity.Not “roughly this corpus” but these exact bytes.
- Integrity. An auditor three years from now can confirm the dataset is the one documented, or see precisely that it is not.
- Lineage. Which source each portion came from, recorded alongside the data rather than in a spreadsheet that has since diverged.
- Composition. The real-versus-synthetic split, sealed with the data so the proportion is provable rather than remembered.
This converts a class of statement from “trust our process” to “here is the hash, check it”. That is the entire contribution, and it is worth having.
What it cannot do, stated plainly
A sealed dataset with impeccable provenance can still be the wrong dataset. It can under-represent the population the system will be used on. It can encode historical discrimination faithfully and verifiably. It can be complete, unaltered, fully documented, and entirely unfit for purpose — and every cryptographic check will pass.
Representativeness is a claim about the relationship between your data and the world. Bias examination requires deciding which disparities matter and why. Relevance depends on the intended purpose. These are judgements requiring domain expertise and a defensible rationale, and the regulation is asking for the judgement, not for a certificate that a judgement occurred.
Sealing helps indirectly here, in one respect worth noting: when the dataset is pinned, a bias assessment can be tied to the specific data it assessed. An assessment that floats free of a precise dataset is difficult to rely on later, because nobody can establish what was actually examined. Fixing the referent makes the human work durable. It does not do the human work.
How to read a vendor pitch in this space
Three questions sort most of them quickly.
Does it claim to make you compliant? Compliance for a high-risk system spans risk management, technical documentation, human oversight, accuracy and robustness, post-market monitoring. A tool is a component. One claiming to deliver the whole thing is telling you something about its vendor rather than about the regulation.
Can the evidence be checked without the vendor?Provenance you can only confirm by logging into the supplier’s console is provenance that expires when the contract does. Records covering high-risk systems outlive procurement cycles; the verification has to work in a world where the vendor is gone.
Is it honest about the judgement half? A vendor who volunteers that they cannot assess representativeness has understood the regulation. One who implies a dashboard settles it has not, or is counting on you not to notice.
Our position
We do the byte half. Sealed datasets with stable content hashes, recorded lineage and provable real-versus-synthetic composition, verifiable by anyone with the open decoder and no dependency on us. That is a real contribution to an Article 10 programme and it is one component of one.
The other half needs people who understand your domain and your deployment. If someone offers to sell you that in a subscription, the useful information is that they offered.
- The product page, in buyer’s terms: EU AI Act data governance
- Proving facts about data without exposing it: verifiable data