Data minimization in ML pipelines: practical guide

Data minimisation is a GDPR principle (Article 5(1)(c)) requiring that personal data be limited to what is strictly necessary for its processing purpose. In machine learning, it means only including personal data attributes in training datasets that are genuinely necessary for the model's performance, retaining training data only as long as necessary, applying pseudonymisation or anonymisation where possible, and documenting the necessity of each personal data feature. Many ML teams violate this principle by including all available personal data in training pipelines without assessing necessity — creating significant regulatory risk.

Differential privacy (DP) is a mathematical framework that adds calibrated noise to data or model training processes, providing a formal guarantee that the model's output reveals no information about any individual training record beyond a defined privacy budget (ε). It helps with GDPR compliance by reducing the risk of personal data exposure through model outputs or membership inference attacks, and by providing a technical measure of the privacy protection applied to personal data in ML training. However, DP is not a complete GDPR solution — it addresses confidentiality but not other GDPR obligations like consent, purpose limitation, and data subject rights.

Synthetic data can often replace real personal data for ML training, eliminating the GDPR personal data problem entirely for the training phase. High-quality synthetic data generators (Gretel.ai, Mostly AI, Hazy) produce datasets that preserve the statistical properties, correlations, and distributions of the original data. However, synthetic data quality must be rigorously validated — poorly generated synthetic data can degrade model performance, fail to capture rare but important patterns in real data, or introduce biases. Synthetic data is not yet universally suitable for all ML applications, particularly those requiring precise individual-level behavioural patterns.

A Data Protection Impact Assessment (DPIA) is a structured risk assessment required by GDPR Article 35 before processing that is "likely to result in a high risk to the rights and freedoms of natural persons." ML projects typically require a DPIA when: they involve automated decision-making with significant effects on individuals; they process sensitive personal data (health, financial, biometric) at scale; they involve systematic monitoring of individuals; or they process data from vulnerable groups. The DPIA must assess the necessity and proportionality of processing, identify risks to data subjects, and document the measures taken to address those risks — including data minimisation decisions.

The right to erasure (Article 17) requires deleting an individual's personal data upon request. For ML models, this means deleting the individual's records from training datasets and feature stores. Whether model weights must also be deleted is legally unsettled — regulators have not issued definitive guidance. The practical approach is: delete from all data stores immediately; assess whether the model demonstrably memorised the individual's data (using membership inference attacks); if memorisation is confirmed or likely, retrain or apply machine unlearning techniques. SISA training enables more efficient removal of individual data points without full retraining.

Federated learning trains ML models on data where it resides (on user devices or in organisational data silos) rather than centralising personal data on a training server. Only model gradients or parameter updates are sent to a central aggregator — never raw personal data. It is most appropriate when: data sharing between organisations is legally restricted (healthcare, cross-border); users are unwilling to share personal data but willing to contribute to a shared model; data residency requirements prevent centralised processing; or the volume of personal data is too large to centralise economically. Federated learning significantly reduces the personal data footprint of ML training but does not eliminate all privacy risks — gradient inversion attacks can still potentially recover training data from shared gradients.

Pseudonymisation replaces direct identifiers (name, email, national ID, customer ID) in training datasets with artificial tokens that cannot be linked back to individuals without access to a separate mapping table. In ML pipelines, pseudonymisation reduces the personal data risk of training datasets while preserving the ability to re-identify records for debugging, erasure requests, or regulatory investigations when needed. GDPR still treats pseudonymised data as personal data (because re-identification is possible), so pseudonymisation does not eliminate GDPR obligations — but it is recognised as a security measure that reduces risk and supports data minimisation, potentially enabling more permissive uses under legitimate interest.

Model cards, introduced by Google, are structured documents that describe a trained ML model's intended use, performance characteristics, training data, and limitations. For GDPR compliance, model cards serve as evidence of due diligence: they document what personal data was used in training, what minimisation and privacy-preserving measures were applied, what the model's purpose is, and who approved the processing. Maintaining model cards creates an audit trail that demonstrates compliance with GDPR principles of data minimisation, purpose limitation, and accountability. Data Protection Authorities increasingly expect this type of documentation during ML-related investigations.