“Train models using decentralized data stored across multiple servers or devices. This approach minimizes the need for centralized data collection and reduces exposure risks.”
“Apply techniques that add noise to the data or outputs, making it difficult for attackers to reverse-engineer individual data points.”
Proof Pudding (Slide 11) worked precisely because raw classification scores were exposed with no noise added — clean enough signal for attackers to reverse-engineer the model behind it. Differential privacy exists for exactly this failure mode.
→ Where feasible, train on decentralized data rather than a single pooled dataset of raw records
→ Add calibrated noise to outputs that expose model internals (scores, confidence values, embeddings) — not just to the final answer text
→ Treat differential privacy as a tunable tradeoff between data fidelity and reconstruction risk, not an all-or-nothing switch
If your model exposes any numeric score, confidence value, or embedding to external callers, ask whether enough of those values, collected over time, could be used to reverse-engineer the underlying logic. Proof Pudding shows the answer is often yes.
Ask your team whether your AI vendor can see your training data — and whether your contract requires them not to use it. If training happens on your vendor's servers, your data is on their servers.