A team decides to run a language model on its own servers instead of calling an external API. The motivation is privacy: keep the sensitive data in-house, never hand it to a third party. That instinct is sound, and the control it buys is real, but it is also incomplete. A model trained on private records can be made to reveal whether a specific person's record was in its training set. Federated updates that never carry raw data can be inverted back into the images that produced them. A large model can memorize and emit chunks of what it was trained on. The data stayed home, and the model still leaked.
That gap, between feeling private and being provably private, is what privacy-preserving machine learning addresses. The standard machine learning pipeline needs raw data accessible to the training infrastructure, which collides with privacy regulation, with data-sovereignty requirements, and with partners who will not share their datasets at all. Privacy-preserving machine learning is the family of techniques that resolves that collision.
The useful distinction is between techniques that reduce data movement, techniques that bound what outputs can reveal, and techniques that keep data confidential during computation. Self-hosting sits beside those controls rather than replacing them.
The Short Version
- Privacy-preserving machine learning (PPML) is an umbrella category, not one method. This article focuses on four major approaches: federated learning, differential privacy, homomorphic encryption, and secure multi-party computation. Other privacy-enhancing architectures, including trusted execution environments, can also appear in PPML systems.
- Federated learning alone does not provide a formal privacy guarantee. It keeps raw data at the source, but shared gradient updates can sometimes be inverted back into training records. Differential privacy is one common way to add a formal leakage bound.
- Differential privacy's strength is usually summarized by epsilon. The guarantee also depends on delta, the protected unit, and the privacy accounting method. A formal guarantee with weak parameters can still be a guarantee on paper and theater in practice.
- Homomorphic encryption is real and slow. Computing on encrypted data works, but the overhead confines it today to simpler models, latency-tolerant inference, and experimental fine-tuning workflows, not ordinary large-model training or full large-model pretraining.
- Self-hosting a model is data localization, not PPML. Keeping data on infrastructure you control governs who can reach it. It does not govern what the model itself can reveal.
Scope note: this is a conceptual explainer, not an implementation guide. It does not cover library setup, epsilon selection, regulatory compliance, or private LLM fine-tuning in depth. The goal here is the map. The turn-by-turn directions belong in dedicated implementation guides.
How Privacy-Preserving Machine Learning Protects Data
Privacy-preserving machine learning is an umbrella term for methods that reduce, restrict, or formally bound information exposure across model training, inference, and collaborative analysis. This article focuses on four major approaches: federated learning, differential privacy, homomorphic encryption, and secure multi-party computation. They protect different assets under different threat models, so they should not be treated as interchangeable guarantees.
The problem is simple: standard ML pipelines often assume the training process can access raw records, while privacy regulation, data-sovereignty requirements, and partner agreements often prevent that access. The four families answer that constraint in different ways: move computation to the data instead of moving data to the computation (federated learning), add calibrated noise so outputs reveal less about any one person (differential privacy), compute on data that remains encrypted (homomorphic encryption), or let several parties jointly compute a result without exposing their raw inputs to one another (secure multi-party computation).
The underlying risk is stated plainly in Google's responsible-AI guidance: machine learning models may remember or reveal aspects of the data they were exposed to, and privacy work exists to put safeguards around that. PPML addresses that risk, and it is distinct from plain anonymization, for reasons the next section makes concrete.
Why Isn't Anonymization Enough?
Anonymized data can still be re-identified. Stripping names and obvious identifiers from a dataset reduces obvious exposure, but it does not guarantee privacy once the data can be linked with outside information. That is the recurring weakness of de-identification approaches such as k-anonymity: they can reduce identifiability under specific assumptions, but they do not provide the formal guarantees available from techniques such as differential privacy or cryptographic PPML methods.
The practical distinction matters to anyone who has been told "we anonymized it, so we're fine." Anonymization is a claim about a dataset under a specific context and threat model. A linkage attack does not need to break encryption or bypass access controls. It only needs another dataset that overlaps yours. That point is made directly in NIST's de-identification guidance, which notes that de-identified data can still be re-identified by linking it with auxiliary datasets.
Differential privacy can provide something ordinary de-identification does not: a mathematical bound on how much an individual's data can affect a released result, under a defined unit of privacy and threat model. Homomorphic encryption and SMPC provide different kinds of cryptographic confidentiality, while federated learning primarily changes where data is processed. Those guarantees are related, but they are not the same.
How Does Federated Learning Work, and Why Isn't It Enough Alone?
In federated learning, a global model is sent out to local devices or servers, trains on the data sitting there, and returns only its parameter updates to the center. Raw data never moves. It is a genuinely useful pattern, and it is in production at scale. It is also, by itself, not a privacy guarantee.
The mechanism is model-to-data rather than data-to-model. Google's Gboard deployment runs 30-plus on-device language models across 7-plus languages and 15-plus countries, training on text that never leaves the phone. That is federated learning working as advertised: the keyboard improves without Google collecting what you typed.
The problem is what travels in the updates. Gradients carry information about the data that produced them, and that information can be recovered. Zhu, Liu, and Han showed this in Deep Leakage from Gradients (NeurIPS 2019), demonstrating gradient inversion attacks that recover private training examples from shared model updates, with pixel-wise accurate image recovery and token-wise matching for text in their experiments. Federated learning reduced data movement. It did not eliminate leakage risk.
If the goal is to bound what participation can reveal, differential privacy is one common addition. Secure aggregation addresses a different risk by hiding individual client updates from the coordinating server. Gboard combines federated learning with formal differential privacy rather than relying on federation alone.
Note
Federated learning is frequently described as "private" because raw data stays at the source. That description is misleading. Without additional protection, federated updates can carry enough signal to reconstruct training records. DP-FL adds a formal differential-privacy guarantee rather than relying on federation alone. Federation on its own is a data-handling choice, not a privacy proof.
What Is Differential Privacy, and What Does Epsilon Actually Control?
Differential privacy is a mathematical definition that bounds how much an analysis can change when one privacy unit is added or removed. Many mechanisms achieve that guarantee by adding calibrated randomness. Epsilon is one visible parameter, but a meaningful guarantee also depends on the privacy unit, the DP variant and any additional parameters such as delta, plus composition, accounting, and implementation details.
Epsilon is described as the privacy budget in NVIDIA's glossary: lower values mean stronger privacy but more noise, higher values preserve accuracy at the cost of weaker guarantees. A common way differential privacy is applied during deep-learning training is DP-SGD, differentially private stochastic gradient descent: clip each per-sample gradient to a bounded size, add calibrated Gaussian noise, then aggregate. The clipping limits how much any one example can influence the model. The noise obscures whatever influence remains.
That budget is consumable. The mechanism is described in Tumult Analytics' documentation on privacy budgets: each query against a protected dataset spends part of the privacy budget. How those spends add up is standard differential-privacy theory, set out in Dwork and Roth's The Algorithmic Foundations of Differential Privacy: under basic composition, k queries each at parameter epsilon sum to a total privacy loss of k times epsilon, and advanced composition theorems give tighter bounds. You do not get unlimited questions. You get a budget, and you spend it.
The parameter choices therefore decide whether the guarantee is meaningful in practice. A peer-reviewed critique of privacy approaches in machine learning argues that the mathematical framing can lend an "objective veneer" that gets used to whitewash a project. Set the privacy parameters weakly enough and the guarantee can become nearly meaningless while still letting a team claim it satisfied differential privacy. The guarantee is real. Its practical strength is a design choice.
Note
A differential-privacy guarantee is only meaningful when you know the privacy parameters and the unit they protect. A very high epsilon, a loose delta, or unclear accounting can make a technically valid guarantee provide little practical protection. Reading "this system uses differential privacy" tells you almost nothing on its own: the privacy parameters, what they were measured over, and how they compose are the parts that carry the meaning. Concrete deployments make this real. Google reports a user-level epsilon of 1 for its Provably Private Insights system, but that is one deployment's choice for one use case, not a number to copy.
How Does Homomorphic Encryption Compute on Data It Never Decrypts?
Fully homomorphic encryption (FHE) lets a server run computations directly on encrypted data and return an encrypted result that only the data owner can decrypt. The server does the work without ever seeing the plaintext. It is one of the strongest privacy tools in the field, but the trade-off is performance.
The useful analogy is a locked glovebox with built-in gloves: a worker can reach in and manipulate what is inside without ever opening the box or removing the contents. The data owner holds the only key. The computation happens on the sealed contents, and only the owner can open the box to read the result. That is what FHE does mathematically: operate on ciphertext such that decrypting the output yields the same answer as computing on the plaintext would have.
The catch is the cost. Concrete ML, from Zama, converts scikit-learn and PyTorch models into FHE-compatible equivalents without requiring the user to work directly with cryptographic primitives, and its v1.9 release landed on April 10, 2025. But the project's own benchmarks show the overhead: a CIFAR10 image classification network runs at roughly 4 minutes per image under FHE. That is fine for some latency-tolerant inference, simpler models, and experimental encrypted fine-tuning. It is still not a practical path to full large-model pretraining or ordinary large-model training workloads. FHE today is a precision instrument for a narrow set of jobs, not a general-purpose privacy layer.
What Is Secure Multi-Party Computation in Machine Learning?
Secure multi-party computation (SMPC) lets several parties jointly compute a function over their combined private inputs without any party seeing the others' raw data. Each party's input stays secret. Only the agreed-upon result becomes known. SMPC can be built with techniques such as secret sharing, garbled circuits, oblivious transfer, and combinations of them. In secret-sharing protocols, private values are split into shares so that an individual share does not reveal the input. Garbled-circuit protocols work differently: they encode a computation so parties can evaluate it without revealing their private inputs.
The natural use case is cross-organization collaboration. Several hospitals want to train a model on their combined patient data, but none can legally share records with the others. SMPC lets them compute the joint model as if the data were pooled, while each hospital's records stay sealed within that hospital. SMPC overhead depends heavily on the protocol, security model, network conditions, number of parties, and the function being evaluated. Many protocols are communication-intensive, so performance has to be measured against the specific collaboration rather than ranked generically against differential privacy or FHE. That exact pattern for healthcare machine learning is covered in a 2025 WIREs Computational Statistics survey.
Can a Machine Learning Model Leak Its Training Data?
Yes. A trained model can betray its training data in several distinct ways: membership inference reveals whether a specific record was in the training set, model inversion and gradient leakage can reconstruct records, and large language models can memorize and emit chunks of their training data verbatim. These are not hypotheticals. They are demonstrated attacks, and they are the reason the techniques above exist.
The foundational result is membership inference. Shokri and colleagues, in Membership Inference Attacks Against Machine Learning Models (2017 IEEE S&P), showed that an attacker observing a model's prediction behavior can determine whether a given record was part of its training set. That sounds abstract until the training set is "patients with a particular diagnosis," at which point membership is the sensitive fact. Model inversion and the gradient-leakage attacks discussed earlier extend this from "was this record present" to "reconstruct the record."
The frontier is large language models, and it is where older PPML frameworks fit least well. Research on LLMs emitting training data documents that large models memorize portions of their training corpus and can be prompted to reproduce it, with extraction attacks recovering verbatim and near-verbatim training data. DP-SGD can be applied to private fine-tuning, but the accuracy and compute cost at large-model scale is severe, which is part of why Apple's 2026 PPML workshop ran an entire track on foundation models and privacy. The defenses that work cleanly for a logistic-regression classifier do not transfer for free to a model with billions of parameters.
PPML and Self-Hosted AI: What Local Inference Does and Doesn't Buy You
Self-hosting a model keeps your data on infrastructure you control. That is a real access-control and data-localization win: the data does not travel to a third party, and you decide who can reach the machine it runs on. It is not, however, privacy-preserving machine learning. Local inference does nothing by itself to stop membership inference against the model, and it does not stop a model from revealing what it memorized.
The two solve different halves of the problem, and conflating them is a common mistake in this space. Data localization governs who can reach the data: a perimeter question, answered by where the bytes live and who holds the keys to the room. PPML governs what the model itself can reveal, an information-leakage question answered by the four techniques above. Running a model on your own server is a strong answer to the first question and no answer at all to the second.
If the question you are weighing is whether to run the model yourself at all, the cost side of that decision is its own analysis: see Self-Hosting an Open-Weight LLM vs. an API: The Real Cost Math.
Build on a Linux VPS with root access, NVMe, and AMD EPYC power.
View Linux PlansFor a platform or infrastructure engineer, the operational reading is this: "it runs on our own server" can satisfy some data-localization and access-control requirements, but it does not by itself constrain what the model can reveal. If the model or its outputs are ever shared, whether across teams, with partners, or in a product, the perimeter you built around the hardware does not follow the model out the door. The architecture choices that actually move the guarantee are the PPML ones: differential privacy on outputs you publish, DP-FL for training across sites you cannot centralize, encryption-based computation where data cannot be exposed even to your own infrastructure. Google's Provably Private Insights deployment is instructive precisely because it combines controls, differential privacy, trusted execution environments, and confidential federated analytics, rather than relying on any single one. Localization is part of a real architecture. It is not the whole of one.
When Should You Use Which PPML Technique?
The selection logic follows the constraint, not the fashion. Use federated learning when the data cannot be centralized. Use differential privacy when you need a formal guarantee on what the model reveals. Use homomorphic encryption when computation must happen on data that is never decrypted and latency allows. Use secure multi-party computation when multiple parties must jointly compute without sharing their inputs.
The techniques also compose. DP-FL is the clearest example: choose the controls according to the guarantees the system needs rather than forcing the problem into one technique.
The trade-offs at a glance:
| Technique | Privacy guarantee | Computational overhead | Where is raw data processed? | Fit for LLM training |
|---|---|---|---|---|
| Federated learning | None without DP | Low | At each client | Partial |
| Differential privacy (DP-SGD) | Formal, set by epsilon and delta | Low to medium | Depends on the deployment | Yes, with accuracy and compute cost |
| Homomorphic encryption (FHE) | Formal confidentiality | Very high | Encrypted at the compute server | Experimental fine-tuning only, not full large-model training |
| Secure multi-party computation | Formal confidentiality | Protocol-dependent, often communication-bound | Each party retains its input | Partial |
Those characterizations are drawn from a March 2026 IoT-focused PPML survey, Zama's Concrete ML benchmarks, and the re-identification literature.
The table is only a starting point. Real systems often combine techniques: a cross-site training problem that also needs a formal privacy guarantee is usually a DP-FL problem, not a choice between federated learning and differential privacy. A reader who wants the decision structured more rigorously can work through the structured decision-support framework for developers published in late 2024.
On tooling, TensorFlow Federated provides an open-source framework for federated learning and computations on decentralized data. TensorFlow Privacy provides differentially private training utilities, Google's Differential Privacy libraries cover differentially private statistics and aggregation, and Concrete ML provides the FHE path. PySyft now focuses more broadly on privacy-preserving remote data science, where computations run against data held by the owner and only approved results are shared. Those are the names and what they do. The setup belongs to dedicated implementation guides, not here. The recurring lesson is that the math can work while the implementation still fails. The guarantee only matters if the system is designed around the right threat model and the privacy parameters match the risk being protected.
Frequently Asked Questions
What Does PPML Mean?
Privacy-preserving machine learning is an umbrella term for methods that reduce, restrict, or formally bound information exposure during machine learning. Major approaches include federated learning, differential privacy, homomorphic encryption, and secure multi-party computation, but they protect different assets and provide different kinds of guarantees.
Is Federated Learning Enough to Protect Privacy?
No. Federated learning keeps raw data at its source, but the parameter updates it shares can be inverted back into training records through gradient inversion attacks. On its own it provides no formal privacy guarantee. Differential privacy can add a formal leakage bound, producing the combination usually called DP-FL.
What Epsilon Value Should I Use for Differential Privacy?
There is no universal value. Epsilon is one of the main parameters in the privacy-accuracy trade-off: lower values generally mean stronger privacy and more noise, while higher values generally mean weaker privacy and less noise. The right setting depends on the sensitivity of the data and the risk you can accept. There is no universal cutoff that makes an epsilon value "safe." Evaluate epsilon together with the privacy unit, the DP variant and any additional parameters such as delta, the composition method, and the system's threat model.
What Is the Difference Between PPML and Anonymization?
Anonymization removes identifiers from a dataset, but anonymized records can be re-identified by linking them to auxiliary data from other sources. Some PPML techniques provide formal guarantees that ordinary anonymization does not. Differential privacy can bound how much an individual's data affects a released result, while FHE and SMPC provide different forms of cryptographic confidentiality.
Can You Extract Training Data From a Machine Learning Model?
Yes. Membership inference attacks reveal whether a specific record was in the training set, model inversion and gradient leakage can reconstruct records, and large language models can memorize and emit training data verbatim. These are demonstrated attacks documented in the security literature, not hypothetical risks.
Does Self-Hosting a Model Guarantee Data Privacy?
No. Self-hosting keeps data on infrastructure you control, which is access control and data localization, a real win for governing who can reach the data. It is not privacy-preserving machine learning and does not stop membership inference or memorization-based leakage. It pairs well with PPML techniques but does not replace them.
What Open-Source Tools Exist for Privacy-Preserving Machine Learning?
Several open-source tools cover different parts of PPML. TensorFlow Federated supports federated learning and computations over decentralized data, TensorFlow Privacy provides differentially private training utilities, and Concrete ML covers machine learning with FHE. PySyft now focuses on privacy-preserving remote data science, where computations run against data controlled by its owner and only approved results are shared.
