你无法删除的用户：AI 系统中的被遗忘权

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

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

这种挑战让人措手不及的原因在于，“删除数据”是一个深深植根于我们构建软件方式中的假设，以至于我们从未察觉。关系型数据库为我们提供了参照完整性和级联删除。对象存储为我们提供了生命周期策略。我们建立了一整个合规产业，其前提是数据是“可寻址的”——即如果它存在，你就可以指向它并将其移除。机器学习悄然打破了这一前提。模型并不存储你的记录；它存储的是这些记录的统计阴影（Statistical Shadow），分布在数十亿个参数中，且没有指向个人的索引。遗忘不再是一个查找操作，而变成了一个研究课题。

副本潜伏在何处

在争论“机器遗忘（Unlearning）”还是“抑制（Suppression）”之前，你必须找到所有东西。这是大多数团队低估的一步，因为在 AI 流水线中，同样的个人数据会扩散到那些看起来不像数据存储的地方。

一个用户的信息通常会落在至少七个不同的位置。训练语料库和任何微调数据集是显而易见的。但还有 RLHF 和偏好数据，用户的交互在这里塑造了奖励信号；为了调试和分析而捕获的聊天日志和遥测数据；悄无声息地复制了生产流量的评估和黄金数据集；驱动 RAG 系统的检索索引（通常是向量数据库）；以及衍生缓存，包括语义缓存、Prompt 缓存和物化检索快照。仅仅触及主数据库的删除操作会留下其他六个副本，根据监管机构的定义，每一个副本仍在处理个人数据。

因此，AI 的数据映射必须是刻意为之并持续维护的，而不是在请求到来时惊慌失措地去重建。实际的做法是在摄取时为数据标记主体身份（Subject Identity），并将该标签传播到每一个衍生工件中——每一个 Embedding、每一个微调分片、每一个评估快照都带有一个指向其来源用户的反向引用。如果没有这种血缘关系（Lineage），你就是在法律期限压力下进行取证考古。有了它，删除请求就变成了一个扇出查询，而不是一场调查。

假装遗忘的向量索引

最危险的缺口是那个看起来已经解决的缺口。你在向量库上调用 delete(ids=[...])，记录从查询结果中消失，然后大家各忙各的。在底层，大多数基于 HNSW 索引构建的向量数据库并不会擦除任何内容。它们只是翻转一个元数据标志（Flag），以便未来的搜索跳过该条目，但原始向量仍保留在磁盘上的索引文件中，物理上没有变化。这是一种伪装成彻底删除的“软删除”。

这种区别并非学术上的抠字眼——它是一个现存的攻击面。Embedding 并不是文本的匿名哈希；它们是有损但可逆的表示，且逆向技术已经变得异常强大。针对 HNSW 库中软删除 Embedding 的研究表明，通过在存储层读取原始索引文件（完全绕过 API），攻击者使用现成的逆向模型可以恢复传记数据中约四分之一的精确姓名和近一半的地理位置，并对患者年龄和性别等结构化字段达到 100% 的恢复率。在人脸 Embedding 上，Top-1 身份恢复率达到了 99%。那个“已删除”的用户一直是可以被重构的。

这里的监管标准非常明确：EDPB 已经表示，删除必须是可验证且不可逆的，仅从查询结果中抑制记录并不满足第 17 条的要求。软删除正是他们告诉你的“不足够”的做法。如果你的合规方案是“我们调用了删除 API”，那么你离审计发现只差一次存储层检查。处理 Embedding 的正确做法是假定它们承载着与其编码的原始文本相同的机密性，并使删除在物理上真实发生——例如通过重写索引的压缩合并（Compaction），或使用能让残留字节变得毫无意义的加密方法。

抑制、删除或遗忘

一旦你找到了副本，你将面临一个真正的工程抉择分叉点，而正确的答案取决于数据存储的位置以及你需要的保证强度。

抑制 (Suppression) 是最快但也最弱的手段。你将个人添加到黑名单中，使模型拒绝展示关于他们的信息，或者在查询时从检索结果中过滤掉他们的记录。这是即时且可逆的，因此非常适合作为第一反应——你可以在收到请求后的几分钟内完成“止血”。但底层数据仍然存在，模型的参数没有改变，越狱 (jailbreak) 或存储层读取仍然可能导致数据暴露。抑制只是争取了时间；它并没有履行删除的义务。

流水线删除 (Pipeline deletion) 是诚实的基准线：物理上从你映射的每一个存储点（语料库、日志、评估集和索引）中移除该用户的记录，采用硬删除 (hard deletes) 和墓碑标记 (tombstoning)，确保没有任何内容可以被重新索引或恢复。除了训练好的模型本身，这就是核心工作，而且这主要是一个管线工程和血缘追踪 (lineage) 问题，而非研究问题。

机器遗忘 (Unlearning) 是当影响已经固化在权重中，且从头开始重新训练不可行时所采取的手段。原生重训是黄金标准，通常仅因成本原因就无法考虑；你不会因为一个用户选择了退出就去重建一个基础模型。机器遗忘尝试以低廉的成本移除特定样本的影响。目前最具生产力价值的模式仍然是 SISA —— 分片 (Sharded)、隔离 (Isolated)、切片 (Sliced)、聚合 (Aggregated) —— 你将训练数据分成互不相交的分片，每个分片训练一个子模型，然后进行聚合。因为每个数据点的影响被限制在单个分片内，删除它意味着只需要从检查点重新训练该分片，而不是整个模型。据报道，重训速度可以提升 55–65%，而准确率损失不到 1%。问题在于 SISA 是你必须在训练 之前 做的架构决策；你无法将其强加给一个已经作为单体训练好的模型。

2025 年的务实姿态是结合这三者：立即抑制以满足截止日期并停止暴露，从每个流水线存储中删除作为真正的补救措施，并将机器遗忘或针对性重训留给监管机构或风险评估真正要求模型本身“遗忘”的情况。

预先设计可遗忘性

能够优雅处理数据擦除的团队，是那些将其视为架构需求而非合规补救措施的团队，而他们动用的最廉价杠杆就是密码学。

加密粉碎 (Crypto-shredding) 将删除问题从内向外翻转。与其搜寻并物理擦除用户数据的每一个副本，不如在摄入时使用“每用户一密钥”的方式对每个用户的数据进行加密。当删除请求到达时，你只需销毁该特定密钥。密文可以保留在原处——无论是在不可变日志、仅追加的事件存储，还是在无法进行手术式编辑的备份中——因为没有密钥，它在密码学上与随机噪声无异。这就是你在从未设计过删除单行数据的系统中满足 GDPR 第 17 条要求的方法，它也可以自然地扩展到嵌入 (embeddings)：在每主体密钥下对向量进行加密，并在删除时丢弃密钥，这样 HNSW 索引中的残留字节就会在毫秒内变得不可恢复，而无需进行完整的索引重建。

更广泛的原则是：可遗忘性是你内置的属性，而不是你稍后运行的程序。 这意味着从数据摄入到每一个衍生制品都要保持主体级别的血缘追踪 (lineage)；当你确信会基于用户数据进行微调时，优先选择 SISA 等架构；将检索索引视为受实际删除约束的数据存储，而不是简单的软标记；并为每个缓存和快照设置有效期和负责人，以免副本悄悄累积的速度超过你的删除速度。这也意味着在你的模型匿名化评估中保持诚实：EDPB 的第 28/2024 号意见书明确指出，不能假定基于个人数据训练的模型是匿名的，你必须证明重新识别的可能性是 微乎其微 的——这比“我们没有存储姓名”的标准要高得多。

令人不安的事实是，整个行业建立 AI 系统的假设是数据一旦摄入就是永久资产——而法律现在断言，数据是具有有效期的负债，且有效期由用户控制。你可以继续将擦除视为每次请求降临时都要进行的火警演习，也可以在下一个模型训练之前决定，进入系统的每一条个人数据都应该有一条清晰的退出路径。能够行使这项权利的用户不会变少。为那些你目前无法执行的删除操作进行设计吧，因为请求已经在某人的队列中了。