You‘ve unknowingly used apps that use them. Google‘s using one to gather statistics about how Chrome is used. Apple‘s working on one to improve autocorrect without actually reading anything you type. These aren‘t just corporate privacy spin. They‘re real systems that are quietly running under your everyday apps, and collectively called Privacy-Enhancing Technologies (PETs).
This isn‘t a post about cookie banners or VPNs. PETs are a deeper category techniques and systems designed to allow data to be used without revealing the individual behind it. They‘re timely today as AI systems learn from ever more personal data, regulators clamp down, and data leaks continue.
If you like tech, AI, or simply care what actually happens to your data, this breakdown is highly recommended.
Table of Contents
What Privacy-Enhancing Technologies Actually Are
Not Just “Privacy Settings”
One of the more common assumptions around privacy tech is that it equates to encryption or disabling ad tracking. PETs are more precise and more interesting.
They are technologies and approaches that seek to reduce the amount of personal data that is used in the first place while still enabling the systems to provide a useful service. According to the UK s Information Commissioner s Office they are, Technology that “embodies core data protection principles by reducing the amount of personal data that is processed and by maximizing the level of security applied to the data”.
Putting it another way: replacing a lock on the door of room X with a magnetic card reader to keep sure that no one infiltrates X, PETs is numerous so X is not need to keep naught delicacies.
They fall into two broad camps:
Soft-privacy tools These work through policy, access controls, and statistical techniques. Differential privacy belongs here.
Hard-privacy tools This category makes use of cryptographic techniques that enable the processing of data without it being readable by the party doing the processing (e. G. Homomorphic encryption or secure multi-party computation).
The Technologies Actually Doing the Work
Differential Privacy – Math That Adds Intentional Noise
The most common example of a PET used today is Differential Privacy (DP). Developed by Cynthia Dwork in 2006, DP is a method where a dataset is ‘queried, and a small amount of carefully scaled random noise (a, b,) is added to the output’. This statistically allows for good data utility, but possesses a provable bound on how much influence an individual‘s data can have on the output.
I‘ve played around with some DP implementations using Google‘s TensorFlow Privacy library, and the amazing thing is how the value of controls the balance. Keep it low, and you get better privacy with noisier results. Keep it high, and you get results closer to the original data. Tuning the right value for a specific use case is actually quite difficult.
Apple employsDP to learn things such as the most popularEmoji used. TheUS Census Bureau transitioned to DP for the 2020 census when they discovered that the traditional anonymization left data vulnerable to reconstruction attacks. In 2025NIST published the first formal framework for formally evaluating a DP guarantee, marking where the standards conversation stands today.
Federated Learning – Training AI Without Seeing Your Data
This one deals directly with how your own specific device‘s keyboard or face unlock gets better. With federated learning (FL), you instead send a model to your device where it is trained on your own data, and only sent back up the revised model weights not the data itself.
Those updates are sent to the server, which combines them from thousands of other devices and learns a better model for everyone. None of your typing habits, photos, or messages are ever sent anywhere else.
Google led the way with this for Gboard. Now, hospitals use it to train diagnostics AI models across institutions without sharing patient records. But FL isn‘t totally private – gradient updates occasionally leak information. So the researchers add DP or Secure Aggregation on top.
Homomorphic Encryption — Computing on Locked Data
I think probably this one is the craziest technically. Homomorphic encryption (HE) isa third party being able to run calculations (doing maths) on a box ofencrypted data. It sends you back a box, you do your calculations on theoutside, returning the box and then when you open it, there are your.results in the box.
Craig Gentry solved the theoretical problem in 2009, but in the real world it‘s still very computationally expensive it‘s conceivable that simply ML-testing data while enciphered on HE is still hundreds of times slower than time as plaintext. Libraries such as Microsoft SEAL and HElib improved things, but it still finds to be utilized largely in narrowly-defined contexts (for example, an encrypted database query in finance or health).
As soon as you want to do anything more substantial than toy-sized data, FHE still seems to be more of a research tool than a drop-in production tool. Hybrid schemes are one of the current workarounds being studied, these mean using a fast symmetric cipher together with HE.
Zero-Knowledge Proofs — Prove It Without Showing It
Zero-knowledge proof (Z KPs) allow you to prove you know something without revealing what it is. A classic scenario is if you want to prove to someone that you are over 18 without revealing your date of birth. An example, is if you want to show someone you have enough money without revealing your balance.
ZKPs have been thrust into the spotlight thanks to blockchain privacy coins such as Zcash, and zk-rollup scaling solutions on ethereum and their applications go far beyond crypto. They can be used for identity systems, testing credentials, and controlling access to resources.
Disadvantage: complexity. Creating a ZKP circuit for a real world function is not trivial, and for some ZK-SNARK schemes, the trusted setup requirements is an issue.
Trusted Execution Environments — A Vault Inside Your Chip
Trusted Execution Environments (TEEs) are secure, isolated sections at the hardware-level (such as Intel SGX or ARM TrustZone) where code and data cannot be accessed by any other code including the OS local to the system.2 Even a compromised server cannot access the contents of an enclave.
Microsoft implemented this in their Azure Confidential Computing infrastructure (ACI). Useful in, for example, wanting to run sensitive AI inference work within a cloud provider who is not to be trusted with the data.
The catch? TEEs have a track record of side-channel exploits (speculative execution attacks, cache timing) so they are not considered invincible.
What Most People Miss About the Privacy–Utility Tradeoff
The other part that doesn‘t appear in most explainer posts.
Every PET has a cost. Aside from the computational overhead there‘s a fundamental tradeoff between privacy and usefulness that cannot be engineered out.
Of course, making the data more private also makes the aggregate statistics less accurate. As some people at NIST have pointed out, DP mechanisms such as DP-SGD “obfuscate model updates so heavily that extremely large amounts of data are required to achieve satisfactory performance.” Which is pretty limiting for organizations that don‘t have extensive datasets to work with.
For federated learning, training on non-IID data (where data is heavily skewed on each devices) makes the models converge badly, and the solutions require much more work.
The overhead with HE and MPC can be several orders of magnitude higher. Not a small engineering problem to address.
The honest take: PETs don‘t make privacy free: They do make it possible while allowing utility–but the tradeoffs are stark, and using the right PET for a particular application requires genuine expertise.
Where Privacy-Enhancing Technologies Are Showing Up Right Now
The spread between theory and deployment has narrowed dramatically over the past five years. This is where PETs are actually being used in production:
Healthcare: Hospitals utilizing federated learning to develop diagnostic models across facilities without exchanging patient information. Differential privacy integrated with datasets for medical research shared between organizations.
Finance: Banks deploying privacy-preserving cross verification of fraud signals using secure multi-party computation.
AI training: Google applies user-level differential privacy when fine-tuning large language models, ensuring that the work of individual users, whose data contributed to the training, is protected.
Government: The US Census bureau decision to convert to DP for 2020 population figures. This was an interesting case study in that it demonstrated that DP could be applied at a national level, but also led to discussions over the compromising of accuracy for smaller geographical regions.
Mobile devices: Federated learning on Android and iOS to learn models for, keyboard prediction, photo tagging, speech recognition, etc.
During my experiments of a federated learning architecture using PySyft, I realized that the tooling has gotten significantly better – what once needed to be a deeply systems-motivated engineer is now quite simple for ML engineers with a week of reading. That‘s quite a leap!
Choosing the Right Tool: A Quick Framework
Not every use case needs HE. Not every situation calls for MPC. Here‘s a rough decision path:
- Publishing or sharing overall aggregated statistics?-> Differential privacy is your best fit.
- Training AI jointly across multiple organizations or devices without pooling raw data? -> Federated learning, ideally with secure aggregation added on top.
- Offloading computation to a third party that is not trusted? -> Homomorphic encryption or TEEs.
- To show that a statement about data is true, without showing the data? -> Zero-knowledge.
- Just need to reduce re-identification risk for internal datasets? -> Pseudonymization or anonymisation at first step, if sharing results externally then DP adding on top.
Begin by using the most basic tool that addresses your threat model. There is no reason to using cryptographic MPC when you can anonymize a data set. And always use audited libraries, the way to break your system is to go at it yourself.
My Take After Going Deep on This
PETs are not one product, not check boxes, but tools that can be used as part of a solution. Some tools are more appropriate than others for given problems. We have seen the field move from mostly theory papers to deployments in production scenarios that people just use every day.
What‘s different in the last 2-3 years is the tooling. Libraries such as TensorFlow Privacy, Microsoft SEAL, and Flower for federated learning have made it possible for the average Python developer without a cryptography PhD to actually get things into production. And that is what‘s leading to adoption.
This regulatory pressure is also tangible. In fact, the European GDPR explicitly advocates the use of pseudonymisation. NIST even published SP 800-226 on differential privacy recommendations in 2025. The US and the EU both published national strategies even listing PET implementation as a priority.
Anything that involves personal data apps, AI models, analytics systems if you know what PETs and Differential Privacy actually do (not the marketing nonsense), then you have a real advantage.
The privacy layer is integrating into the infrastructure. Better understand it now.
I’m a technology writer with a passion for AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and curious. and encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
