If you are building a high-risk AI system, Annex IV of the EU AI Act asks for a clear description of the data you trained on: where it came from, how it was labelled, and how you checked its quality. Most teams can describe their model in detail but struggle to evidence the data behind it. This checklist turns the requirement into concrete steps.
What Annex IV actually asks for
In practice, you need to show the provenance of your datasets, the labelling and review methodology, the measures used to detect bias and errors, and the human oversight applied. The goal is not a marketing summary. It is documentation an auditor can follow from a single output back to the person and process that produced it.
Article 10 sits alongside Annex IV: it expects data governance practices for training, validation and testing sets. Treat the two together and you avoid documenting the same pipeline twice.
A checklist you can act on
For every dataset, record: the source and licensing basis, the collection date range, the labelling instructions and who followed them, the review and quality-control steps, the inter-rater agreement or acceptance criteria, and the retention and residency of the data. For every batch, keep a lineage record that links outputs to contributors and to the review step.
The trick is to capture this as work happens, not to reconstruct it before an audit. Provenance recorded after the fact is the part regulators trust least.
Who this applies to
Annex IV documentation obligations attach to high-risk AI systems under the EU AI Act. If your system falls into a high-risk category (for example many uses in healthcare, employment, credit, education, critical infrastructure or biometric contexts) or you supply components to someone whose system does, this checklist is for you. Even outside high-risk, buyers increasingly ask for the same evidence in due diligence, so treating it as a baseline pays off.
The practical takeaway: you do not need to be certain of your risk classification to start. The documentation below is good data hygiene regardless, and it is far cheaper to capture as you go than to reconstruct under deadline.
What Annex IV actually asks for
In practice, you need to show the provenance of your datasets, the labelling and review methodology, the measures used to detect bias and errors, and the human oversight applied. The goal is not a marketing summary. It is documentation an auditor can follow from a single output back to the person and process that produced it.
Article 10 sits alongside Annex IV: it expects data governance practices for training, validation and testing sets, including relevance, representativeness, and examination for bias and gaps. Treat the two together and you avoid documenting the same pipeline twice.
The traceability gap most teams have
Most teams can describe their model architecture in detail but cannot answer a simple auditor question: for this specific labelled example, who produced it, under what instructions, and who reviewed it? That gap is where reviews stall.
The root cause is that data work is often outsourced through layers, and the record of who did what is thin or reconstructed. Reconstructed provenance is the part regulators trust least, because it can be curated after the fact.
A dataset-level checklist you can act on
For every dataset, record: the source and licensing basis; the collection date range; the labelling instructions and the version used; who followed them and their verification status; the review and quality-control steps; the inter-rater agreement or acceptance criteria; and the retention and residency of the data.
Also record what you excluded and why. Documented exclusions and known limitations are exactly the kind of honest, first-hand governance signal that Article 10 expects and that auditors reward.
A batch-level checklist for traceability
For every batch, keep a lineage record that links each output to its contributor and to the review step, with timestamps. Capture the human oversight applied, any overrides, and a quality signal such as agreement or acceptance rate.
The trick is to capture this as work happens, not to reconstruct it before an audit. When lineage is captured live, you can also quarantine a single suspect batch instead of casting doubt on a whole dataset.
How to stay audit-ready without slowing down
The mistake is to treat documentation as a separate pre-audit project. The efficient pattern is to make provenance a by-product of the workflow: every task records who did it and who reviewed it automatically, and the Annex IV bundle is generated from that record.
Done this way, staying audit-ready costs almost nothing at the margin, and your ML team never stops to assemble evidence by hand.
Make it evidence, not paperwork
Pathwize records provenance at every step, so your Annex IV documentation is a by-product of how the work is done rather than a separate project. If you want to see how the lineage bundles map to Annex IV fields, book a demo and we will walk your compliance and ML teams through it.