Data governance and dataset quality testing
We test the training, validation and testing data sets of a high-risk AI system against the quality criteria in Art. 10(2), 10(3) and 10(4) of Regulation (EU) 2024/1689: representativeness, coverage of the setting of use, error rate, completeness, statistical properties and lineage. The procedure is PR-10-BIAS v1.0. The client receives a dataset profile with one dataset card per set and an assessment memo that reviews the data-management practices against the points of Art. 10(2). The Art. 10 duties apply from the Annex III application date Deferred.
Deliverables
The set is designed to answer what an assessor asks under Art. 10(2)(a) to (e) and (h), Art. 10(3) and Art. 10(4), and what Annex IV section 2(d) requires the technical documentation to describe: where each data set came from, how it was prepared, whom it covers, how many label errors it carries, and which gaps remain. Each item is specified on the deliverables page as a dataset profile with dataset cards or an assessment memo.
| Deliverable | Type | Format | Designed to satisfy |
|---|---|---|---|
| Dataset quality profile: representativeness, coverage, error rates, lineage | Dataset profile and dataset cards | Markdown dataset cards; CSV profile tables; JSON lineage manifest | |
| Dataset cards for training, validation and test sets | Dataset profile and dataset cards | Markdown dataset cards; CSV profile tables; JSON lineage manifest | |
Data-management practice review against Article 10 and prEN 18284 scopeprEN 18284Draft | Assessment memo | PDF with Markdown source |
Who this is for
- Annex III providers
- Annex I manufacturers
- GPAI providers
A provider of an Annex III system such as recruitment screening or credit scoring develops the system on data sets that Art. 10 governs, and the Act gives that provider no representativeness level, no maximum error rate and no completeness level. The provider sets each target and an assessor checks the justification and the counts behind it. A manufacturer that embeds AI as a safety component of an Annex I product carries the same Art. 10 duties inside the sectoral technical file, so the data set evidence is added to that file without duplicating what the sectoral law already covers. The Annex I duties follow their own application date Deferred. A provider of a general-purpose AI model describes the data used for training, testing and validation under Annex XI Section 1 point 2 and publishes the training-content summary under Art. 53(1)(d). The dataset cards and the lineage record give that description a structure, and the Art. 53 duties follow the GPAI application date In force. The Art. 10 duties for Annex III systems follow the entry rendered below.
Scope
The engagement covers the training, validation and testing data sets of one high-risk AI system at a fixed data set version, identified by a file hash per set. Where the system does not train a model, Art. 10(6) applies the criteria to the testing data sets only, and the engagement runs on those sets. Each set is profiled for lineage, subgroup coverage against the persons or groups named in the intended purpose, setting coverage under Art. 10(4), label error rate, completeness, statistical properties against the assumptions statement, and duplicates and overlap between sets. The data-management practices the provider operates are reviewed against the points of Art. 10(2) and against the scope of prEN 18284Draft, a JTC 21 draft with no public text. Where a deployer controls the input data, the live input profile under Art. 26(4) can be added to the scope.
The quality characteristics and the practice checklist come from two documents, listed with their stage on the standards page. prEN 18284Draft supplies the data governance practices and the dataset quality characteristics behind the lineage, coverage and completeness checks. ISO/IEC TR 24027:2021Published supplies the data bias sources behind the label-error sampling. No harmonised standard for Art. 10 is cited in the Official Journal, so a result against either document is evidence for the technical documentation under Art. 11 and Annex IV and carries no presumption of conformity.
The disaggregated bias examination under Art. 10(2)(f), the mitigation re-test under Art. 10(2)(g) and the feedback-loop check are the subject of bias and fairness testing, within the limits stated on what we cannot do. One protocol covers all of Art. 10, so those rows appear in the table below; this engagement produces the data set profile those rows depend on, and runs them only where both services are scoped together.
The engagement is testing and review. It does not decide whether a data set meets Art. 10; it records each measured value against the target the provider justified. It does not select the target population or the protected attributes; it records the provider's statements and the reason for each. It is not a conformity assessment and no step in it replaces the procedure under Art. 43.
Where special categories of personal data are present in a data set or a pipeline stage, the legal basis sits in Art. 4a, the provision Regulation (EU) 2026/1744 moved from the former Art. 10(5), and its necessity threshold is an unsettled point. Step 37 of PR-10-BIAS v1.0 checks the legal-basis record against the working reading below.
What we test
The table lists each testable element of Art. 10, the protocol that tests it and the artifacts it produces for the record.
| Obligation | Testable element | Protocol | Artifacts |
|---|---|---|---|
| Art. 10 | Representativeness of the training, validation and testing data sets against the persons or groups of persons the system is intended to be used for, measured as subgroup coverage against the declared intended purpose (Art. 10(3)) | PR-10-BIAS v1.0 |
|
| Error rate and completeness of the data sets, measured by label-error sampling and missing-value profiling against the targets the provider declares (Art. 10(3)) | PR-10-BIAS v1.0 | ||
| Statistical properties of the data sets, compared with the documented assumptions about what the data measure and represent (Art. 10(2)(d) and 10(3)) | PR-10-BIAS v1.0 | ||
| Coverage of the geographical, contextual, behavioural or functional setting of intended use in the data sets, checked against the setting declared in the intended purpose (Art. 10(4)) | PR-10-BIAS v1.0 | ||
| Bias examination result: system performance and outcomes disaggregated by protected and context-relevant subgroup, with each metric defined (Art. 10(2)(f)) | PR-10-BIAS v1.0 | ||
| Effect of the bias mitigation measures, verified by re-running the disaggregated evaluation after mitigation (Art. 10(2)(g)) | PR-10-BIAS v1.0 | ||
| Feedback-loop check where data outputs influence inputs for future operations, comparing subgroup distributions across operation cycles (Art. 10(2)(f)) | PR-10-BIAS v1.0 | ||
| Special-category data handling check: pseudonymisation and re-use limits present, access restricted to authorised persons, no transfer to other parties, observed in the data pipeline (Art. 4a(1)(b), (c) and (d)) | PR-10-BIAS v1.0 |
Art. 10 names no minimum subgroup count, no maximum label error rate and no completeness level, so each pass criterion in the dataset profile carries the level of the source hierarchy it comes from. Level one is a harmonised standard cited in the Official Journal, and none exists for Art. 10 as of the anchor date. Level two is a JTC 21 draft, stated with its stage. Level three is an ISO/IEC standard or technical report. Level four is a Commission guideline or code of practice, with its publication date. Level five is NIST AI RMF or a sector framework. Level six is the state of the art the provider justifies and documents. No document at any level publishes a coverage, error or completeness threshold for Art. 10(3), so step 10 of the protocol records the provider's target for each characteristic with its justification and its source level, and step 32 compares each measured value with that target.
Protocols used
One protocol covers this service, and its page states the derivation of every step from the documents named above.
- PR-10-BIAS v1.0Bias and subgroup performance protocolv1.0
PR-10-BIAS v1.0 traces each data set to its collection source, collection process and original purpose of collection, lists the preparation operations in the order applied. It counts the records per subgroup and per setting-of-use category, re-labels a random sample with an independent annotator to measure the label error rate, profiles missing values per feature and per subgroup, compares each feature distribution with the assumptions statement, and reports duplicates within and overlap between sets. It produces the dataset quality profile, the data set lineage record and the dataset cards, each with a provenance block that carries the protocol version and the file hashes. It measures coverage only on the attributes the data sets identify; where the provider holds no protected attribute data, the protocol records the gap for the Art. 10(2)(h) register and does not infer the attribute. The clause references to prEN 18284Draft name the subject of each clause, since the draft has no public text, and the protocol is revised when the text is published.
Engagement shape
Fixed-scope, scoped per request. The classification and readiness assessment is the entry service and precedes this one where the obligation set of the system has not been mapped. The client provides the data sets in scope with a schema, labels and a record identifier, the intended purpose and instructions for use with the persons or groups the system is intended to be used for, the dataset documentation under Art. 10(2)(a) to (e), the coverage, error and completeness targets with a justification for each, and a description of the data governance and management practices in operation.
The work follows the order of the protocol. Preparation records the scope, the training-technique statement under Art. 10(1) and 10(6), the target population and setting-of-use statements, the assumptions statement and the threshold justification. Execution traces lineage, logs the preparation operations, counts coverage, samples label errors, profiles completeness and statistical properties, and reports duplicates and overlap. Analysis compares each value with its target and marks each result pass or fail. Reporting assembles the dataset profile, the dataset cards and the practice review, each with a provenance block that carries the protocol version and the file hashes.
What we cannot do
- We do not perform conformity assessments where a notified body is required.
- We do not issue CE marking or the EU Declaration of Conformity.
- We are not a notified body.
- We do not give legal opinions on classification or liability.
- We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.
For this service, the dataset profile records measured values against the targets the provider justified, and the practice review is a reasoned technical assessment for discussion with the provider's notified body where Art. 43 requires one and with counsel. Neither document states that the system meets Art. 10; that decision remains with the provider.
What the client must have ready
The elements below are documentation and process elements of Art. 10 that the protocol records as inputs and does not test.
Art. 10Data and data governance
- Statement of whether the system uses techniques involving the training of AI models, which determines whether the criteria apply to all data sets or to the testing data sets only (Art. 10(1) and 10(6)) documentation
- Design choices record for the data sets (Art. 10(2)(a)) documentation
- Data collection and origin record, including the original purpose of collection for personal data (Art. 10(2)(b)) documentation
- Data-preparation record listing the annotation, labelling, cleaning, updating, enrichment and aggregation operations (Art. 10(2)(c)) documentation
- Statement of assumptions about the information the data are supposed to measure and represent (Art. 10(2)(d)) documentation
- Assessment of the availability, quantity and suitability of the data sets that are needed (Art. 10(2)(e)) documentation
- Record of identified data gaps or shortcomings and how they are addressed (Art. 10(2)(h)) documentation
- Justification of the representativeness, error and completeness targets against the intended purpose, and a statement of whether the characteristics are met per data set or by a combination of data sets (Art. 10(3)) documentation
- Record of the reasons why processing special categories of personal data was strictly necessary and why other data, including synthetic or anonymised data, could not achieve the objective, in the records of processing activities (Art. 4a(1)(a) and (f)) documentation
- Access control documentation for special-category data, listing the authorised persons and their confidentiality obligations (Art. 4a(1)(c)) documentation
- Retention period statement for special-category data processed for bias detection (Art. 4a(1)(e)) documentation
- Data governance and management practices operated across the lifecycle for the training, validation and testing data sets (Art. 10(2)) process
- Bias examination repeated when a data set changes and, where data outputs influence inputs for future operations, at each operation cycle (Art. 10(2)(f)) process
- Bias detection, prevention and mitigation measures applied and maintained as identified biases change (Art. 10(2)(g)) process
- Data gap and shortcoming identification repeated at each data set update (Art. 10(2)(h)) process
- Deletion of special-category data at the earlier of bias correction and the end of the retention period (Art. 4a(1)(e)) process
- Where a deployer or a provider of another AI system processes special-category data under Art. 4a(2), application of all the Art. 4a(1) conditions and safeguards to that processing (Art. 4a(2)) process
A dataset card per data set carries the design choices, the collection and origin record, the preparation record, the assumptions statement and the availability assessment; the Annex IV section 2(d) text serves the same purpose where it exists. The practice description is supplied as the provider's own procedure documents, and an existing quality management system procedure under Art. 17(1)(f) serves where it covers the data sets in scope.
Questions
What does the AI Act require for data governance?
Art. 10(2) requires the training, validation and testing data sets of a high-risk AI system to be subject to data governance and management practices appropriate for the intended purpose, covering the points in Art. 10(2)(a) to (h). Art. 10(3) requires data sets that are relevant, sufficiently representative, and to the best extent possible free of errors and complete. Art. 10(4) requires the data sets to reflect the setting of intended use. Art. 10 sets no numeric threshold; PR-10-BIAS measures each data set against the provider's justified targets.
How does the EU AI Act interact with GDPR?
Art. 2(7) states that Union data protection law applies to personal data processed in connection with the Act, and that the Act does not affect Regulation (EU) 2016/679. Art. 10(2)(b) requires the data governance practices to record the original purpose of collection for personal data. Art. 4a(1) permits the processing of special categories of personal data for bias detection only to the extent strictly necessary, with the safeguards in points (a) to (f). The lawfulness decision remains with the provider and its counsel.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.