EU AI Act Article 10 — Data Governance Requirements for Chinese AI Companies

If your AI system falls under Annex III of the EU AI Act — hiring decisions, credit scoring, medical diagnosis, biometric identification, autonomous vehicles — Article 10 is not optional. It mandates how you collect, prepare, and document the data your models are trained on. For Chinese AI companies, this creates a specific tension: your training data often originates in China, under data practices that don't map cleanly onto EU requirements.

This post explains exactly what Article 10 demands, where Chinese AI companies typically fall short, and how Privacy-Enhancing Technologies close the gap without forcing you to rebuild your data pipeline from scratch.

What Article 10 actually requires

Article 10 applies to any provider of a high-risk AI system listed in Annex III. It establishes six concrete obligations for training, validation, and test data:

1. Data governance practices — You must document how data was collected, selected, and processed. "We scraped the web" is not a governance practice.
2. Examination for possible biases — The regulation explicitly requires examining data for biases that could lead to discrimination, particularly across geographic, demographic, or contextual dimensions. This is not just a fairness metric — it is a documented audit process.
3. Identification of data gaps — You must identify where your data is insufficient to represent the population your model will operate on. A model trained on Chinese demographic data that will be deployed on European users has representational gaps that must be named and documented.
4. Data preparation procedures — Labelling methodology, cleaning procedures, enrichment steps, and the criteria for including or excluding data must all be documented in a reproducible way.
5. Assumptions about what the data represents — If your training data assumes certain behavioural patterns, cultural contexts, or user demographics, those assumptions must be made explicit.
6. Assessment of data availability, quantity, and suitability — Why is this dataset appropriate for this use case? The burden of justification sits with the provider.

These six points collectively require something most Chinese AI companies do not currently have: a formal, auditable data governance system that produces written documentation, not just internal engineering practices.

The four gaps Chinese companies consistently have

From auditing AI pipelines as part of Mayfly's advisory work — and from my own time inside NEC Labs, NIO, and Alibaba — the same four gaps appear repeatedly:

1. Training data documentation doesn't exist in EU-readable form. Chinese companies typically have internal data records, but they are in formats, languages, and at levels of granularity that don't meet EU standards. "We have a data team" is not Art.10 documentation.

2. Bias examination is China-centric or absent. Models trained on Chinese user data are evaluated against Chinese demographic distributions. When deployed in Germany or France, they encounter a fundamentally different population distribution. The bias examination required by Art.10 must cover the EU deployment context — not just the original training context.

3. Cross-border data origin creates a double bind. If your training data contains EU personal data that was transferred to China for processing, you now have overlapping obligations: GDPR Art.46 governs the original transfer (which required SCCs or BCRs), and Art.10 requires you to document that data's complete lineage. Producing that lineage documentation may conflict with Chinese DSL restrictions on what data records can cross borders.

4. No data governance owner exists as a role. This is a compliance function, not just an engineering function. Someone needs to own the documentation, maintain it, and be accountable to regulators. In most Chinese AI companies with European operations, this person does not exist.

Why your Chinese training data is an Art.10 problem specifically

Article 10 itself doesn't specify where training data must originate. But the moment Chinese-origin data becomes part of a training pipeline for an EU-deployed AI system, several other requirements activate simultaneously:

• If any training data contains EU residents' personal data that was transferred to China for processing, GDPR Art.46 applies to that transfer. The only available legal bases — SCCs, BCRs, or adequacy decisions — all require that the data importer (your Chinese operations) comply with GDPR-equivalent standards. China has no EU adequacy decision.

• China's Data Security Law (DSL) classifies certain data categories as "important data" that cannot leave China without a government security assessment. For automotive companies, this includes map and sensor data. For others, it may include operational records that overlap with what Art.10 requires you to document.

• This creates a genuine catch-22: Art.10 demands full transparency about your training data's origin and lineage. DSL may prohibit transmitting that lineage documentation across the Chinese border if it contains sensitive information.

The catch-22 is not theoretical — it is the live operating reality for every Chinese AI company with significant EU deployment and Chinese training data.

How Privacy-Enhancing Technologies resolve this

The three PET strategies that directly address the Art.10 compliance problem:

Federated Learning. Train the EU-market model locally on EU data, without sending EU data to China. The Chinese training data stays in China and trains a China-specific model. Two separate models, each trained within their own jurisdiction, each with a clean data lineage that can be documented without cross-border conflicts.

The EU model's Art.10 documentation only needs to cover EU-sourced data — no DSL conflict arises. Model improvements can still flow between the two models through gradient aggregation, which (with appropriate Differential Privacy noise) does not constitute a transfer of personal data.

Differential Privacy. Add calibrated noise during training so that the trained model cannot be used to reconstruct individual training records. The practical compliance benefit: your Art.10 documentation can describe the DP mechanism and privacy budget (ε) rather than exposing individual data records. A documented ε value is a mathematical guarantee that regulators can evaluate — it moves you from "trust us" to "verify this."

Synthetic Data Generation. Generate synthetic data with the same statistical properties as the original Chinese dataset, then train on synthetic data in the EU. Synthetic data is not personal data under GDPR, which eliminates the Art.46 transfer concern and significantly reduces the Art.10 documentation burden. The primary requirement shifts from data lineage to synthetic data validation — demonstrating that the synthetic distribution is sufficiently faithful to the original.

Each of these approaches requires upfront engineering investment but avoids the alternative: attempting to produce Art.10-compliant documentation for Chinese training data in ways that conflict with Chinese law — a conflict that has no clean legal resolution.

The Art.10 compliance checklist

What a high-risk AI system provider needs to have documented before EU market placement:

• Data inventory: origins, collection method, processing history for all training/validation/test data
• Bias examination report covering EU demographic groups and deployment contexts
• Data preparation procedures document: labelling standards, cleaning criteria, enrichment methodology
• Cross-border transfer mechanism for any data that moved jurisdictions (SCC, BCR, or PET alternative)
• Data governance owner appointed with documented responsibilities
• Ongoing monitoring plan for training data drift post-deployment
• Data retention and deletion schedule aligned with GDPR
• Technical documentation bundle connecting Art.10 to Art.11 requirements

What to do in the next 90 days

Week 1–2: Map your training data. List every dataset used in training, validation, and testing. For each: origin country, collection date, legal basis for processing, whether it contains EU personal data, and whether it has crossed any borders.

Week 3–6: Run a bias examination. Take your EU deployment population and compare it to your training data's demographic coverage. Document the gaps. This doesn't require fixing everything immediately — it requires documenting what you found and what your mitigation plan is.

Week 7–12: Choose a PET strategy. Based on your data flow map: if EU personal data is in your Chinese training pipeline, you need to eliminate that transfer (Federated Learning or synthetic data). If your training data documentation conflicts with DSL restrictions, synthetic data or FL separates the jurisdictions. Engage a technical advisor to scope the implementation.

If you're not sure where to start, Mayfly's free compliance report generates a company-specific assessment of your AI Act risk tier and data governance gaps in 2 minutes.

Qifei Li is the founder of Mayfly, an EU AI Act compliance advisory specialising in Privacy-Enhancing Technologies for Chinese AI companies in Europe. Previously Research Scientist at NEC Laboratories Europe (Intel SGX / Federated Learning, IEEE ICDCS 2025) and Privacy Computing Researcher at Alibaba Group (Homomorphic Encryption, IEEE ICDE 2020). Based in Heidelberg, Germany.