A chatbot should not be the only employee in the company responsible for keeping secrets. That sounds obvious until we look at how many enterprise RAG systems are designed. A user asks a question. The system retrieves internal documents. The documents are placed into the model context. A policy instruction is added somewhere above the user prompt: do not reveal sensitive information. Then everyone hopes the model behaves. ...
Hospitals do not usually wake up excited to pool brain data. Neither do device vendors, rehabilitation centers, or anyone with a lawyer who has read a privacy regulation without falling asleep halfway through. EEG data is useful precisely because it is personal. That is also why centralizing it is awkward. This is the practical tension behind SAFE, short for Secure and Accurate Federated Learning, a proposed framework for EEG-based brain-computer interfaces, or BCIs.1 The paper is not interesting because it says “federated learning protects privacy.” That line has already been printed on enough PowerPoint slides to qualify as industrial wallpaper. The interesting part is that the authors treat federated learning as only one piece of the problem. ...
Face. That is where the privacy problem starts to become awkward. A company does not need to build a facial-recognition product to create facial-recognition risk. It may only add a multimodal model to a customer-support workflow, an HR document review process, a KYC assistant, a media-monitoring tool, or a claims-processing system. Someone uploads an image. The model sees a person. Then the user asks: Who is this? Where do they live? What is their email? What is their religion? What is their medical condition? ...
An employee privately tells a colleague that she plans to resign. Weeks later, she asks her AI assistant to draft an email to her manager about her future goals. The assistant searches her previous conversations, retrieves the resignation discussion, and helpfully writes that her priority is preparing for a smooth transition because she has accepted another role. ...
Data markets usually sound simpler than they are. A buyer wants data. A seller owns data. A platform matches them. Payment moves. Everyone gives a keynote about “unlocking value.” Then the real problems arrive wearing steel-toed boots: the data is private, the seller may be low quality, the buyer wants a model rather than a spreadsheet, the compute layer may be dishonest, and nobody wants to trust a central broker unless absolutely necessary. ...
A user asks to be forgotten. The recommender team opens the dashboard, sighs quietly, and faces the usual menu of unpleasant options. Retrain the model from scratch, which is clean in theory and expensive in practice. Partition the data so only part of the system needs rebuilding, which sounds elegant until collaborative signals leak across groups like gossip at a small wedding. Or approximate the user’s influence with gradients and influence functions, which is efficient until similar users get nudged around because the model learned their tastes together. ...
Hospital search is rarely a search problem in the clean, consumer-internet sense. The useful information is not sitting in one tidy index, wearing a name badge, waiting to be embedded. It is scattered across clinical notes, relational databases, knowledge graphs, departmental systems, hospital networks, and legal boundaries. Naturally, this is where people decide to add a large language model and call it “modernisation.” Brave. ...
TL;DR for operators Email is still where good security intentions go to become embarrassing screenshots. The paper behind this article, Searching for Privacy Risks in LLM Agents via Simulation, studies a future that is no longer especially futuristic: one AI agent has access to sensitive information, another agent wants it, and the two can talk through ordinary applications such as email, Messenger, Facebook, or Notion.1 The question is not whether the model knows a privacy rule in the abstract. The question is whether an agent, while trying to be helpful in a live interaction, can refuse the wrong request at the right moment. ...
TL;DR for operators Deletion sounds simple until the deleted record has already shaped millions of model parameters. The clean answer is to retrain the model without that record. The operational answer is usually less glamorous: nobody wants to burn a full training cycle every time a user, regulator, data-quality team, or security analyst says, “Remove this.” ...
TL;DR for operators Enterprise LLM safety is often discussed as if the main question is whether the model has been trained to “behave”. That is the comforting version of the story. It is also too small. IBM’s OneShield paper argues for a different operating model: treat safety as a separate, model-agnostic guardrail layer that sits around the LLM, runs multiple specialised detectors in parallel, and then applies explicit policy decisions through a separate policy manager.1 In plain business terms, OneShield is less like teaching the model good manners and more like installing a configurable safety-control plane around every AI interaction. Glamorous? Not especially. Operationally useful? Very much so. ...