决定哪些任务可以委托给系统

委托明确的决策，而不是笼统的能力

“在部门里使用人工智能”并没有界定决策边界。应明确输入、允许的输出、受影响人群，以及系统必须拒绝处理或按规则升级转交处理的条件。适用于狭窄常规决策的工具，未必适合证据含混且不可逆的判断。同一个模型在不同工作流程中可以承担不同角色。

识别现实可行的替代方案和延误的后果。要求专家批准每一项琐碎决定，可能消耗稀缺的专业资源而不改善结果。但在另一些场景中，移除独立判断会切断发现重大错误的唯一路径。真正有用的问题是：哪种安排既能改善服务，又能保留与风险相称的纠错渠道？

区分否决权与签字

屏幕要求某个人点击批准，并不意味着此人就是有效的保障。此人能否检查依据、取得相反证据、拒绝建议，并承担这样做所需的时间成本？组织是否允许不同意见，而不把它当成绩效失败？这些都是涉及决策权限与资源的运营问题。

转交处理规则必须明确接收方与响应期限。“转交疑难案件”并不完整：如果没有具备能力的接收人，或原决定在审核之前已经生效，这条规则就可能失去作用。审核渠道也可能让受影响者难以使用。应计入启动渠道的实际成本，而不是只确认政策文件里写有该渠道。

检验边界

扩大部署前，应测试接近边界的情形：数据缺失、证据相互矛盾、不熟悉的人群，以及上游服务失效。拒绝处理或转交处理可能正是正确输出。不能一方面宣称限定运行范围的好处，另一方面又把每次不作答都算成系统缺陷。

记录谁有权改变边界。阈值、输入字段或默认设置悄然发生变化，就可能扩大系统影响，而品牌名称并未改变。应对决策规则和运行条件进行版本管理。环境变化时就应复核部署，而不是只在日历提醒出现时才复核。

写出能够实际执行的委托边界

制定包含六个字段的决策规范：输入要求、允许动作、禁止动作、转交触发条件、获授权的接收人，以及需要保留的证据。以虚构的发票分流助手为例，对发票分类和准备付款建议属于不同权限；两者都不能在没有说明的情况下被视为付款授权。应明确哪一步只是提出建议，哪一步会改变外部状态。

按边界测试表逐项开展测试，表中包含一张普通有效发票、一张重复发票、供应商标识缺失、银行收款指令变更、核验来源不可用，以及金额超限六种情形。开展练习前先写下预期动作。当核验来源不可用时，系统拒绝处理可能正是在正确遵守边界。应测量由此产生的延迟成本，而不是看到结果后才重新定义任务。

再加入一次中断的交接：常规审核者不在，截止时间正在逼近。学员必须在已获授权的替代人员、临时搁置或范围更窄且可撤销的动作之间作出选择。紧急性不会创造权限。记录哪些动作能够撤销，哪些只能阻止未来风险，哪些在执行后需要另行补救。

研讨：质疑批准界面

一组仅用纯文字设计人工审核界面。另一组收到有争议的案件，必须说明缺少什么证据、如何拒绝，以及申诉交给谁。如果审核者无法取得相关证据，或无法改变结果，那么增加一个批准按钮并没有补上缺失的能力。

提交六字段规范及六情形边界测试表。在总结讨论中，分析一个强制审核会浪费稀缺专业资源的情形。优秀设计应提高常规服务效率，同时把有重大后果的干预保留给真正能够执行它的人。