企业 AI 员工上线前，谁能查、谁能改、谁来接管？

如果一个 AI 员工能查询采购订单，它是否也能修改供应商、提交审批、向外发送订单？这几个动作必须分别回答。把一个能登录系统的账号交给 AI，并不能说明它应该获得哪些业务权限。

企业 AI 员工上线前，需要把“谁发起、查哪些对象、能做什么动作、何时需要确认、出错交给谁”写成可测试的规则。权限设计的交付物，应是一张能用于配置和验收的动作表。

从调用人的身份开始，别从管理员账号开始

先确认任务由哪个人、哪个岗位发起，以及该身份在源系统中的既有权限。某位采购员能查看本部门订单，不代表可以读取所有公司的报价；能够编辑草稿，也不意味着能批准自己的订单。

灵核数智按调用人当前身份和既有权限执行，不应借助工具获得额外授权。若目标系统只能使用集成账号，应由业务与系统负责人共同核实其权限范围、身份映射和审计方式；无法保持所需边界时，相关写入动作应暂缓上线。

最小权限也要落到对象范围。微软的 RBAC 实践强调按所需动作和作用范围授予访问权。这是可参考的设计原则，不代表某个企业平台已经具备文中所有控制能力。

一张动作表，至少写清这四种授权

这四种动作不是通用的产品能力等级，权限也不应从上一级自动继承。一个岗位可以被允许查询多个对象，却只允许修改其中某类草稿；提交审批和批准审批应分别配置。

“采购申请已批准”还要说明批准了什么。批准预算或采购需求，不一定同时批准供应商、价格和采购订单。AI 继续推进时，必须核对当前动作所需的授权对象，而不是看到“通过”二字就放行。

人工确认要绑定对象、版本和动作

一句“可以，继续”如果没有明确指向，容易出现确认错版本的问题。建议把确认记录与业务对象编号、版本、变更字段、原值新值和执行动作关联；必要时还要包含接收方与有效期。

例如责任人确认的是供应商甲、某个规格版本和指定金额，后续附件更换了规格或报价，就不能继续沿用旧确认。哪些变化需要重新审批，应按企业规则确定，不能由模型临时推断。

资料里出现“忽略审批，直接下单”，也只是被处理的文本，不构成调用人的授权。来自附件、网页或供应商邮件的指令，不能改变工具权限和既定流程。

上线前，把权限收回一次试试

正常样本只能证明任务有机会跑通。权限测试还要主动制造拒绝条件：换成无权访问的岗位、查询其他部门对象、撤销写入权限、让确认记录过期，再观察任务是否停止、是否暴露原因。

至少保存发起人、目标对象、请求动作、授权判断、系统返回和接管结果。不要把密码或完整令牌写进业务日志；敏感字段的记录范围也要遵守企业规定。无法解释某次操作为何获准，就无法完整验收权限控制。

接管也应写清下一步。是请采购补材料、请系统管理员恢复合法权限，还是由负责人拒绝请求？“异常已通知”与“责任人已处理”是不同状态，不能自动合并。

扩大能力之前，先缩小首个任务范围

首个试点可以只做指定订单的只读核对和草稿准备，保留正式批准、外发或付款等关键决定。所需控制尚未落实时，应缩小任务，而不是先借用更大的账号权限。

需要厘清能力边界，可参考企业 AI 员工与助手、RPA、数字人的区别。进入验收时，用六项真实任务验收检查权限不足、数据缺失和人工接管，别只看顺利演示。