A downloaded model brings executable code into your environment. A prediction service reveals information about its training data. A request to remove one person's records reaches a data lake designed never to change. These are different problems, so begin by separating security from privacy and identifying what needs protection. Follow the threats through external artifacts, deployment systems and the data itself. The middle talks compare privacy methods, then examine the limits of noisy statistics and encrypted computation in more detail. Finish with an application that connects a language model to private data and tools, where permissions determine how far an injected instruction can reach. The talks span 2020 to 2024; use their mechanisms and failure cases without treating historical tools or legal commentary as current guidance.
Why first: The panel separates protecting a system from protecting the people whose information it processes. Prompt monitoring itself can create privacy exposure. Establish that distinction before choosing controls, then use the following threat examples to decide which data flows and model behaviors need attention.
Why second: Chaieb follows risks into training data, pretrained artifacts, prediction APIs and distributed updates. The model inherits ordinary software threats and adds ways to leak or manipulate learned behavior. This widens the inspection beyond the public endpoint before the next talk turns it into repeatable operating work.
Why here: Morgan makes artifact origin, lineage and automated scans part of development and deployment. Recording which datasets produced which models helps a team respond when a source is later found unsafe. Those controls address what enters the system; the next account asks whether the system can remove personal data once it is there.
Why here: Albertsson describes the engineering conflict between immutable shared data and deleting an individual's records. Separating personal data or planning for reprocessing changes the design before collection. This grounds the privacy discussion in storage and change management, rather than assuming a mathematical technique can repair an unsuitable data architecture.
Why here: This overview distinguishes encrypted computation, differential privacy, federated learning and synthetic data. Their limitations differ: keeping data local adds coordination work, and generated data inherits weaknesses in its source. Use the comparison to identify a candidate mechanism, then examine the next two talks and their narrower guarantees.
Why here: Dimitrakakis explains how useful aggregate learning can coexist with uncertainty about individuals, then shows where the promise ends. Privacy loss accumulates across releases, and protecting one defined record does not hide every correlated fact. This is the detail needed before translating a privacy parameter into a claim about the system.
Why here: Ryffel asks a different question: who may see the data, the model or the agreed result during computation? Secret sharing makes the mechanism tangible, while the distinction between curious and malicious participants exposes an important assumption. A convenient encryption call does not choose that threat model for you.
Why last: Dawson returns to the complete application, where retrieved instructions can reach tools and private records through excessive permissions. His threat-modeling examples connect inputs, outputs and access tokens. End by checking those concrete paths and limiting authority, rather than assuming model-level defenses protect everything attached to it.