EU AI Act Article 10: Data Governance Requirements for Licensed Training, Validation and Test Data

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Who Article 10 binds, and when it applies

Article 10 binds the provider of a high-risk AI system, not the company that supplied the data. It applies to systems that use techniques involving model training with data, and it covers all three splits: training, validation and testing [1]. A lender that fine-tunes a credit scoring model on licensed loan-servicing records is the provider; the servicer that licensed the records is not. If you are unsure whether fine-tuning makes you a provider, read when fine-tuning with acquired data creates provider duties.

The timing changed in 2026, and so did Article 10. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and amends the AI Act [2][3]. Secondary commentary reports two new dates as of October 2026: Annex III high-risk systems (including creditworthiness, employment, life and health insurance pricing, and access to essential services) move to 2 December 2027, and Annex I product-embedded systems move to 2 August 2028 [4]. Regulation (EU) 2026/1744 also amends Article 10 [3], so check the dates against the consolidated text and use the Omnibus deadline planning guide to work back from your conformity assessment date.

Article 10 also differs from the general-purpose AI duties in Article 53, which cover training-content summaries and copyright policies for model providers [6]. A high-risk system built on a GPAI model can trigger both regimes. The Article 53 obligations guide covers the GPAI side.

The eight Article 10(2) practices in plain terms

Article 10(2) lists eight governance and management practices that must be appropriate to the system's intended purpose [1]:

• (a) Design choices. Why this data, at this grain, for this decision.
• (b) Collection processes and origin. Where the data came from and, for personal data, the purpose it was originally collected for.
• (c) Preparation. Annotation, labelling, cleaning, updating, enrichment and aggregation.
• (d) Assumptions. What the data is supposed to measure and represent.
• (e) Availability, quantity and suitability. Whether enough of the right data exists.
• (f) Bias examination. Biases likely to affect health and safety, harm fundamental rights or cause discrimination prohibited by Union law, especially where outputs feed back into future inputs.
• (g) Bias measures. Steps to detect, prevent and mitigate the biases found under (f).
• (h) Data gaps. Gaps or shortcomings that block compliance, and how they will be addressed.

For licensed data, points (b), (c) and (d) depend most on the supplier. Only the company that ran the source system knows how records were created, which were purged, and what a status code meant in 2021. If you do not get that information before signing, you are reverse-engineering it from the files afterward, and some of it cannot be recovered.

Mapping each practice to supplier evidence

The practical approach is to name, for each 10(2) practice, the document or field-level evidence the supplier must hand over and the check your team runs on it. The table below works as a pre-contract request list. Attach it to your due diligence and to the data schedule of the license.

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

Two failure modes come up again and again. The first is the silent filter: a supplier drops "test" or "fraud" records during extraction and never says so, which skews base rates. The second is the code-list drift: a denial reason code is reused for a new meaning after a system migration, so labels across the boundary are not comparable. A field dictionary with change history, like the one in our data dictionary template for dataset deliveries, is the cheapest defense against both.

Representativeness and statistical properties under 10(3) and 10(4)

Article 10(3) requires training, validation and test sets to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. They must also have appropriate statistical properties for the persons or groups the system will be used on [1]. These properties can be met by individual data sets or by a combination of them [1]. In practice, you can license several sources to cover a population that no single supplier represents.

Article 10(4) adds that data sets must account for the geographic, contextual, behavioral or functional setting where the system will be used, to the extent the intended purpose requires [1]. This is where licensed US operational data needs care for EU deployment. A credit model trained on US consumer loan records carries US credit-bureau variables, state-level lending rules and US income distributions. If the system will assess creditworthiness in Germany or Spain, you need to document why the US data is still suitable, add EU-setting data, or narrow the intended purpose.

Concrete checks for 10(3)-(4):

• Compare the supplier's distribution on key covariates (age band, region, product, channel) with your deployment population, and record the gaps.
• Measure label error on a hand-reviewed sample, and report the rate with a confidence interval rather than a single "clean" claim.
• Test completeness per field and per period, not just overall null rates.
• Build validation and test sets that oversample rare but consequential cases. See stratified evaluation sets for rare and high-risk cases.

Operational labels in credit, hiring and claims usually record past human decisions, not ground truth. A historical approval flag inherits the policies and biases of the underwriters who set it. Our guide to auditing historical decision bias in operational labels covers the reject-inference and selective-labels problems this creates for 10(2)(f).

Special-category data and the bias-detection exception (now Article 4a)

Regulation (EU) 2026/1744 deleted Article 10(5) and moved the special-category bias-detection exception to a new Article 4a, which lets providers process special categories of personal data, such as ethnicity or health, only where strictly necessary to detect and correct bias, and only with safeguards [1]. These include showing that synthetic or anonymized data would not work, applying pseudonymization and strict access controls, not passing the data to other parties, and deleting it once the bias is corrected or the retention period ends [1]. GDPR continues to apply alongside the AI Act to any personal data processed [5].

For buyers, this has a contract consequence. If you need protected attributes to run bias tests, the license must say how they are delivered, who may access them and when they are deleted. Operational suppliers often remove these fields by default, and the Article 10(5) guide goes through the conditions in detail.

Systems without training: the 10(6) test-data rule

When a high-risk system does not use techniques involving model training, paragraphs 2 to 4 of Article 10 and Article 4a(1) apply only to the testing data sets [1]. This covers rules-based scoring engines, retrieval systems with fixed logic, or systems that use a third-party model without training it. Teams building these systems sometimes conclude that Article 10 does not reach them. It does: the test set still needs documented origin, preparation, assumptions, representativeness and bias examination.

Licensed real-world records are often the most defensible test sets for these systems, because they reflect the distribution the system will actually see. If you build one, keep it out of any training pipeline and record that separation. For more on test-data obligations across regimes, see regulatory requirements for AI validation and test data.

Writing supplier obligations into the license

Article 10 compliance cannot be transferred to a data supplier by contract, because the duty sits with the provider. What a license can do is oblige the supplier to provide the information and access you need to meet it. Before you sign, check that the license covers the following:

1. Information deliverables tied to each 10(2) practice: collection description, source system, original purpose, transformation log, field dictionary and known exclusions.
2. Change notification when the supplier changes extraction logic, code lists or de-identification method between deliveries in an ongoing purchase.
3. Cooperation on questions from your notified body or market surveillance authority about data origin. See regulator access to licensed training datasets.
4. Retention rights long enough to keep data-set records for your technical documentation, reconciled with any deletion duty in the license.
5. Permitted uses that explicitly include training, validation, testing and bias examination for the named system.

These deliverables feed two other documents you will write anyway. The data-set description belongs in your Annex IV technical documentation. The procedures for acquiring and checking data belong in your quality management system under Article 17's data management procedures. The general controls also appear in the AI training data due diligence checklist and the data governance glossary entry.

An illustrative supplier data-set record

A single structured record per delivery keeps the evidence together and versioned. The record below shows the fields a governance lead might require for a claims-triage model. Teams aligning with the ISO/IEC 5259 data quality series can map the quality fields to their own measures.

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

dataset_id: claims-triage-2019-2025-v3
intended_system: motor claims triage scoring (high-risk under internal policy; motor insurance is not an Annex III use)
unit_of_record: first notice of loss (one row per claim)
source_system: claims administration platform, v10.x; migrated 2022-03
extraction_window: 2019-01-01 to 2025-12-31
original_collection_purpose: claims handling and settlement
preparation_log:
  - step: exclude internal test claims (flag test_ind = Y); rows removed: recorded
  - step: replace names, emails, phone numbers, policy numbers with tokens
  - step: derive label fast_track_eligible from settlement_days <= 10
assumptions:
  - fast_track_eligible approximates low-complexity claims; reflects 2019-2025 handling policy
known_exclusions: [litigated claims, claims reopened after 2025-12-31]
known_gaps: [loss_description truncated to 2,000 chars before 2022-03]
code_list_changes: [denial_reason 14 redefined at 2022-03 migration]
subgroup_fields_available: [region, vehicle_age_band, policy_tenure_band]
special_category_fields: none delivered
quality_measures: {label_audit_sample: recorded, null_rate_by_field: attached}

How SourceX handles licensed data for high-risk use cases

SourceX sources operational datasets from US companies on request. Each dataset is rights-reviewed for ownership and consents and delivered under a license that defines the records, uses, term and delivery. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset; check them against the Article 10(2) evidence list above. Personal details such as names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded, and a sample is checked, though no method is perfect.

Buyers describe the data they need, and SourceX looks for US businesses that hold it. Every release is approved by the supplying company, and nothing is contracted until a supplier agrees, so a request does not guarantee a match. Delivery runs through private, access-controlled workflows after an executed agreement and supplier approval. If you are planning acquisition for a 2027 conformity assessment, you can describe your high-risk training data needs to SourceX; for a broader view of approvals, see the guide for AI governance leads approving third-party data, the EU AI Act and data licensing overview, and the compliance hub.

Request Article 10-ready training, validation and test data

Tell SourceX what records, fields, periods and intended system you need, and it will assess data and licensing permissions with suppliers before anything is agreed. Each dataset comes with per-dataset diligence materials and a license that defines records, uses, term and delivery. Start a buyer request.