资讯与观点

给AI设两道门：权限之外，还要回答“该不该自动做”

企达翼诚　·　2026-09-17　·　阅读约 7 分钟

让AI去动业务数据，企业最担心的从来不是它答错，而是它做错，并且没人拦得住。

一、权限回答不了全部问题

大部分系统在权限这块做得很扎实：谁能看什么、谁能改什么，都有明确的授权表。但真到了让AI执行动作的时候，光有权限还不够。

举个具体的例子。一个员工有“修改客户订单状态”的权限，这不代表系统就应该让AI自动替他改。订单金额多大、改了之后能不能撤回、会不会触发对客户的外部通知、当前系统状态是否可靠——这些决定了这件事该不该自动做，而权限表里没有这些字段。

所以我们把判断拆成两道门。

二、第一道门：能不能做

这一道是传统的权限校验，回答的是“有没有资格”。四个要素必须核清楚：

• 身份：当前请求的人是谁，身份是否可验证
• 业务对象：要操作的是哪一条具体数据
• 动作范围：这个动作是否被允许、范围边界在哪
• 当前状态：对象此刻处于什么状态，是否具备执行条件

任何一项不明确，直接不做，不给模糊通过。

三、第二道门：该不该自动做

这一道才是企业场景的关键。四个维度决定自动化到什么程度：

• 真实影响：动作发生后，影响范围和后果有多大
• 可逆性：能不能撤回，撤回的成本高不高
• 外部性：是否会影响客户、合作方或对外口径
• 执行条件：依赖的系统是否可靠，前置数据是否齐全

综合这四个维度，系统在五个处置档位里选一个：

1. 自动完成：影响小、可逆、无条件依赖
2. 提醒确认：执行后告知，用户可以撤销
3. 强确认：执行前必须明确确认，展示固定内容
4. 人工审批：提交给责任人审批后再执行
5. 拒绝执行：超出边界，直接拒绝并说明原因

四、一条底线：确认不能创造权限

这句话是我们内部反复强调的原则。用户点一次“确认”，不能让AI获得它本来没有的权限。确认只是对某次具体动作的授权，不是权限的扩张。

信息不足、权限未知或执行条件不可靠时，默认不做，并明确告诉用户下一步该找谁。

配套的还有降级策略。执行失败、信息缺失、系统超时，都按同一套逻辑处理：补资料、重试、转人工。系统不会为了“完成任务”而编造一个成功结果——假成功会污染后续所有判断，比明确的失败危险得多。

取舍上我们选保守的一端：AI自作主张改了业务状态，损失比它多问一句话大得多。

五、配套：答案必须有出处

动作的约束之外，回答本身也要可信。同一个问题，不同的人问、不同的时间问，能看到的资料和正确答案可能不一样。知识库的难点从来不在存文档，在于建立可信的业务上下文。

• 原始内容：文件、会议、消息、制度、业务记录
• 人员与组织：身份、部门、岗位、在职状态
• 可见范围：谁能看、谁能办
• 时间与版本：生效时间、最新版本、撤回与过期
• 出处与证据：原文定位、引用、反馈与复核

目标是做到答案有出处、材料可复核、权限不泄露、内容撤回能及时生效。答不准的时候，告诉你下一步找谁，不硬答。

六、这些机制怎么验收

安全设计不能只写在文档里，要能被测出来。我们通常会和客户一起准备几类用例：

• 越权反例：用不具备权限的身份请求敏感动作，系统应直接拒绝
• 权限过滤：同一问题由不同岗位提出，返回的答案范围应不同
• 高风险动作确认率：涉及外部影响、不可逆的动作，是否 100% 触发确认或审批
• 降级路径：信息缺失时是否如实降级，而不是生成看似完整的答复
• 审计完整率：每一次确认、执行、转人工是否都留痕可查

这些用例在 PoC 阶段就要跑，而不是上线之后补。