企业知识库的权限,别等出事了才想起来设计

传统的文件权限,管的是「你能不能打开这份文档」。可一旦把知识库接进大模型做问答,问题就变了:用户不再直接看文件,而是「问」内容。这时候,权限要管的是「他能不能通过提问,得到这份内容里的信息」。这是两件事,很多团队上线时才发现没对齐。

一个真实会发生的尴尬

设想一下:HR 的薪酬文档进了公司知识库,普通员工本来没有权限打开它。但如果权限没做对,他在问答里问一句「公司薪酬结构是怎样的」,模型从那份文档里检索到内容,大大方方地答了出来。文件他打不开,信息却问得到——这就是权限没跟上的典型翻车。

“在 RAG 里,如果一份内容能被检索到,就等于能被「问」出来。权限必须卡在检索这一层。

权限要前移到检索层

正确的做法,是在检索的那一步就带上用户的身份和权限,只在他有权访问的范围内做召回。换句话说,A 用户问问题时,系统只会从 A 有权看的文档里找答案,无权的内容压根不进入候选。这样,无论他怎么变着花样问,都问不出越权的信息。

上线前要确认的几件事

• 每份文档的访问范围,有没有清晰的归属和分级
• 检索时,用户身份能不能准确传递并生效
• 答案给出来源时,会不会无意中暴露无权文档的标题或片段

连「来源」都可能泄密

有个容易忽略的细节:很多知识库问答会贴心地附上答案来源。但如果权限只卡了正文、没卡来源,系统可能在引用里露出一份无权文档的标题、甚至一小段原文。用户正文没看到,却从「参考资料」里读到了不该读的东西。所以权限过滤必须贯穿到底——召回、生成、来源展示,每一环都按用户身份来。

再加一道:可审计

光控制还不够,还得留痕。谁、在什么时候、问了什么、系统给了哪些内容,最好都有日志可查。一来出了问题能追溯,二来这本身也是合规要求。对监管严格的行业,「事后查得到」和「事前防得住」同样重要。

权限要跟着组织变

还有个容易被忽略的点:权限不是设一次就完事的。员工入职离职、岗位调动、部门重组,访问范围天天在变。如果知识库的权限和公司的组织架构、账号体系是两套各管各的,迟早会对不上——离职的人还能问到内部资料,调岗的人还留着旧权限。靠谱的做法,是让知识库的权限尽量复用企业已有的身份和权限体系,组织一变,访问范围跟着自动变。

说白了,知识库的权限不该是个孤岛,而该是企业整体权限治理的一部分。接进统一的身份体系,既省了重复维护的功夫,也避免了「两套权限对不齐」这个最容易出事的口子。

权限的粒度,有时要细到段落

大多数场景,权限做到「文档级」就够了——能看这份、不能看那份。但有些场景要更细:一份合同,普通员工能看条款、不能看金额;一份病历,研究用途能看诊断、不能看患者身份。这时候,「整份文档要么全给、要么全不给」就太粗了,得做到段落级、甚至字段级的脱敏和过滤。粒度该多细,取决于业务的敏感程度,这件事最好在设计知识库时就一起想清楚。

实现上,常见的做法是给文档片段也打上敏感级别的标签,检索和生成时按用户权限决定哪些能用、哪些要脱敏。粒度越细,实现越费劲,但在金融医疗这类场景,这份功夫省不得——一次越权暴露,代价可能远超你为做细权限多花的成本。

在普通企业内部,权限做漏了可能是尴尬;但在金融、医疗、政务这些行业,这就是合规红线,碰不得。所以我们做这类项目,权限模型一定是在动模型之前就设计好、并且在系统层面强制执行,而不是寄希望于模型「自觉」不说。安全这件事,从来不能靠自觉。

留下你的场景和痛点,我们帮你判断从哪一步开始。