16 篇博文 含有标签「gdpr」

当你的第一个微调模型上线生产环境时，你的权重就成了一种你的隐私计划从未编目过的新型记录。进入训练组合的客户服务记录不再仅仅是数据库中你可以 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 条适用于此，监管机构正在密切关注。

当你在多个区域运行无状态 HTTP API 时，路由问题基本上已经解决了。在前面放一个全球负载均衡器，按地理位置分配请求，最糟糕的情况也不过是缓存项稍微过时。任何副本都可以处理任何请求，并获得相同的结果。

LLM 推理打破了每一个假设。一旦你添加了提示词缓存（Prompt Caching）——你肯定会加，因为缓存命中和未命中的成本差异大约是 10 倍——你的服务就会以大多数基础设施团队预料不到的方式变得有状态，直到他们在第二个区域看到延迟数据退化。

大多数团队发现他们的 AI 智能体存在 GDPR 问题的方式都是错误的：当一个数据主体提交删除请求时，法务团队询问哪些系统持有该用户的数据，而工程团队开出的工单最终演变成了一场长达六个月的审计。个人数据散落在对话历史中、向量存储的某个角落、可能缓存的工具调用输出中，甚至可能嵌入在微调后的模型检查点里 —— 却没有任何人事先对此进行梳理。

这不是配置上的疏忽，而是架构上的缺失。决定你的 AI 系统是否具备合规性的决策，通常在构建的头几周就已经做出，远早于法务部门找上门来。本文涵盖了受监管行业工程师在将 AI 智能体投入生产环境之前需要解决的四个结构性冲突。