当公司的机密数据交给 AI 系统处理时，这份数据在整个流程的每一站，分别面临什么风险、又该如何防范？

RAG 的合规之所以比传统数据库更棘手，在于它天然缺乏审计轨迹。一次提问会在几秒内跨多个来源完成读取、检索、汇总，而 GDPR、HIPAA 这类法规要求企业能说清个人数据存在哪、被如何使用。一旦系统在回答里带出了本不该出现的个人数据，事后往往难以证明合规。所以下面按数据的四种"状态"逐一梳理风险，这四种状态（静态、传输、使用、落地）背后是业界通用的安全概念，不过把它们归拢成一份四项清单是本书的讲法，并非某项合规标准（如 ISO 27001、SOC 2）的正式分类。

表里有三处值得单独点破，因为它们最反直觉，也最容易埋雷：

"删除"往往只是假象。 向量数据库出于性能考虑，默认把删除做成元数据层面的"软删除"——把 API 返回无错误当成删除成功，数据其实可能仍物理存在。这与"权重难以定点删除"是同一个痛点在不同存储层的体现，而 GDPR 第 17 条要求的是真正、完整的删除。

脱敏不是一涂了之。 简单涂黑会破坏语义：把姓名或账号直接抹掉，模型也就失去了生成有用回答所需的信息——比如"客户 ___ 的账号 ___ 被重复扣款两次"，姓名和账号一抹掉，模型连"谁的、哪个账号"这个基本结构都读不出来，自然答不好。正确做法是用保留上下文的令牌化替代粗暴删除：把"张三"换成 [姓名_1]、把具体卡号换成 [账号_1] 这样的占位符，句子变成"客户 [姓名_1] 的账号 [账号_1] 被重复扣款两次"——具体是谁、哪个账号，模型看不到（遮住了敏感值），但"这里有一个姓名""这里有一个账号"这个角色信息保留了下来，模型依然能顺着完整的句子结构组织出有用的回答，而不是对着几个空格发呆。

权限默认会丢失。 来自 Confluence、SharePoint、内部 wiki 的文档，一旦转成向量，原有的访问控制就不再随附。这正是"绑定 ACL"必须作为一个额外动作去做的原因——它不会自动继承。

这些并非危言耸听。下一章会换到攻击者的角度，把这些风险再看一遍。

两个最值得记住的结论：

1. 全流程中最敏感的单一动作，是机密内容被拼进完整 Prompt、送往云端模型的那一刻——这是数据真正离开公司掌控的时点。
2. 最易被漏掉的单一风险点，是日志系统——注意力都放在"数据库安不安全"，却忘了日志里也完整存着一份明文对话。

延伸：托管云端模型（MaaS）到底会存下什么？

MaaS（Model-as-a-Service，模型即服务）指通过网络调用的云端模型，而非自建部署。它到底留存什么，是合规评估的关键：

• 权重是只读的：提问的内容不会被写进模型参数、改变模型本身。"模型自己带存储"是常见误解——除非供应商特意拿对话去做后续训练，那是另一回事。
• 提示缓存是易被忽略的短期落点：若供应商开启跨请求的提示缓存（见 3.3），请求开头的部分内容会以 KV cache 形式在其基础设施中短暂驻留。这不等于用于训练或长期留存，但严格说，推理并非完全无状态。
• 真正会长期保留的是日志（完整问答明文）、滥用检测记录、以及（合同允许时）用于训练的数据——是否保留、留多久，取决于合同条款与技术设置。
• ZDR（Zero Data Retention，零数据保留）：一种合同条款，签署后可关闭上述持久化留存。但需确认它是否涵盖提示缓存这类基础设施层的短期驻留，以免留下缺口。OpenAI 的文档就写明：至少对一部分模型而言，启用 ZDR 的组织默认只把缓存放在内存里，不启用 24 小时的扩展保留。³

以 OpenAI 为例：它的 API 自 2023 年 3 月起默认不拿客户数据训练模型，但所有 API 调用都会生成"滥用监控日志"，其中可能包含提示词和回复，最长保留 30 天；要排除这部分，需要申请零数据留存，并经 OpenAI 事先批准。⁴ 所以，"不拿你的数据训练"和"不留存你的数据"是两个独立的问题，评估供应商时要分开问。