The Question
Your organization wants to train a machine learning model on sensitive data — patient records, financial transaction history, customer behavioral data — that you cannot simply aggregate into a central training environment without violating privacy obligations or data residency requirements. The ML team is proposing one of several privacy-preserving approaches: federated learning, synthetic data generation, or homomorphic encryption. Each technique has been presented with a level of enthusiasm that reflects its recent research profile rather than its current production maturity. The question the CISO, CDO, and ML leadership need to answer is: which of these techniques is appropriate for our specific use case, at what cost, and what does it actually protect?
The honest assessment is that all three techniques are real, all three are in production somewhere, and all three have specific operational constraints and tradeoffs that are frequently omitted from the sales pitch and the research paper abstract. Federated learning involves significant communication and convergence complexity. Synthetic data requires training a generative model on real data to produce the synthetic data, which introduces a bootstrapping problem. Homomorphic encryption for neural network training is not yet computationally feasible at enterprise scale. Understanding these constraints before selecting an approach is the difference between a production deployment and an expensive proof of concept that cannot scale.
Privacy-preserving ML techniques are not theoretical — they are in production at Google, Apple, and major healthcare networks — but each has specific tradeoffs that must be evaluated against the actual use case, and no single technique solves the full AI data privacy problem.
Why This Matters Now
Three developments have elevated privacy-preserving ML from research topic to operational priority for enterprise AI programs in the past two years.
First, a consortium of European healthcare networks announced in late 2024 that they had successfully trained a clinical diagnostic AI across twelve hospital systems in seven EU member states using federated learning with differential privacy, without centralizing patient data from any of the participating institutions. The consortium published accuracy benchmarks showing that the federated model matched the performance of a centrally-trained baseline on held-out test sets, with a measurable but acceptable accuracy penalty from the DP component. This was the first large-scale demonstration that FL + DP could deliver clinically meaningful model quality on sensitive healthcare data at a multi-institution scale that would be legally impossible under a centralized data sharing model.
Second, the synthetic data market expanded materially in 2024 and 2025, with Gretel AI, Mostly AI, and Tonic AI all securing significant enterprise contracts and publishing case studies from financial services, healthcare, and telecommunications organizations. The practical use case that drove most of this adoption was not model training but data sharing: organizations that needed to share sensitive datasets with development teams, third-party vendors, or regulatory bodies found that high-quality synthetic data satisfied the use case without the legal overhead of data sharing agreements.
Third, Microsoft and IBM published benchmark results in 2025 showing that homomorphic encryption inference — running ML model inference on encrypted data, with the inference provider never seeing the unencrypted input — had reached latency profiles acceptable for non-interactive use cases. Healthcare applications involving medical imaging analysis where the imaging data cannot be decrypted outside the originating institution are the target deployment. Training under HE remains infeasible, but inference under HE is becoming a production option for specific regulated use cases.
What the CURVE™ Data Shows
The 2026 Stackcurve Data Security for AI CURVE™ Report evaluated privacy-preserving ML tools and platforms across federated learning frameworks, synthetic data generation platforms, and homomorphic encryption libraries. The evaluation assessed production readiness, enterprise integration, and the accuracy/privacy tradeoff documentation each platform provides.
TensorFlow Federated and PyTorch Opacus are the primary production FL + DP frameworks, both open-source and backed by substantial engineering investment. Opacus has the more active enterprise adoption trajectory due to PyTorch's dominant position in enterprise ML. PySyft (OpenMined) provides the strongest privacy-first federated learning framework but has a steeper operational learning curve. FATE (Federated AI Technology Enabler) is the dominant framework for financial services consortium training in Asia-Pacific and has growing adoption in Western markets. On synthetic data, Gretel AI leads on enterprise platform features and compliance documentation, Mostly AI leads on tabular data fidelity, and Tonic AI has the strongest engineering workflow integrations. For HE inference, Microsoft SEAL and IBM HElib are the primary production libraries, both open-source, with commercial deployment support from their respective enterprise platforms.
No commercial vendor provides a single platform covering all three techniques with production-grade tooling. Organizations implementing privacy-preserving ML are doing so with a combination of open-source frameworks and, in some cases, managed services built on top of them.
The full vendor rankings are in the 2026 Stackcurve Data Security for AI CURVE™ Report — free to download.
The Gap Most Buyers Miss
Each privacy-preserving ML technique has a specific set of operational realities that are consistently underrepresented in vendor and research presentations. Understanding them is necessary to select the right technique and plan for the actual implementation cost.
Federated Learning: real tradeoffs that the architecture diagrams omit.
The federated learning architecture — train locally, share gradients, aggregate centrally — is straightforward to diagram and genuinely more complex to operate at scale. The operational challenges are:
Communication overhead is significant. A standard federated training run involves many rounds of gradient exchange between participants and the aggregator. For large models, gradient updates are large, and the number of rounds required for convergence can be in the hundreds. Communication cost between geographically distributed participants is a real infrastructure expense that grows with model size.
Non-IID data is a convergence problem. Federated training assumes that each participant's data is drawn from the same distribution as the global dataset. In practice, different participants have different data distributions — different patient populations, different geographic markets, different customer demographics. Non-IID data makes convergence slower, less stable, and harder to tune. There is active research on non-IID FL training, but it remains an unsolved operational challenge for many real-world distributions.
Gradient inversion attacks require DP. The gradient updates shared in federated training can be used to reconstruct training records through gradient inversion — a documented attack class. FL without differential privacy does not prevent this attack. Production FL deployments at organizations with genuine privacy requirements (healthcare, financial services) use FL + DP, accepting the combined accuracy penalty. Organizations evaluating FL as a privacy measure without also evaluating DP are not solving the full gradient privacy problem.
Synthetic Data: the bootstrapping problem and membership inference.
The core promise of synthetic data — generate artificial data with the same statistical properties as real data, use it in place of real data — is genuine. High-quality synthetic data has become a production tool for development testing, regulatory data sharing, and model augmentation. The tradeoffs are:
Generating high-quality synthetic data requires training a generative model on the real data. This is the bootstrapping problem. To create synthetic patient records that are statistically indistinguishable from real patient records, you must train a generative model (a VAE, GAN, or diffusion model) on real patient records. The privacy risk in synthetic data generation is concentrated at the generative model training step, not at the data sharing step. If the generative model is trained without privacy controls, the synthetic data may still leak information about individual records.
Membership inference on synthetic data generators is possible. Researchers have demonstrated that it is possible, in some cases, to determine whether a specific individual's record was in the training data for the generative model by querying the generator. This attack surface is smaller than for discriminative models, but it is not zero. High-stakes applications should combine synthetic data generation with DP training of the generator.
Synthetic data quality for training discriminative models is use-case dependent. Synthetic data is well-suited for development and testing, for sharing datasets in compliance with data sharing restrictions, and for augmenting limited labeled data. It is less well-suited as a direct replacement for real training data in high-accuracy, high-stakes models — the model trained on synthetic data will learn the patterns of the generative model, not the patterns of the real data. This distinction matters for clinical AI, fraud detection, and other applications where model accuracy on real-world distributions is critical.
Homomorphic Encryption: inference is practical, training is not.
The current state of HE for ML is important to state precisely: inference under HE is becoming practical for specific use cases. Training under HE is not computationally feasible at any meaningful scale. This distinction is frequently blurred in vendor presentations and research summaries.
HE inference allows a party to send encrypted data to an inference service, receive an encrypted result, and decrypt it locally — with the inference service having no access to the unencrypted input or output at any point. This is a genuine and valuable privacy property for use cases where the sensitivity is in the input data, not the model. Medical imaging analysis, genomic screening, and financial risk assessment on sensitive records are the target applications.
The latency and computational overhead of HE inference is significant — currently 100x to 1000x the latency of plaintext inference, depending on the model architecture and the encryption parameters. This rules out HE for interactive applications and makes it practical only for batch inference or asynchronous workflows where latency is not a constraint. Organizations evaluating HE should assess whether their use case fits within these constraints before treating HE as a production option.
Questions Your Buying Team Should Be Asking
1. For our specific use case, which privacy-preserving ML technique provides the right tradeoff between privacy protection, model accuracy, and operational complexity — and what does the evidence base look like for that technique in our industry vertical?
This is the starting question because the right technique is genuinely use-case dependent. Federated learning requires distributed data sources and multi-party coordination — it is not appropriate for organizations that can centralize training data. Synthetic data is appropriate for development, testing, and data sharing, but requires careful evaluation of accuracy for high-stakes discriminative model training. HE is appropriate only for inference, not training, and only for batch or asynchronous workloads. Ask practitioners to map your specific use case to the technique before committing to an implementation approach.
2. For federated learning specifically: how many communication rounds does your implementation require for convergence on our model architecture, and what is the communication overhead per round at our expected number of participants?
These numbers determine whether FL is operationally viable for your deployment. A federated training run that requires 500 communication rounds with 50 participants generating 1GB gradient updates per round has a communication cost that may exceed the infrastructure budget for the AI program. Ask for benchmark data on convergence behavior under non-IID data conditions similar to the actual distribution differences you expect across your federated participants.
3. For synthetic data: what membership inference risk does your generative model training process introduce, and does your platform support differentially private generative model training to bound that risk?
The synthetic data vendors who have thought seriously about the full privacy chain — not just the data sharing step, but the generative model training step — will have a clear answer to this question. Vendors who present synthetic data as inherently privacy-safe without addressing the generative model training risk are underselling the attack surface. Ask for documentation of the membership inference resistance properties of their generative approach and whether DP training is available for the generative model.
4. For homomorphic encryption inference: what is the latency profile for our model architecture under HE, what is the accuracy penalty from the approximations required by HE-compatible activation functions, and what is the integration path with our inference infrastructure?
HE for neural networks typically requires replacing non-polynomial activation functions (ReLU) with polynomial approximations that are compatible with HE operations. This introduces an accuracy penalty on top of the computational overhead. Ask for benchmark data on your specific model architecture — not generic benchmark data — and for a description of the integration path for your inference infrastructure. Organizations that find these questions difficult to answer during vendor conversations should treat HE as an emerging capability to monitor rather than a production option to deploy.
5. How do privacy-preserving ML techniques interact with our existing data governance and access control requirements — specifically, what data governance documentation does each technique generate that can be used in regulatory conformity assessments?
Privacy-preserving ML techniques do not substitute for data governance — they address specific risk vectors within a broader governance framework. Ask vendors and practitioners to describe what governance artifacts each technique generates: FL training generates provenance records of which participants contributed gradients to which model versions. Synthetic data generation generates a record of the source data and generative process. HE inference generates an audit trail of encrypted inputs and outputs. Understanding how these artifacts integrate with your existing governance documentation is essential for compliance use cases.
The Stackcurve Take
The honest evaluation conclusion for privacy-preserving ML is that all three primary techniques are production-ready in specific, bounded contexts and not production-ready in others. Federated learning is in production at Google, Apple, and major healthcare consortiums — but these deployments have significant engineering investment behind them, and the communication and convergence challenges are real constraints that make FL substantially more complex than centralized training. Synthetic data is in production across financial services, healthcare, and technology organizations for development, testing, and data sharing — but the bootstrapping problem and membership inference risk on the generator require attention in high-stakes applications. Homomorphic encryption for inference is approaching practical latency profiles for batch use cases — but it is not a training-phase tool, and the computational overhead rules it out for interactive applications.
The organizations that have successfully deployed these techniques share a common characteristic: they selected the technique based on a rigorous analysis of their specific use case requirements, not based on the technique's research profile. Federated learning is not valuable because it is architecturally elegant; it is valuable when training data legally cannot be centralized and when the operational overhead of the FL deployment is justified by the privacy benefit. Synthetic data is not valuable because it is a clever substitute for real data; it is valuable when the use case genuinely requires sharing or using data that cannot be shared or used in its original form.
No single privacy-preserving ML technique solves the full AI data privacy problem. Organizations building serious AI data security programs should evaluate all three techniques against their specific use cases, plan for the operational complexity each technique introduces, and combine them with conventional data governance controls — data classification, access control, audit logging — rather than treating them as substitutes for governance.
The 2026 Stackcurve Data Security for AI CURVE™ Report covers federated learning frameworks, synthetic data platforms, and homomorphic encryption libraries with production readiness assessments and use-case fit guidance. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.