构建符合GDPR的RAG管道：编辑、同意与向量数据库中的被遗忘权

检索增强生成已成为企业AI系统在专有数据上回答问题的默认架构。模式很简单：将文档分块，嵌入到向量存储中，在查询时检索相关块，然后将其传递给语言模型进行合成。

问题在于这种模式是为准确性设计的，而非隐私。向量数据库存储源文本的密集数值表示，这些表示可以编码个人数据——姓名、电子邮件地址、医疗详情、金融标识符——以事后几乎无法选择性移除的方式。如果你正在构建一个涉及欧盟居民个人数据的RAG管道，你需要从一开始就建立一个符合GDPR的RAG管道，而不是事后补加的合规改造。

为什么向量存储会产生GDPR问题

GDPR赋予数据主体一系列权利，这些权利与大多数RAG系统的构建方式直接冲突。理解摩擦点是解决它们的第一步。

删除权（第17条）。 当数据主体请求删除其个人数据时，你必须能够将其移除。在关系数据库中，这意味着删除行。在向量存储中，个人数据与其他语义内容一起编码在嵌入向量内。你无法从一个同时编码了周围段落含义的1536维向量中精确地移除一个人的姓名。你的选择是删除整个块（丢失有用的非个人上下文）或重新嵌入不含个人数据的块（大规模操作时成本高昂且容易出错）。

同意追踪（第6条）。 系统中的每条个人数据都必须有合法的处理依据。向量存储没有同意记录的原生概念。它们存储向量和可选的元数据——没有内置机制来记录你为什么被允许处理特定嵌入，或在之后使该许可无效。

目的限制（第5(1)(b)条）。 为某一目的收集的个人数据不能在未获得额外同意的情况下被重新利用。当你将客户支持对话记录嵌入RAG系统用于产品改进时，你可能正在违反数据最初收集的目的。向量存储不追踪目的——它只是存储嵌入。

存储限制（第5(1)(e)条）。 个人数据不得保留超过必要的时间。向量存储在设计上倾向于追加。大多数团队从不删除嵌入。没有TTL机制，没有自动过期，没有内置的保留策略执行。

数据主体访问请求（第15条）。 当有人询问你持有他们哪些个人数据时，你必须能够回答。在向量存储中搜索"与张三相关的所有数据"不是一个简单的查询——嵌入是语义化的，不是结构化的。相似性搜索可能会显示相关块，但不能保证完整性。

构建带有PII编辑的RAG的最佳方式

最有效的策略是确保个人数据从一开始就不进入向量存储。如果你的嵌入不包含PII，那么删除请求就无需擦除任何内容，向量层的同意追踪变得不必要，针对向量存储的数据主体访问请求不会返回任何个人信息。

这就是"先编辑后嵌入"模式，它改变了整个管道的合规态势。

架构概览

管道有四个阶段，编辑插入在摄取和嵌入之间。

阶段1——文档摄取。 源文档从任何来源进入管道——文件上传、API集成、数据库导出。此时，文档包含明文个人数据。你将原件存储在受控的、访问受限的文档存储中，并有完整的审计日志。

阶段2——PII编辑。 在任何分块或嵌入发生之前，每个文档都经过PII编辑层。该层识别并移除个人数据——姓名、地址、电话号码、电子邮件地址、国家标识符、金融账号和健康信息。编辑引擎将每个识别的实体替换为占位符标记。占位符标记与原始值之间的映射单独存储在加密查找表中，并有严格的访问控制。

这就是Ertas PII编辑器在架构中的位置。它在本地运行，因此文档在编辑过程中永远不会离开你的基础设施。没有向第三方编辑API的跨境数据传输。编辑器生成每个已识别和已编辑实体的审计记录，这是你向监管机构证明GDPR合规所需的。

阶段3——分块和嵌入。 经过编辑的文档被分块并嵌入到你的向量存储中。由于PII已被移除，嵌入编码的是不含个人数据的语义含义。你的向量存储现在从构建上就符合GDPR——没有需要删除的个人信息，嵌入层面无需追踪同意，也没有PII会在响应访问请求时被暴露。

阶段4——查询时检索和再水化。 当用户查询RAG系统时，从向量存储中检索相关块。如果用例需要响应中包含原始个人数据（且用户有授权），占位符标记可以从加密查找表中再水化。如果用例不需要个人数据，编辑后的块直接传递给语言模型。

处理数据主体访问请求

根据GDPR第15条，数据主体可以请求获取你持有的所有个人数据的副本。使用"先编辑后嵌入"架构，你的响应工作流程很清晰。

向量存储不包含个人数据，因此被排除在DSAR范围之外。加密查找表包含占位符与原始PII之间的映射——这可以按数据主体标识符搜索。原始文档存储包含源文档——这些可以通过标准数据库查询搜索。你的审计记录准确显示哪些文档被处理、编辑何时发生以及识别了哪些实体。

这比试图在向量数据库中搜索"与此人相关的所有内容"要简单得多，后者在技术上不可靠且在法律上不充分。

处理删除请求

当数据主体根据第17条行使被遗忘权时，工作流程同样直接。

从加密查找表中删除该主体的条目。从原始文档存储中删除或编辑该主体的数据。向量存储不需要任何操作——它不包含个人数据。在审计记录中记录删除操作以备合规文档。

与替代方案对比：没有预嵌入编辑，针对RAG系统的删除请求意味着识别每个可能包含该主体数据的块（使用语义搜索不可靠），删除或重新嵌入这些块（成本高昂且可能破坏检索质量），以及向监管机构证明你找到了所有内容（无法保证）。

同意追踪和目的限制

同意管理属于文档存储层，而非向量存储层。当文档进入管道时，记录处理的合法依据、数据收集的具体目的、任何同意记录或合法利益评估，以及保留期限。

这些元数据随文档在管道中流转。如果同意被撤回，你从源存储中移除文档，删除查找表中的相应条目，如果目的限制要求，还可以选择从向量存储中移除相关的（已经不含PII的）块。

由于编辑步骤被记录，你可以向监管机构准确展示哪些文档在哪种合法依据下被处理，以及何时处理的。

存储限制执行

在文档存储层面实施保留策略。当文档的保留期到期时，从源存储和查找表中删除它。向量存储中已编辑的嵌入可以保留更长时间，如果它们服务于合法目的——由于不包含个人数据，GDPR存储限制约束会放宽。

这给你一个实际的平衡：你的RAG系统在嵌入有用的期间保留其知识库，同时个人数据按照你的保留计划自动清除。

RAG向量存储GDPR合规实践

合规RAG管道与不合规管道之间的区别不在于你选择的向量数据库或使用的嵌入模型。而在于个人数据是否到达了向量存储。

在嵌入之前编辑PII消除了最困难的GDPR挑战——从密集向量中选择性删除、跨分布式嵌入的同意追踪，以及访问请求的完整性保证。当向量存储根本不包含个人数据时，这些问题变得微不足道。

在本地运行编辑步骤，正如Ertas PII编辑器所支持的，消除了将个人数据发送给第三方处理者进行编辑的次要合规风险。数据留在你的基础设施边界内，编辑在本地进行，审计记录在你的控制之下。

如果你正在构建一个将处理欧盟居民个人数据的RAG管道，首先设计编辑层。当向量存储从一开始就是干净的，下游的一切都会变得更简单。