24 篇博文 含有标签「privacy」

用户根据 GDPR 第 17 条提交了删除请求。你的团队删除了 Postgres 中的行，清除了 S3 中的缓存文档，并从 CDN 中轮换掉了缓存的 PDF。搞定。隐私团队签字，安全团队签字，工单关闭。六个月后，一名拥有向量索引读取权限的数据分析工程师为了一项聚类实验提取了一组 float[1536] 数组样本，通过公开可用的反演模型（inversion model）运行这些数据，并重建了原始 32-token 文本块中大约十分之九的内容——包括你已经“删除”的文档。没人预料到这一点。没人怀有恶意。流水线完全按照设计运行，只是威胁模型从未将向量存储视为数据副本。

在我见过的几乎每个 RAG 团队中，这种思维误区都是一致的：嵌入（embeddings）被视为不透明的数值产物——是衍生品，而非数据。安全评估批准上线是因为“嵌入不是 PII（个人身份信息）”。隐私评估批准了删除处理，是因为“源文本已不存在”。这两个团队都错了，谁都没有将向量存储建模为用户数据的第三份副本——它紧挨着源数据库和分析仓库，任何拥有索引读取权限的人都可以查询，且由于没有任何工具能识别出 1536 维的浮点向量属于敏感数据，它完全处于所有 DLP（数据泄露防护）扫描器的范围之外。

当你的第一个微调模型上线生产环境时，你的权重就成了一种你的隐私计划从未编目过的新型记录。进入训练组合的客户服务记录不再仅仅是数据库中你可以 DELETE 的一行 —— 它现在被冗余且不可提取地编码进了你的 API 所提供的参数中。原始记录可以从 S3 中擦除，从你的仓库中抹去，并从你的 RAG 索引中删除，而模型仍会继续使用该客户的姓名、账户 ID 或病史片段来完成提示词。你的销售团队签署的数据保护协议 (DPA) 承诺你会履行删除请求。但没有人问过 ML 团队这在技术上是否可行。

关于 PII 提取的研究表明，这并非假设。PII-Scope 基准报告显示，在现实的查询预算下，针对预训练模型的对抗性提取率最高可增加五倍；而使用自提示校准的成员推理攻击已将微调模型的 AUC 从 0.7 提升至 0.9。Llama 3.2 1B 是一个被广泛复制的小型基座模型，已被证明会记住其训练集中存在的敏感记录。对于任何在生产追踪数据上发布微调模型的人来说，结论是生硬的：你不能假设你的权重已经忘记了。

这一点很重要，因为大多数微调流水线是由 ML 工程师设计的，他们优化的是损失 (loss)，而不是由优化 GDPR 第 17 条款的数据主管设计的。结果产生了一个法律地位模糊、来源极少被记录、且不存在“删除用户 X”工作流的产物。

大多数构建 RAG 管道的团队对 GDPR 的理解方式是错误的。他们关注推理调用——模型是否生成了 PII？——却忽略了静静地藏在向量数据库中的更严重的风险敞口。每当用户提交一份文档、一张支持工单或一条个人笔记，经过分块、嵌入和索引后，该向量存储在 GDPR 下就成为了个人数据处理器。当用户行使被遗忘权时，"按 ID 删除"并不能解决问题。

被遗忘权不仅仅是从关系型数据库中删除一行数据。由个人数据派生的嵌入向量携带着可恢复的信息：研究表明，句子级嵌入中 40% 的敏感数据可以用简单代码重建，对于较短文本，这一比例高达 70%。派生的表示形式是个人数据，而非经过净化的抽象。GDPR 第 17 条适用于此，监管机构正在密切关注。

大多数团队将LLM隐私视为一个二元选择：要么将数据发送到云端并承担风险，要么在本地运行所有内容并承担成本。这两种框架都是错误的。实际上存在一个风险特征和工程预算差异显著的方法光谱——大多数团队在这个光谱上的位置是错误的，却浑然不知。

研究人员最近证明，他们可以以每条记录0.012美元的成本，以48.9%的成功率从3912人中提取真实PII。这个统计数字往往被当作学术威胁建模而被忽视，直到安全审计或合规审查落到你的桌上。问题不是是否要关注LLM隐私，而是哪些控制措施真正能改变局面，以及每种措施的实施成本。

你的新内部聊天机器人刚刚告诉一名实习生整个工程部门的薪资范围。HR 总监没有配置错任何东西。没有人分享了不该分享的链接。系统只是... 检索到了它，因为实习生询问了“工程师的薪酬预期”。

这是大多数团队预料不到的 RAG 隐私失效模式。它不是传统意义上的漏洞 —— 而是检索工作方式与访问控制预期方式之间的根本不匹配。

大多数工程师认为embedding是安全抽象的——一堆无法被逆向工程的浮点数。这个假设是错误的，而感知与现实之间的鸿沟正是用户数据泄露的地方。

最新研究仅凭文本embedding就实现了超过92%的精确token序列重建准确率——包括完整姓名、健康诊断和电子邮件地址——而无需访问原始编码器模型。这些不是理论攻击。可迁移的逆向技术在黑盒场景下同样有效：攻击者构建一个模仿你的embedding API的代理模型，就可以发动攻击。无论你使用的是专有模型还是开源模型，攻击面都存在。

本文涵盖embedding隐私风险的三个层面：逆向攻击的实际能力、检索管道中访问控制悄然失效的位置，以及能为用户提供适当控制权的架构模式——按用户命名空间、检索时权限过滤、审计日志和删除安全设计。

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 GDPR 和 HIPAA 的合规。但它几乎肯定没有说明：在任何策略控制生效之前，用户的姓名、电子邮件地址或病史是否以明文形式传输给了托管的 LLM API。

这个缺口——你能指出的隐私政策与你实际能证明的隐私保证之间的距离——正是大多数生产 LLM 系统悄然失守的地方。研究显示，提交给 ChatGPT 和 Copilot 等工具的提示词中，约有 8.5% 包含敏感信息，包括 PII、凭据和内部文件引用。在企业环境中，用户将邮件、客户数据和支持工单粘贴到 AI 辅助工作流程中，这一比例几乎肯定更高。

问题不在于开发者粗心大意。而在于 LLM 提示层从未被设计为数据处理边界。它从上游系统——用户输入、RAG 检索、智能体上下文——继承内容，却不执行治理整个技术栈其他部分的数据分类规则。

大多数将"差分隐私"视为合规复选框的团队实际上并没有得到保护。他们在流水线的某个环节添加了噪声——也许是在微调时添加到梯度上，也许是在检索时添加到查询嵌入上——然后得出结论认为问题已经解决。合规文档写着"已启用 DP"，工程团队继续前进。

他们没有做的是：定义 epsilon 预算、核算系统将服务的每一次查询所消耗的预算，或者验证其隐私损失是否受到有效约束。在实践中，"我们添加了噪声"与"我们拥有有意义的隐私保证"之间的差距，正是大多数现实世界 AI 隐私事件发生的地方。

本文就是关于这个差距的：差分隐私对 LLM 实际承诺了什么，这些承诺在哪里失效，以及团队做出的工程决策——通常是隐性的——如何决定他们的 DP 部署是真正的保护还是表面文章。

每个构建过 LLM 功能的工程师都说过类似的话："我们很谨慎——不会向模型发送 PII。"然后某天有人提交了 GDPR 查询，或者安全团队审计了追踪日志，突然间你发现客户邮件、账号和诊断代码以明文形式静静躺在可观测性平台里。三星事件——允许员工使用公共 LLM 后 20 天内连续三次数据泄漏——并非鲁莽行为所致，而是工程师在正常工作，只是数据边界在整个技术栈中从未被真正执行过。

问题在于，"不要向 API 发送 PII"是一项政策，而非一种控制手段。而政策会在你的系统做任何比单轮聊天机器人更复杂的事情时失效。

你的推理模型在 98% 的情况下能正确识别出数据是敏感的，但它在思维链（chain-of-thought）中泄露该数据的概率却高达 33%。这种差距——即知道某事是隐私与实际保持其私密性之间的脱节——是推理轨迹（reasoning trace）隐私问题的核心，而大多数生产团队尚未为此做好准备。

深度思考（Extended thinking）已成为对准确性要求极高的应用程序的标准工具：客户服务分流、医疗编码辅助、法律文件审查、财务分析。而这些领域恰恰是 Prompt 中数据最敏感的地方。在这些场景中部署推理模型，如果不了解轨迹如何处理这些数据，将面临巨大的暴露风险。

大多数基于推理模型进行构建的团队将隐私视为一个双面问题：清理输入的提示词，清理输出的回复。中间的推理链（reasoning trace）为了可观测性而被完整记录，被提供给下游系统进行调试，有时甚至会被传回给那些要求“查看思考过程”的用户。那一层中间层才是真正的风险所在——而大多数生产部署并未将其视为应有的隐患。

2026 年初的研究量化了从业者一直在口头观察到的现象：大型推理模型（LRM）在中间推理步骤中泄露个人身份信息（PII）的频率高于其最终答案。在一项针对五个开源模型在医疗和金融场景下的测试研究中，结论是明确的——中间推理可靠地浮现了最终回复成功隐瞒的 PII。最终答案被清理了，但推理链没有。

大多数构建 LLM 应用的团队都将隐私视为一个模型问题。他们担心模型知道什么——它的训练数据、它的记忆——却在模型周围的流水线中留下了巨大的漏洞。令人尴尬的事实是，生产环境 LLM 系统中绝大多数的数据泄露根本不是来自模型。它们来自你未经脱敏就索引的 RAG 分块、你逐字写入磁盘的提示词日志、包含数据库凭据的系统提示词，以及被投毒文档劫持以窃取知识库中所有内容的检索步骤。

Gartner 估计，到 2025 年底，30% 的生成式 AI 项目将因为风险控制不足而被放弃。这些失败中的大多数并不是因为模型幻觉——而是源于工程师本以为在掌控之中的系统隐私和合规性故障。