EU AI Act Article 10 Data Governance: What Sanitization Contributes
Article 10 of the EU AI Act sets data and data governance requirements for high-risk AI systems that use training, validation, and testing datasets. Sanitizing personal data before it enters a dataset or a model pipeline is one practical way to support those practices. It does not replace the provider obligations.
Summary
Article 10 requires providers of high-risk AI systems to apply appropriate data governance and management practices to the datasets they use, including attention to data collection processes and the origin of data, data-preparation operations such as annotation, labelling, cleaning, and aggregation, an assessment of the availability, quantity, and suitability of the data sets, and examination for possible biases. These duties apply to training, validation, and testing data sets where a high-risk system is developed using techniques that train AI models; for systems that do not train models, they apply to the testing data sets.
Where datasets are assembled from operational records, removing direct identifiers before the data reaches annotation tools, fine-tuning jobs, or external model services reduces the personal data in scope. ZTDS provides that step as a deterministic, reversible, client-side operation.
Dataset Lifecycle Mapping
| Lifecycle stage | Governance concern | ZTDS position |
|---|---|---|
| Collection and export | Operational records contain direct identifiers that the dataset does not need. | Tokenize identifiers at export time so the dataset carries surrogates only. |
| Preparation and annotation | Annotators and tools see personal data unnecessarily. | Annotation proceeds on tokenized text; the mapping stays with the data controller. |
| Fine-tuning and evaluation | External services receive records for training or testing. | The external service receives tokens, not original values (Invariants 1 and 4). Special-category data processed for bias detection under Article 10(5) must not be transmitted to or accessed by other parties, so keep that processing local. |
| Inference-time inputs (not an Article 10 data set) | Live prompts to a deployed system include personal data. Article 10 addresses training, validation, and testing data sets. For input data, the Act separately requires a deployer that controls it to ensure it is relevant and sufficiently representative (Article 26(4)), which is not a privacy requirement. | Tokenization before egress reduces what a provider can retain. That is a GDPR matter, not an Article 10 or Article 26(4) requirement. |
How ZTDS Applies
Use the four invariants as the sanitization contract for dataset work:
- Invariant 1 — Zero cleartext egress: identifiers are replaced before any network socket call leaves the host boundary.
- Invariant 2 — Deterministic reversible surrogates: tokens such as
[EMAIL_1]preserve syntax and meaning so the model remains useful, and the mapping is restored locally. - Invariant 3 — Volatile RAM isolation: the token map lives in host memory only and is zeroized at the end of the session.
- Invariant 4 — Zero external subprocessors: no third party participates in the sanitization step.
Document the sanitization profile used for each dataset version so reviewers can see which entity categories were removed.
What This Control Does Not Cover
- Article 10 duties rest on the provider of the high-risk system. A tool does not transfer or discharge them.
- Sanitization does not address representativeness, bias examination, or error assessment of datasets.
- Article 10(5) allows providers to exceptionally process special categories of personal data where strictly necessary for bias detection and correction, only if the purpose cannot be met with synthetic or anonymised data and subject to safeguards that include pseudonymisation and a ban on transmission to other parties. Removing identifiers can conflict with that purpose, so choose the sanitization profile per dataset.
- Whether a given system is high-risk is a legal classification that requires its own analysis.
- This page is not a conformity assessment and carries no authority from EU institutions.
Frequently Asked Questions
Does EU AI Act Article 10 require removing personal data from training sets?
Article 10 requires appropriate data governance and management practices for datasets used by high-risk AI systems. Minimizing personal data is one practice that supports it, but the Article does not prescribe a single technique and the obligation stays with the provider.
Can sanitization make a system compliant with the EU AI Act?
No. Sanitization supports one area, data handling. Compliance requires a full assessment of the system classification and every applicable obligation.
Why use reversible tokens instead of deleting identifiers?
Reversible surrogates keep text coherent for annotation and model use, and the controller can restore original values locally when a legitimate need arises, while the external party never holds them.
Related Specifications and Tools
- ZTDS RFC v1.0 Specification — The four invariants referenced on this page.
- Global Regulatory Compliance Matrix — Cross-framework statutory mapping.
- AI and RAG Blueprints — Integration recipes for agent and retrieval stacks.
- Framework Mappings Hub — All framework mappings in one index.
- OWASP LLM02 Sensitive Information Disclosure — Maps pre-egress tokenization to OWASP LLM02:2025 and states what it does not cover.
- NIST AI RMF Generative AI Profile — Places ZTDS across GOVERN, MAP, MEASURE, and MANAGE for generative AI data privacy risk.
- GDPR Articles 25 and 32 for AI Prompts — Explains data protection by design and security of processing for prompts sent to AI providers.
- HIPAA Safe Harbor for LLM Prompts — Shows how 18-identifier removal applies to clinical text sent to language models.
- MCP stdio PII Sanitization — Describes a local gateway that sanitizes JSON-RPC traffic over the MCP stdio transport.
- RAG Pipeline PII Sanitization — Places sanitization at ingestion, retrieval, and prompt assembly stages of a RAG pipeline.
- Client-Side Sanitization vs Proxy DLP — Compares client-side in-memory sanitization with network proxy and cloud DLP approaches.