Data Governance for AI Systems: Article 10 Compliance

Every dataset used in the system lifecycle requires structured documentation covering provenance, composition, preparation, quality, annotation, and known limitations. Generic data catalogue entries do not satisfy Article 10; documentation must be specific enough for an assessor to evaluate suitability for training the system in question.

Provenance requires specificity: "data collected from deployer ATS systems between January 2021 and December 2023 under data processing agreements" is acceptable; "data from various sources" is not. The record must state the collection methodology, whether informed consent was obtained or another legal basis under GDPR Article 6 applies, and the licensing terms for any third-party data including whether those terms permit the intended use.

Composition covers dataset size (record count, feature count, storage size), temporal coverage, and geographic and demographic distribution. Statistics must be presented both in aggregate and disaggregated by relevant subgroups, particularly where protected characteristics are represented and in what proportions relative to the deployment population.

Preparation documents every preprocessing, cleaning, transformation, augmentation, and feature engineering step. Records removed must be logged with the reason and count. Missing value handling and imputation methods must be recorded with the assumptions they encode. Quality captures the metrics applied, error rates observed, how errors were detected and corrected, and the automated quality checks enforced. Annotation records annotator qualifications, guidelines, inter-annotator agreement rates, disagreement resolution processes, and whether annotators were compensated fairly under conditions that support quality, since annotation quality directly affects label accuracy which directly affects model fairness. Known limitations identifies gaps, biases, underrepresented subgroups, and temporal or geographic skew.

The Datasheets for Datasets framework (Gebru et al., 2021) provides the most thorough structure, organising documentation into seven sections: motivation, composition, collection process, preprocessing and cleaning, uses, distribution, and maintenance. For EU AI Act compliance, the composition section must include distributional analysis across protected characteristics feeding the bias assessment. The collection process section must document the GDPR lawful basis. The preprocessing section must align with data lineage requirements. The uses section must explicitly state limitations relevant to the system's intended purpose.

Documentation depth should be proportionate to the dataset's role. Training datasets for high-risk systems warrant comprehensive datasheets; static reference datasets warrant lighter treatment. A 50-page datasheet for a simple lookup table adds cost without compliance value. The AI System Assessor must document the standard applied to each dataset category and the rationale for the proportionality decision. Dataset documentation is a living artefact updated whenever the dataset changes, with version bumps triggering corresponding documentation updates. Data catalogue tools such as OpenMetadata and DataHub support attaching structured documentation to dataset versions with change tracking. For lighter tooling, a Markdown file co-located with the dataset in the data versioning system (DVC, Delta Lake) provides version-controlled documentation that evolves alongside the data.

Article 10(3) requires datasets to be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete." Completeness has three dimensions that the AISDP must address: feature completeness, population completeness, and temporal completeness.

Feature completeness means every feature the model's intended purpose logically requires should be present and populated. Missing features force the model to rely on proxy variables, which may introduce bias. The AISDP must document which features are available, which are missing and why, and what compensating controls are in place.

Population completeness requires the dataset to represent the full range of persons and groups on whom the system will operate. If deployed across the EU/EEA, training data should reflect the demographic diversity of the deployment population. Underrepresentation of specific subgroups degrades the model's performance for those subgroups and creates fairness risk. Temporal completeness requires sufficient coverage of seasonal, cyclical, and trend variations. A model trained on one year of data may not capture multi-year patterns. Module 4 records the temporal coverage and the assessment of whether it is sufficient for the system's intended purpose.

Complete data is rarely achievable in practice. Module 4 must record the compensating controls applied when completeness gaps are identified. Synthetic data augmentation can address underrepresentation of specific subgroups, though the AISDP must document the generation algorithm, validation against real data distributions, the proportion of synthetic data in the final training set, and the trade-off between coverage and the risk that synthetic data fails to capture real-world complexity. Transfer learning from related domains can compensate for limited data in the target domain, provided the domain relevance is justified and performance degradation from domain shift is measured and documented. Stratified sampling ensures small subgroups appear in validation and test sets in sufficient numbers for meaningful performance metrics. Ensemble methods combining predictions from multiple models trained on overlapping but non-identical subsets can improve robustness to completeness gaps, with the ensemble composition and combination logic documented in the AISDP.

Data quality validation is the automated gate that prevents corrupted or drifting data from reaching the model. Without it, a single upstream change, such as a source system schema modification, a data provider's silent methodology change, or a pipeline bug introducing null values, can propagate through to the model and degrade performance or introduce bias.

Validation should run at three pipeline checkpoints: at ingestion (before raw data enters the system), after each transformation step (confirming the transformation produced expected output), and before training (confirming the final dataset meets all quality standards). Each checkpoint enforces a different set of expectations.

Schema validation catches structural problems: renamed columns, changed data types, and unexpected formats. Pandera provides lightweight schema validation for Pandas DataFrames using a decorator pattern. For SQL pipelines, dbt's built-in tests (unique, not_null, accepted_values, relationships) provide schema-level assertions. Statistical validation catches distributional problems: sudden feature distribution shifts, correlation structure changes, or anomalous batches. The Kolmogorov-Smirnov test and chi-squared test are the workhorses, with reference distributions captured from a validated baseline dataset and updated periodically (for example, quarterly, aligned with the risk register review). Evidently AI generates data quality reports that include distribution comparisons, correlation analysis, and drift metrics suitable for both pipeline gating and periodic review. Anomaly detection catches individual-record problems: extreme values, multi-feature statistical outliers, duplicates, or corrupted entries. Isolation forests and z-score methods are standard approaches.

Great Expectations is the most comprehensive tool for this purpose. It uses a declarative approach where expectations (assertions about data) are defined as code, organised into expectation suites (collections of assertions for a specific dataset), and run as part of the pipeline. An expectation might state "the column age should have no null values," "the column income should be between 0 and 10,000,000," or "the distribution of gender should match the reference distribution with a KS test p-value above 0.01." When an expectation fails, the pipeline halts and produces a structured validation result documenting exactly which expectations failed and by how much. The expectation suites serve as executable documentation of data quality standards that an assessor reviewing Module 4 can read to understand exactly what checks were applied. Great Expectations also generates Data Docs, HTML reports summarising validation results, which serve as evidence artefacts.

For third-party data sources, the validation pipeline is particularly important. Contractual quality specifications set the expected standard, and automated validation confirms each delivery meets it. Deliveries that fail are quarantined (not ingested) and flagged for investigation. The quarantine mechanism and investigation process are documented in the AISDP.

Bias detection is the most technically demanding aspect of data governance under Article 10. Article 10(2)(f) requires providers to examine training data for "possible biases that are likely to affect the health and safety of persons, have a negative impact on fundamental rights, or lead to discrimination." The assessment operates in two phases: before training and after training.

Pre-training bias assessment examines the data before any model is trained. Distributional analysis computes the distribution of each feature across protected characteristic subgroups, using chi-squared tests for categorical features and Kolmogorov-Smirnov or Mann-Whitney tests for continuous features. The practical output is a matrix with features on one axis, protected characteristics on the other, and each cell showing the test statistic and p-value. Features with statistically significant distributional differences (p less than 0.05 after Bonferroni correction for multiple comparisons) are flagged for investigation. ydata-profiling automates this for tabular datasets, producing an HTML report with correlation matrices and distribution comparisons.

Label bias analysis examines whether outcome labels themselves reflect historical discrimination. In a recruitment context, the "hired/not hired" label encodes human recruiter decisions that may carry conscious or unconscious bias. Detecting label bias requires stepping outside the data: inter-rater reliability analysis (having multiple independent labellers rate the same instances, measuring agreement via Cohen's kappa or Krippendorff's alpha) reveals the extent to which labels are subjective. Re-labelling by diverse panels provides a corrective dataset for comparison. Where relabelling is infeasible, the AISDP documents the known label bias, its potential effect on the model, and the compensating controls.

Proxy variable detection identifies features that correlate strongly with protected characteristics. Postcode correlates with ethnicity and socioeconomic status. University name correlates with social class. Name correlates with gender and ethnicity. Detection computes correlation between each feature and each protected characteristic using Pearson for continuous-continuous pairs, point-biserial for continuous-binary pairs, and mutual information for any pair. Features with correlation above a defined threshold (typically 0.3, calibrated to the domain) are flagged. The flag does not mean automatic removal; the Technical SME justifies retention where predictive value warrants it and proxy risk can be mitigated through fairness constraints during training.

Intersectional analysis examines subgroup combinations, since a dataset may have adequate representation of each characteristic individually but critically small cell sizes for intersectional subgroups (for example, women from ethnic minority backgrounds at 3 to 5% of the dataset). Cell sizes must be reported in the AISDP for all examined intersectional subgroups. Where cell sizes fall below minimum thresholds for meaningful analysis (commonly 30 instances for basic metrics, 100 or more for reliable fairness metrics), the AISDP states this limitation explicitly rather than reporting unreliable metrics. Fairlearn's MetricFrame supports intersectional analysis by accepting multiple sensitive features and computing metrics for every combination with confidence intervals.

Post-training bias evaluation measures whether the trained model produces fair outcomes using five complementary metrics. The selection rate ratio (four-fifths rule) flags adverse impact when the positive outcome rate for any subgroup falls below 80% of the majority group's rate. Equalised odds requires similar true positive and false positive rates across subgroups; differences mean the model makes systematically different types of mistakes for different groups. Predictive parity requires positive predictions to be equally accurate across subgroups. Calibration within groups tests whether predicted probabilities correspond to actual outcomes consistently; reliability diagrams (plotting predicted probability against observed frequency per subgroup) are the standard visual tool. Counterfactual fairness testing measures whether changing a protected characteristic while holding other features constant changes the output.

These metrics can conflict: a model achieving equalised odds may fail predictive parity. The organisation must decide which fairness concept takes priority for its specific system and document the rationale.

No bias mitigation technique eliminates bias without side effects. Every technique trades one form of accuracy or fairness for another, and the AISDP must document what technique was used, why it was chosen over alternatives, what trade-off it introduced, and whether that trade-off is acceptable.

Pre-processing mitigations modify the training data before the model sees it. Resampling is the simplest approach: oversampling underrepresented subgroups or undersampling overrepresented subgroups. SMOTE (Synthetic Minority Over-sampling Technique) generates synthetic examples by interpolating between existing minority records, reducing overfitting risk compared to simple duplication. ADASYN focuses synthetic generation on boundary regions where the classifier struggles. Reweighting assigns higher training weights to underrepresented subgroups, with weight for each instance inversely proportional to its subgroup's prevalence. AI Fairness 360 provides a reweighting preprocessor that computes optimal weights automatically. The disparate impact remover (Feldman et al., 2015) modifies feature values to reduce correlations with protected characteristics while preserving predictive value. Learning fair representations (Zemel et al., 2013) learns a new feature space explicitly uninformative about protected characteristics.

In-processing mitigations modify the training procedure itself. Fairlearn's ExponentiatedGradient solves a constrained optimisation problem, maximising accuracy subject to a fairness constraint such as demographic parity or equalised odds. It trains many candidate models with different constraint levels and returns the best balance of accuracy and fairness, integrating with scikit-learn estimators. Adversarial debiasing (Zhang et al., 2018) trains an adversary network that tries to predict protected characteristics from the model's internal representations, penalising the model for leaking demographic information. The adversary's learning rate relative to the main model critically affects the trade-off.

Post-processing mitigations modify outputs after inference. Threshold adjustment sets different decision thresholds per subgroup to equalise selection rates or error rates. Fairlearn's ThresholdOptimizer automates finding per-subgroup thresholds that satisfy a given fairness constraint while maximising accuracy. Reject option classification routes borderline predictions (where confidence is low) to human review. Calibrated equalised odds (Pleiss et al., 2017) adjusts probability scores per subgroup to achieve both calibration and equalised odds.

Post-processing mitigations face legitimate criticism as cosmetic adjustments that mask underlying model bias without addressing root causes. A model requiring aggressive threshold adjustment has learned something problematic, and the adjustment will not fix that learning if the input distribution shifts. For AISDP purposes, valid reasons for choosing post-processing include: root-cause mitigation would require protected characteristic data the organisation cannot lawfully obtain; root-cause mitigation would reduce accuracy below declared performance thresholds; or the bias is an artefact of historical data that cannot be corrected within the training data. The AI Governance Lead must sign off, and residual risk must be documented. Where no technique fully eliminates bias, compensating controls may include mandatory human review for decisions affecting disadvantaged subgroups, enhanced outcome monitoring, or deployment restrictions.

Data lineage, the ability to trace every data element from source collection through each transformation to final use in the model, is foundational to AISDP Module 4. Without it, the organisation cannot prove what data the model was trained on, how that data was prepared, or whether preparation steps introduced bias.

Lineage operates at three levels, and most organisations need all three. Pipeline-level lineage captures the macro view: which steps ran, in what order, with what inputs and outputs. DAG-based orchestration tools (Airflow, Prefect, Dagster) provide this automatically because the pipeline definition is itself a directed acyclic graph of steps with declared dependencies. Every pipeline execution must be logged with a unique execution ID, timestamp, input dataset versions, output dataset versions, and execution status.

Transformation-level lineage captures the logic within each step: what the cleaning step actually did, what the feature engineering computed, what the imputation strategy was. This requires each transform to be defined as version-controlled code, not ad hoc SQL queries or Jupyter notebook cells. dbt is the strongest tool for SQL-based transforms, with each model defined as a SQL file in a Git repository with tests, documentation, and automatic lineage graph output. For Python-based transforms, the code provides lineage when version-controlled, but parameters (thresholds, imputation values, normalisation statistics) must also be captured as structured metadata.

Column-level lineage is the finest grain and the most valuable for bias analysis. It tracks how each column in the output dataset relates to columns in source datasets. If the model uses a "risk_score" feature, column-level lineage reveals that it was derived from "annual_income" (source: payroll system) and "postcode" (source: address database), making the proxy relationship with ethnicity visible. OpenLineage provides an open standard for emitting lineage events at all three levels, with Marquez implementing it as a queryable lineage server. DataHub and Apache Atlas offer similar capabilities.

Feature stores (Feast, Tecton, Hopsworks) address a specific lineage gap: the connection between raw data and computed features. They centralise feature definitions, versioned feature values, and metadata, enforcing consistency between training and inference features to eliminate training-serving skew. Each data engineering step should be wrapped in a pre-step/post-step record capturing the input datasets by version identifier, the intended transform and rationale, expected output characteristics, and actual output characteristics for comparison. Data versioning through DVC, Delta Lake, LakeFS, or cloud-native versioning ensures every dataset has an immutable identifier linked to the model version it trained, so the AISDP can state precisely which data was used for each model version.

Article 10(5) permits processing of special category personal data strictly for bias monitoring and detection, subject to specific safeguards. This provision resolves a fundamental tension: meaningful bias detection is frequently impossible without access to the demographic data that data protection law restricts.

The gateway condition is the sufficiency test. Before processing real special category data, the organisation must demonstrate that bias detection "cannot reasonably be carried out" using synthetic or anonymised alternatives. This is not a formality; it requires a documented technical assessment. Synthetic data evaluation involves generating datasets replicating protected characteristic distributions (using tools like SDV, Gretel.ai, or MOSTLY AI), running the full bias detection suite, and assessing whether results reliably indicate real-world fairness behaviour. Synthetic data frequently falls short because it fails to capture the correlational structure between protected characteristics and features such as educational attainment, postcode, or employment history. The evaluation should quantify this by comparing bias metrics on synthetic data against metrics on a small, carefully governed sample of real data.

Anonymisation evaluation assesses whether anonymised data preserves the subgroup structure needed for disaggregated fairness analysis. k-anonymity, l-diversity, and t-closeness provide formal privacy models; the choice depends on dataset size and data sensitivity. The DPO Liaison documents the anonymisation technique, privacy parameters, re-identification risk assessment, and suitability conclusion.

When alternatives are insufficient, processing requires five layers of safeguards. Isolation stores special category data in a dedicated, physically or logically separated environment blocked from the main development and production data. Pseudonymisation replaces direct identifiers with pseudonymous keys, with the mapping table stored separately (for example in HashiCorp Vault) under stricter access controls accessible only to the DPO Liaison and a named data governance officer. Encryption requires AES-256 at rest and TLS 1.3 in transit, with no unencrypted special category data at any pipeline point. Access control and audit restricts access to named individuals with documented business need, with immutable audit trails capturing accessor identity, timestamp, data accessed, and purpose. Confidential computing provides the highest assurance through hardware-secured enclaves (Azure SGX, AWS Nitro, Google Confidential VMs) that prevent data exfiltration even by system administrators.

A formal governance workflow requires the Technical SME to prepare a Special Category Data Processing Request specifying the bias detection purpose, specific data elements, processing methodology, and expected retention period. The DPO Liaison reviews for GDPR Article 9 compliance, and the AI Governance Lead confirms that only the minimum data necessary will be processed. Results are extracted in aggregate form only; individual records must not leave the secured environment. Following completion, special category data is deleted or anonymised, with the DPO Liaison verifying deletion technically across all storage locations including backups, caches, and derived datasets.

The AI Act's data governance requirements operate alongside the GDPR as cumulative obligations. An organisation that satisfies Article 10 but violates the GDPR is non-compliant with both regulations, because the AI Act's data governance provisions presuppose GDPR compliance. Module 4 of the AISDP must address both frameworks in an integrated manner.

Lawful basis selection under GDPR Article 6 is one of the most consequential data governance decisions. Consent (Article 6(1)(a)) offers the strongest legal footing but is often impractical for large-scale datasets, since consent must be freely given, specific, informed, and unambiguous. Withdrawal rights create operational challenges: if a data subject withdraws consent, the organisation must remove their data from the training set and either retrain or demonstrate the data cannot be recovered from model parameters. Legitimate interest (Article 6(1)(f)) is more commonly relied upon, requiring a documented three-part balancing test (legitimate interest identified, processing necessity demonstrated, interests balanced against data subjects' rights) for each dataset and processing purpose. Public interest (Article 6(1)(e)) is available for public authority AI systems, while contract performance (Article 6(1)(b)) applies where the AI system processes personal data to fulfil a contract.

Data subject rights present specific technical challenges in the AI context. The right to erasure (GDPR Article 17) is the most demanding: the organisation must remove data from the training dataset and either retrain the model or demonstrate that the individual's data cannot be recovered from the model's parameters. Three approaches exist with different cost and assurance profiles. Full retraining removes the records and retrains from scratch, which is cleanest but expensive for large models. SISA training (Sharded, Isolated, Sliced, Aggregated) partitions training data into shards with separate models, so only the shard containing the data subject's records requires retraining. Approximate unlearning attempts to reverse the effect of specific records without full retraining but lacks formal guarantees and should be treated as supplementary for high-risk systems.

The right of access (Article 15) requires a training data provenance index mapping individual identifiers to dataset versions. The right to rectification (Article 16) may require dataset modification and model retraining depending on the correction's materiality. The right not to be subject to solely automated decision-making (Article 22) intersects with Article 14 human oversight requirements: if the human oversight documented in AISDP Module 7 constitutes meaningful involvement, processing may not be "solely" automated. Article 86 of the AI Act provides affected persons with a right to explanation of individual decision-making, complementing GDPR Recital 71.

DPIA and FRIA coordination is required because GDPR Article 35 mandates a Data Protection Impact Assessment while AI Act Article 27 requires a Fundamental Rights Impact Assessment. These are distinct but overlapping; findings from each should inform the other. The data retention tension between GDPR's storage limitation principle and Article 18's ten-year AISDP retention obligation is reconciled by retaining documentation (metadata, provenance records, quality metrics, distributional statistics) after the underlying personal data has been deleted or anonymised. Data architecture must be designed so that compliance-relevant information about training data can survive the deletion of the individual records it describes.

Many high-risk AI systems rely on data the organisation does not collect, curate, or control. Article 10's governance requirements apply regardless of data source, and the organisation bears full compliance responsibility for data it has limited ability to govern directly.

Embedding models and knowledge bases in RAG architectures similarly require governance proportionate to their influence on system outputs.

Third-party data governance operates across three layers. The contractual layer establishes the baseline across five domains: provenance disclosure (collection methodology, GDPR lawful basis, populations represented, known limitations, prior processing); quality specifications (measurable standards for completeness, accuracy, timeliness, and consistency); bias and representativeness warranties (demographic composition statistics where lawful); change notification (30 to 90 days notice before material methodology changes); and audit rights (risk-proportionate inspection of supplier governance practices, annual for high-sensitivity data, biennial for lower-risk sources).

The technical layer validates every delivery regardless of contractual promises. An automated intake validation pipeline checks schema compliance, completeness against contracted thresholds, statistical distribution against historical baselines, and anomaly detection for unusual records or batches. Great Expectations or Soda Core can define a dedicated expectation suite per supplier encoding contractual quality specifications as automated checks. Deliveries that fail are quarantined and do not enter the training pipeline. Periodic re-assessment, at least annually, evaluates whether data remains representative. The monitoring layer defends against silent changes through statistical comparison of each delivery's distributional profile against the historical baseline.

Knowledge base governance applies Article 10 requirements adapted for inference-time retrieval. Documentation covers composition (document count, types, source distribution, temporal coverage), completeness against the deployment context, currency (staleness thresholds for time-sensitive domains), provenance for each document, and bias assessment. A medical decision-support RAG system whose knowledge base covers only English-language US guidelines will produce systematically different responses for EU patients where national clinical guidelines differ.

Embedding model bias is a structural concern. Research consistently demonstrates that embedding models trained on broad web corpora encode societal biases that manifest as differential retrieval quality across demographic subgroups. Assessment combines intrinsic evaluation (WEAT and sentence-level extensions) and extrinsic evaluation (paired queries differing only in demographic markers). Multilingual performance varies significantly across models; evaluation should use language-specific retrieval benchmarks (MIRACL, MTEB) and domain-specific test queries. Embeddings as personal data require GDPR assessment where original text can be reconstructed through inversion attacks. Version control coordinates the embedding model version with the knowledge base index version; any model change triggers re-indexing since mismatched vector spaces degrade retrieval quality.

Where a supplier refuses adequate provenance disclosure, quality specifications, or audit rights, the AI System Assessor records the gap in the risk register. If compensating controls are insufficient, the data source must be replaced. Contractual liability allocation does not diminish regulatory obligations; the provider or deployer remains responsible under the AI Act regardless of data source. The contract should specify the supplier's liability for data quality breaches, the obligation to cooperate with regulatory investigations, and indemnification arrangements for losses arising from breach of data quality, provenance, or bias warranties.