By Data Movement

Data movement is the first hard constraint. It does not decide the PET alone, but it rules out many bad ideas quickly.

Decision Matrix

Data movement pattern	Use this when...	Candidate PETs	Avoid this when...	Hidden cost
Raw data centralizes	One party is allowed to process data and can be held accountable	Centralized processing, DP, minimization, access controls	The central operator is not trusted or cannot legally receive the data	Concentrated breach and misuse risk
Raw data stays at each party	Participants can compute locally and send protected artifacts	FL, federated analytics, secure aggregation, MPC, PSI	Participants cannot run reliable infrastructure or agree on protocols	Coordination, versioning, identity, and dropouts
Data enters a controlled environment	Data can move only into a governed or confidential boundary	Clean rooms, TEEs, confidential computing	The platform operator is in the adversary model and hardware trust is unacceptable	Policy, attestation, logging, and procurement
Only encrypted inputs move	The service must not see plaintext inputs	HE, MPC, PSI	The workload is broad, interactive, or latency-sensitive without benchmarking	Cost, limited operators, complex debugging
Model updates move	Training data remains local but gradients, weights, or metrics leave	FL, secure aggregation, DP, robust aggregation	You cannot tolerate update leakage or poisoning risk	Updates are still sensitive artifacts
Data-like artifacts leave	External users need something shaped like data	Synthetic data, DP synthetic data	Users need high-fidelity rare cases or individual-level truth	Memorization testing and utility validation

Raw Data Can Centralize

Centralization can be the right answer. Do not choose a complex PET only to avoid saying that governance is the real problem.

Use centralization when:

one accountable operator is acceptable;
access control, minimization, retention limits, and audit logs are enforceable;
the workload needs high fidelity, low latency, or operational simplicity;
the privacy claim is about controlled processing, not cryptographic separation.

Add differential privacy when the released output must limit the contribution of one person, account, device, or organization. DP is an output guarantee; it does not make sloppy data handling safe.

Raw Data Cannot Move

Need	Better starting point	What can break
Train a shared model	Cross-silo FL	Update leakage, poisoning, non-IID data, weak local operations
Compute aggregate metrics	Federated analytics or MPC	Small-cell leakage, collusion, expensive protocols
Find common records	PSI	The intersection may itself be sensitive
Serve inference	HE or TEE confidential inference	HE latency, TEE trust assumptions, output leakage
Release data-like artifacts	DP synthetic data	Memorization, weak utility, misunderstood residual risk

The phrase "data cannot move" is underspecified. Ask whether records, features, labels, identifiers, gradients, embeddings, prompts, logs, or outputs can move. Many failures happen because teams protect one artifact and leak another.

Recommendation Cards By Movement Pattern

Movement pattern	Recommended PET	Alternative PETs	Why	Tradeoffs	Failure modes	Operational considerations
Records cannot leave silos, but model updates can	FL + secure aggregation	Governed centralization, clean room training, MPC for analytics	Raw training records stay local while model learning is shared	Local training, update privacy, non-IID utility, round coordination	Gradient leakage, poisoning, small rounds, weak local controls	Participant identity, minimum rounds, local validation, per-site metrics
Identifiers cannot be broadly shared, but overlap may be revealed	PSI	MPC, clean room matching, trusted third-party matching	Nonmatches stay hidden while agreed overlap is produced	Narrow output, identifier normalization, repeated-query policy	Sensitive match set, false matches, intersection misuse	Allowed output, match-use policy, query limits, audit logs
Inputs must remain encrypted from the service	HE for narrow workloads; MPC for multi-party computation	TEE confidential inference, client-side inference	Plaintext inputs do not need to be exposed to the compute service	Latency, operator support, ciphertext expansion, harder debugging	Unsupported model layers, metadata leakage, output inference	Benchmark p95 latency, key ownership, supported operators, output review
Data can enter a governed boundary	Clean room or TEE	MPC/HE if the operator is in scope; governed centralization if trust is acceptable	The main constraint is controlled access, policy, and auditability	Platform trust, attestation, procurement, output review	Policy bypass, overbroad analyst access, plaintext logs	Query governance, role design, log retention, attestation checks
Data-like artifact must leave	DP synthetic data for formal release	DP query access, restricted data enclave, non-DP synthetic data for internal testing	Consumers need a table-shaped artifact without raw release	Privacy-utility tension, release documentation, rare-pattern loss	Memorization, overtrust, downstream misuse	Privacy budget, release review, memorization tests, utility benchmarks

Data Moves To A Controlled Environment

Clean rooms and TEEs are useful when data can move only into a governed or confidential environment.

Use this when:

the main need is controlled collaboration, auditability, or policy enforcement;
the computation is too broad for HE or MPC;
the parties accept a platform, hardware, or operator trust assumption;
outputs can be reviewed before release.

Avoid this when:

the platform operator is explicitly untrusted;
participants cannot verify code, policy, logs, or attestation;
the output will reveal the sensitive fact anyway;
the team is using "clean room" as a vague procurement label.

Data Moves As Updates

Federated systems move gradients, model deltas, sketches, or metrics. Treat these as sensitive unless there is evidence otherwise.

Use supporting PETs based on the leakage:

Leakage concern	Add	Caveat
Coordinator should not inspect individual updates	Secure aggregation	Makes debugging and poisoning detection harder
Individual participation should be bounded	Differential privacy	Utility may drop and accounting must be maintained
Clients may send malicious updates	Robust aggregation, validation, anomaly detection	Harder when updates are hidden
Sites may be small or unique	Minimum round sizes, grouping, DP	Small cohorts can defeat aggregate privacy intuition

Worked Example: Cross-Bank Fraud Signals

Two banks cannot share raw transactions. They first think "federated learning," but the immediate business question is whether accounts appearing at both banks are associated with known mule patterns.

Better path:

Use PSI to identify permitted overlap or MPC if the fraud score requires joint features.
Apply thresholds and output review so tiny match sets are not exposed.
Consider FL only after there is a stable shared modeling task.

The recommendation changes if the banks need a continuously trained model rather than a specific joint computation.

Checklist

What exact artifact is forbidden to move?
Who sees intermediate values?
Who sees the final output?
Can parties collude?
Are there minimum cohort sizes?
Does the chosen PET protect inputs, outputs, both, or neither?
What is the cheapest evidence that would disprove the design?