企业不是没算过灾难半径——金融业的压力测试、风控敞口、灾备演练,算的都是这笔账。问题在于,那套账本建立在一个正在失效的假设上:错误以人的速度传播。当 AI Agent 开始直接执行真实动作,企业需要重算的不是会不会出错,而是一次错误究竟能走多远。一、一家公司如何在不知不觉中放大了自己的灾难半径一家企业上线了一套 AI 客服系统。最初,它只负责整理用户问题、生成回复建议,再由人工确认后发送。几个月后,为了进一步提高效率,企业逐渐向它开放了更多能力:查询订单,修改地址,发放优惠券,处理退款,调整会员权益。每一次权限开放,单独看都很合理。查询订单可以减少人工检索,自动退款可以缩短处理时间,直接修改用户资料可以提升服务体验。这些动作分开存在时,只是几个效率工具;但当它们被接到同一个 AI Agent 上,系统的性质就变了。它不再是一个提供建议的软件。它开始拥有连续改变真实业务状态的能力。如果它误解了一条规则,影响的可能不再是一句错误回复,而是一批错误退款;如果它读取了被污染的数据,结果可能不再是一份错误报告,而是一连串真实操作;如果它的账号、上下文或工具接口被滥用,风险也不会停留在某一个系统内部,而会沿着企业已经打通的自动化链路继续扩散。值得注意的是,在这个过程中,没有任何一次权限审批是错的。每一次开放都通过了评审,每一个接口都符合规范。灾难半径的扩大,不是某个决策失误的结果,而是一连串合理决策的副产品。这时,企业真正需要回答的问题已经不是AI 会不会出错,而是:当它出错时,一次错误最多能影响多少客户、多少资金、多少数据、多少系统,以及多长时间?这就是 AI 时代企业必须重新评估的灾难半径。二、企业不是没算过灾难半径,而是算的是人的速度必须先承认一个事实:计算灾难半径,不是新鲜事。金融业算了几十年。银行有风险敞口限额,有单笔与单日交易上限,有压力测试和情景分析;监管要求资本充足率,本质上是在为最坏情况预留缓冲。IT 部门也算:系统可用性、RTO(恢复时间目标)、RPO(数据恢复点)、灾备演练,全都是在回答出事之后损失多大、多久恢复。制造业的安全生产、航空业的冗余设计,同样是灾难半径思维的产物。所以问题不是企业没算过,而是那套账本的所有参数,都隐含着三个正在失效的假设。第一个假设:错误以人的速度传播。传统风控默认,一个错误从发生到扩大,中间要经过人的手——填单、复核、审批、执行,每一步都要花时间。压力测试里的极端情景,往往也是以天、以小时为单位推演的。第二个假设:错误在单点发生。一个柜员做错一笔,一个系统宕掉一台,一个账号被盗一个。风控矩阵按部门、按系统、按角色切分,默认风险会被组织边界拦住。第三个假设:错误以可见的方式出现。异常交易会触发告警,错误报表会被人看出来,违规操作会留下不合常理的痕迹。AI Agent 同时动摇了这三个假设。它以机器的速度执行,以跨系统的方式串联,以看起来完全正常的方式犯错。于是出现了一个尴尬的局面:企业为宕机、坏账、火灾都建立了精确的损失模型,却没有为一个拥有跨系统权限的自动化主体连续犯错建立任何模型。企业算过宕机的代价、坏账的敞口、火灾的损失,却没算过自动化的杀伤力。一个系统上线之前,管理者会追问它能服务多少用户、节省多少人力。但很少有企业在立项阶段认真计算:一个管理员账号失控后,最多能修改多少系统?一条自动化规则配错后,最多能影响多少订单?一个拥有跨系统权限的 AI Agent,最多能连续完成多少个真实动作?一个错误决策进入执行链后,要经过多少环节,才会被另一个独立机制停下来?传统信息安全围绕如何避免被攻破展开,希望用账号权限、身份认证、审批流程把错误挡在外面。重新评估灾难半径,问的是另一个问题:即使攻击已经发生,账号已经失陷,模型已经误判,管理员已经犯错——系统能把损失限制在哪里?防止错误把安全建立在成功之上:账号不能被盗,模型不能误判,流程不能被绕过。限制灾难半径则承认这些事迟早发生,并追问:当所有预防措施中至少有一道失败时,企业还剩下什么?三、AI 没有创造灾难半径,它拆掉了天然的减速带过去的软件当然也能执行真实动作。银行系统可以转账,电商系统可以退款,运维平台可以重启服务器。AI 不是第一个拥有执行能力的软件。真正的变化在于,过去复杂操作之间存在大量天然的停顿。一个员工导出数据,另一个员工检查结果;一个系统生成申请,另一个系统等待审批;工程师写好脚本,另一名工程师登录生产环境执行。这些流程谈不上高效,甚至常常显得笨重,但它们客观上增加了风险传播的摩擦——错误想从一个念头变成一场事故,必须穿过不同的人、不同的系统、不同的时间节点。哪怕这些节点不是为安全而设计,它们也在无意间拦下过无数次错误的放大。AI Agent 正在消除这些停顿。一个 Agent 可以读取邮件、理解需求、访问数据库、生成计划、调用接口、修改参数、提交任务,并根据执行结果继续下一步。过去被拆散在几天里完成的流程,现在可能在几分钟内连续发生。效率提高的另一面,是错误传播机制的质变:过去一次错误只完成一个动作,现在一次错误判断可以被自动拆解成几十个动作;过去错误需要多次人工参与才能继续,现在系统会根据上一步的错误结果,自动生成下一步行动。风险不再取决于某个动作有多危险,而取决于软件能把多少个动作连接起来。真正需要警惕的,从来不是 AI 偶尔给出一个错误答案,而是它能把一个错误答案,转换成一条完整的执行链。四、权限不等于灾难半径,权限组合才是企业通常用权限矩阵管理风险:客服只能查订单,财务可以处理退款,运维管理服务器,管理员创建账号。权限拆分之后,企业会自然地认为风险已被隔离。但在自动化时代,权限不能只看单个接口,要看它们组合之后形成了什么能力。一个系统可能没有转移资金的权限,但它可以修改收款账户;另一个系统可以依据账户信息自动付款。单独看,每项权限都有限;连起来,它们构成了一条完整的资金执行路径。一个 AI Agent 可能没有删除生产数据库的权限,但它可以提交变更请求、调用运维平台、修改部署配置、触发一套已获授权的流水线——每一步都符合权限设计,最终结果却远超设计者的预期。因此,评估灾难半径不能只问它拥有哪些权限,还要问:它能否跨系统调用这些权限?能否在没有人工停顿的情况下连续调用?一次授权维持多久?执行结果会不会自动触发下一套流程?它能否修改后续系统判断所依赖的数据?异常发生后,谁有能力终止已经开始的链路?权限矩阵管住了每一扇门,却没有人管这些门连成的走廊。过去,权限管理解决谁能进入哪一扇门。AI 时代还要解决:一个主体进入多扇门之后,能否把它们连成一条通往灾难的走廊。五、灾难半径的四个维度:范围、速度、深度、可逆性企业谈论事故规模时,往往只看最终损失金额。但重新评估灾难半径,至少要沿四个维度展开。范围:一次错误能影响多少客户、账户、设备、系统和业务区域。一个只能处理单个订单的系统,与一个能批量修改所有客户状态的系统,执行同一种动作,半径完全不同。速度:系统每分钟能执行多少次,错误能多快扩散。一个必须等人工确认的错误,与一个数秒内完成数千次调用的错误,初始权限相同,后果相差几个数量级。深度:错误停在当前系统,还是继续触发其他流程。错误订单会不会进入仓储,错误账户信息会不会进入付款,错误配置会不会同步到所有生产节点。可逆性:错误能否撤销,恢复要多久,是否存在追不回的资金、恢复不了的数据、已经发给客户的信息、已经对外生效的合同与权限变更。所以企业不能只问这个 Agent 可以做什么,还要问:它可以多快地做多少次,这些动作会继续触发什么,以及企业来不来得及撤销。同样一项错误操作,发生在可回滚的测试环境,和发生在不可逆的生产链路,是两种性质的风险。六、审批和日志,为什么缩小不了灾难半径面对高风险操作,企业最常见的动作是加审批。这有价值,但审批容易制造一种错觉:只要有人点了同意,系统就安全了。问题在于,审批解决的是某个人是否表达了同意,它不天然保证最终发生的动作,仍然是这个人同意的那个动作。审批者看到的是一个订单,系统执行的可能是另一组参数;审批页面展示的是单次操作,后台提交的可能是批量任务;审批时上下文正常,执行时依赖的数据已经变了。在传统流程里,审批之后还有人工操作,至少提供了第二次检查。在自动化流程里,审批一旦通过,后续动作立即连续发生——审批不再是风险链路上的一道独立边界,而只是自动化程序等待的一个状态值。更麻烦的是,如果审批展示、审批状态、执行接口和日志都在同一个软件环境里,这个环境一旦失陷,攻击者可以同时影响审批者看到的内容、系统保存的审批结果、最终提交的执行参数,以及事后用于审计的日志。流程上一切合规,灾难半径没有缩小分毫。审批证明有人同意过,不证明发生的就是他同意的那件事。日志是另一个常见误区:把可审计等同于安全。事故之后,日志确实能还原过程、定位责任。但日志回答的是发生了什么,不是还能不能继续发生。如果自动化系统每秒执行大量操作,告警响起时损失已经完成;如果监控和执行共享同一个管理员权限,攻击者还能关闭监控、修改记录。企业必须区分两种能力:事故发生后的解释能力,和事故进行中的制动能力。很多系统日志详尽到能记录每一次错误退款,却无法在损失越过某个边界之前自动停下来。日志是行车记录仪,不是刹车。事故可以被完整回放,却不会因此少发生一次。七、从权限管理到执行约束:计算最大可执行损失要真正管理灾难半径,信息化设计需要从权限管理走向执行约束。权限管理回答谁被允许发起某类动作;执行约束回答即使已获权限,一次最多能执行到什么程度。一个退款系统不能只区分有没有退款权限,还要明确单笔金额、累计金额、执行频率、适用对象和异常状态下的降级规则。一个运维 Agent 不能只区分能不能管理服务器,还要限制一次影响多少实例、是否允许跨区域、能否连续重启、生产变更是否必须拆分执行。一个能管理账号的系统,不应因为拿到管理员身份,就能在短时间内修改所有高权限账户、关闭所有安全策略、同时清除相关日志。企业真正需要计算的指标是:在任何一个账号、模型、规则、接口或管理角色失效的情况下,它所能造成的最大可执行损失是多少?这个数字不能只写在制度里。制度规定单笔退款不超过一万元,但接口允许一次提交一百万条退款请求,半径就没有被限制;管理手册规定生产变更必须分批,但自动化平台允许管理员直接向所有节点发布配置,真正的边界仍由系统能力决定。制度写在纸上,灾难半径写在接口里。只有当限额、频率、对象范围、时间窗口、执行次数和异常停止条件被真正写进执行路径,灾难半径才从管理口号变成工程能力。八、缩小灾难半径,不等于牺牲自动化有人会担心,限制执行范围会让 AI 失去价值。但缩小灾难半径,不是让所有动作退回人工,而是让自动化程度与可承受损失相匹配。低风险、可恢复、影响面小的动作,尽管高度自动化:查询信息,生成报告,修改未发布的草稿,在明确额度内处理标准退款。高风险、不可逆、传播面大的动作,则需要拆分、限速或增加独立确认:一次更新不必同时推向全部生产环境,一次资金操作不必开放无限额度,一个账号不必长期持有完成整条业务链的全部能力。系统还应该在异常时自动收缩,而不是继续尝试。调用频率突增、操作对象偏离常态、上下文变化、关键依赖失联时,系统的第一反应应该是缩小权限、暂停连续执行、退回保守模式。这与传统尽可能保持业务连续的思路不同:内容服务降级续跑是合理的,但资金、权限、生产配置和关键数据操作,异常状态下继续执行,比暂停服务危险得多。AI 系统尤其需要这种设计,因为它可能把执行失败理解为需要继续尝试。第一次调用没得到预期结果,Agent 会更换参数、改走其他接口、调整操作顺序。站在完成任务的角度,这是能力;站在风险控制的角度,这意味着系统会主动寻找绕过失败的方法。企业必须明确区分:什么失败可以让 AI 自动修复,什么异常必须立即停止执行。九、灾难半径应该写进 AI 项目的立项书今天企业评估 AI 项目,看的是准确率、响应速度、部署成本、节省工时和用户体验。这些指标衡量的,是系统在正常情况下创造多少价值。当 AI 开始获得真实执行能力,立项时必须增加另一组问题:这个系统能调用哪些真实业务权限?一个错误判断最多连续执行多少步?一次授权能用多少次、持续多久?错误会不会自动传播到其他系统?系统能否修改自己后续判断所依赖的数据?执行过程中,谁能真正终止它?最坏情况下,企业要恢复多少资金、数据、客户关系和生产资源?这些问题不该等到安全评审才出现,更不该等到事故之后才被追问。它们应该像预算、收益率和实施周期一样,在项目获批之前就被计算。同样是节省一百个人工小时的项目,一个只会整理资料,另一个能直接修改生产配置,不应该接受相同的风险评估。企业不能只计算自动化的收益,还必须计算自动化获得执行权之后形成的最大负债。企业采用 AI 的速度不会因为风险而放慢。从客服、销售、财务到研发、运维、供应链,越来越多的软件正在从提供信息走向完成任务。这不是工具升级,而是企业内部执行权的重新分配:过去执行权掌握在人、岗位和流程手中,未来它会越来越多地被封装进账号、接口、自动化规则和 AI Agent。当执行权进入软件,企业就不能继续只用访问控制的思路管理它。允许一个系统进入,不代表它可以无限行动;允许一个 Agent 完成任务,不代表它应该拥有完成所有步骤的全部能力。真正成熟的 AI 信息化,不是建立一个永不犯错的系统——这样的系统不存在。成熟意味着企业提前承认:模型会误判,数据会被污染,管理员会犯错,账号会失陷,流程会被滥用。然后在这些事发生之前,明确规定:一次错误最多影响多少对象,一次失陷最多持续多久,一个主体最多控制多少执行环节,一个异常最多传播到哪里,超过什么范围,系统必须停止。过去,企业安全最常问的是:谁有权限做这件事?AI 时代必须再问一句:即使它有权限,我们准备让它最多做到什么程度?决定一场事故规模的,往往不是第一个错误发生在哪里,而是系统允许这个错误走了多远。企业必须重新评估自己的灾难半径。不是因为旧账本一无是处,而是因为旧账本的每一个参数——速度、边界、可见性、可逆性——都是按人的世界标定的。AI 不会等企业换完账本再犯错。当错误不可避免时,企业至少应该提前决定:它必须在哪里停下。