AI 最小权限怎么发：能力按角色收敛，数据边界归原系统

AI 工作台接进企业之后，授权怎么发，往往比要不要发更难定。范围给得宽，员工可能接触到职责以外的数据；给得窄，业务能力又用不起来。最小权限的目标不是一味压小范围，而是让每个人获得与职责相符、依据清楚并可复核的业务能力。

核心观点

权限发得合适，关键在于发放有依据、范围能收回，并且在岗位和组织变化后及时复核。连接器这一层决定谁能调用哪项业务能力；具体能看到哪些行和字段，仍由目标系统按员工原有权限判断。两层各管一段，才有清晰的责任边界。

能力发布之后，授权为何容易失焦

企业接入 AI 工作台时，常先把 ERP 订单查询、WMS 库存查询或 OA 页面等能力整理好并发布。授权往往随后处理：有人申请就先开通，想着之后再细化。

但同一项能力可能被不同岗位使用。采购、销售和财务都可能需要订单查询，关注的数据与工作职责却不同。如果授权没有岗位依据，范围就可能逐渐偏宽。反过来，员工转岗后只新增新岗位权限、没有回收旧权限，也会留下难以解释的授权记录。

授权清单只增不减，平时未必立刻影响使用；到了复核或审计时，团队却可能说不清某项权限为何存在、由谁批准、现在是否仍然需要。

最小权限的两层边界

先区分每一层负责判断什么。连接器侧判断员工、用户组或组织能不能调用一项业务能力；目标系统侧判断同一员工在原系统里能看见哪些功能和数据。

数据范围的最终判断以目标系统为准。连接器侧收窄的是可调用的能力，不会替代或复制原系统的数据权限规则。

连接器并不掌握目标系统内部全部角色与数据规则，也不应再复制一套。员工在 ERP 等系统中的已有权限应继续由原系统判断。

授权按什么粒度发

连接器侧可按员工、用户组或组织授权。选择哪种粒度，可以看这批人的职责相似程度，以及成员变化的方式。

实践中可以先用用户组或组织覆盖稳定的岗位职责，再把少数个别情况落到员工粒度。这样既能减少重复维护，也保留处理例外的空间。具体授权方式仍需结合目标组织结构和业务职责评估。

怎样逐步收敛到够用

最小权限通常需要逐步调整。可以先给岗位基线所需的能力，实际使用中发现缺少必要能力时，再补充并记录理由。与一次性放宽后再追着回收相比，这样更容易解释每一次授权。

• 发布一项能力时，先写清楚哪些岗位需要它；说不清业务依据的授权先暂停。
• 新人上岗时按岗位基线配置，不直接照抄前任全部授权；额外条目逐项核对。
• 结合调用审计查看长期未使用的授权，核对它是否确有业务需要。
• 为每条授权留下批准人和理由，便于后续复核。
• 能力升级或接口调整后，再检查原授权是否仍然适用。

只保存授权结果而不保存判断依据，会让下一轮复核不得不从头开始。把依据和调整记录放在一起，可以让授权范围更容易被解释和维护。

组织变动时怎样调整

转岗时，先核对旧岗位授权是否需要回收，再按新岗位重新配置，避免新旧职责对应的能力长期叠加。离职或授权变更时，应按实际撤权流程执行，并检查服务端是否阻断后续调用。

部门拆分或合并时，按组织授权的范围也要重新核对。拆分后把旧组织的授权分配到新的职责范围；合并时不要不经核对地把原有范围简单相加。

界面隐藏不等于撤权已生效。客户端可能缓存旧工具列表；应以服务端是否拒绝撤权后的调用为准。

若目标系统已经完成某项业务动作，连接器中止调用并不代表目标系统会自动回滚；仍需核对原系统回执与实际业务状态。

如何判断授权发得合适

可以用几项可核查的结果复盘授权是否贴合职责：

• 能列出某位员工当前可以调用的能力，并说明每项授权的依据。
• 用不同岗位的员工账号调用同一能力时，数据范围由目标系统按各自权限判断。
• 新增授权时能查到批准人、理由和对应岗位。
• 员工转岗后，旧岗位不再需要的能力已经复核并按流程调整。
• 调用审计可以按员工、能力、时间、目标系统和结果查询使用记录。
• 撤销授权后，不刷新客户端再次发起调用，服务端会按授权状态进行处理。

这些检查应在实际目标环境中逐项核对。使用产品能力演示时，明确使用演示或脱敏数据；演示结果不代表客户上线成果。

结语

最小权限的价值，是把“谁能用、用到什么程度”从个人印象变成有依据、可复核的管理过程。可以先从人员变化频繁、数据敏感的岗位做起，把能力授权、目标系统权限判断、调用审计和撤权连起来，再根据实际验收结果逐步扩展。星云 PLUS AI 系统连接器支持将已有数据、接口、业务页面、Skill 和 Agent 发布为可授权、可确认、可审计的业务能力；具体系统范围、部署形态与实施周期以项目评估为准。

常见问题

相关阅读：AI 业务能力授权定期复核、连接器授权与数据权限。上一篇：AI 工作台读 ERP 数据：实时查询还是先同步？。