19 篇博文 含有标签「gdpr」

一个删除请求进入了你的队列。用户行使了他们的被遗忘权（Right to Erasure），而在法律上你有一个月的时间让他们的个人数据消失。在常规系统中，这只是一个 DELETE 语句和一个得意的审计日志条目。但在 AI 系统中，这一刻你会发现你的数据并不只存在于一个地方——它已经散布在微调模型的权重中，固化在向量索引中，缓存在十几个检索快照中，并复制到了上季度的评估集中。没有单行数据可以删除。从非常字面意义上的工程层面来看，该用户是无法删除的。

这并非假设。2025 年 3 月，欧洲数据保护委员会（EDPB）在 30 个国家监管机构中发起了一项协调执法行动，专门针对被遗忘权。监管机构已达成一个令人不安的共识：将某人的数据纳入训练属于“处理”行为，因此 GDPR 第 17 条适用于模型，而不仅仅是数据库。每个 AI 团队最终都会面临一个问题：输出抑制（Output Suppression）——即教导模型拒绝谈论某人——是否足够，还是你实际上必须从系统中移除其数据的影响。诚实的答案是，大多数团队从未针对这两种情况进行过设计。

在你公司的内部数据分类政策中，总会有这么一个表格。原始客户文本——支持票据、医疗笔记、聊天记录——被归入“敏感”行，受到加密要求、访问控制和删除服务等级协议（SLA）的保护。然而，还有一个存储着 这些文本对应的 嵌入向量（embeddings）的向量库，它被归类为……什么也不是。衍生数据。匿名数学。只是一堆浮点数。

这种分类是错误的，而且这种错误现在已经得到了实验证明。逆向攻击（Inversion attacks）可以从嵌入向量中重建原始文本——在研究最充分的场景下，92% 的案例可以 准确 恢复 32 个 token 的输入，包括临床笔记中的全名。如果攻击者拿到你的向量后能读出你客户的话，那么你的向量就继承了这些话语的敏感性。监管机构已经开始公开声明这一点，而大多数检索架构尚未对随之而来的后果做好准备：删除请求必须触及每个索引、每个快照和每个衍生工件——而不仅仅是行存储（row store）。

一份客户支持记录离开位于法兰克福的服务器，被拼接成一段提示词 (prompt)，然后跨越大西洋传输到位于弗吉尼亚州的 GPU。模型思考了 800 毫秒。响应返回。从用户的角度来看，什么都没发生 —— 聊天正常进行。从你的监管机构的角度来看，你将个人数据转移到了第三国，而你可能无法说明其法律依据。

这是 LLM 落地过程中演示版本会隐藏的部分。原型调用 api.openai.com 然后上线。接着，来自德国银行、法国医院或你公司法务团队的采购问卷会提出一个原型从未需要回答的问题：推理在哪里发生，谁可以强制访问这些数据？ “供应商符合 SOC 2 标准”是下意识的回答，但这是错误的 —— 它回答的是关于供应商内部控制的问题，而不是关于哪个司法管辖区的法院可以触及你的提示词。

合规计划是对审计员签字通过当天你公司所拥有系统的描述。你公司今天的系统是另一套完全不同的组合，而这两者之间的差距，就是从那时到现在期间每一个上线了新持久化存储的发布版本的表面积。你向客户承诺的删除保证是针对第一套系统的保证，而最终对此进行询问的监管机构，问的将是第二套。

这种失败模式并非删除代码中的 Bug。删除代码本身是正确的。Saga 流程会扇出到数据清单中命名的每一个存储系统，调用每个系统的删除端点，收集每个系统的回执，并在每个回执都返回已签署状态时报告成功。Saga 正在准确执行其被构建时所承担的任务。问题在于，Saga 迭代的是一份 18 个月前的存储系统列表，而智能体平台团队在 6 个月前上线了一个长期记忆功能，却没有任何人将其添加到该列表中。

你的驻留审计追踪了来自租户流量的每一个出站请求，观察它在法兰克福的一个主机名上终止，并签了字。审计对它所测量的一切都是正确的。但它也看错了层级。请求确实去了欧盟。但满足该请求的字节——即服务商哈希并从最近可用节点提取的缓存前缀——却存放在 us-east-1。你的区域端点向你承诺了一个目的地。而缓存什么也没承诺，因为缓存是一个不同的产品，受不同的 SLA 约束，是为成本而非合规而设计的。

客户的审计员发现了它。不是你的。另一个供应商的事件报告提到 Prompt 缓存的放置与推理区域是解耦的，于是客户的 GRC 团队提出了那个显而易见的后续问题：我们的前缀去了哪里？修补这一差距的合同修正案花了 90 天。续约被暂停了。根据他们拿到的文档，编写集成的团队并没有做错任何事。

一个仅针对入站流量运行的 PII 脱敏器就像是安装在管道错误一端的单向阀。它在用户提交的姓名、电子邮件和账号进入日志之前拦截它们。但它对模型的输出无能为力 —— 而现在，模型正是在输出端积极地组合可能包含这些相同标识符的文本，这些内容可能源自 RAG 检索、工具返回、对话历史或用户从另一个租户数据中粘贴的内容。我观察过每一个上线了输入端脱敏器的团队，他们的待办事项中都有一个标记为“输出端对齐”的后续任务。大多数这类任务永远不会关闭，因为在长达六个月的时间里，没有任何事故暴露出这个缺口。六个月后，该任务经过多次重新排序，看起来更像是一个功能需求，而不是缺失的一半安全控制手段。

失败模式是恒定的：输入端脱敏被视为标准的控制手段，因为它的工程问题更简单，审计故事也更容易讲。你编写了一套正则表达式，运行了一个标注好的基准测试，证明了在固定语料库上的精确率和召回率，在特性开关后上线了它，安全评审也将其接受为 PII 边界。输出端则完全没有这些优势。模型的响应是生成性的，表面积是无限的，而且测试方法论 —— “在无限多的上下文中它不应该说什么” —— 在结构上比“我们应该从已知输入中剥离什么”要困难得多。因此，上线入口端的团队将出口端视为未来的工作，而这个未来永远不会到来，直到有客户举报另一个客户的电子邮件出现在他们的对话记录中。

一次客户审计发现，在 Redis 集群中存放了长达 11 个月的逐字记录的用户 PII，而数据驻留团队中没人知道这个集群的存在。系统并未遭到破坏。没有攻击者入侵。这些数据是推理团队为了性能优化而构建并命名为“Prompt 缓存”的服务故意写入在那里的。分析路径上的脱敏工具在此期间运行得非常完美。只是脱敏工具根本没在那条路径上。

尽管如此，违规行为是真实的。根据 GDPR，保留时间超过合同约定的 30 天就已经足够；数据无需泄露即可触发第 33 条规定的通知义务。数据驻留团队的清单列出了每一个日志、每一个仓库、每一个队列——但唯独漏掉了这个缓存，因为在组织架构图中，这个缓存位于推理团队的一侧。每个人都信任的隐私边界直接顺着分析流水线向下延伸，却在大模型（LLM）栈开始的地方止步了。

交付 “面向欧盟客户的 AI” 的团队通常只交付一种驻留控制：锁定在欧盟地区的推理端点。采购团队拿到 DPA，架构图在 “模型托管在法兰克福” 旁边打上绿色对勾，接着发布。架构图中没显示的是：客户的原始查询在前往模型的途中被美国托管的嵌入 API 向量化；查询与之匹配的向量存储的运维平面位于 us-east-1；重排序模型是部署在供应商自选地区的第三方 SaaS；提示词缓存在命中的情况下是按地区键入的，而在未命中的情况下则是全局的；记录检索块的追踪存储有一个 30 天的保留期存储桶，并为了冗余进行跨区域复制。

推理层遵守了驻留规定。而检索流水线甚至不知道自己也是参与者。

这就是大多数 “符合 GDPR” 的 RAG 部署在面临团队甚至没意识到会到来的审计时失败的缺口。修复方案不是针对模型调用增加另一个控制 —— 而是意识到数据驻留是客户字节所接触的每个组件的属性，并且拥有 “LLM” 的团队最多只拥有涉及到的六个表面中的一个。

针对你的智能体记忆层的第一次合规升级，几乎从不以监管机构信函的形式出现。它往往是以你企业级销售工程师发来的一张 Jira 工单的形式出现的，上面写着：“客户的隐私团队正在阻碍合同签署——他们想知道在你的系统中‘忘记我的用户’到底是什么意思，并且他们要求在周五前给出书面答复。”这张工单通常在记忆层发布 6 到 12 个月后送达，而构建该功能的工程团队在读完问题的那一刻就会发现，他们不小心构建了一个没有任何记录管理系统（records-management system）应有原语的记录管理系统。

这是智能体产品中长期记忆的结构性问题。构建它的团队通常会针对记忆功能的卖点进行优化——检索质量、延迟、存储成本，以及让助手感觉很懂用户的个性化体验。在设计评审中，没有人会去估算同时被构建出来的那个并行系统的代价：一个按用户、按租户、跨区域的数据存储，它带有保留义务、删除语义、审计导出要求，而且从第一个用户数据进入其中的那一刻起，监管机构的倒计时就开始了。记忆并不是一个功能。它是每个隐私制度、每份企业采购调查问卷以及每个被遗忘权（right-to-erasure）请求最终都会找上的运营界面（operational surface）。

你的黄金评估集（Golden eval set）是一个你的安全团队甚至不知道其存在的隐私边界。它是通过对生产环境的 Trace 进行采样构建的，这意味着它是一系列精心挑选的真实客户查询集合——通常包含姓名、电子邮件、账号、愤怒的通话记录、输入了一半的信用卡卡号——并配有标准正确回复，最后提交到评估流水线读取的任何存储桶中。

最后一部分正是评估数据具有独特危险性的原因。原始的生产 Trace 之所以敏感，是因为它记录了客户所说的话。而评估案例则以一种全新的方式变得敏感，因为它记录了客户所说的话 加上标注的正确答案。这个标签是一个衍生作品，由某人（通常是标注员或领域专家）有目的地添加。它标志着“这是标准答案”。它赋予了 Trace 原始日志从未有过的生命力——日志保留策略最终会将 Trace 轮转删除，但评估案例现在成为了一个永久的测试 fixture（固定数据），团队致力于保持其测试通过（keeping green）。

一位客户提交了一份主体访问请求（Subject-Access Request），要求删除他们的数据。数据工程师清理了生产数据库、分析仓库、支持工单存档以及冷备。法务团队在数据清单中列出的每个系统都反馈清理完毕。随后，房间里有人提出了一个没人想第一个回答的问题：那模型呢？

三个月前，该客户的支持记录被用于一次微调运行。从那时起，由此生成的适配器（Adapter）就一直在为其他客户提供预测服务，其中嵌入了该客户的措辞、账户名称，偶尔甚至还有权重中的原句。你可以证明数据仓库中的数据已删除。但你无法证明模型中的数据已删除 —— 团队中最诚实的那位成员会大声说出这一点。

你的 AI 功能上线了。用户正在使用它。每一次会话回放、每一次点踩、每一个返回错误答案的请求，都清晰地暴露出它现在的表现与它应有水平之间的差距。信号就在眼前。问题是：你是否可以合法地利用这些信号。

这就是团队撞上合规高墙的地方。这不是一堵理论上的墙——而是实实在在的。仅在 2024 年，欧洲监管机构就开出了逾 12 亿欧元的 GDPR 罚款，OpenAI、Meta 和 LinkedIn 均在被点名之列。大多数执法行动背后有一条共同主线：以原先收集目的之外的方式使用行为数据，或收集了超出运营功能所必要的数据。监管机构并不会因为你的意图是改进模型而非投放广告就网开一面——尽管工程师们往往这样以为。