知识库检索与业务系统查询的权限边界怎么设
AI助手接业务系统，最怕的不是回答不准，而是权限穿透。一个只该查自己工资单的员工，通过自然语言绕到了别人的考勤记录；一个只该看销售报表的主管，用一句“帮我改一下客户状态”触发了写操作。这类问题不能靠提示词约束，必须在知识库检索与业务系统查询之间划出一条硬边界：身份统一、权限映射、只读优先、写操作隔离、全程审计。
知识库检索和业务系统查询为什么要分开管权限
知识库检索和业务系统查询是两类完全不同的数据访问行为。知识库检索面向的是企业已经沉淀、清洗、授权范围内的文档和知识内容，比如制度文件、产品手册、SOP、FAQ。业务系统查询面向的是实时生产数据，比如HR里的薪酬、ERP里的库存成本、CRM里的客户联系方式。
两者混在一起管理时，最容易出现三个问题：
- 知识库权限模型过粗，员工用自然语言绕过菜单权限，直接问出原本看不到的数据；
- AI助手拿到业务系统接口权限后，把只读查询和写操作放在同一个通道里，误操作风险极高；
- 知识库文档里本身嵌入了敏感字段，比如测试环境的数据库连接串、历史报表里的手机号，一旦被检索出来就形成泄露。
所以权限边界的第一步，是把知识库检索权限和业务系统查询权限拆开设计、统一管理、分别审计。
适合什么企业先做这件事
不是所有企业一上来就要做完整的ABAC权限体系。以下三类企业最应该优先落地：
- AI助手已经或计划接入HR、ERP、CRM等核心业务系统，哪怕只做只读查询；
- 知识库中包含分级文档，比如管理层会议纪要、薪资制度、未公开的项目资料；
- 需要通过等保、ISO 27001或行业合规审计，AI助手的数据访问行为会被纳入检查范围。
如果企业还处在只做内部知识问答、不接业务系统的阶段，可以先完成知识库分级授权和基础审计，不用一次性上全套API网关策略。
先做什么：把身份和权限映射做成一张表
IT负责人在动手开发前，应该先完成一张“身份—数据范围—操作类型”的权限映射表。这张表不需要很复杂，但要覆盖三类核心信息：
1. 身份来源统一
AI助手不应该自己维护一套用户账号体系，而是复用企业现有的统一身份认证。员工通过SSO或OAuth2登录，AI助手拿到的是企业身份标识，比如员工工号、部门编码、岗位角色。后续所有权限判断都以这个身份为准。
2. 数据范围映射
把知识库和业务系统的数据访问范围，映射到企业已有的RBAC角色上。例如：
| 角色 | 知识库可见范围 | 业务系统可查范围 | 写操作 | | --- | --- | --- | --- | | 普通员工 | 全员制度、公共SOP | 本人工资条、本人考勤 | 无 | | 部门主管 | 本部门制度、部门报表模板 | 本部门员工考勤、绩效数据 | 无 | | HR专员 | HR制度、招聘SOP | 候选人信息、员工档案 | 按流程提交 | | 财务主管 | 财务制度、审批模板 | 应付账款、成本报表 | 按流程提交 |
这张表的关键是：默认只读，写操作单独列出。
3. 操作类型分离
查询和写入必须分开授权。AI助手在集成业务系统时，优先只申请只读接口。写操作不放进AI助手的默认工具包里，必须走单独的审批流程，或者由人工在业务系统里完成。
权限边界怎么落地：三层隔离
第一层：知识库分级授权
知识库本身要按文档密级和部门归属做分级。员工提问时，AI助手只能检索该员工有权看到的文档切片。具体做法是在知识库入库阶段就给每个文档打上权限标签，比如“全员可见”“部门可见”“指定角色可见”。检索时先过滤权限，再做语义匹配，而不是先搜索再拦截。
这样能避免一个常见误区：知识库先检索出敏感内容，再靠提示词让模型“不要回答”。这种方式不可靠，模型在长对话或多轮追问下容易泄露。正确的做法是让无权限的文档根本进不了检索候选集。
第二层：业务系统API网关鉴权
AI助手不直接连业务系统的数据库，而是通过API网关调用标准接口。网关层做三件事：
- 校验OAuth2令牌，确认当前请求对应的员工身份；
- 根据权限映射表，判断该身份是否有权调用这个接口；
- 对请求参数做范围限制，比如只能查本人数据，不能通过修改参数查他人数据。
业务系统接口需要区分只读和写入。IT团队可以将AI助手可调用的接口范围限制在只读组里，比如GET /salary/self可以，POST /salary/adjust不行。写操作接口不注册到AI助手的工具列表中。
第三层：敏感字段脱敏与人工确认
部分场景里，即使用户有权查询，AI助手也不应该直接返回全部字段。比如HR专员查询员工档案时，手机号、身份证号、家庭住址等字段可以脱敏展示，或者只返回“有权限在HR系统查看完整信息”的提示。
涉及个人微信、电话外呼、客户数据、未成年人信息时，建议把人工确认做成流程的一部分。AI助手可以整理待确认的外呼名单或客户信息，但最终发送、导出或写入动作由有权限的人在业务系统中完成。
审计日志要记什么
权限设计是否正确，最终要看审计日志能不能回答三个问题：
- 谁在什么时间问了什么问题；
- AI助手调用了哪个业务接口、传了什么参数、返回了什么数据范围；
- 有没有越权尝试被拦截。
审计日志至少记录：用户身份、时间戳、问题文本、命中的知识库文档ID、业务接口调用记录、权限判断结果。日志保留周期要符合企业合规要求，并且与现有SIEM或日志平台打通。
这里有一个常见误区：只记录用户问题和AI回答，不记录接口调用。一旦出现数据泄露，无法还原AI助手实际访问了哪些业务数据，审计就是无效的。
容易踩的三个坑
第一，让AI助手直接连业务数据库。 数据库账号权限很难做到细粒度控制，而且查询行为不容易审计。只开放API接口，绕开数据库直连。
第二，写操作和查询操作混在一个工具里。 模型在对话中可能误判用户意图，把“帮我看看能不能改”理解成执行修改。写操作必须从AI助手的默认能力里拆出去，要么走人工审批，要么在业务系统里完成。
第三，权限测试只在正常场景下做。 IT团队通常会测试“有权限的人能不能查到”，但很少测试“无权限的人通过换一种问法能不能查到”。权限验证要做对抗性测试，比如用无权限账号尝试查询他人工资、用主管账号尝试修改员工状态、用普通员工账号尝试检索管理层会议纪要。
交付成果长什么样
一个完整的知识库检索与业务系统查询权限设计项目，最终交付物通常包括：
- 权限映射表，明确角色、知识库范围、业务接口范围、读写权限；
- API网关鉴权策略配置，限定AI助手的可调用接口组；
- 知识库文档分级标签方案与入库规范；
- 审计日志字段定义与留存策略；
- 对抗性测试用例，覆盖越权查询、越权写操作、敏感词诱导等场景。
智未来AI在企业知识库与RAG系统落地中，通常从权限映射表开始，先帮企业把“谁能查什么、谁能写什么”梳理清楚，再进入技术实现环节。这样可以避免方案做完才发现权限模型对不上业务现实。
常见问题
1. 我们公司AI助手目前只接知识库，不接业务系统，需要做权限边界吗？
需要，但可以先做轻量版。知识库本身就要按部门或密级做分级授权，否则员工提问时可能检索到管理层纪要、未公开制度等敏感内容。先把知识库权限标签和基础审计做起来，后续接业务系统时再扩展到API网关。
2. AI助手能不能直接帮员工改HR系统里的信息？
不建议。AI助手默认只做只读查询，写操作走人工确认或在业务系统里由有权限的人完成。如果确实需要AI辅助提交，比如生成请假申请草稿，最终提交动作应该在业务系统里由用户本人确认，AI助手不直接持有写接口权限。
3. 知识库文档太多，怎么判断哪些该做权限分级？
先按部门归属和密级做粗分类，比如“全员可见”“部门可见”“指定角色可见”。以HR制度、财务数据、管理层文件为优先分级对象。IT团队不需要一开始就把所有文档打标签，可以先覆盖高风险文档，再逐步扩展。
4. 我们已经有统一的OA或企业微信身份，AI助手怎么复用？
通过OAuth2或SSO把现有身份体系接到AI助手的登录流程里。AI助手拿到的是企业身份标识，权限判断完全基于这个标识，不自己维护账号。这样员工离职、调岗后，权限自动跟着企业身份系统走。
5. 智未来AI能帮我们做权限设计和落地吗？
智未来（上海）智能科技有限公司可以提供企业知识库与RAG系统的权限架构设计、API网关鉴权策略配置和审计日志方案。一般先做权限映射梳理，再根据企业现有系统情况确定实施范围。具体需求可以联系智未来AI咨询企业AI项目。
企业做AI助手权限边界，核心不是堆技术名词，而是先想清楚“谁在什么情况下能查什么、不能写什么”。这张权限映射表理清楚了，知识库检索和业务系统查询的安全边界就立住了。