🤖 machine learning

SoK: Data Minimization in Machine Learning

This paper presents the first systematization of knowledge for Data Minimization in Machine Learning (DMML), introducing a unified framework to bridge the gap between fragmented research and clarify terminology, metrics, and techniques for practitioners and researchers.

Original authors: Robin Staab, Nikola Jovanović, Kimberly Mai, Prakhar Ganesh, Martin Vechev, Ferdinando Fioretto, Matthew Jagielski

Published 2026-02-19

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Robin Staab, Nikola Jovanović, Kimberly Mai, Prakhar Ganesh, Martin Vechev, Ferdinando Fioretto, Matthew Jagielski

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a chef trying to make the world's best soup.

The Old Way: You go to the market and grab everything. Every vegetable, every spice, every jar of sauce, even the dirt from the ground. You dump it all into a giant pot. You think, "More ingredients mean better soup!" But in reality, you've created a muddy mess. You've wasted money, your kitchen is a disaster, and you've accidentally included some toxic weeds that ruin the flavor. Worse, you've left a trail of receipts showing exactly what you bought, which might get stolen by a thief.

The New Way (Data Minimization): You look at your recipe. You realize you only need three specific carrots and a pinch of salt. You buy only those. Your kitchen stays clean, the soup tastes perfect, and you have no receipts for the thief to steal.

This paper is a massive Systematization of Knowledge (SoK) about this "New Way" in the world of Artificial Intelligence (AI). It's called Data Minimization in Machine Learning (DMML).

Here is the breakdown of the paper using simple analogies:

1. The Problem: The "Hoarding" Habit

Right now, AI companies are like the chef who grabs everything. They collect massive amounts of personal data (your photos, your health records, your location) hoping it makes their AI smarter.

The Risk: Laws like the GDPR (in Europe) and CPRA (in California) say, "Stop hoarding! Only collect what you absolutely need." If you don't, you get fined millions.
The Confusion: The problem is that AI researchers and lawyers speak different languages. Lawyers say "Minimize data," but researchers say "Here is a cool new technique called Federated Learning." They don't realize that their cool technique is actually a form of data minimization! This paper tries to translate between the two groups.

2. The Framework: The "Data Pipeline"

The authors created a map (a framework) to understand how data moves. Imagine a factory assembly line:

The Client (You): You are the person dropping off your raw materials (data) at the factory gate.
The Collector (The Factory Manager): They gather all the materials from different people.
The Server (The Master Chef): They cook the soup (train the AI model) using the materials.

The Danger Zones: At every step of this line, a "Thief" (an Adversary) could be hiding.

They could steal your raw ingredients at the gate.
They could steal the mixed-up ingredients in the manager's office.
They could steal the final recipe (the AI model) from the chef.

Data Minimization is the art of changing the ingredients before they get to the thief, so even if the thief steals them, they are useless.

3. The Toolkit: 12 Ways to Minimize Data

The paper reviews 12 different "tools" or techniques that people use to minimize data. The authors realized these tools were scattered in different departments, so they put them all in one toolbox.

Here are the main tools, explained simply:

Federated Learning (The "Secret Recipe" Method): Instead of sending your raw ingredients to the factory, you keep them in your own kitchen. You let the factory send you a "recipe update," you mix it with your ingredients, and you send back only the changes. The factory never sees your actual ingredients.
- Analogy: You teach a chef how to make your soup by sending them a note saying "Add more salt," but you never send them the pot.
Differential Privacy (The "Noise" Method): Before sending your data, you add a little bit of static or "noise" to it. It's like putting a filter on a camera. The AI can still learn the general shape of the face, but it can't see the specific details (like your birthmark).
- Analogy: You tell the chef, "I'm roughly 30 years old," instead of "I am exactly 30 years and 4 days old."
Feature Selection (The "Paring Knife" Method): You look at your data and cut off the parts you don't need. If you are predicting heart disease, you don't need to know the person's favorite color. You just cut that data out.
- Analogy: You throw away the peels and stems before giving the vegetables to the chef.
Synthetic Data (The "Fake Ingredients" Method): Instead of using real people's data, the AI learns to create fake data that looks real but isn't attached to anyone.
- Analogy: The chef makes a plastic model of a carrot. It looks like a carrot, but if a thief steals it, they can't find the real farmer.
Active Learning (The "Ask Only When Needed" Method): The AI doesn't ask for all your data at once. It asks for a little bit, makes a guess, and if it's unsure, it asks for just one more specific piece of data.
- Analogy: A detective who only asks you for your ID if they see something suspicious, rather than asking for your ID, your bank account, and your diary immediately.
Secure Computation (The "Encrypted Box" Method): You put your data in a locked, unbreakable box. The chef can cook with the box (do math on it) without ever opening it or seeing what's inside.
- Analogy: Sending a sealed envelope to the chef. They can shake it to hear the ingredients, but they can't open it until the soup is done.

4. The Big Takeaways

The paper concludes with three main lessons for everyone:

There is no "One Size Fits All": Just like you wouldn't use a hammer to fix a watch, you can't use one data minimization technique for every problem. Sometimes you need to cut data (Feature Selection), sometimes you need to hide it (Encryption), and sometimes you need to fake it (Synthetic Data).
Trade-offs are Real: You can't have everything. If you minimize data too much, the soup might taste bland (the AI becomes less accurate). If you minimize it too little, you risk a data breach. The goal is to find the "Goldilocks" zone.
We Need a Common Language: Lawyers need to understand that "Federated Learning" is a good way to follow the law. Engineers need to understand that "Data Minimization" isn't just a legal buzzword, but a way to save money and make better AI.

Summary

This paper is a bridge. It connects the legal world (which says "Don't collect too much!") with the tech world (which has invented 12 cool ways to collect less). It gives practitioners a map to choose the right tool for their specific job, ensuring they build AI that is not only smart but also respectful of your privacy and safe from thieves.

1. Problem Statement

The paper addresses a critical disconnect between Data Minimization (DM) principles in data protection regulations (e.g., GDPR, CPRA) and the technical implementation of Machine Learning (ML) systems.

Regulatory Context: Laws like GDPR Article 5(c) mandate that personal data be "adequate, relevant and limited to what is necessary." Violations result in massive fines.
The Gap: While many ML techniques (e.g., Federated Learning, Differential Privacy, Feature Selection) implicitly achieve data minimization, they are rarely framed or evaluated through a DM lens. Conversely, explicit DM research often lacks a unified technical framework.
Consequences: Practitioners are confused about which techniques satisfy legal DM obligations. There is no standardized way to compare methods, evaluate trade-offs (privacy vs. utility), or understand the specific adversarial threats each method mitigates.

2. Methodology: The DMML Framework

The authors propose the first Systematization of Knowledge (SoK) for Data Minimization in Machine Learning (DMML). They introduce a unified framework to categorize and analyze both explicit DM techniques and "DM-adjacent" methods.

A. The DMML Pipeline & Actors

The framework defines a standard data flow involving:

Actors: Data Owner (Client), Data Collector, and Service Provider (Server).
Pipeline Stages: Data Collection $\rightarrow$ Preprocessing $\rightarrow$ Model Training $\rightarrow$ Storage $\rightarrow$ Inference.
Adversaries: The framework identifies six specific adversarial models based on when and where they access data:
1. T-Collect: Access to raw training data during collection.
2. T-Preprocess: Access to preprocessed training data before training.
3. I-Collect: Access to raw inference data.
4. I-Preprocess: Access to preprocessed inference data.
5. A-Store: Access to stored data.
6. A-Model: Access to the trained model parameters.

B. Dimensions of DMML

To systematically compare techniques, the authors define a set of dimensions:

Original Objective: Is DM the primary goal or a side effect?
Type of Minimization:
- Horizontal: Reducing the number of data points (e.g., removing records).
- Vertical: Reducing information within a data point (e.g., suppression, generalization, perturbation).
- Transformative: Non-interpretable transformations (e.g., embeddings).
Point of Application: Where is minimization applied? (Client-side vs. Collector/Server-side).
Pre- vs. Post-Hoc: Does minimization happen before data leaves the client (Pre-Hoc) or after collection (Post-Hoc)?
Client Requirements: Does the method require active client participation or specific technical capabilities?
Personalization: Is the minimization uniform or tailored to individual users?
Targeted Adversary: Which specific threat model does the method defend against?
Privacy Guarantees: Does the method offer formal guarantees (e.g., Differential Privacy) or heuristic protections?

3. Key Contributions

Unified Framework: The paper establishes a common vocabulary and pipeline model to reconcile legal definitions with technical ML implementations.
Systematic Analysis of Techniques: The authors analyze 13 major categories of techniques, mapping them to the DMML framework. These include:
- Explicit DM: Vertical/Horizontal minimization, Active Learning, RAG (Retrieval-Augmented Generation).
- DM-Adjacent: Federated Learning, Differential Privacy (Central/Local), Secure Computation (FHE/MPC), Privacy-Preserving Data Publishing (k-anonymity), Fair Representation Learning, Synthetic Data, Dataset Distillation, Data Selection, Data Augmentation, Feature Selection, and Model Compression.
Identification of Trade-offs and Gaps: The analysis reveals that many techniques have unintended consequences. For example, while Differential Privacy protects against model inversion, it often requires more data to achieve the same utility, potentially violating horizontal minimization.
Dataset Overview: The paper provides a comprehensive catalog of datasets used in DM-adjacent research, highlighting a bias toward tabular data and a lack of evaluation on complex modalities (images, text) in explicit DM studies.

4. Results & Key Findings

Diverse Flavors of DM: There is no single "best" technique. The suitability of a method depends entirely on the specific threat model (e.g., untrusted collector vs. untrusted server) and the pipeline stage.
Unintended Effects:
- Differential Privacy (DP): While offering strong formal guarantees against model extraction, Central DP requires collecting full data first (failing T-Collect protection) and often needs larger datasets, conflicting with horizontal minimization.
- Model Compression: While reducing model size, it often requires fine-tuning on original data, increasing exposure.
- Federated Learning (FL): Prevents raw data collection but is vulnerable to gradient leakage unless combined with DP or Secure Aggregation.
Inference-Time Minimization: A significant gap exists in protecting data during the inference stage (I-Collect/I-Preprocess). Techniques like RAG and Active Feature Acquisition are emerging here but lack standardized evaluation.
Lack of Standardization: There is no consensus on metrics for evaluating DM. Utility is often measured by accuracy, but privacy is measured inconsistently (e.g., reconstruction error vs. membership inference success), making cross-study comparison difficult.
Operational Challenges: Translating legal concepts like "necessity" and "proportionality" into technical parameters (e.g., $\epsilon$ in DP, $k$ in k-anonymity) remains a major hurdle for practitioners.

5. Significance

Bridging Law and Tech: The paper provides a crucial bridge for legal practitioners to understand technical ML methods and for engineers to understand regulatory compliance requirements.
Research Roadmap: It identifies clear research gaps, such as the need for:
- Standardized evaluation benchmarks and datasets for DM.
- Methods that combine horizontal and vertical minimization effectively.
- Techniques that offer inference-time privacy guarantees without sacrificing utility.
- Context-aware minimization policies (e.g., using Contextual Integrity theory).
Practical Guidance: By mapping techniques to specific adversarial models and pipeline stages, the framework allows organizations to select the right combination of tools to meet their specific compliance and security needs, rather than relying on "one-size-fits-all" solutions.

In conclusion, this SoK paper transforms Data Minimization from a fragmented set of regulatory requirements and disparate technical papers into a cohesive, analyzable field, providing the necessary structure to advance both the theory and practice of privacy-preserving machine learning.