The Private Compute Room: AI and Privacy-Enhancing Technologies

Privacy-enhancing technologies do not make sensitive data harmless. They change who can see which representation, under what assumptions, and with what measurable leakage. A confidential-computing label cannot fix an unrestricted prompt log; federated learning cannot stop a malicious coordinator by itself; synthetic data can still expose rare people; and differential privacy implemented with an untracked budget may be privacy theater.

The right question is not “Which PET should we buy?” It is: What useful computation must occur, which parties and components are not trusted, what information may each learn, and how will we verify that boundary? The answer often combines data minimization, conventional security, legal governance, and one or more PETs.

Start with the computation and threat model

Write a privacy contract before selecting technology:

“Encrypt the data” is incomplete. Data may be protected at rest and in transit but exposed during processing, in model outputs, through access patterns, or in debug traces. Define trust at every transition.

Use data protection impact assessment and applicable legal review. NIST’s Privacy Framework is a voluntary risk-management tool, not certification or legal advice. PETs can support minimization and security, but regulators such as the UK ICO explicitly frame them as aids to compliance, not replacements for lawful basis, transparency, purpose limitation, or rights.

Minimize before applying advanced cryptography

The strongest privacy improvement is often not collecting or transmitting a field. Ask whether the task can use:

• a count instead of row-level data;
• a category instead of free text;
• an age band instead of birth date;
• derived features instead of the original document;
• local filtering before a cloud request;
• a retrieval result instead of a whole repository;
• an ephemeral representation instead of permanent memory.

Separate direct identifiers, quasi-identifiers, sensitive attributes, labels, prompts, and operational metadata. Token counts, error messages, timestamps, filenames, and access patterns can reveal information even when content is encrypted.

Redaction must be context-aware and tested. Removing names does not anonymize a rare diagnosis, exact location, employer, and date combination. Pseudonymization preserves linkability and usually remains personal data under data-protection regimes.

For memory and personalization controls, see Memory Without Surveillance.

Match the PET to the boundary

Different PETs solve different problems:

Differential privacy

Differential privacy (DP) bounds how much an output distribution changes when one person’s data is added or removed. It is especially useful for statistics, telemetry, training, and some synthetic-data mechanisms.

A real DP claim must state adjacency, mechanism, epsilon (ε), delta (δ) where used, clipping or contribution limits, accounting method, and composition horizon. NIST SP 800-226, finalized in 2025, emphasizes evaluating the complete guarantee and implementation hazards—not merely attaching “DP” to a product.

Smaller epsilon is generally stronger privacy but not comparable without the rest of the definition. Repeated queries consume privacy budget. Debug endpoints, subgroup releases, and retries must enter the accountant.

Secure multiparty computation and private set operations

Secure multiparty computation (MPC) lets parties compute a function over their inputs without one party receiving all raw inputs. Private set intersection (PSI) is a narrower pattern for learning overlap, sometimes with associated values.

Security depends on the protocol, number of parties, corruption threshold, malicious versus semi-honest model, collusion assumptions, and output. MPC hides inputs beyond what the output reveals; it does not make an overly revealing output private.

Homomorphic encryption

Homomorphic encryption allows selected computation on encrypted values. It can reduce trust in the compute operator, but supported operations, numeric approximation, latency, ciphertext expansion, and key ownership matter. “Encrypted inference” may protect input while exposing model structure or output to another party.

Benchmark the exact circuit and accuracy, not a toy operation. Plan key rotation, backup, recovery, and revocation before production.

Trusted execution environments and confidential computing

A trusted execution environment (TEE) isolates code and data during use and can provide remote attestation. It changes trust from the whole infrastructure operator toward hardware, firmware, attestation, workload measurement, and supply chain.

TEEs do not automatically stop side channels, compromised code inside the enclave, excessive output, rollback, or leakage before and after the protected boundary. Verify the exact measurement, fail closed on invalid attestation, minimize enclave interfaces, and patch the platform.

Federated learning

Federated learning moves training updates closer to distributed data. It reduces central collection of raw examples but gradients or updates may leak information, and a coordinator or participant may poison the model. Use secure aggregation, clipping, robust aggregation, participant authentication, and often DP.

“The data never leaves the device” can be misleading if updates, metrics, crash logs, or evaluation samples do.

Zero-knowledge proofs and verifiable computation

Zero-knowledge proofs can show that a statement or computation satisfies a condition without revealing the underlying witness. They can help verify eligibility, policy compliance, or execution properties. They do not prove the input was truthful or the model was appropriate unless those facts are part of the proven statement.

Each technique protects a boundary, not the whole lifecycle. The OECD’s 2025 report on sharing trustworthy AI models similarly describes combinations of TEEs, federated learning, MPC, DP, and homomorphic encryption, while warning about utility, efficiency, and usability trade-offs.

Compose protections deliberately

A practical system may combine:

• local redaction and feature extraction;
• federated training;
• secure aggregation using MPC;
• contribution clipping and central or distributed DP;
• TEE-based aggregation with remote attestation;
• encrypted storage and short retention;
• policy-gated output release.

Composition can close gaps, but it can also introduce new ones. Ask:

• Does the TEE operator also hold the decryption key?
• Can two MPC parties collude?
• Is DP applied before or after secure aggregation?
• Does a failure fallback send raw data?
• Are retries counted in the privacy budget?
• Can telemetry leave the protected environment?
• Does model evaluation use an unprotected copy?

Draw the data-flow diagram at field level and mark where data is plaintext, pseudonymous, encrypted, aggregated, or DP-protected. Mark key owners and trust assumptions. Update the diagram when the workflow changes.

Concrete example: cross-hospital cohort discovery

Suppose three hospitals want to estimate how many patients meet research criteria without pooling complete records:

1. They agree on a precise cohort query, permitted purpose, output recipients, minimum group size, retention, and withdrawal handling.
2. Each hospital validates data quality locally and converts fields to a shared schema.
3. Direct identifiers stay local. A PSI or privacy-preserving linkage step identifies overlap so the same person is not counted repeatedly, under a documented linkage and collusion model.
4. An MPC protocol computes aggregate counts and selected statistics. No participant receives the other hospitals’ row-level inputs.
5. Contribution limits and differential privacy protect released subgroup statistics. A central accountant records every release against the approved budget.
6. A policy layer suppresses cells below the minimum size and blocks arbitrary follow-up queries.
7. The output includes query version, participating sites, DP parameters, utility intervals, data-quality caveats, and audit reference.
8. Raw working data and temporary keys are deleted under verified procedures; necessary evidence is retained separately.

This design still needs ethics, governance, security, and legal controls. MPC cannot fix biased source data, DP cannot make an invalid clinical conclusion correct, and a small cohort count may remain sensitive even if no raw row moved.

Protect the full AI lifecycle

PET architecture must cover:

1. collection: consent or other lawful basis, minimization, device permissions;
2. preparation: labeling, deduplication, joins, and feature stores;
3. training: raw examples, gradients, checkpoints, optimizer state, and distributed updates;
4. evaluation: holdout data, failure examples, human review, and slice reports;
5. deployment: prompts, retrieval, embeddings, caches, model endpoints, and tools;
6. monitoring: traces, logs, feedback, abuse reports, and incident artifacts;
7. retirement: model, index, replica, backup, key, and vendor deletion.

Embeddings are not anonymized by definition. Models can memorize, leak membership signals, or reveal sensitive attributes. Synthetic data needs disclosure-risk testing against the source and utility evaluation for the intended use; see Synthetic Data Governance.

Keep privacy controls at the output too. A protected training pipeline can still deploy a model that returns personal records through retrieval or an over-broad tool.

Engineer verifiable boundaries

For each protected computation, maintain:

• protocol and library version;
• security model and cryptographic parameters;
• workload measurement and attestation policy where relevant;
• key inventory, owner, rotation, recovery, and destruction;
• DP definition, accountant, budget owner, and release ledger;
• participant identity and authorization;
• input schema and contribution limits;
• output policy and disclosure review;
• performance and accuracy regression tests;
• threat-model review and independent test results.

Do not invent cryptography. Use reviewed implementations and current parameters, isolate key material, and commission specialist review for high-risk deployments. Vendor certification for one component does not validate the end-to-end data flow.

Privacy-Preserving Data Collaboration covers the organizational contracts around these technical controls.

Measure privacy, utility, and operations together

Privacy without usable output will be bypassed; utility without privacy defeats the purpose. Track:

Run membership-inference, reconstruction, linkage, model-extraction, poisoning, collusion, and rollback tests appropriate to the threat model. Passing one attack implementation is not proof of privacy; record attacker knowledge and resources.

For DP, evaluate the mathematical definition and the realized software. NIST SP 800-226’s “privacy hazards” framing is useful because correct equations can be undermined by contribution errors, unsafe defaults, finite-precision behavior, or composition mistakes.

Common privacy theater

Warning signs include:

• “anonymized” data with no attacker or re-identification test;
• “federated” training with readable per-client updates;
• a TEE with no verified attestation or plaintext fallback;
• “homomorphic” claims benchmarked only on a trivial function;
• DP without published parameters, accountant, or budget;
• synthetic data evaluated only for utility;
• encrypted prompts copied into plaintext logs;
• raw data removed but embeddings, checkpoints, and backups retained;
• a PET vendor operating all non-collusion roles;
• privacy claims that ignore the model output and tool permissions.

The ICO’s PET guidance is under review because of UK legal changes as of 2026. That status reinforces a general rule: regulatory guidance is jurisdiction- and date-specific. Technical controls must be mapped to current obligations by qualified counsel and privacy professionals.

Release gates

Before sensitive production use, require:

• documented purpose, lawful authority, affected people, and prohibited reuse;
• field-level data-flow and threat model approved by privacy, security, legal, and product owners;
• evidence that minimization was attempted before advanced PETs;
• explicit security assumptions and failure behavior for every PET;
• keys, attestation, participants, and privacy budgets inventoried and monitored;
• no plaintext fallback or debug export can bypass the protected route;
• disclosure and utility tests pass for every intended output slice;
• DP parameters and composition are reviewed against the release ledger;
• collusion, poisoning, replay, rollback, and side-channel scenarios are tested where relevant;
• user-rights and deletion workflows include models, indexes, logs, backups, and vendors;
• independent review finds no critical privacy or security issue;
• rollback or shutdown can stop new computation without destroying evidence.

Choose numerical thresholds from the threat model and use case. There is no universal epsilon, minimum cohort size, or acceptable inference-attack rate.

Frequently asked questions

Do PETs make data anonymous?

Not automatically. Some designs may support an anonymization assessment under specific assumptions, while others only reduce exposure or pseudonymize data. Evaluate identifiability with context and applicable law.

Which PET is best for AI?

None universally. DP limits leakage from released statistics or training; MPC and homomorphic encryption change input visibility; TEEs isolate computation; federated learning changes data location. The computation and adversary determine the combination.

Is on-device inference a PET?

It can be a privacy-enhancing architecture when data and outputs remain controlled, but device logs, backups, updates, permissions, and later cloud calls still matter.

Can we guarantee zero privacy risk?

No useful data system can promise that broadly. State the formal guarantee, implementation assumptions, residual risks, and operational controls precisely.

Source notes

Sources reviewed and current as of July 30, 2026:

• NIST Privacy Framework 1.0 — voluntary privacy-risk framework, not certification or legal compliance.
• NIST SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees — final 2025 guidance on DP definitions, evaluation, and implementation hazards.
• UK ICO Privacy-Enhancing Technologies guidance — regulator guidance across eight PET categories; marked under review following UK legal changes.
• OECD: Sharing Trustworthy AI Models with Privacy-Enhancing Technologies — 2025 policy analysis of combinations, applications, and trade-offs.
• OECD: Emerging Privacy-Enhancing Technologies — regulatory and policy overview; PETs complement rather than replace governance.