在 RAG 系统中，知识库是回答准确性的根基，同时也往往是企业最敏感的数据资产。客户信息、内部报价、未公开的技术方案、合规审查记录——这些内容一旦泄露，损失远超一次回答错误。因此，数据安全从一开始就不能被视为附加功能，而应是整个 RAG 架构设计的前置约束。
RAG 在数据安全方面的核心原则可以概括为两点：私有数据不出域，访问权限精细控制。
24.1.1 私有数据不出域：架构上的天然隔离
与直接使用公有云大模型服务最大的不同在于，RAG 将知识存储与模型推理做了物理或逻辑上的分离，这为数据不出域创造了条件。
典型的部署模式是：
- 向量数据库、文档存储、嵌入模型等涉及原始数据的组件，全部部署在企业自己的私有环境（本地服务器、私有云或受控的 VPC）中。
- 只有当需要进行最终答案生成时，才将检索到的文本片段以加密方式发送给大模型（无论是本地部署的开源模型，还是经过合规评估的公有云 API）。
- 如果企业选择完全本地化方案（例如使用 LLaMA、ChatGLM 等私有部署模型），原始文档甚至可以做到全程不离开内网。
这种做法从根本上避免了将整个知识库上传至第三方平台的风险。检索过程产生的向量和中间结果也都留在可控环境中，不存在被外部服务商用于训练或分析的隐患。
实用考量：
- 对于高敏感数据（如个人身份信息、商业机密），可以在切片入库前进行离线数据脱敏。例如将真实姓名替换为代号、金额模糊化，生成的向量本身就不再携带敏感原文。
- 即使调用外部模型服务，也应选择承诺“不记录、不利用 API 数据训练”的供应商，并签署数据处理协议（DPA），从法律和技术两个层面构筑防线。
24.1.2 访问权限控制：谁能问、谁能答、谁能看
知识不出域保障了存储安全，而访问权限控制则决定了在不同使用者之间，信息如何被恰当隔离。
1. 用户身份与文档级权限映射
RAG 系统通常服务于企业内部不同角色：普通员工、部门经理、合规审计员等。他们能问的问题、应获得的答案范围是不一样的，因为其可查阅的知识文档本身就是不同的。权限控制的关键在于：检索结果必须符合提问者的文档访问权限。
实施方法一般是在向量数据库中为每个文档或切片打上权限标签（如“全员可读”“财务部专用”“高管层”）。检索时，除了向量相似度筛选，还附加一条过滤条件：只检索该用户有权访问的切片。这与传统文档管理系统的权限体系一脉相承，只不过这里过滤的是检索到的知识片段，而不是整个文件。
2. 动态数据脱敏与生成控制
有些情况下，即使检索到了用户有权查看的片段，答案中仍可能包含需要进一步屏蔽的细节（例如仅允许查询薪资范围，但不能透露具体个人薪资）。此时可以通过后处理或提示词指令，让模型在生成答案时执行脱敏规则，例如“回答时不要出现具体金额，只描述计算方法”。
3. 审计与日志管理
安全不只是预防，更在于事后可追溯。每一次提问、检索到的片段、最终生成的回答都应被完整记录，形成访问日志。日志记录内容应包括：用户 ID、时间戳、原始问题、检索命中的文档 ID 列表、返回给用户的回答。这既满足了内部合规审计要求，也为异常行为排查提供了依据。日志本身同样需要权限控制，确保只有授权人员能够查看。
4. 分权管理
知识库的维护权限与使用权限应分离。只有经过审核的内容管理者可以上传、更新文档，普通用户只能提问、查看答案，避免无意或恶意的知识污染。在技术实现上，可通过独立的文档管理后台和角色权限体系来保障。
24.1.3 落地建议
- 从第一天开始考虑权限：不要等系统上线后再对权限进行补丁式添加，应在设计向量数据库 schema 时就预留权限字段，并将权限过滤融合进检索流水线。
- 定期进行最小权限审查：随着组织变化，及时回收离职员工的知识访问权限，调整部门间文档可见范围。
- 结合现有身份认证系统：与企业的 SSO（单点登录）、LDAP 或 IAM 系统对接，避免单独维护一套用户体系，减少权限管理碎片化。
通过这些措施，RAG 系统能够在保障知识问答便利性的同时，严守数据安全底线，让企业放心地将核心知识注入 AI 工作流，而不必担心私有数据失去控制。