GDPR 的删除难题：为什么你的 LLM 记忆存储是法律风险

大多数构建 RAG 管道的团队对 GDPR 的理解方式是错误的。他们关注推理调用——模型是否生成了 PII？——却忽略了静静地藏在向量数据库中的更严重的风险敞口。每当用户提交一份文档、一张支持工单或一条个人笔记，经过分块、嵌入和索引后，该向量存储在 GDPR 下就成为了个人数据处理器。当用户行使被遗忘权时，"按 ID 删除"并不能解决问题。

被遗忘权不仅仅是从关系型数据库中删除一行数据。由个人数据派生的嵌入向量携带着可恢复的信息：研究表明，句子级嵌入中 40% 的敏感数据可以用简单代码重建，对于较短文本，这一比例高达 70%。派生的表示形式是个人数据，而非经过净化的抽象。GDPR 第 17 条适用于此，监管机构正在密切关注。

为什么向量数据库的设计不考虑删除

近似最近邻搜索的主流范式将向量视为索引后基本不可变的数据。FAISS——为大多数早期向量搜索基础设施提供动力或灵感的库——没有原生的删除操作。删除一个向量意味着重建索引或维护单独的阻止列表——如果删除比例超过索引的 10–15%，查询质量就会下降，直到从头重新索引。

即使是后来添加了删除功能的数据库，通常也将其作为软操作实现：在元数据中将向量标记为已删除，在查询时过滤掉，定期压缩。从性能角度来说，这是正确的技术权衡，但它有一个具体的法律含义：至少在下一个压缩周期之前，用户行使被遗忘权后，数据仍物理存在于存储中。墓碑标记的记录是否满足第 17 条的要求存在真正的争议，大多数数据保护机构尚未发布明确指导。

Pinecone 支持通过单个 API 调用进行基于元数据的删除，对于命名用户来说效果很好。但无服务器 Pinecone 索引根本不支持按元数据删除——只支持按 ID 前缀删除——这意味着你需要在摄入时维护从用户身份到向量 ID 的映射。如果没有做到，删除将成为全表扫描操作，甚至更糟。

更深层的问题不是 API 表面，而是大多数团队在没有用户级隔离的情况下，将数据摄入共享命名空间。当用户要求被遗忘时，如果他们的数据与其他所有人的数据共存于一个扁平索引中，就无法干净地删除他们的向量。

三种真正有效的架构模式

存储层的用户范围命名空间

最可靠的 GDPR 兼容架构是在索引时而非检索时，在物理或逻辑层面分离用户数据。在查询时进行过滤（传递 where user_id = X 条件）并不满足被遗忘权——数据仍然存在。分离必须发生在存储层。

Weaviate 的多租户模型为每个租户提供专用分片：独立的倒排索引、向量索引和元数据桶。删除租户相当于删除一个文件。该系统支持每个集群超过一百万个并发活跃租户。Qdrant 通过带有每租户访问控制的载荷级分区采用了类似方法。如果在架构设计时采用，两种方法都有效。将命名空间隔离改造到共享索引上代价高昂。

实践要求：在摄入时，用来源用户的标识符标记每个向量，并将其路由到用户范围的分区。这在写入时增加了开销，并使跨用户聚合查询变得复杂，但它使删除请求无需维护单独的 ID 映射层即可处理。

嵌入前脱敏

解决删除问题最简洁的方案是一开始就不嵌入个人数据。Tonic.ai 的研究表明，在嵌入前对敏感内容进行脱敏，可以使所得向量的敏感数据恢复率达到 0%，而直接嵌入原始文本时恢复率为 40–70%。事后无法"取消嵌入"姓名或地址；可以防止其进入索引。

嵌入前脱敏通过扫描摄入内容中的 PII 模式——姓名、地址、标识符、财务数据——并在嵌入调用前用确定性占位符标记替换它们来实现。"John Smith 的账户余额为 4200 美元"变为"[PERSON_001] 的账户余额为 [AMOUNT_001]"。嵌入捕获语义结构，而不编码可恢复的个人数据。

确定性标记化在这里至关重要。随机匿名化会破坏跨文档的引用完整性；同一实体应在会话或语料库中始终映射到同一标记，以确保检索仍能正确工作。多个隐私工程库实现了这一点，值得将管道构建为在嵌入前调用它们，而不是作为事后补充。

这种方法需要前期投入于 PII 检测，以处理你的特定数据类型。现成的基于正则表达式的扫描器会遗漏很多内容；使用带有分类提示的次级 LLM 调用进行语义扫描可以捕获更微妙的模式，但会增加延迟和成本。对于任何预期会收到删除请求的数据，这种权衡是值得的。

有界保留的索引墓碑标记

对于摄入时无法脱敏的数据——历史语料库、你无法控制内容的上传文档——索引墓碑标记是备用方案。收到删除请求后立即将向量标记为已删除，在查询时过滤它们，并按照定义的计划（每日压缩、每周完整重新索引）执行物理删除。该计划成为你处理活动记录文档的一部分。

墓碑标记的法律风险是真实存在的：请求和压缩运行之间，数据仍在物理上存储。缓解因素包括：对已删除记录的存储块进行加密（即使存在也无法访问）、文档化的最大保留窗口（尽可能在操作上可行的范围内缩短），以及向审计员证明删除请求收到时间和物理删除确认时间的日志系统。

西班牙数据保护机构 AEPD 于 2026 年初发布了关于智能体 AI 和 GDPR 的详细指南，恰好涵盖了这一场景。在删除请求后以"以防万一"或"性能优化"为由保留数据违反了目的限制和数据最小化原则。压缩窗口需要有可辩护的操作理由，而非无限期推迟。

为什么 RAG 管道是个人数据处理器

有时人们对 RAG 系统的知识库是否构成个人数据处理存在疑惑。答案几乎总是肯定的，如果被索引的文档涉及可识别的个人——这包括支持工单、内部通信、用户生成内容以及大多数企业知识库。

欧洲数据保护监督员识别了 RAG 部署中的具体风险：无意中检索包含在训练语料库中的个人数据、通过描述性输出进行身份推断（即使没有直接标识符也能重新识别），以及通过指示检索系统显示受限信息的文档进行的间接提示注入。这些不是假设的风险，而是已部署系统中出现过的故障模式。

部署 RAG 系统的控制者与其他任何个人数据处理者负有相同义务：处理的合法依据、数据主体权利支持、处理活动记录以及适当的安全措施。如果使用第三方 RAG 或向量数据库供应商，你需要一份数据处理协议，明确处理的性质、涉及的数据类别以及已采取的保护措施。欧洲数据保护委员会 2024 年 12 月的意见明确指出，大型语言模型的匿名化"很少"达到 GDPR 第 4(1) 条规定的真正匿名的标准，这意味着你不能依靠嵌入过程本身来消除合规义务中的个人数据。

机器遗忘的死胡同

面对已训练模型（而非仅推理时 RAG）的 GDPR 删除请求时，自然的直觉是寻找"遗忘"特定数据的技术机制。机器遗忘是一个活跃的研究领域，有几种有前途的方法：负偏好优化、知识差距对齐以及各种基于蒸馏的方法。但没有一种方法在 GDPR 适用的规模下已投入生产。

唯一有保障的遗忘方法是从头重新训练。对于任何商业规模的模型，这意味着每次删除请求需要数周计算和数百万美元的成本。这不是可行的合规机制。研究界对此有所了解，欧洲数据保护委员会也知晓这一点。当前的监管立场实际上要求，如果事后无法满足删除请求，就必须防止个人数据进入模型训练管道——这是一个比表面看起来更难的上游要求。

对于 RAG 系统，实际含义是你的检索层是你拥有控制权的地方，也是你的合规架构必须存在的地方。一旦模型部署，训练时进入模型权重的内容在很大程度上超出了你的操作范围。推理时索引到向量数据库中的内容是你可以用上述模式管理的东西。

GDPR 执法信号

针对 AI 系统的 GDPR 执法已显著加速。自 2018 年以来累计罚款超过 71 亿欧元，仅 2025 年就开出 12 亿欧元。超过 60% 的总罚款金额是自 2023 年 1 月以来征收的——执法体制并非只是理论。

对 LLM 记忆架构师而言最重要的案例，不是针对平台广告定向或密码存储的头条罚款，而是为 AI 特定数据流建立充分合规标准的指导文件和调查。AEPD 于 2026 年 2 月发布的 71 页智能体 AI 指南是任何监管机构发布的关于 AI 记忆系统最详细的数据保护评估。它确立，智能体系统中的每个记忆层——短期上下文窗口、长期向量存储、操作日志——都受数据主体权利约束，包括访问、更正和删除。组织必须有"关于智能体可以存储什么、为何存储以及存储多长时间的明确规则"。

这一框架是有用的工程要求。将记忆视为无需合规的优化层已不再可行。问题不是是否要为删除而设计，而是如何在不破坏系统效用的情况下做到这一点。

上线前需要构建的内容

决定你 GDPR 风险敞口的架构决策几乎都是在设计时做出的。改造代价高昂，且成本随索引中已有个人数据的数量而扩大。

在发布涉及用户数据的 LLM 功能之前：

• 决定命名空间策略。 存储层的每用户隔离，而非过滤时的分段。如果你选择的向量数据库不支持这一点，那就是选型标准。
• 构建嵌入前脱敏管道。 即使是简单的基于正则表达式的 PII 扫描器，也能阻止最常见的个人数据模式进入索引。确定性标记化保留了语义实用性。
• 定义压缩计划并记录在案。 如果有时间限制，墓碑标记是可接受的。"我们在收到删除请求后 24 小时内压缩"是可辩护的立场；"我们在索引太大时压缩"则不是。
• 检测删除请求处理。 你需要一个日志，记录每位用户、每类数据的请求收到时间和物理删除确认时间。这是你应对监管调查的审计跟踪。
• 审查供应商数据处理协议。 如果你的向量数据库供应商无法承诺具体的删除时间线并提供确认，你就承担着应反映在风险登记册中的法律风险敞口。

被遗忘权不会消失，对最大 AI 市场拥有管辖权的监管机构正在积极开发专门针对记忆系统的执法框架。现在构建删除感知基础设施的团队，将来不必在合规命令下重新构建。