一位客户提交了一份主体访问请求（Subject-Access Request），要求删除他们的数据。数据工程师清理了生产数据库、分析仓库、支持工单存档以及冷备。法务团队在数据清单中列出的每个系统都反馈清理完毕。随后，房间里有人提出了一个没人想第一个回答的问题：那模型呢？
三个月前，该客户的支持记录被用于一次微调运行。从那时起，由此生成的适配器（Adapter）就一直在为其他客户提供预测服务，其中嵌入了该客户的措辞、账户名称，偶尔甚至还有权重中的原句。你可以证明数据仓库中的数据已删除。但你无法证明模型中的数据已删除 —— 团队中最诚实的那位成员会大声说出这一点。
这是每个基于客户数据进行微调的团队最终都会遇到的失效模式，通常第一次发生是在最糟糕的时刻。那些在收到第一个请求之前就划定好范围的团队有机会做出妥善回答。而那些没准备好的团队，最终只能在截稿压力下在两个糟糕的选项中做出选择：要么进行一次什么都没删除的诚实披露，要么进行一次耗时一个季度的紧急重建。
为什么“从模型中删除”不是同一种操作
在你的隐私团队之前处理过的每一个系统中，删除都是一种行操作。你找到以客户为键的记录，删除它们，验证它们已消失，然后签字确认。语义非常清晰，因为存储是结构化的：数据以离散单元的形式进入，也以离散单元的形式退出。
模型不是行存储。一旦某行数据进入损失函数，它就会随同其他数百万行数据一起，被抹在参数矩阵中。客户的信息并没有存储在一个贴着他们邮箱标签的内存单元里 —— 它是权重矩阵中的一个扰动，在处理该批次数据的那天对梯度做出了贡献。对于微调后的适配器，不存在 DELETE WHERE customer_id = X，因为适配器没有 WHERE 子句。
大多数监管机构在原则上理解这一点。欧洲数据保护委员会（EDPB）2025 年 1 月关于数据主体权利的指南承认，AI 系统带来了新的技术挑战，且 GDPR 第 17(3) 条包含一项“不成比例的努力”（disproportionate effort）例外，一些团队希望能以此为依靠。但是，“我们探索了替代方案，但它们太贵了”这一立场只有在你确实探索并记录了这些方案时才是站得住脚的。一个在沟通时没有任何血缘追踪（Lineage）、没有可提取性测试、也没有考虑过任何替代方案的团队，会发现很难证明“努力不成比例”的论点。
在请求到来前，你希望已经构建好的血缘链
要回答“这个客户的数据是否在这个制品中？”你所需的最小制品是一个连接原始数据与部署推理的血缘链。这条链条大致包含六个环节：
原始摄取 ：每条记录都带有客户 ID 和时间戳，且这些标识符在随后的每一次转换中都得以保留。训练分片 ：用于特定训练运行的语料库快照经过哈希处理并命名，客户 ID 到分片的映射是可查询的。预处理流水线 ：从原始数据到 Token 的确定性转换是版本化的，版本号与分片哈希一起记录。检查点 ：模型制品在其元数据中携带训练分片哈希和预处理版本，而不只是记录在 Wiki 页面上。部署的适配器 ：决定哪个适配器响应请求的路由层可以指明构建该适配器的检查点，且该名称可以通过链条向后溯源。实时推理 ：每条请求日志都带有服务它的适配器 ID，因此在使用包含已删除客户数据的适配器时，事后是可以审计的。
拥有这条链条的团队可以在一个下午回答律师的问题：“是的，该客户的数据存在于适配器 A、C 和 D 中；这是每个适配器的部署状态；这是目前由它们提供服务的客户。”没有这条链条的团队，最终只能在截稿期临近时，从 S3 的时间戳和 Slack 消息中进行逆向工程。
构建这条链条的工作并不光鲜，且大多发生在训练流水线的边界处。人们很容易诱惑于推迟这项工作，因为从来没有客户问过，而且团队也无法量化节省的成本。触发因素通常是第一个请求。那些推迟了这项工作的团队会发现，他们的预处理流水线将客户 ID 转换成了仓库不再识别的格式，某个训练分片是由一个已经离职的外包人员组装的，而目前在生产环境中的适配器是基于一个血缘关系为“我觉得 Karen 那周运行过它”的检查点构建的。
四种政策选择，以及每种选择的代价
一旦客户的数据进入了微调后的制品，你就有四个实质性的选项。没有一个是免费的，团队的工作是慎重选择，而不是随波逐流。
针对每次擦除请求进行重新训练。 这是合规性最高但也最昂贵的姿态。它还有一个上限：如果你的客户群足够大，产生的删除请求很频繁，你花在重建上的时间会比提供服务的时间还要多。对于训练运行只需一个周末的模型，这可能行得通。对于需要一个季度的模型，这行不通。
累积擦除请求并按计划重新训练。 这是用延迟换取成本：你告诉客户他们的数据将在（比如）90 天内从活跃模型中删除，然后每季度根据累积的删除请求重新构建。如果团队决定继续进行微调，大多数团队最终会转向这种方式。代价是你现在运行的 AI 系统中明知包含客户要求删除的数据，并将法律风险推入了一个记录在案的保留期。这个保留期必须写进你与客户签订的合同中，而不是为了应对请求临时编造。
接受记忆化风险并在 DPA 中记录。 一些团队采取的立场是，微调后的模型是一个派生的统计聚合，单个数据点在实践中是不可提取的，因此他们不会重新训练。只有当模型确实没有在个人层面进行记忆时，这才是站得住脚的立场 —— 这意味着团队必须运行提取测试，记录结果并进行更新。2025 年关于从生产语言模型中提取训练数据的研究不断证明，即使是经过良好对齐的模型，在合适的提示词下也会泄露逐字的训练内容，因此“实践中不可提取”的说法如果没有持续测试就会过时。监管机构会接受有证据的团队的论点，而拒绝那些只会空谈的团队。
完全避免基于客户数据进行微调。 这是架构上最干净的答案。团队承诺绝不让客户数据接触损失函数 —— 微调运行在合成数据、内部生成的示例，或通过具有有限 Epsilon 的差分隐私训练流水线处理后的客户数据上。客户的数据存在于检索索引中，而不是权重中。这样删除就又变回了行操作，因为个人数据从未被编码进权重。代价是模型质量：能够接触到真实客户措辞的微调模型通常优于不接触的模型。选择这条路的团队通常会接受质量损失，并在其他方面进行补偿，通常是通过更好的检索和更强大的系统提示词。
机器反学习并非营销宣传中所说的那种“逃生门” 人们很容易在研究了机器反学习 (machine-unlearning) 领域后得出结论，认为技术方案已经在路上了。它确实在路上，但研究文献与监管机构认为的“充分”之间存在着巨大的鸿沟，足以引发一场持续整个季度的严重事故。
坦率地说，近似反学习技术可以减少特定训练数据对模型行为的影响，通常不需要完全重新训练。但它们无法可靠地保证数据已经以监管机构所定义的“擦除 (erasure)”意义上消失了。Grimmelmann 关于反学习能做什么和不能做什么的论文观点很直接：机器反学习是一种有用的安全原语 (safety primitive)，但它不等同于删除操作，将两者混为一谈会增加法律风险，而不是降低风险。2024 年关于反学习技术的综述文献也提出了同样的观点——目前还没有通用的方法来验证反学习是否成功，且现有的验证方法之间也存在分歧。
对于企业团队来说，这意味着反学习应该与重新训练和 DPA 语言更新一起放在工具箱中，而不是作为它们的替代品。你可以用它在计划的重新构建之前的窗口期内降低风险。但当监管机构询问数据是否已删除时，你可能无法将其作为唯一的答案。
现已出现在每份企业合同中的采购条款 对话已经从隐私团队转移到了采购部门。在 2025 年和 2026 年签署 AI 供应商合同的客户越来越多地要求以书面形式明确：如果他们要求收回数据，数据会发生什么。仅回答“我们将从生产存储中删除”已不再足够——现在的采购问题会写道：“还有你们的微调模型、适配器以及任何从中衍生的工件。”
OpenAI 的数据处理附录 (DPA) 和类似的企业 DPA 已经演变为直接解决这一问题：默认情况下，客户内容不会用于训练或微调底层模型，任何对此类用途的授权 (opt-in) 都与主服务协议是可分离的。如果供应商在没有明确、可分离的授权情况下利用客户数据进行微调，那么他们就已经脱离了当前合同市场的趋势。
对于那些确实利用客户数据进行微调的团队来说，这意味着销售流程发生了变化。数据使用条款不再是 MSA 后面的细枝末节，而是一个采购门槛。企业客户会很早就提出这个问题，而如果答案中没有一个可信的擦除方案，这正开始成为一个阻碍交付 (stop-ship) 的问题。在第一个大客户提出要求之前就解决这一问题的团队，将能够自主设计架构，而不是在最后期限前进行被动改造。
本季度按优先级排序的行动指南 如果你利用客户数据进行微调，且尚未收到第一个擦除请求，那么预期价值最高的行动顺序大致如下：
构建溯源链 (Lineage Chain)。 即便是部分的溯源也比没有好。在训练分片上添加哈希，记录适配器到检查点 (checkpoint) 的映射，在推理追踪中记录适配器 ID。这是后续每一步都依赖的基础。明确制定政策。 从四个选项中选择一个并记录下来——写进 DPA、工程操作手册以及面向客户的隐私文档中。最糟糕的姿态是“等事情发生时再想办法”。对当前的微调工件运行提取测试。 如果你打算声称个人数据是不可恢复的，你需要证据。如果测试显示数据是可恢复的，那么那四个选项中究竟哪一个才是真正站得住脚的，就会随之改变。准备好 DPA 语言。 无论你选择哪种政策，合同都必须与之匹配。一旦客户的理解与你的不同，DPA 中的模糊之处就会变成法律风险。将下一次训练视作第一次具有完整溯源的训练。 你无法为已经完成的运行补全溯源，但你可以确保从现在开始的一切都是可追溯的。切换得越快，遗留债务的窗口就越小。 所有这一切背后的认知应该是：微调对于个人数据来说是一扇单向门。一旦一条数据进入了损失函数，“删除”就变成了重新构建而非简单的抹除。任何将模型仅仅视为另一个数据存储的团队，最终都会发现其合规承诺在他们忘记映射的存储层失效了。在第一个请求到来之前就界定好范围的团队可以自由选择架构；而没做准备的团队最终只能向监管机构解释，为什么他们的删除按钮实际上并没有删除任何东西。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
