企业知识库权限怎么做?按部门、角色、来源三层隔离

企业知识库权限可按三层设计:部门层定资料范围,角色层定查看与提问深度,来源层定密级和更新责任人。先小范围开放,再逐步放宽。

要点速览

• 知识库的风险在回答里,能被问出来比能搜到更值得警惕
• 权限按部门定范围、按角色定深度、按来源定密级与责任人
• 先小范围开放再逐步放宽,不要先全员放开再收紧
• 上线前用不同角色账号换着问法实测,验证是否越权
• 离职调岗的权限回收要写进流程,并定期复核

企业知识库的权限,不能只靠文件夹的读写设置来管。比较稳妥的做法是分三层来想:按部门划定资料范围,按角色决定谁能查看、谁能提问、能问到什么深度,按资料来源标定密级和更新责任人。这三层分别回答三个问题:这份资料属于谁,这个人能用到哪一步,这份资料出了问题找谁。上线前把这三件事想清楚,先小范围开放再逐步放宽,比先全员放开再回头收紧要省事得多,也少很多解释成本。

这篇只讲权限。资料怎么整理、问答为什么不准,前面两篇已经分别讲过,可以参考企业知识库上线前先整理的五类资料和知识库问答不准时该查的四个地方。

知识库能回答问题之后,"谁能看到什么"变了性质

在共享盘时代,资料的保护在很大程度上依赖"找不到"。一个普通员工就算有权限打开某个目录,他也得知道文件在哪、叫什么名字、值不值得点开。很多敏感资料其实没有被严格锁住,只是藏得深、没人去翻。

知识库把这个前提改掉了。员工不再需要知道文件在哪,只要用自然语言提一个问题,系统就会从多份资料里检索相关片段,整理成一段回答。这带来一个容易被忽视的差别:"能搜到"和"能被问出来"不是一回事。

• 人事资料:一份薪酬调整方案放在人事部的目录里,普通员工可能从来不会去打开。但如果它进了全员可问的知识库,有人问一句"今年某个职级的调薪幅度大概是多少",回答里就可能直接带出具体区间。
• 财务资料:预算表、成本核算、供应商付款记录,单独看是一张张表格;被问出来时,可能是"某个项目今年花了多少钱、主要花在哪"这样一段很直白的话。
• 合同资料:已签合同里有客户名称、报价、违约条款和特殊约定。员工问"我们一般给大客户什么折扣",知识库如果能读到全部合同,就可能拼出一个本不该对外的答案。

换句话说,风险不只在文件本身,还在回答里。提问者可能从没打开过那份文件,但他已经拿到了文件里的关键信息。而且回答往往是多份资料的拼接,单看每一份都不算敏感,拼在一起却可能说明问题。所以权限要管的,不只是"谁能打开哪个文件",还包括"谁的问题能用到哪些资料来回答"。

三层思路:部门、角色、资料来源

把权限拆成三层,是为了让每一层只回答一个问题,避免所有规则搅在一起,越设越乱。三层是叠加关系:一份资料要能出现在某个人的回答里,需要三层都放行。

部门层:这份资料属于哪个范围

部门层解决的是资料的"归属地"。大多数企业的资料天然带有部门属性:人事的、财务的、法务的、销售的、研发的。先按部门把资料分成若干个范围,是成本较低、也较容易达成共识的一步。

判断问题:这份资料离开本部门之后,会不会造成困扰或风险?

小例子:公司的考勤制度、报销流程,虽然由人事和财务维护,但本来就是给全员看的,可以放进公共范围;而员工花名册、绩效记录、薪酬明细,离开人事部就会带来问题,应当只留在人事范围内。同一个部门产出的资料,也要分开对待,不能因为都是"人事的"就整体打包。

角色层:这个人能用到哪一步

部门层定了范围,角色层定的是深度。同一个部门里,负责人、普通员工、实习生需要的资料并不一样;跨部门协作时,也常常需要让别的部门的某些角色看到一部分内容。这里建议把"能看到原文"和"能通过提问得到结论"分开考虑,因为两者的信息量和风险并不相同。

判断问题:这个角色在日常工作里,是需要看原文、只需要知道结论,还是根本不需要接触这类资料?

小例子:销售人员需要了解合同的标准条款和常见问题的处理口径,这部分可以对销售角色开放提问;但具体某个客户已签合同里的价格和特殊约定,只应对负责这个客户的人员和法务开放。实习生可以问制度和流程,但不应该能问到任何具体客户或员工的信息。

来源层:这份资料从哪来、谁负责

来源层容易被忽略,但它决定了权限能不能长期维持。资料的来源不同,敏感程度和更新节奏也不同:内部制度会改版,外部合同含有对方的信息,会议纪要可能包含尚未公开的决策。每类来源都应该有一个明确的密级,以及一个对它负责的人。

判断问题:这份资料是从哪里来的,谁对它的准确性和时效负责,过期或需要下架时谁来处理?

小例子:行政发布的制度文件,由行政指定专人负责版本更新,旧版本下线后知识库里同步撤掉;客户提供的资料,除了本公司的密级,还要考虑合同里的保密约定,责任人通常是对接这个客户的业务负责人;管理层会议纪要默认设为高密级,只在明确需要时才向特定角色开放。

三层叠在一起看,大部分权限问题都能找到落点:范围不对,调部门层;深度不对,调角色层;资料过期或密级标错,找来源层的责任人。

三个常见误区

误区一:先全员开放,出了问题再收紧。这种做法的想法是"先让大家用起来"。问题在于,知识库里的回答一旦被看到、被截图、被转发,就收不回来了。而且收紧权限时,用户会明显感到"以前能问的现在不能问了",很容易引来质疑。更稳妥的方式是反过来:先给每个角色开放够用的范围,再根据实际需要逐步放宽。

误区二:权限只设在文件夹上,不设在知识库层面。不少企业的思路是"文件服务器上已经有权限了,知识库照着同步就行"。但前面说过,知识库的风险在回答里。文件夹权限管的是"能不能打开",而知识库需要管的是"提问时能检索到哪些内容"。如果两者没有对上,就会出现员工打不开文件、却能通过提问拿到文件内容的情况。上线前应当确认,知识库在生成回答时同样遵守权限划分。

误区三:离职、调岗之后没人回收权限。权限的设定往往在上线时很认真,之后就没人管了。员工从财务调到市场,原来的财务权限还在;外包人员项目结束了,账号没有停用。时间一长,权限表和真实的组织架构就对不上了。解决办法不复杂:把权限回收写进离职和调岗流程,由人事触发,由 IT 执行,并定期做一次核对。

上线前自查清单

下面这份清单可以直接复制,在知识库上线前逐项打勾。每一项都应该有明确的负责人和完成时间。

1. 所有入库资料是否都标明了所属部门,公共资料和部门资料是否已经分开。
2. 人事、财务、合同、管理层会议纪要等敏感资料,是否单独列出并设定了较高密级。
3. 每个角色能查看原文的范围、能通过提问获取结论的范围,是否分别写清楚。
4. 是否用不同角色的测试账号实际提问过,确认低权限账号问不出高密级内容,包括换一种问法、拆成几个小问题去问。
5. 每类资料来源是否有指定的更新责任人,过期资料下架的流程是否明确。
6. 外部来源资料(如客户提供的文件)是否核对过相关保密约定。
7. 离职、调岗、外包结束时的权限回收,是否已写入人事和 IT 的流程。
8. 是否约定了定期复核权限的频率,以及发现越权情况时由谁处理、如何处理。

其中第 4 条值得多花时间。权限设计在纸面上看起来没问题,不代表实际提问时不会绕过去。用真实的问法去试,比反复检查配置表更能发现漏洞。这部分测试结果也可以作为项目验收的一项依据,具体可以参考企业 AI 项目验收的四个维度与问题清单。

工具层面:先想清楚知识放在什么环境里

权限规则怎么定,是企业自己的管理问题,任何工具都替代不了这一步。但规则能否落实,和知识库运行在什么环境里有直接关系。在讨论内部谁能看什么之前,企业通常还要先回答一个更靠前的问题:这些资料存放在哪里、由谁来管理。

润迅的 MaxKnow 是一个企业知识管理平台,定位是横向支撑各行业应用。它运行在 MaxDeploy 一体化交付的基座上:下层是 R30 私有化硬件提供算力,中间是 XunOS,再往上由 MaxModel 统一管理和调用模型。选择私有化交付的企业,往往是希望资料的存放和使用环境由自己来规划,这样内部权限怎么划分,才有一个可以讨论的前提。关于这方面的思考,可以参考润迅之前写过的数据不出门,AI 才敢进门。

具体到某个企业的部门结构、角色划分和资料来源怎么映射到平台上,以及数据边界如何约定,建议在交付沟通阶段逐项确认,以产品页面和实际交付方案为准,不要事先假设。

行动建议:从一张表开始

如果你正在准备上线知识库,可以按下面的顺序推进:

• 先列表:把计划入库的资料按部门、来源列成一张表,每一行标出密级和责任人。这张表本身就是权限设计的草稿。
• 再定角色:和各部门负责人一起,确定每个角色需要看原文还是只需要结论,写成简单的规则,不求一次完美。
• 小范围试:先在一两个部门试运行,用不同角色的账号反复提问,记录越权和误拦的情况,调整后再扩大范围。
• 写进流程:把离职、调岗的权限回收和定期复核写进制度,而不是靠某个人记得。

另外需要说明的是,涉及法律、财税等敏感资料的场景,知识库和其中的 AI 能做的是资料整理、初步审核、风险标记与提示;哪些资料可以向谁开放、回答内容是否可以采信,判断和确认仍由专业人员负责。如需进一步了解 MaxKnow 和私有化交付方式,可以拨打润迅业务热线 400-854-5566 沟通。

→ 联系润迅,聊聊你的场景,获取适合的方案