For years, privacy programs have focused largely on controlling what organizations are allowed to collect.
Privacy-enhancing technologies, or PETs, approach the problem differently: what if a company could still use valuable data without actually exposing the underlying data?
That distinction is becoming increasingly important as organizations try to reconcile two competing pressures. Businesses want to combine more datasets, train more sophisticated AI systems and extract more useful information from customer behavior. Privacy laws increasingly require minimization, purpose limitation, security safeguards and tighter controls around sensitive information.
PETs sit directly in the middle of those two objectives.
The International Association of Privacy Professionals recently highlighted several increasingly practical deployments, including Google’s use of differential privacy for Maps, Mastercard’s use of fully homomorphic encryption for fraud detection, and federated learning projects that allow researchers to work across sensitive health datasets without centralizing them.
The more interesting development, however, is not that these technologies exist.
It is that privacy engineering is starting to move from a model built around “collect the data and protect the database” toward one in which organizations can redesign whether raw personal data ever needs to be collected, transferred or exposed in the first place.
That could change what a privacy program actually looks like.
PET Is Not One Technology
“Privacy-enhancing technology” can sound like another broad privacy industry label. It is more useful to think about PETs according to the problem each one solves.
Differential privacy lets an organization extract statistical information from a dataset while limiting what can be learned about any particular individual.
Federated learning allows multiple devices or organizations to participate in model training while keeping their underlying datasets separate.
Homomorphic encryption permits certain calculations to be performed while data remains encrypted.
Secure multiparty computation allows different parties to jointly calculate an answer without each party revealing all of its inputs.
Trusted execution environments create hardware-protected areas in which sensitive information can be processed while limiting access even by the operator of the surrounding infrastructure.
Synthetic data attempts to reproduce useful statistical properties of real information without simply providing another copy of the original dataset.
Those technologies solve different problems and have very different maturity levels, costs and limitations. OECD guidance expressly cautions against treating PETs as a universal solution. The organization divides the field into categories including data obfuscation, encrypted processing, federated and distributed analytics, and accountability technologies. It also notes risks ranging from re-identification to information leakage and substantial computational overhead.
In other words, “we use PETs” means almost nothing by itself.
The useful question is: What privacy risk was the technology supposed to eliminate, and does the implementation actually eliminate it?
Differential Privacy: Useful Answers Without Exposing Individuals
Differential privacy is one of the clearest examples.
Imagine a company wants to know how many customers in Miami visit a particular category of store each week.
The conventional approach might be:
collect everyone’s precise location history;
store it centrally;
associate it with device or account identifiers;
run the analysis;
and restrict access to the database.
Differential privacy tries to change the architecture.
Instead of relying exclusively on organizational promises that analysts will not identify individuals, mathematical noise is introduced so the aggregate answer remains useful while it becomes significantly harder to determine whether any particular person’s information influenced the result.
Google uses this type of approach in Maps to generate information such as how busy a location is from users who have opted into relevant location services.
But implementation matters enormously.
Differential privacy is not equivalent to simply removing names from a database.
It depends on mathematical parameters governing how much information can be revealed. Queries can consume a “privacy budget,” and poorly chosen parameters can produce something that technically uses differential privacy while providing much weaker protection than the organization suggests.
That is why NIST published Special Publication 800-226 specifically to help organizations evaluate differential-privacy guarantees and common implementation hazards.
This is an important distinction for privacy counsel.
A marketing statement saying that a dataset is “differentially private” should eventually receive the same scrutiny that privacy teams now give statements such as “anonymous,” “encrypted” or “de-identified.”
The name of the technology is not the protection.
The implementation is.
Federated Learning Changes Where the Data Goes
Federated learning attacks a different problem.
Traditional machine learning frequently works like this:
Company A has Dataset A.
Company B has Dataset B.
Researchers want to train a better model using both.
So everyone sends their data somewhere central.
That centralization creates an obvious privacy problem. It produces a larger dataset, increases the number of data transfers, concentrates risk and can trigger additional contractual and regulatory obligations.
Federated learning can reverse that structure.
The model travels to the data rather than requiring the raw data to travel to the model.
Each participant trains the model locally. The system then sends model updates back for aggregation instead of transmitting the underlying records.
The IAPP article describes a pediatric cancer research example where datasets were held by institutions in multiple countries. Federated learning allowed local model training while avoiding movement of the original underlying datasets.
This is particularly compelling for rare diseases.
Centralizing genomic information from small patient populations can create substantial re-identification concerns. Genetic information also creates unusual privacy risks because it contains information not merely about the patient but potentially about relatives.
NIST is now using genomic information in its own PETs Testbed to study privacy-preserving federated learning. The project combines techniques including federated learning, differential privacy and cryptographic protections to examine how machine learning can operate across separate genomic repositories.
That is a fundamentally different privacy strategy from drafting a data-sharing agreement and moving everything into one warehouse.
But Federated Does Not Automatically Mean Private
There is an important catch.
If raw data stays on the device or inside the institution, that does not mean nothing sensitive can leak.
Model updates themselves can sometimes reveal information.
That is why serious federated-learning systems may layer several PETs together.
Differential privacy can obscure contributions from individual records.
Secure aggregation can prevent the coordinating server from seeing individual participant updates.
Homomorphic encryption may permit encrypted calculations.
Trusted execution environments can isolate sensitive processing.
NIST has examined precisely this problem, including ways to protect model updates through cryptographic systems and secure hardware.
This layered model may ultimately become one of the defining characteristics of mature privacy engineering.
Organizations will not simply select “a PET.”
They will build privacy architectures from combinations of technologies.
Homomorphic Encryption Solves an Almost Counterintuitive Problem
Encryption traditionally protects data at rest and in transit.
The difficult point has always been data in use.
Normally, if a computer needs to calculate something using encrypted data, the data must first be decrypted.
That creates a moment when the underlying information becomes available to the system performing the calculation.
Fully homomorphic encryption changes that assumption.
It allows certain computations to occur directly on encrypted information. The party performing the calculation may never see the plaintext data.
The IAPP article points to Mastercard’s work using fully homomorphic encryption in cross-border financial fraud analysis. The objective is to allow organizations to check account information while keeping sensitive source data encrypted and localized.
Consider the implications.
Two financial institutions might want to determine whether accounts in their respective systems overlap with a fraud dataset.
The old choices might be:
Bank A sends information to Bank B;
Bank B sends information to Bank A;
both send information to a third party;
or the analysis does not happen.
Privacy-preserving computation introduces another possibility:
calculate the answer without either side exposing unnecessary underlying records.
That creates a very different risk model.
PETs Could Change the Meaning of Data Minimization
Privacy laws frequently tell organizations to collect only the information necessary for a defined purpose.
Traditionally, data minimization has been interpreted largely as a policy question:
Do we really need this field?
How long should we retain it?
Who should have access?
PETs create a more technical version of the same inquiry:
Does this business process actually require anyone to see the underlying data?
That question is more powerful.
Suppose a company wants to verify that someone is over 18.
A conventional process might collect:
name;
date of birth;
government ID;
ID photograph;
document number;
and perhaps biometric information.
But the actual business question may only be:
Is this person at least 18?
A privacy-preserving credential or zero-knowledge proof could theoretically answer that binary question without handing over the birth date or entire identity document.
Instead of minimizing the number of fields stored after collection, the organization minimizes disclosure before collection.
That is a much stronger form of data minimization.
AI Makes PETs More Relevant, Not Less
Generative and agentic AI have increased pressure to aggregate information.
Organizations want larger datasets because large datasets can produce better models, stronger fraud detection, more accurate recommendations and more useful analytics.
At the same time, centralized AI datasets create unusually attractive targets and can be difficult to unwind once information enters a training pipeline.
PETs offer a possible alternative.
The OECD has specifically examined the role of PETs in collaborative AI development. Its 2025 paper identifies technologies including trusted execution environments, federated learning, secure multiparty computation, differential privacy and homomorphic encryption as mechanisms that can enable organizations to train or share models while reducing exposure of underlying data and intellectual property.
This does not eliminate AI privacy risk.
It changes some of the attack surface.
An AI system trained using federated learning can still have problematic outputs.
A model using differential privacy can still be biased.
A trusted execution environment can still be part of a poorly designed application.
PETs are architecture, not absolution.
There Is Also a Legal Trap: PETs Do Not Erase Regulation
One of the easiest mistakes would be assuming that using a PET means privacy laws no longer apply.
That is not generally how the analysis works.
The IAPP panel specifically cautioned that technologies such as encryption do not automatically eliminate data-transfer rules. They may materially reduce risk, but the organization still has to determine what information is being processed and which legal obligations apply.
The same issue appears with pseudonymization.
Pseudonymized personal data can remain personal data when someone retains the ability to reconnect the information to a person.
Encrypted personal information does not necessarily cease being personal information simply because unauthorized parties cannot presently read it.
PETs can therefore reduce the risk of a processing activity without necessarily changing its legal classification.
Those are separate questions.
The Next Privacy Vendor Problem: “PET Washing”
As PETs become commercially attractive, privacy teams should expect marketing claims to outrun engineering reality.
We have already seen this phenomenon with terms such as:
“anonymous data”;
“military-grade encryption”;
“AI privacy”;
“zero knowledge”;
and “de-identified.”
PETs provide even more technical language for vendors to use.
A vendor saying it uses federated learning should be able to explain whether raw records ever leave participating environments.
A vendor claiming differential privacy should be able to discuss its privacy parameters and privacy accounting.
A homomorphic-encryption provider should explain which calculations remain encrypted and where decryption ultimately occurs.
A trusted-execution-environment implementation should explain what is inside the trust boundary and what happens before and after information enters it.
Privacy teams do not necessarily need cryptographers on every procurement call.
They do need enough technical competence to distinguish an architectural privacy control from a marketing label.
PETs Could Also Become Evidence of Reasonable Privacy Engineering
There is another issue that has received less attention.
As privacy-enhancing technologies become more mature and commercially practical, organizations may eventually face questions not merely about whether PETs were available, but why they were not considered.
This does not mean every company will have a legal obligation to deploy homomorphic encryption or federated learning.
That would be unrealistic.
But privacy law increasingly relies on concepts such as necessity, proportionality, reasonable safeguards, privacy by design and risk-based controls.
Technology affects what is considered reasonable.
A security control that was prohibitively expensive in 2005 may be commonplace in 2026.
Privacy engineering can evolve in the same way.
If an organization routinely centralizes enormous amounts of sensitive information even though an established architecture could accomplish the same function without centralizing the information, the design decision may eventually receive more scrutiny.
That will depend on jurisdiction, context, technological maturity, cost and risk.
But the direction is worth watching.
Start With the Problem, Not the Acronym
The IAPP panel offered perhaps the most useful rule: PET selection must occur case by case. Organizations need to balance utility, privacy, cost and the actual business outcome they need.
A practical PET assessment should therefore begin with the data flow.
What information exists?
Who currently receives it?
Why does that party need it?
Does the underlying information need to move?
Does anyone need to see the raw information?
Can the desired answer be calculated from encrypted information?
Could computation occur where the data already resides?
Could aggregate information replace individual-level information?
Can identity be proven without revealing the identity itself?
Only after answering those questions does it make sense to choose a technology.
Sometimes the answer will be differential privacy.
Sometimes federated learning.
Sometimes encryption.
And sometimes the best privacy-enhancing technology will be much less exotic: simply stop collecting information that the business never needed in the first place.
That is ultimately why PETs are becoming relevant to ordinary privacy programs.
They shift privacy from a question of how an organization promises to handle data after it receives it toward a more fundamental engineering question:
How much of that data did the organization ever need to possess?