当被遗忘权遇上微调：当删除止于快照

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

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

这是每个基于客户数据进行微调的团队最终都会遇到的失效模式，通常第一次发生是在最糟糕的时刻。那些在收到第一个请求之前就划定好范围的团队有机会做出妥善回答。而那些没准备好的团队，最终只能在截稿压力下在两个糟糕的选项中做出选择：要么进行一次什么都没删除的诚实披露，要么进行一次耗时一个季度的紧急重建。

为什么“从模型中删除”不是同一种操作

在你的隐私团队之前处理过的每一个系统中，删除都是一种行操作。你找到以客户为键的记录，删除它们，验证它们已消失，然后签字确认。语义非常清晰，因为存储是结构化的：数据以离散单元的形式进入，也以离散单元的形式退出。

模型不是行存储。一旦某行数据进入损失函数，它就会随同其他数百万行数据一起，被抹在参数矩阵中。客户的信息并没有存储在一个贴着他们邮箱标签的内存单元里 —— 它是权重矩阵中的一个扰动，在处理该批次数据的那天对梯度做出了贡献。对于微调后的适配器，不存在 DELETE WHERE customer_id = X，因为适配器没有 WHERE 子句。

大多数监管机构在原则上理解这一点。欧洲数据保护委员会（EDPB）2025 年 1 月关于数据主体权利的指南承认，AI 系统带来了新的技术挑战，且 GDPR 第 17(3) 条包含一项“不成比例的努力”（disproportionate effort）例外，一些团队希望能以此为依靠。但是，“我们探索了替代方案，但它们太贵了”这一立场只有在你确实探索并记录了这些方案时才是站得住脚的。一个在沟通时没有任何血缘追踪（Lineage）、没有可提取性测试、也没有考虑过任何替代方案的团队，会发现很难证明“努力不成比例”的论点。

在请求到来前，你希望已经构建好的血缘链

要回答“这个客户的数据是否在这个制品中？”你所需的最小制品是一个连接原始数据与部署推理的血缘链。这条链条大致包含六个环节：

1. 原始摄取：每条记录都带有客户 ID 和时间戳，且这些标识符在随后的每一次转换中都得以保留。
2. 训练分片：用于特定训练运行的语料库快照经过哈希处理并命名，客户 ID 到分片的映射是可查询的。
3. 预处理流水线：从原始数据到 Token 的确定性转换是版本化的，版本号与分片哈希一起记录。
4. 检查点：模型制品在其元数据中携带训练分片哈希和预处理版本，而不只是记录在 Wiki 页面上。
5. 部署的适配器：决定哪个适配器响应请求的路由层可以指明构建该适配器的检查点，且该名称可以通过链条向后溯源。
6. 实时推理：每条请求日志都带有服务它的适配器 ID，因此在使用包含已删除客户数据的适配器时，事后是可以审计的。

拥有这条链条的团队可以在一个下午回答律师的问题：“是的，该客户的数据存在于适配器 A、C 和 D 中；这是每个适配器的部署状态；这是目前由它们提供服务的客户。”没有这条链条的团队，最终只能在截稿期临近时，从 S3 的时间戳和 Slack 消息中进行逆向工程。

构建这条链条的工作并不光鲜，且大多发生在训练流水线的边界处。人们很容易诱惑于推迟这项工作，因为从来没有客户问过，而且团队也无法量化节省的成本。触发因素通常是第一个请求。那些推迟了这项工作的团队会发现，他们的预处理流水线将客户 ID 转换成了仓库不再识别的格式，某个训练分片是由一个已经离职的外包人员组装的，而目前在生产环境中的适配器是基于一个血缘关系为“我觉得 Karen 那周运行过它”的检查点构建的。

四种政策选择，以及每种选择的代价

一旦客户的数据进入了微调后的制品，你就有四个实质性的选项。没有一个是免费的，团队的工作是慎重选择，而不是随波逐流。

加载中…