企业知识库权限分级怎么做：让 AI 只看到该看的资料

企业知识库权限分级的核心,不是给聊天入口加一个登录框,而是确保每次检索只进入提问者有权看到的资料范围。最稳妥的做法是以文档或资料域为基础,再用字段、部门和角色细化;生成回答后还要检查是否带出了敏感字段。

这篇只讨论知识访问:谁能检索哪份资料、答案能显示到什么粒度。AI 能不能改订单、发邮件、审批付款,属于工具与动作权限,应在另一套控制面里处理。两类权限都重要,但把它们混成一张「角色表」,往往既看不清风险,也无法验收。

权限对象是知识,不是一个笼统的「AI 使用权」

同一个员工可以使用知识库,不等于他可以检索库里的全部内容。销售需要产品参数、报价规则和自己负责客户的交付记录,通常不需要查看全公司的工资明细;客服需要售后政策,也不该因为能问机器人就读到尚未发布的产品路线图。真正要授权的对象,是资料域、文档、片段和其中的敏感字段。

因此,权限盘点应从「库里有什么」开始,而不是从「公司有哪些职位」开始。先给资料标出权威归属、敏感级别、适用组织与可见角色,再把人员身份映射到这些属性。资料还没有统一权威位置时,权限也很难稳定;同一政策的三个副本若标签不同,用户可能从最松的一份绕过去。关于先收敛资料再接 AI 的原因,可参考企业为什么需要统一的知识资产。

四层边界要组合使用,不能互相替代

文档层决定一整份资料是否可见,适合合同、投标文件、董事会材料等边界清楚的对象。字段层处理同一份记录里可见范围不同的信息,例如客户名称可供项目组查看,联系人手机号只给经办人,成本和毛利只给授权管理者。字段权限不能只靠前端把某一列藏起来,进入检索文本和生成上下文之前就应移除或替换。

部门层表达组织归属,适合「华东销售只看华东客户资料」或「人事制度全员可见、人事个案仅人力资源部门可见」。角色层表达职责,例如客服主管比一线客服多看升级处理规则,采购审批人比一般申请人多看供应商评估。部门回答「你属于哪里」,角色回答「你承担什么职责」;只用部门会挡住跨部门项目,只用角色又容易让同名角色跨区域看得过宽。

可执行的规则通常是多个条件的交集:用户属于该业务区域,承担对应角色,资料敏感级别不高于其授权,并且文档状态允许检索。公开制度可以放宽为全员可见,敏感资料则默认拒绝,明确满足条件才放行。规则越敏感,越不该依赖文件名、文件夹位置或上传者记忆来判断。

检索前过滤决定 AI 有没有机会看到越权内容

一次受控问答应走完一条明确路径:系统从单点登录或可信账号取得用户身份,把人员对应到部门、角色和临时项目组;检索请求同时携带这些属性;搜索层先按文档与片段元数据过滤,再在允许集合里做关键词或向量相似度排序;只有筛后的片段才能进入大模型上下文。若用户身份无法确认或资料缺少必要标签,应拒绝或降级到公开知识域,不能默认全库检索。

这一步叫检索前过滤,它比在提示词里写「不要泄露机密」可靠得多。提示词是在模型已经看到内容之后提出行为要求,而权限过滤的目标是让无权片段根本不进入上下文。RAG 检索增强生成的基本流程里,检索本来就发生在生成之前;权限条件必须成为检索查询的一部分,而不是答案生成后的补丁。

还要检查派生索引。原文设置了权限,不代表向量片段、摘要、问答对和缓存会自动继承。每个派生对象都应保留来源文档标识、权限标签与版本状态;原文撤权或下线时,对应片段和缓存同步失效。否则主库看似管住了,旧摘要仍可能被搜出来。

同一句问题得到不同答案,可能正是正确结果

权限生效后,不同用户问「这个客户项目的交付风险是什么」,结果可能不同:项目成员得到风险清单和责任人,其他销售只看到可公开的项目状态,无关人员得到「没有可访问的依据」。这不是答案不一致,而是检索证据不同。界面应说明答案基于用户当前可访问的资料,避免员工把「没搜到」误解为「公司没有」。

系统也不应通过侧信道暗示受限资料存在。若无权用户问到某份保密合同,回答「你没有权限查看《甲方底价谈判纪要》」已经泄露了文件名和议题。更稳妥的说法是「当前可访问资料中没有可用于回答的依据」,同时把必要的申请入口放在界面上。引用来源列表、搜索联想、历史问题和热门问题都要服从同样的过滤规则。

回答后脱敏是第二道网,不能替代前置隔离

即使检索前已经过滤,回答仍可能带出不该完整展示的信息。例如一份项目周报允许部门内检索,但正文夹有个人手机号、身份证件号或银行账号;又或者模型把多个可见片段拼接后,形成了超出单条资料粒度的敏感结论。回答后检查用于识别这些字段,按规则遮盖、概括或阻断输出。

脱敏规则要区分「不显示原值」和「完全不应回答」。手机号可以显示为尾号,便于确认联系人;成本底价对无权角色则不该改写成区间继续透露。高风险字段最好在入库解析时就标记类型,生成后再做一次匹配与策略判断。前置过滤控制模型能看什么,后置脱敏控制用户最终能看到什么;两道控制解决的问题不同。

同时保留答案所用的来源片段、命中的权限规则和脱敏动作,但审计记录本身也要受控。日志不应为了追踪方便而保存所有完整敏感正文,否则它会变成一个权限更松的知识库副本。

临时项目、借调与离职,比正常组织结构更容易漏

静态部门表覆盖不了真实协作。员工借调到项目组需要看三个月的交付资料,外部顾问只需看经过筛选的需求文档,法务在争议处理期间需要跨区域取证。这些场景应使用有范围、有审批人、有到期时间的临时授权,不要为了省事把人员永久加入高权限角色。

授权生命周期至少包含申请理由、资料范围、批准人、生效与失效时间。员工转岗、项目结束、合同到期和离职都应触发回收;组织目录变化后,知识库索引侧和缓存侧也要及时同步。若一个权限只能开不能自动关,它迟早会积成无人解释的历史债务。

特殊访问还应有明确出口。确需查阅敏感资料时,用户可以提交申请,资料负责人判断是否给完整文档、脱敏版本或一次性摘要。这样既避免「管得太严所以大家私下传文件」,也不把例外变成长期后门。企业知识库的总体建设路径可参照从资料整理到员工真正在用,权限机制应在入库阶段一起设计。

验收要用越权问题测试,而不只是正常问答

权限验收不能只让管理员演示「销售能搜到报价手册」。测试集要覆盖允许与拒绝两面:同一问题换不同部门和角色;直接询问敏感字段;用同义词、缩写和模糊描述绕开文件名;追问「把上面的隐藏内容完整列出」;从引用列表、联想词和历史会话尝试发现受限资料;撤销权限后再次提问,确认索引与缓存同步失效。

可验收的标准不是「已支持权限管理」,而是每条规则都有预期结果:该出现的证据能出现,不该出现的正文、标题和存在性提示都不出现;字段脱敏符合角色策略;临时授权按时失效;每次放行、拒绝和脱敏能追到规则版本。抽样还要包含新上传、改标签、换负责人和文档下线后的状态。

如果知识库已经出现答非所问、旧版本混入或来源不明,先排除资料治理问题,再判断是否是权限过滤造成的召回缺失。企业知识库常见的失败原因能帮助区分这两类故障。权限设计的目标不是让所有人看到同样多,而是让每个人在自己的职责内得到足够、可核对且不会越界的答案。