Part 6 (final) of our series on Privacy Enhancing Technologies
Five posts in, here’s the honest summary: there is no single best privacy enhancing technology. Each one solves a different problem, costs a different amount, and needs a different level of engineering sophistication. That’s not a cop-out. It’s the actual, useful answer, and this post is about making it concrete.
If you remember nothing else from this series, remember this: the right question is never “which PET is best?” It’s “what am I actually trying to protect, and what can my team realistically build?”
Quick Recap: What Each One Actually Needs
| Technology | What it needs from you | Who it needs to trust |
|---|---|---|
| Anonymization / pseudonymization (Part 1) | Basic process discipline, no special engineering | Nothing exotic; this is table stakes |
| Differential privacy (Part 2) | A real engineering pipeline, ongoing | Math, but someone has to set the parameters correctly |
| Synthetic data (Part 3) | Generation plus leakage testing (the testing is not optional) | Whoever built and tested the generator |
| Federated learning (Part 4) | Multiple cooperating institutions, each with their own infrastructure | Every participating institution |
| MPC (Part 5) | Multiple cooperating institutions agreeing on one exact question | Math, split across all parties |
| FHE (Part 5) | Specialist cryptography talent | Math, all in one place |
| TEE (Part 5) | Off-the-shelf cloud product, no custom cryptography | The chip manufacturer’s hardware |
If You’re Not a Tech Giant: Start Here
Start with anonymization and pseudonymization
Step one, always, no exceptions: Part 1’s anonymization basics. If you don’t know whether your “anonymized” data would actually hold up under GDPR versus HIPAA versus CCPA, nothing else in this series matters yet. This costs no special engineering. It’s a process and a legal-standards question, and it’s where every single client conversation should start.
Consider synthetic data as an achievable advanced option
The most achievable “advanced” option today: synthetic data (Part 3), specifically because of something that’s changed recently. Most companies now have an enterprise LLM sitting on their desk, which makes generation itself genuinely easy. The catch, which we said plainly in that post, is that generation is only half the job. Skipping the leakage-testing half is how “privacy-preserving” quietly becomes privacy theater with better marketing.
Use TEEs when you need compute isolation
If you just need compute isolation, not new cryptography: TEEs (Part 5). This is the cheapest and fastest of the three frontier technologies, and it’s already a standard product from every major cloud provider. You don’t need to invent anything; you’re renting a security property that already exists.
When You May Need a Specialist or Partner Institution
If none of the above fits, you probably need a specialist, or a partner institution:
When should you use differential privacy?
Need a mathematical guarantee, not just good practice? Differential privacy (Part 2), but budget for real engineering, not a checkbox.
When should you use MPC?
Need to collaborate with another organization that doesn’t trust you with their raw data? MPC (Part 5), but you need that other organization on board too, doing real work on their end.
When should you use FHE?
Need the absolute strongest guarantee, no matter the cost? FHE (Part 5), but this needs cryptography specialists most companies don’t have in-house.
When should you use federated learning?
Are you actually a hospital network, research consortium, or similarly resourced multi-institution group? Federated learning (Part 4) might be worth the infrastructure investment. If you’re a single company, it almost certainly isn’t yet.
The One Idea Worth Keeping
Every technology in this series trades off privacy strength against cost, speed, and complexity. None of them is free, and none of them is magic. The companies that get burned aren’t the ones that pick the “wrong” PET. They’re the ones that assume a PET solves the problem completely, stop asking questions, and skip the testing and legal review that turns a promising technology into an actual, defensible privacy practice.
That’s the whole series in one sentence: know what you’re actually protecting, know what your team can actually build, and don’t mistake the name of a technology for a guarantee.
Get Help Choosing a Privacy-Enhancing Technology
If you want help figuring out where your company actually falls on this list, that’s what we’re here for. General Legal has attorneys who work on data privacy and AI governance day-to-day, and we’re glad to talk through your specific situation.
This post is for general informational purposes and does not constitute legal advice. Which of these technologies, if any, satisfies your specific regulatory obligations depends entirely on your data, your architecture, and your jurisdiction. Talk to us before relying on any of them as a compliance answer.
- There is no single best privacy-enhancing technology (PET); each one solves a different problem at a different cost and engineering difficulty, so the right question is what you're protecting and what your team can realistically build.
- Anonymization and pseudonymization should be step one for almost every company, since they require no special engineering, just process discipline and knowing which legal standard applies.
- Synthetic data is the most achievable "advanced" option today because enterprise LLMs make generation easy, but the leakage-testing half of the job is not optional and is often skipped.
- TEEs (trusted execution environments) are the cheapest and fastest of the frontier technologies when you just need compute isolation, since they're already a standard product from major cloud providers.
- Differential privacy, MPC, and FHE each require real engineering investment or cooperating institutions, and federated learning only makes sense for genuinely multi-institution groups like hospital networks or research consortia.
- Companies get burned not by picking the "wrong" PET, but by assuming any one PET solves the problem completely and skipping the testing and legal review that make it a defensible practice.
| The series' conclusion | There's no single best privacy-enhancing technology; the right question is what you're protecting and what your team can realistically build. |
|---|---|
| Start here | Anonymization and pseudonymization require no special engineering and should be the first step for every company, before anything else in the series matters. |
| Best achievable advanced option | Synthetic data is now easy to generate thanks to enterprise LLMs, but skipping the leakage-testing half turns it into privacy theater. |
| Cheapest frontier option | TEEs need only an off-the-shelf cloud product and no custom cryptography, making them the fastest route to compute isolation. |
| When to go further | Differential privacy needs real engineering investment for a mathematical guarantee; MPC and federated learning require cooperating institutions; FHE needs specialist cryptography talent. |
| Federated learning's fit | Only genuinely multi-institution groups, like hospital networks or research consortia, should consider federated learning; single companies almost certainly shouldn't. |
| The common failure mode | Companies get burned not by choosing the wrong PET, but by assuming a PET solves privacy completely and skipping the testing and legal review that make it defensible. |
| Where to get help | General Legal's attorneys work on data privacy and AI governance day-to-day and can help evaluate which PET fits a company's specific situation. |
Is there a single "best" privacy-enhancing technology?
No. Each technology solves a different problem at a different cost and engineering difficulty; the right approach depends on what you're protecting and what your team can realistically build, not which technology has the strongest reputation.
What should a company with no special privacy engineering do first?
Start with anonymization and pseudonymization basics. This requires no special engineering, just process discipline and knowing whether your data would hold up under GDPR, HIPAA, or CCPA specifically.
Is synthetic data a realistic option for a typical company today?
Yes, and increasingly so, since most companies now have an enterprise LLM that makes generation easy. But leakage testing is not optional; skipping it turns synthetic data into privacy theater with better marketing.
When does a company actually need MPC, FHE, or federated learning?
MPC fits when you need to collaborate with another organization that won't share raw data with you. FHE fits when you need the strongest possible guarantee regardless of cost and have cryptography specialists. Federated learning generally only makes sense for actual multi-institution groups like hospital networks, not single companies.
What's the most common mistake companies make when adopting a PET?
Assuming the technology solves the privacy problem completely, then skipping the testing and legal review needed to turn it into an actual, defensible practice.
- Synthetic Data: The Most Exciting Privacy-Enhancing Technology, and the Most OversoldSynthetic doesn't mean private. Generative models can leak real records—here's what testing catches.
- 7 Best Contract Review AI Tools for Legal Teams [Comparison]Explore the best contract review AI tools and find the right solution to review agreements faster, and reduce legal risks.
- How to Use AI in Law: 10 Practical Examples for Legal TeamsLearn how to use AI in law so you can improve legal workflows, reduce repetitive work, support better research, and drafting.