Building a data governance file for EU AI Act Article 10

Article 10 of the EU AI Act asks providers of high-risk systems to govern the data their models learn from: training, validation and testing datasets have to be relevant, sufficiently representative, and examined for possible bias. The article does not prescribe a document. What it creates is a duty to be able to explain, on request, how a dataset was assembled and why it looks the way it does.

The practical way to be able to explain that is a governance file — one folder per dataset, opened when collection starts and maintained until the dataset is retired. Assembled retroactively from memory, it is fiction. Maintained as the work happens, it is evidence.

One folder per dataset, and a dataset is not the same as a corpus

Define the unit first. A dataset, for governance purposes, is a corpus plus an annotation version plus a processing pipeline. Re-annotate the same audio under a new guideline, and you have a new dataset version that needs its own record — not an update to the old one. Teams that skip this definition end up with one folder covering three different things, and no way to say which version trained which model.

The core sections of each folder, and what belongs in them:

• Identity: dataset name and version, owner, the system it feeds, and whether that system is classified as high-risk.
• Sources: where the raw material came from, whether each source was commissioned, licensed or public, and the rights basis for each one.
• Design choices: why this speaker count, these recording conditions, this size — including the options that were considered and rejected.
• Annotation and quality: guideline versions with dates, which version applied to which batch, and the quality reports that came out of it.
• Representation and bias: the analysis that was done, what it found, and what was decided about the findings.

Who fills what

A file assembled by one person reads like one person's memory, and reviewers can tell. Assign sections: the data lead owns identity and design choices, the annotation manager owns guideline versions and quality reports, legal or privacy owns the rights basis for each source, and someone who did not build the dataset signs the representation section.

The test of a working file: a second person can trace any claim in it back to its source — a signed form, a guideline document, a quality report — without asking the original author. If a claim has no underlying artifact, the claim does not belong in the file.

The design-choice log is the section people wish they had

When a reviewer asks why a dataset underrepresents a region, or why two planned languages were dropped, the answer lives in decisions made months earlier by people who may have left. Reconstructing those decisions later is guesswork.

Keep each entry short and factual: the decision, the date, the alternatives considered, and who made the call. One page maximum per decision. The entries that matter most record a limitation knowingly accepted — a smaller speaker pool because recruitment stalled, a dialect left out because no qualified annotators were available. A file that records only successes reads as marketing.

When to update

The update triggers, roughly in order of how often they get missed:

• Any data added to the dataset, including small top-up batches collected to fix a coverage gap.
• Any change to the annotation guideline, including clarifications that do not change labels.
• A new source, supplier or collection campaign.
• A change to the processing pipeline — a new denoiser, a re-run of diarization, a change in how files are segmented.
• Each retraining of the consuming model with a materially different data mix.

What the file does not need to be

It does not need a prescribed template, a certification or a tool. A versioned folder with a consistent structure, access-controlled and stored where the team actually works, covers the requirement. The update should happen in the same week as the change; a file updated quarterly is always slightly wrong, and slightly wrong documentation is worse than obviously stale documentation, because it gets trusted.

It also does not need to describe a perfect dataset. Article 10 does not demand perfection, it demands governance, which includes awareness of limitations. What it cannot do is describe a process the team did not follow. Start with the dataset that feeds the most consequential system, and open the second folder when the first one has survived a review.