Representative, Error-Free and Complete: Applying EU AI Act Data Quality Criteria to Purchased Datasets

This page covers the legal threshold and how to evidence it for acquired data, as part of the compliance guides for AI data buyers. For the wider governance duties, see EU AI Act Article 10 data governance for licensed data; for how the evidence lands in your technical file, see Annex IV technical documentation for licensed data sets.

What Article 10(3) and 10(4) actually say

The two paragraphs set four qualities plus a setting test, and every one is measured against the intended purpose, not against an abstract ideal. Article 10(3) says data sets "shall be relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose," and that they shall have "the appropriate statistical properties, including, where applicable, as regards the persons or groups of persons in relation to whom the high-risk AI system is intended to be used" [1]. It adds that these characteristics may be met at the level of individual data sets or a combination of them [1].

Article 10(4) requires data sets to take into account, to the extent required by the intended purpose, "the characteristics or elements that are particular to the specific geographical, contextual, behavioural or functional setting" in which the system will be used [1]. Article 10(2) supplies the working steps: document collection processes and data origin (and, for personal data, the original purpose of collection), assess availability, quantity and suitability, examine for biases, and identify "relevant data gaps or shortcomings" and how they can be addressed [1].

Three reading points matter for buyers:

• The combination clause is your friend. A US-sourced dataset need not be representative on its own if, combined with EU records, synthetic augmentation or a targeted top-up, the training mix is. Document the combination, not just each part.
• "To the best extent possible" is a documentation duty. Read it as requiring you to find, quantify and record errors and missing data, and to justify residual levels, not as a claim of perfection.
• Article 10(6) narrows scope for non-trained systems. Where a high-risk system does not train models, paragraphs 2 to 5 apply only to testing data sets [1].

Timing: as of October 2026, the AI Act has been amended by Regulation (EU) 2026/1744, and commentary reports that Annex III high-risk obligations now start on 2 December 2027 and Annex I obligations on 2 August 2028, with Article 10 itself also amended [2]. Check the dates in the Official Journal text; the deadline planning guide covers acquisition timing.

Turning each criterion into a measurable test

Each criterion becomes defensible once you attach a metric, a threshold you set in advance and an owner. The Act does not prescribe metrics, so the burden is on the provider to choose ones that fit the intended purpose and to explain the choice.

Representativeness has two defensible meanings, and you should say which one you rely on. One treats the dataset as a miniature of the target population; the other treats it as good coverage of the input space, including rare cases [3]. Scoring models with population base rates usually need the first for calibration and the second for robustness, so a common approach is a proportionally weighted validation set plus a stratified evaluation set for rare and high-risk cases.

Error rates deserve a number, not an adjective. An audit of 10 widely used machine learning test sets estimated an average label error rate of at least 3.3%, using confident learning to flag candidates and human reviewers to confirm them [4]. If curated public benchmarks carry that much noise, operational records labeled as a by-product of business workflows should be audited before you rely on them for validation or testing.

US-sourced records for an EU deployment: the 10(4) gap analysis

US operational data can support an EU high-risk system, but only with a written gap analysis showing which setting differences matter and what you did about each one. Article 10(4) names four dimensions (geographical, contextual, behavioural, functional), and the analysis should walk through each [1].

Distribution shift across locations and settings is a measured, not hypothetical, effect: benchmark work on in-the-wild shifts shows models trained in one domain losing accuracy when deployed in another [5]. For US-to-EU transfers, the recurring gaps are:

• Geographical: different demographic mix, address and postal formats, currencies, VAT versus sales tax fields, and date and decimal conventions.
• Contextual: different regulatory regimes producing different record fields (for example, consumer-credit disclosures, employment law events, or product standards in manufacturing records), and different product catalogs.
• Behavioural: customer channel preferences, complaint and escalation patterns, payment behavior and seasonality.
• Functional: language of free text (English-only US records feeding a multilingual EU service), workflow steps that exist in one market only, and the human role the system supports.

De-identification can widen the gap. HIPAA Safe Harbor, for example, removes geographic subdivisions smaller than a state and most date elements other than year [9], which can strip exactly the location and timing signals you need to test regional representativeness. Ask the supplier which fields were generalized or removed, and treat that list as a known completeness limit in your Article 10(2) gap log.

Evidence to request from a data supplier

Most of the Article 10(3) record for purchased data depends on facts only the supplier holds, so ask for them before signing, not after delivery. Put the request in writing and keep the responses with your technical documentation, which providers of high-risk systems must retain for 10 years after placing the system on the market or putting it into service [7].

Illustrative example: invented to show structure; it does not describe an available dataset.

request: "Supplier evidence for Article 10(3)-(4) quality criteria"
dataset_ref: "support-tickets-2022-2025-us"
intended_purpose: "triage-priority classifier for EU consumer support (high-risk use case under assessment)"
population_and_coverage:
  source_entity_type: "US consumer electronics retailer, 3 support channels"
  time_window: "2022-01-01 to 2025-12-31"
  geography: "US, state-level only after de-identification"
  languages: ["en-US"]
  strata_counts: "per channel, product line, customer tenure band, outcome label"
collection_process:
  origin_systems: ["ticketing system export", "CRM case records"]
  original_purpose: "customer service operations"
  inclusion_exclusion_rules: "spam, test and internal tickets removed; rule documented"
labels:
  definition: "priority set by agent at close, not at open"
  label_error_estimate: "audited sample size, method, estimated error rate with interval"
completeness:
  missing_rate_per_field: "table, overall and per stratum"
  records_removed_in_deidentification: "count and reasons"
  fields_generalized: ["zip -> state", "dates -> month"]
known_issues:
  - "channel taxonomy changed mid-2023; mapping table supplied"
refresh:
  cadence_available: "to be agreed in license"
  change_log: "schema and policy changes per delivery"

Pair this request with a data dictionary so field semantics are fixed; a data dictionary template for dataset deliveries covers the field-level detail. The SourceX guide to evaluating data supplier quality covers supplier-side checks that sit alongside these legal criteria.

Writing the representativeness and completeness record

The record should let an assessor follow your reasoning from intended purpose to residual risk without rerunning your analysis. Notified bodies assessing technical documentation can be given access to training, validation and testing data sets [6], so the record must also match the data you actually used.

A workable structure, in order:

1. Intended purpose and target population. Who the system affects, where, and in which workflow; the attributes that define relevant groups.
2. Reference distribution. The source you compare against (deployment logs, a pilot sample, official statistics) and its own limits.
3. Source description. Supplier, collection process, time window, original purpose and de-identification steps, per Article 10(2)(b) [1].
4. Comparison results. Stratum-by-stratum counts and proportions, divergence measures, and coverage of rare strata.
5. Error and completeness results. Label-error estimate with method and interval, per-field and per-stratum missingness, and records removed.
6. 10(4) setting gap analysis. The four dimensions, each with finding, impact and mitigation.
7. Mitigations and residuals. Reweighting, targeted acquisition, augmentation, exclusion of out-of-scope use, and the residual gap you accept with justification.
8. Version binding. Dataset version identifiers and hashes, linked to model versions.

Keep the measurement method separate from the legal argument. The quality cluster covers techniques such as using a licensed real-data holdout to validate synthetic data; this page's job is to show the threshold was considered and met for the intended purpose.

Keeping the criteria true across the lifecycle

Article 10 quality is not a one-time acceptance test; market-practice commentary treats the requirements as applying throughout the system lifecycle [8], and in practice the deployment population drifts away from any fixed training snapshot. Plan for that in the commercial terms, not just in monitoring code.

Practical controls:

• Drift triggers tied to strata. Monitor the same attributes you used in the representativeness comparison, and set thresholds that trigger a data review.
• Refresh deliveries in the license. If the supplier's data will be needed for retraining, the license term and delivery schedule should allow later cuts with consistent schemas.
• Change logs per delivery. Schema changes, policy changes and label-definition changes upstream are the most common silent cause of new errors.
• Re-run the record. Each retraining should produce an updated comparison and gap log bound to the new dataset version, feeding your Article 17 data management procedure.

How SourceX fits a representativeness-driven request

SourceX sources operational datasets from US companies on request, so a buyer can describe the records, coverage and time window that a representativeness analysis calls for, without naming businesses. Nothing is held in stock, and a request does not guarantee a match; every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery, and diligence materials covering source, rights, preparation and allowed use are prepared per dataset, which feeds the Article 10(2) provenance record. Personal details are removed or replaced before delivery and the method is recorded, which helps you list the fields de-identification changed. More on the regulation itself is on the EU AI Act and AI data licensing page, and buyers can start at the SourceX buyer page.

Sourcing data for a representativeness gap

If your 10(4) gap analysis shows missing coverage in US operational records such as support histories, sales histories, engineering records or finance and legal workflows, SourceX can look for US businesses that hold data matching your description and manage the licensing. Nothing is contracted until a supplier agrees. Describe the records your high-risk system needs.