Short Answer
EU AI Act Article 10 mandates governance and quality criteria for the training, validation, and test datasets of high-risk artificial intelligence systems (including medical device software): datasets must be relevant, as free of errors and as complete as possible, have the appropriate statistical properties, and represent the characteristics of the persons or groups on whom the system will be used (geography, demographics, clinical context). Article 10(5) also grants limited permission to process special category (health) data where necessary for bias detection and correction. These obligations begin to apply to high-risk systems on 2 August 2026; because MDR/IVDR compliance is already required on the medical AI side, the AI Act adds a data governance layer on top of it.
Serteser Danismanlik is run by a biomedical engineer (BME MSc) who has developed a medical AI medical device and published it in a peer-reviewed international journal; we design the standalone clinical validation study at the core of the TITCK-CDSS, EU-MDR, and FDA files for your SaMD/AI devices, carry out the statistics of dataset representativeness and subgroup bias analysis, and sign as the named methodologist. Management system certification (ISO 13485) and product registration paperwork are out of scope; we focus on the statistical and methodological core of Article 10.
One of the most frequently overlooked yet, for medical AI, most critical articles of the EU AI Act (Regulation (EU) 2024/1689) is Article 10. While most manufacturers concentrate their attention on Article 9 (risk management) and Article 15 (accuracy, robustness, cybersecurity), the real gap in an audit tends to surface on the data side: where the training data came from, whom it represents, and whether performance collapses in subgroups.
This article makes the text of Article 10 concrete in the medical AI context: it addresses what the representativeness requirement means in practice, how bias/subgroup analysis is designed, the Article 10(5) health data exception, and the 2 August 2026 entry-into-force timeline, all from a methodologist's perspective.
What Exactly Does Article 10 Mandate
Article 10 defines the data and data governance obligations for high-risk systems trained with training data. The core provisions:
- Data governance practices (10(2)): Design choices, data collection processes and origin, labeling/annotation, data preparation (cleaning, aggregation), formulation of assumptions, assessment of data suitability, and examination of possible biases must be documented.
- Quality criteria (10(3)): Training, validation, and test datasets must be relevant, sufficiently representative and, to the extent possible, free of errors and complete. The statistical properties must reflect the persons or groups on whom the system will be used.
- Contextual characteristics (10(4)): Datasets must take into account the characteristics of the geographic, contextual, behavioral, or functional setting in which the system will be used. Training a diagnostic model intended for use in a European population on single-center, single-ethnicity data directly violates this provision.
- Special category data for bias detection (10(5)): Where strictly necessary to detect and correct bias, the manufacturer may process special category data such as health data; however, technical limitations, security safeguards, and GDPR/EHDS compliance are required.
A critical nuance: Article 10 does not say "there must be no bias in your data at all." It says examine, measure, and, where necessary, mitigate bias in a documented way. What the auditor looks for is not flawless data but the methodological trail showing that the flaws are known.
What "Sufficiently Representative" Means in Practice
Representativeness appears abstract in the text; it needs to become concrete on the statistical side. For medical AI, we define representativeness along these axes:
- Demographic axes: Age bands, biological sex, ethnic origin/skin tone (especially in dermatology and image-based models), body composition.
- Clinical axes: Disease severity distribution, comorbidity profile, representation of rare variants, closeness of the normal-abnormal ratio to the prevalence at the site of use (spectrum bias).
- Technical/workflow axes: Imaging device manufacturer and model, field strength (MRI 1.5T vs 3T), protocol/reconstruction differences, number of centers. Single-device data is exposed to domain shift in production.
- Geographic-contextual axis: Is the country/center profile where the model will be deployed represented in the training data? A model intended for use in Turkey trained entirely on US data is weak against 10(4).
Practical tool: produce an intended-use population profile, then compare the marginal distributions of your training/test set against this profile. Gaps (for example, the under-representation of patients over 70 years of age) are documented, and a minimum subgroup sample size in the test set is guaranteed.
The Statistics of Bias and Subgroup Analysis
The publishable evidence of Article 10 compliance is a performance breakdown across pre-defined subgroups. Here the methodology is decisive:
- Pre-registered subgroups: Which subgroups will be examined (sex, age band, device, center) is defined in the validation protocol before the data is seen. This is what distinguishes it from post-hoc subgroup screening; the latter creates a multiple comparisons problem.
- Metrics per subgroup: Overall AUC-ROC alone is not enough; for each subgroup, sensitivity, specificity, and appropriate fairness metrics (equalized odds, equal sensitivity difference) are reported with confidence intervals.
- Stratification and sample size: Wide confidence intervals in small subgroups do not mean "no problem"; they mean the power is insufficient. The minimum subgroup n is planned in the test set design.
- Alignment with TRIPOD-AI and PROBAST-AI: Reporting of subgroup performance overlaps with the items required by TRIPOD-AI; PROBAST-AI, meanwhile, evaluates representativeness and selection bias within a risk-of-bias framework. The AI Act file asks for the same evidence as these guidelines, in a different language.
To align your data governance plan and subgroup analysis protocol with EU AI Act Article 10 and TRIPOD-AI, request a 15-minute free scoping call.
Article 10(5): The Health Data Processing Exception for Bias
The paradox is this: to measure bias by sex or ethnic origin, you need to collect these sensitive attributes, but GDPR restricts special category data by default. Article 10(5) opens this bottleneck, under strict conditions:
- The processing must be strictly necessary solely for bias detection/correction.
- It must not be possible to achieve the same result with synthetic or anonymized data (these must be tried first).
- Technical limitations (a re-use prohibition), pseudonymization, access control, and documentation are mandatory.
For medical AI, this is an intersection that must be considered together with the EHDS (European Health Data Space) and KVKK/GDPR. Our lane here is the statistical and protocol side: which sensitive variables will be collected at what minimal granularity, and how the fairness metric will be defined. Data protection legal opinion and QMS documentation are separate areas of expertise, and we do not take ownership of them.
Entry-into-Force Timeline and Relationship with MDR
The timing is being misunderstood. The clear framework:
- 2 August 2026: The Chapter III obligations for high-risk AI systems (including Article 10) generally begin to apply.
- Medical AI is mostly high-risk: Medical device software that requires third-party conformity assessment under MDR/IVDR is considered high-risk via AI Act Annex III/Article 6.
- MDR is already in force: Clinical evaluation (a CER in the logic of MEDDEV 2.7/1 Rev 4) is already required. The AI Act does not establish a new device approval process; it adds data governance, logging, and transparency layers on top of the existing MDR technical file.
- GPAI and other timelines are separate: General-purpose AI model obligations (August 2025) and some other provisions have different dates; for medical SaMD, the key date is 2026.
Practical takeaway: if you are starting a new validation study, embedding the subgroup and representativeness analysis into the protocol today feeds both the CER and the AI Act file with a single evidence set.
Common Mistakes
- Relying on overall AUC and skipping the subgroup breakdown: High overall accuracy can hide that performance collapses in a specific subgroup (for example, dark skin tone or age 75+); Article 10 and PROBAST-AI question exactly this.
- "Narrating" representativeness after the data has been seen: Justifying subgroups and the intended-use profile after the analysis is post-hoc. Without pre-registration (protocol plus, where possible, a versioned timestamp), it is weak against an auditor.
- Claiming Europe-wide coverage with single-center/single-device data: 10(4) demands contextual representativeness; models that ignore domain shift (device, protocol, geography) fail on external validation.
- Never collecting sensitive data for bias measurement: Saying "we did not collect sex/ethnicity because of GDPR" makes bias invisible, not gone. 10(5) opens the way precisely for this legitimate need; planned and minimal collection is the correct answer.
Related Articles
- TRIPOD-AI and PROBAST-AI: Reporting for AI Diagnostic Models
- How to Design a SaMD Clinical Validation Study
- Data Leakage and Train-Test Split in AI Validation
EU AI Act Article 10 offers medical AI manufacturers not new bureaucracy but a framework that turns what good methodology already requires into a legal obligation: whom your data represents, what it does in subgroups, and how you document this. Scope, duration, and budget differ for every file; we clarify these in a free scoping call. The right timing is to build the protocol along this alignment from its very first line.