AI 知识库权限怎么设计：别让检索结果越权

AI 知识库最大的风险之一，是用户问了一个问题，系统检索到了他本不该看到的资料。RAG 和向量检索让知识库更聪明，但也让权限设计更重要。权限不应该只在页面层控制，还要进入文档、检索、生成和日志每一层。

这篇是草稿，正式发布前需要核对具体数据库和权限框架。基础 RAG 流程可以看 RAG 知识库怎么搭，向量库可以看 向量数据库怎么选。

适合谁

适合准备搭企业内部知识库、客户支持知识库、项目资料问答或团队 SOP 助手的人。你可能已经能上传文档并回答问题，但还没设计谁能看哪些内容。

也适合接企业 AI 项目评估的人。客户说要知识库，你要主动问权限、文档分级、成员角色、日志和删除流程。

不适合谁

不适合只做公开资料问答的人。如果所有文档都完全公开，权限压力较小。但只要出现内部文档、客户资料或部门资料，就必须设计权限。

如果项目涉及合规、合同、财务、人事、客户隐私或安全资料，新手不应该独立做权限方案。

第一步：文档分级

先把文档分级：公开、内部、部门、项目、个人、敏感。每份文档都要有负责人、可见范围和更新时间。

不要把所有文档放进同一个知识库集合里。没有分级，后面很难做过滤和审计。

第二步：用户角色

定义用户角色：访客、员工、部门成员、项目成员、管理员、审计人员。每个角色能看哪些文档，要写成表格。

角色设计要尽量简单。角色越多，维护越难，也越容易出错。

第三步：检索过滤

RAG 系统检索文档片段时，要根据用户权限过滤。不能先检索全部资料，再靠模型自己判断能不能说。

向量库或检索层最好带上元数据，例如部门、项目、文档类型、可见范围。查询时先过滤，再做相似度检索。

第四步：回答和引用

回答里最好带来源，但来源也要符合权限。用户无权访问的文档，不应该出现在引用里。

如果系统找不到用户有权限查看的资料，就应该说明没有找到依据，而不是从其他权限范围里拿内容。

第五步：日志和删除

日志可能包含用户问题、检索片段和模型回答，因此也有权限要求。谁能看日志、保存多久、是否脱敏，都要提前设计。

文档删除或权限变更后，知识库索引也要同步更新。否则旧向量可能继续被检索到。

权限验收要准备反向测试。不要只测试“有权限的人能看到”，还要测试“没有权限的人看不到”。比如同一个问题，用普通员工、部门成员、项目成员和管理员分别提问，检查检索来源和回答内容是否符合权限。

还要测试人员变动。员工加入项目、退出项目、换部门、离职后，知识库权限和向量索引是否同步变化。真实组织里权限不是静态表格，变动流程设计不好，后续越权问题会反复出现。

交付说明里要写清楚权限由谁维护。比如部门负责人负责文档可见范围，管理员负责角色变更，开发者负责索引同步和日志排查。否则系统搭好后，一旦文档或人员变化，所有问题都会回到技术人员身上。

如果客户没有现成权限体系，就先做最简单的版本：公开文档、内部文档、项目文档三层。先把三层跑通，再考虑更细的部门和角色。权限设计越早复杂化，越容易让维护成本超过知识库本身的价值。

风险提醒

权限越权是知识库上线的核心风险之一。模型生成阶段不能替代权限控制，权限必须在数据层和检索层落实。

另一个风险是维护缺失。文档权限变了，但索引没有更新；员工离职了，但角色没有移除；这些都可能导致问题。

具体步骤

第一步，列出文档类型和可见范围。

第二步，定义用户角色和权限矩阵。

第三步，在文档元数据里写入部门、项目、角色和更新时间。

第四步，检索时先做权限过滤，再做相似度匹配。

第五步，测试越权问题和删除同步。需要检查表或人工协助，可以从 工具导航 进入。

免责声明

本文是 AI 知识库权限设计草稿，不构成安全合规或企业架构建议。正式发布前需要人工核对具体平台、数据库和组织权限规则。涉及敏感数据时，请由专业人员复核。