第三份副本：向量存储、删除完整性以及 RAG 团队一直忽视的 GDPR 缺口

用户根据 GDPR 第 17 条提交了删除请求。你的团队删除了 Postgres 中的行，清除了 S3 中的缓存文档，并从 CDN 中轮换掉了缓存的 PDF。搞定。隐私团队签字，安全团队签字，工单关闭。六个月后，一名拥有向量索引读取权限的数据分析工程师为了一项聚类实验提取了一组 float[1536] 数组样本，通过公开可用的反演模型（inversion model）运行这些数据，并重建了原始 32-token 文本块中大约十分之九的内容——包括你已经“删除”的文档。没人预料到这一点。没人怀有恶意。流水线完全按照设计运行，只是威胁模型从未将向量存储视为数据副本。

在我见过的几乎每个 RAG 团队中，这种思维误区都是一致的：嵌入（embeddings）被视为不透明的数值产物——是衍生品，而非数据。安全评估批准上线是因为“嵌入不是 PII（个人身份信息）”。隐私评估批准了删除处理，是因为“源文本已不存在”。这两个团队都错了，谁都没有将向量存储建模为用户数据的第三份副本——它紧挨着源数据库和分析仓库，任何拥有索引读取权限的人都可以查询，且由于没有任何工具能识别出 1536 维的浮点向量属于敏感数据，它完全处于所有 DLP（数据泄露防护）扫描器的范围之外。

这篇文章不是另一篇关于“你的 RAG 需要访问控制列表（ACL）”的指南。那样的文章已经有人写过了。本文关注的是删除端：反演攻击相关文献究竟证明了什么，为什么当嵌入持久化存在时，GDPR/CCPA 的删除处理远未达到“擦除”标准，以及如何通过运营规范将向量存储从被遗忘的后门转变为受妥善监管的用户数据副本。

反演攻击究竟能恢复什么

目前最显著的研究成果来自 vec2text 系列工作：将一种迭代优化解码器应用于 OpenAI 风格的句子嵌入，可以从 32-token 的输入中精确恢复约 92% 的原始标记（tokens），并且 BLEU 分数达到 90 多分。这种攻击不需要访问原始编码器。后续研究（如可迁移反演、ALGEN 风格的少样本对齐）表明，攻击者只需针对不同的嵌入模型训练一个千余对样本的替代反演器，即可将其迁移到你的生产环境嵌入 API 中。

实际的理解是：如果你对用户的提示词、工单消息、医生诊断书或合同条款进行嵌入处理，并将生成的向量存储在后续可读取的地方，你就是在存储一份有损但可恢复的源文本副本。“有损”不等于“加密”，也不等于“匿名”。成员推理攻击（membership-inference）和属性推理攻击（attribute-inference）甚至不需要完全重建——它们只需要确认特定记录是否在索引中，或恢复来源的人口统计学特征。这些攻击所需突破的隐私保护屏障甚至更加薄弱。

OWASP 的 LLM08:2025 条目正式将这一类别——向量和嵌入漏洞——与数据投毒和跨上下文泄露并列。这不再仅仅是学术界的冷门关注。它已成为生成式 AI 的十大风险类别之一，且 GitHub 上已有记录在案的攻击代码。

为什么 GDPR 删除会存在漏洞

GDPR 第 17 条（“擦除权”）和 CCPA 的删除权所针对的“个人数据”定义包括衍生数据——即任何可以直接或间接识别个人的信息。反演攻击相关的文献恰恰证明了用户内容的嵌入符合这一定义。但运营流程几乎从未体现这一点。

标准的删除流程通常如下：

• 用户提交请求。
• Worker 从主数据库中删除用户的行。
• 第二个 Worker 使缓存失效并清理文件存储。
• 第三个 Worker 根据保留窗口清理衍生的分析数据和事件日志。

向量存储很少出现在这个清单上。即使在清单上，集成方式通常也只是针对摄取时插入的向量调用 delete_by_id(vector_id)——而且团队往往依赖嵌入服务在源文档和向量之间生成稳定的 ID 映射。如果用户的内容被分成了 10 个向量块，其中 2 个在模型升级后以新 ID 重新嵌入，还有 1 个被复制到了用于离线评估的备份索引中，那么删除调用可能只删除了其中的 7 个。

OWASP AI 安全验证标准（ASVS）的“记忆与嵌入”控制项 (C08) 专门指出了这一点：向量存储必须支持标记删除（tomb-stoning）和硬删除，以确保撤销的向量无法被恢复或重新索引。AWS 关于 Bedrock Knowledge Bases “被遗忘权”的博客文章明确描述了级联删除的挑战——你必须识别出数据块到达的每一个地方（主索引、副本、备份、评估快照，以及可能存在的微调数据集），并从所有这些地方将其删除，然后你还必须重新嵌入那些合法保留但曾与已删除内容切分在一起的文档。

残酷的是：截至本文撰写时，还没有主流商业向量数据库提供“可证明”的删除机制。你可以获得删除 API 和审计日志，但你无法获得加密保证，证明该向量无法从磁盘页面、复制流或备份磁带中恢复。向云数据库寻求此类保证的合规团队碰了壁：删除操作在一个专为快速最近邻搜索而非取证擦除设计的底层结构上，仅仅是一项“尽力而为”的操作。

第三份副本

这是一个有用的威胁模型框架。在任何存储用户内容嵌入（embeddings）的 RAG 流水线中，用户数据（至少）存在于三个地方：

• 源头 —— Postgres 行、S3 对象、CRM 记录。删除机制已被清晰理解。
• 缓存层 —— CDN、Redis、浏览器。由于有 TTL 机制，其删除机制在一定程度上已被理解。
• 向量索引 —— Pinecone、Weaviate、Qdrant、pgvector、OpenSearch。其删除机制很少被清晰理解。

每一份副本都有其自身的访问控制模型、备份方案、保留策略和数据泄露披露影响。第三份副本最常继承自“这只是一个索引，不是数据库”的心智模型 —— 而这正是安全审查出错的地方。

补救措施在技术上并不复杂，更多是组织层面的。从第一天起，就将向量索引视为一级生产数据存储（tier-1 production data store）：

• 如果被攻破，它属于数据泄露披露法律的管辖范围。
• 它属于访问审计的范围（谁读取过；谁列出过）。
• 它属于租户隔离要求的范围（逻辑分区、每个租户的加密密钥、付费客户之间不共享命名空间）。
• 它属于“被遗忘权”流水线的范围，需要进行级联删除，触及主库、副本、备份以及任何派生索引。

大多数团队对关系型数据库已经拥有了这些规范。将它们提升到向量存储层面主要只是文书工作 —— 最困难的部分是第一次建立这些规范。

真正缩小爆炸半径的运营实践

威胁模型框架是必要的，但还不够。有五种值得采用的运营实践，它们通常不会出现在典型的 RAG 发布检查清单上。

租户级的静态向量加密。 使用单一租户密钥对整个索引进行“静态加密”只是账面功夫，而非隔离。索引的备份快照会泄露每个租户的向量。通过使用租户专属密钥，并结合与你现有 KMS 挂钩的信封加密和密钥轮换策略，你可以撤销某个租户的密钥，使其向量在备份中无法被读取 —— 这比 delete_by_id 提供了更强的保障。

采用距离保持方案的应用层加密。 这是密码学界为向量数据开发的路径 —— 近似距离保持加密（approximate distance-preserving encryption），它允许你在加密向量上进行最近邻搜索，而无需向索引暴露明文。这种权衡是真实存在的（索引速度变慢，在已发表的基准测试中召回率下降约 1–3%），但它改变了反向攻击（inversion-attack）的威胁：窃取加密向量的攻击者只会得到一个反向还原为噪声的向量。对于高敏感领域（医疗、法律、金融），这种召回率的权衡通常是正确的选择。

查询向量日志策略。 这一点经常被忽视。当用户发送查询时，你的检索层会将其嵌入并运行搜索。如果你为了调试或分析而记录该查询，你实际上存储了用户内容的另一份嵌入 —— 且通常存储在受控程度低于主向量库的系统（如你的 APM、数据仓库）中。解决方法是：在记录日志前对查询向量进行哈希处理，或者仅存储元数据（时间戳、延迟、top-k ID）而非向量本身。否则，分析层将成为最容易的数据外泄路径。

定期重新嵌入以废除旧产物。 嵌入模型会发生变化。每当你迁移到新模型时，旧向量就会变成孤儿 —— 如果你为了“以防需要回滚”而将它们保留在冷存储中，你实际上将每个用户嵌入内容的保留期限延长到了隐私声明披露的范围之外。定期进行重新嵌入轮换，按计划（通常与隐私声明中声明的保留期挂钩）清除上一代数据，可以弥补这一漏洞。

像审计生产数据库一样审计向量索引的读取访问。 这是一个杠杆率最高、但也最常缺失的规范。大多数向量数据库交付时的权限模型是：数据团队的每个成员都拥有对每个命名空间的读取权限，因为“我们需要它来进行评估”。如果你存储相同数据的关系型数据库不允许这样做，那么向量存储也不应该允许。修复过程可能令人不适 —— 工程师必须提交访问请求，而不是直接查询 —— 但它能彻底改变内部人员违规或开发账号被攻破时的爆炸半径。

组织失效模式

我见过一再重复的模式：一个 RAG 项目通过了标准的治理审查。安全审查得出结论：嵌入（embeddings）不是 PII（个人身份信息），因为“它们不是人类可读的，也不能直接识别身份”。隐私审查得出结论：删除流水线是合规的，因为“源文本已被移除”。从各自的角度来看，每项审查都是合理的，没有哪个团队失职。缺失的是这样一个步骤：如果源文本可以从嵌入中恢复，这是否会改变另一项审查的结论？

考虑到反向还原（inversion）的相关文献，答案是肯定的。但大多数公司的组织形式 —— 安全和隐私作为独立的职能部门，各自审查其负责的部分 —— 默认并不会提出这个问题。解决办法是增加一行政策变更：任何存储用户内容嵌入的机器学习（ML）功能都需要进行联合审查，由两个团队共同签署整体威胁模型，而非仅看局部。

成熟的做法是在隐私声明中明确衍生 PII 的范围：告知用户他们的数据被存储为嵌入，这些嵌入有删除流水线，并说明保留期限。这句话比这一段文字还要短，但它决定了你的合规是“我们合规”还是“我们的合规清晰可见”。

结语

AI 系统中新的隐私边界不再是“模型说了什么”。这个问题已被充分理解、充分监测，并且是行业内每一次提示注入（prompt-injection）和内容安全讨论的主题。普通团队尚未跨越的边界是“嵌入（embedding）记住了什么”。逆向攻击（inversion-attack）文献在三年前就跨越了这一边界。监管机构现在也正在跨越它——最明确地体现在欧盟的执法指南中，将衍生表示（derivative representations）视为第 17 条的适用范围。供应商尚未提供能够弥补这一差距的删除保证，这意味着责任落在了你，即工程师的身上，你需要将向量存储视为数据的一份副本，并将所有现有的数据治理规程扩展到该副本上。

架构上的认知很简单，即使工程实现并不容易：将用户内容的嵌入视为衍生 PII，将向量索引视为一级（tier-1）生产数据存储，并将这第三份副本纳入与前两份副本相同的治理体系中。然后去检查谁拥有你生产环境向量存储的读取权限。这个人数几乎总是过高。