企业级AI知识库权限隔离设计：让AI“懂规矩”比“懂知识”更重要

当AI客服知道所有秘密时，如何确保研发部的商业机密不会被销售部“套话”？

从“知道什么”到“谁能知道”

在构建企业内部AI客服或知识库系统时，我们往往把精力放在召回率和生成质量上——模型能不能找到对的资料、能不能给出对的答案。但一个更棘手的问题常常被忽略：AI如何做到“看人下菜碟”？

想象一下这个场景：销售部的小王问AI：“我们最新产品的成本是多少？”如果系统没有权限隔离，AI可能从研发部的技术文档里扒出真实成本数据。更危险的是，小王甚至不需要“恶意越权”——他只是问了一个看似正常的问题。

这就是企业级RAG（检索增强生成）系统必须面对的核心挑战：如何在“有问必答”和“不该说的不说”之间找到平衡。

权限隔离的三层架构

要解决这个问题，不能只靠“在提示词里加一句‘不要泄露机密信息’”——那就像告诉一个记性超好但不懂人情世故的天才，“有些事别乱说”，但他根本不知道“有些事”是哪些事。

真正有效的权限隔离需要从存储、检索、应用三个层面层层设防。

第一层：存储隔离——数据就该“分而治之”

在存储层面，有两条截然不同的路线：

路线一：每个部门/租户一个独立“仓库”（Store-per-Tenant）

这是最“物理隔离”的方案——每个部门拥有独立的向量数据库实例或索引。研发部有自己的知识库，销售部有自己的知识库，互不干扰。

优势：数据天然隔离，不用担心“串库”；性能互不影响，一个部门的疯狂查询不会拖慢另一个部门。
代价：运维成本高，每个仓库都要单独管理；如果部门很多（比如几十上百个），维护起来是场噩梦。

路线二：多租户共享一个“大仓库”（Multitenant Store）

所有部门的数据放在同一个向量数据库里，但每条数据都打上“部门标签”（tenant_id/group_id）。查询时强制带上过滤条件：只返回tenant_id = 当前用户所属部门的文档。

优势：成本低、易管理，适合部门数量多但每个部门数据量不大的场景。
代价：需要查询层面做严格过滤；万一过滤逻辑有bug，数据就可能“串门”。

实际落地时，多数企业会采用混合策略：核心机密数据（如研发中的产品参数）走物理隔离，通用资料（如公司规章制度、产品FAQ）走共享仓库。

第二层：检索过滤——让AI“自带偏见”

如果数据已经混在一个仓库里，下一步就是在检索环节做权限预过滤。

“三明治过滤法”是一种被验证有效的实践：

前置过滤（向量检索前） ：直接在向量检索的 where 条件里加上权限过滤——tenant_id = X AND (visibility = 'public' OR department = X)。这样，向量检索压根不会把无权文档纳入候选集。
后置校验（重排序前） ：混合检索（BM25 + 向量 + RRF）召回Top-K候选后，再用Python做一次权限检查，双重保险。
提示词约束（生成前） ：在送LLM的Prompt里明确告知“如果上下文信息不包含用户所需内容，请直接说‘无权访问’而非猜测”。

这种“过滤→重排→约束”的链路，确保了LLM从输入端就看不到越权内容。

第三层：访问控制——谁、能看什么、在什么条件下

权限模型的设计直接决定了系统的安全边界。一个常用的成熟模型包含以下维度：

维度	说明
租户/部门隔离	用户只能访问所属部门的数据
文档密级	1-4级，用户密级需 ≥ 文档密级
可见性范围	public / department / private / role / group
高管特权	高管角色可跨部门查看（审计场景）

在技术实现上，通常会采用JWT（JSON Web Token）承载用户权限上下文的方式：用户登录时，系统将租户ID、部门、角色等信息注入JWT；后续每次RAG请求，协调层（Orchestrator）解析JWT，构建权限过滤条件后去查询向量库。

实战架构：一个可落地的参考

综合多个企业的实践，一个典型的企业级权限感知RAG架构长这样：

用户请求（带JWT令牌）
        ↓
   API网关（解析JWT，提取租户/部门/角色）
        ↓
   协调层（根据权限构建过滤条件）
        ↓
   ┌────────┴────────┐
   ↓                 ↓
向量检索（带where过滤）  关键词检索（BM25，后置权限校验）
   ↓                 ↓
   └────────┬────────┘
            ↓
      RRF融合排序
            ↓
   Prompt组装 + LLM生成
            ↓
        返回结果

这套架构的关键在于：权限判断发生在检索之前，而非生成之后。这就好比图书馆管理员在帮你找书之前，就知道你只能进哪个阅览室——而不是等你把书拿到手了再说“这本你不能借”。

别忘了“人”的维度

技术方案再完善，也绕不开两个组织层面的问题：

1. 权限不是“按部门一刀切”

同一个人在不同场景下可能需要不同权限。比如财务部的小李，日常只能看本部门数据，但季度汇报时可能需要临时查看销售部的汇总数据。这就涉及临时提权和审批流的设计。

2. 审计日志不可或缺

谁、在什么时间、问了什么问题、AI返回了什么内容、引用了哪些文档——这些都需要记录下来。既是安全合规的要求，也是事后追溯越权行为的依据。

小结

企业内部AI知识库的权限隔离，不是“加个登录页就行”的事。它需要从存储隔离方案的选择，到检索链路的权限过滤，再到用户身份与权限模型的精细化设计，层层递进。

一个优秀的权限感知RAG系统，应该让用户感觉不到权限的存在——他们问什么都能得到合理的回答，却从未察觉AI“知道”但“不说”的边界在哪里。这，才是真正的安全与体验的平衡。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

博客园 - 若-飞