Privacy-Preserving AI Techniques: Federated Learning, Differential Privacy, TEEs, and Synthetic Data

Privacy-preserving AI is not one technology; it is four deployable technique families plus one that is still mostly in the lab. Differential privacy protects individuals in the outputs. Federated learning keeps raw data where it lives. Trusted execution environments protect data while it is being computed on. Synthetic data replaces the sensitive dataset outright. Homomorphic encryption — computing on ciphertext — remains research-grade for deep learning. They are not interchangeable, and picking among them is a topology and regulation question before it is a cryptography question.

The threat these techniques mitigate is concrete, not hypothetical. Carlini et al. demonstrated a training-data extraction attack against GPT-2 that recovered "hundreds of verbatim text sequences from the model's training data" — including personally identifiable information — and warned that "larger models are more vulnerable than smaller models"^[1]. Models memorize, and what they memorize can be pulled back out. That attack surface, and the model-theft and supply-chain risks around it, are covered in depth in /guides/ai-model-security-guide; this guide maps the techniques that shrink it before and during training and inference.

1. The map: five families, one question each

The fastest way to cut through vendor noise in this space is to ask, for each technique, exactly what it protects and from whom. Differential privacy protects individuals from being inferred out of aggregate outputs — releases, analytics, trained models. Federated learning protects raw data from ever crossing an organizational or jurisdictional boundary. A TEE protects data in use from the infrastructure it runs on — the cloud operator, the hypervisor, a co-tenant. Synthetic data protects the original records by not using them downstream at all. Homomorphic encryption protects data from the party doing the computation. Those are five different attackers, which is why mature deployments combine techniques rather than choose one.

2. Differential privacy: the only one with a mathematical guarantee

Differential privacy is the lone member of this list that offers a provable, quantified guarantee rather than an architectural assurance. NIST SP 800-226 defines it as "a mathematical framework that quantifies privacy loss to entities when their data appears in a dataset"^[5]. In practice: calibrated noise is added to computations so that any single individual's presence or absence changes the output distribution by at most a bounded amount, tracked as a privacy budget (epsilon).

For machine learning specifically, the foundational result is DP-SGD. Abadi et al. (arXiv:1607.00133) set the problem plainly: "the training of models requires large, representative datasets, which may be crowdsourced and contain sensitive information. The models should not expose private information in these datasets." Their contribution was "new algorithmic techniques for learning and a refined analysis of privacy costs within the framework of differential privacy," demonstrating that one can "train deep neural networks with non-convex objectives, under a modest privacy budget, and at a manageable cost in software complexity, training efficiency, and model quality"^[14]. Gradient clipping plus noise plus tight privacy accounting is now the standard recipe, implemented in mainstream open-source libraries.

The deployment proof point is the 2020 US Census. The Census Bureau states that "modern computers and today's data-rich world have rendered the Census Bureau's traditional confidentiality protection methods obsolete," and that its 2020 disclosure avoidance system — "designed to withstand modern re-identification threats" — "is based on a framework for assessing privacy risk known as differential privacy," which it calls "the only solution that can respond to this threat while maximizing the availability and utility of published census data"^[4]. That is a national statistical release, under legal confidentiality mandate, betting on DP. The enterprise translation: DP is strongest exactly where the Census used it — when you publish aggregates, run analytics over individual-level data, or train models whose outputs the outside world can query.

3. Federated learning: move the training, not the data

Federated learning was named and formalized by McMahan et al. in 2016 (arXiv:1602.05629) as an approach that "leaves the training data distributed on the mobile devices, and learns a shared model by aggregating locally-computed updates." Their federated averaging algorithm — "a practical method for the federated learning of deep networks based on iterative model averaging" — was shown to be robust to "unbalanced and non-IID data distributions" and delivered "a reduction in required communication rounds by 10-100x as compared to synchronized stochastic gradient descent"^[2].

The paper's setting was phones; the enterprise setting is silos. Cross-silo federation — hospitals training a shared diagnostic model, banks pooling fraud signal, subsidiaries in different jurisdictions training against locally resident data — is where the technique earns its complexity. The decision trigger is topological: choose federated learning when the data genuinely cannot move, whether for data-residency law, sector regulation, contractual restriction, or because the counterparties are competitors who will share model improvements but never records.

Be clear-eyed about what federation alone does not guarantee. Zhu et al. showed in Deep Leakage from Gradients that "it is possible to obtain the private training data from the publicly shared gradients" — recovering training inputs at pixel and token level from exactly the updates federated systems exchange^[8]. Federated learning is a data-minimization architecture, not a privacy proof. Production deployments pair it with differential privacy on the updates, secure aggregation, or a TEE around the aggregator — which is why the leading frameworks build those in.

On implementation paths, two first-party open-source frameworks dominate. Flower describes itself as "a framework for building federated AI systems," designed so that "Flower can be used with any machine learning framework" — its README lists PyTorch, TensorFlow, Hugging Face Transformers, scikit-learn, JAX, XGBoost, and more^[6]. NVIDIA FLARE is "a domain-agnostic, open-source, extensible Python SDK that allows researchers and data scientists to adapt existing ML/DL workflows to a federated paradigm," with built-in algorithms (FedAvg, FedProx, FedOpt, Scaffold), support for "both horizontal and vertical federated learning," and — critically for the leakage problem above — "privacy preservation with differential privacy, homomorphic encryption, private set intersection (PSI)" plus "security enforcement through federated authorization and privacy policy"^[7].

4. Confidential computing and TEEs: the pragmatic near-term winner

If differential privacy has the strongest math, trusted execution environments have the strongest deployment story. The Confidential Computing Consortium definition, as adopted by Microsoft, is that "Confidential Computing protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment"^[15]. The pragmatic appeal is that, unlike DP or federation, a TEE changes the trust boundary rather than the workload: no retraining, no noise, no accuracy loss. Azure's confidential VMs "create a hardware-enforced boundary between your application and the virtualization stack," and Microsoft states "you can use them for cloud migrations without modifying your code"^[10].

The three platform options cover different isolation granularities. AWS Nitro Enclaves carve an isolated environment out of an EC2 instance: "enclaves are fully isolated virtual machines, hardened, and highly constrained," with "no persistent storage, no interactive access, and no external networking," such that "even a root user or an admin user on the instance will not be able to access or SSH into the enclave" — with cryptographic attestation to "verify the enclave's identity and that only authorized code is running"^[9]. That deliberate austerity fits key custody and narrow, high-assurance inference paths more than full training pipelines. Azure's confidential VMs take the opposite shape — whole-VM isolation on "AMD SEV-SNP, or Intel TDX enabled processors," with a dedicated virtual TPM and boot-time attestation that will "prevent the VM from starting" if the platform's isolation settings are missing^[10] — which is the lift-and-shift option for existing regulated workloads.

The piece that changed the calculus for AI specifically is GPU confidential computing. CPU-only enclaves were a poor match for deep learning; NVIDIA's Hopper generation closed the gap. NVIDIA's trusted-computing documentation states: "Confidential computing protects a user's code and data from even the owner of the computer or cloud service, and Hopper delivers the required GPU feature set to enable accelerated confidential computing," with the H100 introducing "several new hardware features to ensure the security and integrity of both the data and algorithms operating within the GPU"^[11]. This is already consumable as cloud infrastructure: Azure's confidential VM size list includes an "NVIDIA H100 Tensor Core GPU powered NCCadsH100v5-series"^[10]. For the first time, training and serving on sensitive data inside an attested hardware boundary — CPU and GPU — is a provisioning decision, not a research project.

What TEEs do not do matters just as much. A TEE protects the computation from the infrastructure; it does nothing about what the computation itself does. A model trained in an enclave still memorizes training data, and its outputs can still leak individuals — the extraction attack from the opening of this guide works regardless of where the model ran^[1]. TEEs also relocate trust rather than eliminate it: you are now trusting the silicon vendor's implementation and, above all, your own attestation discipline.

5. Homomorphic encryption: honest status, still research-grade for deep learning

Homomorphic encryption computes directly on ciphertext, so the compute provider never sees the data at all — the strongest trust model on this list, and the least deployable for AI. The most candid assessment comes from Microsoft's own SEAL library, the most widely used HE implementation. Its documentation states plainly: "Homomorphic encryption also comes with a substantial performance overhead, so computations that are already very costly to perform on unencrypted data are likely to be infeasible on encrypted data." Ciphertext is "many times larger than unencrypted data," and operations "such as encrypted comparison, sorting, or regular expressions, are in most cases not feasible to evaluate on encrypted data." Microsoft's guidance: "only specific privacy-critical cloud computation parts of programs should be implemented" with HE^[13].

For machine learning, the relevant scheme is CKKS, which per SEAL "allows additions and multiplications on encrypted real or complex numbers, but yields only approximate results"^[13] — a reasonable fit for machine learning, which tolerates approximation by nature. Feasibility for neural inference was established a decade ago: CryptoNets (ICML 2016) ran encrypted MNIST inference at "99% accuracy and can make around 59000 predictions per hour on a single PC"^[3]. The honest read on the decade since: the gap between an MNIST-scale demonstration and a transformer is vast, and no first-party source we can cite claims production HE inference for deep learning at enterprise scale. Where a vendor claims otherwise, ask for the latency, the model size, and the scheme parameters in writing.

The enterprise posture: keep HE on the watch list, use it today only for narrow arithmetic workloads — private scoring of small models, encrypted aggregation inside a federated pipeline (NVIDIA FLARE ships it as one of its privacy options^[7]), private set intersection between partners — and do not put it on the critical path of an AI roadmap. If your requirement is "the provider must not see the data, this year," the answer is a TEE, not HE.

6. Synthetic data: useful tool, weakest guarantee

Synthetic data — generating artificial records that preserve the statistical shape of a sensitive dataset — is the most seductive of the four families because it promises to make the privacy problem disappear: no real records, no privacy obligation. The research record says otherwise. Stadler, Oprisanu, and Troncoso's systematic evaluation (arXiv:2011.07018) found that "synthetic data either does not prevent inference attacks or does not retain data utility," that "the privacy-utility tradeoff of synthetic data publishing is hard to predict," and that the result is "highly variable privacy gain and unpredictable utility loss"^[12].

The mechanism behind that finding is membership leakage: a generative model trained on sensitive records can emit records close enough to real ones — especially outliers — that an attacker can infer who was in the training set. The same memorization dynamic that lets an LLM regurgitate training text^[1] operates in tabular and image generators. Two consequences for practice. First, synthetic data is a governed derived dataset, not a free-of-obligation one: it needs a per-release privacy evaluation, and your legal team should not treat 'synthetic' as a synonym for 'anonymous.' Second, the credible way to harden it is to train the generator itself under differential privacy — at which point you inherit DP's utility cost, and the techniques compose rather than compete.

7. Matching technique to use case

Most real deployments are combinations, keyed to where the data sits and who must not see it. The table below maps the recurring enterprise scenarios to a primary technique and the pairing that covers its weak point.

8. Honest objections: when the complexity is not worth it

The strongest argument against this entire toolbox is that most enterprises have a cheaper privacy problem. If sensitive data is leaking through an over-permissive RAG index, a retention policy nobody enforces, or service accounts with blanket read access, then federated learning is a distraction: you would be adding distributed-systems complexity on top of an access-control failure. The unglamorous controls — data classification, query-time authorization, retrieval-layer permission trimming — deliver more risk reduction per engineering hour for a typical AI deployment, and they are prerequisites anyway (we cover that layer in /guides/securing-enterprise-rag). Privacy-preserving techniques restrict what a system can leak in principle; most incidents come from what it was allowed to do in practice.

Each family also carries an objection worth steelmanning. Differential privacy's utility cost is real and falls hardest on small cohorts — the noise that hides one person also hides your smallest, often most decision-relevant, segments; the Census Bureau accepted that tradeoff under a legal mandate most enterprises do not have^[4]. Federated learning does not remove the need for lawyers: a federation is a multi-party agreement about model ownership, liability, and update semantics, and the coordination cost frequently exceeds the engineering cost. TEEs concentrate trust in one or two silicon vendors and stand or fall on attestation practices your team must actually operate. And synthetic data's guarantee is, per the strongest available evaluation, "highly variable" and "hard to predict"^[12].

The rejoinder is that when the driver is real, these are not optional. If regulation or data-residency law prohibits centralizing the data, federation is the only architecture that trains on it at all. If a regulator or counterparty requires that the cloud operator be provably unable to read data in use, only an attested TEE makes that claim — Microsoft's phrasing, "Microsoft can't access unencrypted customer data," is precisely the sentence a compliance team needs to be able to write^[15]. The decision is not whether these techniques are costly — they are — but whether your constraint can be satisfied any other way.

9. The decision framework: driver × topology × maturity tolerance

Run the three axes in order and the portfolio mostly assembles itself. A regulated US insurer doing cloud inference on claims data lands on confidential VMs plus attestation, DP on any published analytics, and synthetic data for its dev tier — no federation needed, because the topology is single-party. A hospital consortium lands on federated learning under NVIDIA FLARE or Flower with DP on updates and a TEE-hosted aggregator — because the topology, not preference, forces it. Neither should be piloting homomorphic encryption except as research. The failure mode this framework prevents is the common one: choosing the technique by novelty and then hunting for a use case.