AI Agent开始替企业做事,究竟该由谁负责?

假设一家制造企业准备让Agent查询订单与产能，并直接回复客户交期。销售希望更快确认订单，生产需要守住排产安排，IT接通了系统，安全团队也确认了数据访问范围。

但一个交期只有插单才能兑现，还会影响其他客户。谁能批准它发出去？

进入正式业务流程的Agent，需要一位获得相应授权的牵头负责人，组织业务取舍和后果处置。技术、安全及各业务环节的责任也要分别落实。

CIO、CISO还是业务负责人，取决于这里的Owner究竟指什么。平台有人维护、账号有人管理，不能直接说明有人持续对这项业务的运行结果负责。

IBM近期一篇讨论AIOps的文章提出：安全、运行、数据可能各有人管，而AI可以自主做到哪一步，仍需要明确谁来决定。这个问题也值得放到业务流程里看。

对于交期承诺，销售提供客户优先级，生产确认产能约束，IT落实权限和执行控制，安全团队核查访问与防护条件。牵头人需要把这些判断组织起来，推动作出决定，并跟进承诺造成的影响。

所以，选择负责人要看他对哪个流程结果负责、拥有什么决定权。采购场景可以由采购流程负责人牵头，IT运维场景可以由IT负责人牵头；不能仅凭谁开发了Agent来确定。

图：假设交期场景，各项条件确认仍须衔接业务授权。

假设企业指定订单履约负责人牵头这个Agent，却没有赋予他协调销售与生产的权限。他只能反复转发消息，最后仍由开发人员四处找人确认。责任表填上了名字，决策问题还在。

有效的安排，需要同时说明：他能决定哪些事，哪些必须上报，谁提供判断依据，谁安排处理例外的人手。

NIST的AI风险管理参考资料强调角色、职责和沟通路径，也提出管理层应向相应层级配置权力与资源。这支持权责配套的原则，并未指定所有Agent都归某个职位管理。

牵头负责人要能推动结果闭环，各方仍须对自己的专业工作负责。程序错误由IT处理，数据问题由相应维护者纠正，业务取舍由有权决定的人作出。不能因为业务签过字，就免除技术实现和运行保障责任。

回到插单情境。销售认为新订单重要，生产认为不能挤占既有承诺。此时，要求双方“共同负责”还不够，需要说明分歧怎样结束。

企业可以先沿用既有业务授权：已确认规则和授权范围内的常规回复，允许Agent执行；涉及改变客户优先级或挤占其他订单的事项，转交相应审批路径。

牵头人组织双方说明影响、备选交期与代价。有权决定的事项，由他决定；超出权限的，交预先指定的经营管理者裁决。等待期间，相关动作保持在原批准范围内，不能把无人回复当成默认同意。

跨部门裁决也有边界。安全或技术条件不满足时，应明确缺口和整改要求；可授权的例外，按企业规则记录批准人、范围与期限。企业已经明确不可豁免的限制，不能靠更高层签字取消。

一位牵头人不必拥有所有决定权，但必须知道每类决定该交给谁。若整条路径走下来仍无人有权取舍，管理层就需要补上授权，或缩小Agent的工作范围。

图：裁决路径示意；超出授权转交有权者，等待不等于同意。

如果Agent已经向客户发出了错误交期，首先需要阻止影响继续扩大。事先获授权的业务、运行或安全值守人员，应能按约定条件暂停相关动作，并通知牵头负责人。

随后，销售核对客户承诺，生产评估订单影响，IT检查执行记录，各方处理对应问题。牵头人组织这些工作，确保客户沟通、业务补救和技术修复有人跟进。

有权暂停，不自动等于有权恢复。接口修好了，客户承诺可能还没纠正；业务已经补救，权限缺口也可能尚未关闭。相关条件满足后，由预先指定的恢复批准人决定是否重启，必要时只恢复部分动作。

这份责任还要持续到日常运行。项目交付结束、牵头人调岗，都应完成交接，避免最后只剩开发人员被动维护。

图：暂停与恢复的权限分别安排，恢复前核对相关条件。

这些原则与传统自动化治理相通。Agent可能在任务中选择工具和执行路径，更需要把可行动范围及跨环节的决定权说清楚。

企业可以先选一个准备进入正式流程的场景，写清四件事：负责人对什么结果负责，能决定什么，争议交给谁，谁能暂停与批准恢复。低风险个人辅助无需照搬整套安排，也不必给每个底层子Agent各设一位高管。

对CIO而言，推动各方完成这些安排，是把Agent接入企业流程的一部分。给Agent一个负责人，也要让这个人拿得到依据、调得动资源，并知道权限之外该找谁。