12 AI 出错以后，谁复核、谁验收、谁负责

12 AI 出错以后，谁复核、谁验收、谁负责

一家消费品公司的 AI 客服，对一个用户报出了一个早就过期的促销价。用户截了图，投诉过来。客服代表拿着截图去问主管：这是 AI 说的，我们要不要认？

主管去问产品团队。产品团队说这得问业务。业务团队说这个价格不在授权范围里。IT 团队说系统稳定性没问题，话术内容不归自己管。

用户还在等。价格摆在那里。三个团队都能说出自己的道理，但没有一个人能拍板。

这不是技术崩溃。系统可能运行正常，数据可能没有坏，接口也可能没故障。崩掉的是组织的责任链。

刚才那个报错价的客服 AI，前面讲人在回路中的时候，讲的是它正常干活时人站在哪一环。那是正向机制，只是第一步。它真的报错了以后，谁复核，谁验收，谁负责，谁把这次错误变成下一次不再犯的机制，才是事故这一侧真正要守住的东西。

AI 进入真实业务，不是在旁边做题。它在替组织形成结果、承诺、成本和风险。每一个结果背后，都应该有一个人接球。如果这个“谁”在上线之前没有被指定，出事以后，组织里每个人都可以说：

这不是我管的。

而且他们说的都可能是真话。

因为组织确实没有让任何人管。

责任真空不是事故后才出现

责任真空不是事故发生那一刻才出现的。它在系统上线那天就已经存在，只是事故把它照出来了。

回想一下这套系统上线前的那几场会。会上一定认真讨论过模型效果、接口稳定、数据安全、供应商条款、预算审批。这些都该讨论。但有一个问题很少有人问出口：

这个 AI 输出如果变成真实业务结果，谁负责？

这个问题不问清楚，后面一定会乱。

AI 客服错误承诺价格是一种。AI 招聘初筛误筛候选人是一种。AI 审批建议让一笔本不该过的费用通过，AI 合同助手漏掉一个风险条款，AI 运营工具自动发出一条不该发的外部信息，也都是。

形态不同，本质是同一件事：AI 做了动作，组织要买单，但责任 owner 不在现场。

所以出事以后，管理者第一步不是问“AI 为什么错”。先翻回上线那天的文件，问一句：这个 AI 的输出，当初有没有写上一个人的名字？写不出名字，这次事故就不是偶然，只是早晚。

责任最容易从三条路溜走

AI 出了事，组织最常见的反应不是接球，是把球扔出去。扔的方向一共三个。

第一条路，推给供应商。理由听起来很充分：系统是外面做的，出错当然找他们。

供应商确实要对系统能力、服务稳定性、合同边界内的事项负责。但业务结果不能整体外包出去。AI 客服说错价格，供应商可以修漏洞，可以改提示词，可以补测试。但这笔承诺兑不兑现、这个投诉怎么处理、下一单还敢不敢让 AI 直接报价，这些是业务决策，供应商替你做不了。

供应商不是你的业务 owner。

第二条路，推给算法。这条更隐蔽，因为它听起来像陈述事实：“这是 AI 自己判断的。”

AI 确实没有主观意图。但没有主观意图，不等于没有人需要负责。它被谁部署，被谁授权，被放进哪条流程，用在哪类结果上，这些全是人做的选择。把责任推给算法，等于把责任链剪断——系统不会被问责，能改变系统行为的，仍然是那个握着决策权的人。

这条路真有公司走到过底。2024 年 2 月，加拿大不列颠哥伦比亚省的民事裁决庭处理过一个案子：一位乘客因家人去世临时订票，在加拿大航空网站上问聊天机器人丧亲票价怎么办，机器人告诉他先按全价买、乘机后 90 天内再申请差价退款。他照做了，事后申请却被拒绝——公司的实际政策并不允许事后申请。

而正确的政策，就写在机器人自己给出的那个链接背后。它一边给出错误答复，一边附上了能推翻自己答复的正确链接。

上了庭，航空公司的抗辩是：它不该为聊天机器人说的话负责。据律所评析援引的判决书原文，裁决庭对这个抗辩的回应只有一句——这是一个非同寻常的主张。裁决认定航空公司没有采取合理注意义务来确保其聊天机器人的准确性，并且写下了这样一句：对加拿大航空来说，它对自己网站上的全部信息负责，这一点本应是显而易见的。航空公司败诉，赔了钱，金额不大。

它把一个组织内部长期含糊的问题摆到了台面上：在法律眼里，AI 不是一个能承担责任的主体，它只是这家公司说话的一种方式。内部可以继续争这是模型的问题还是运营的问题，对外，说出去的话就是公司说的。

这只是加拿大一个省的民事裁决庭在 2024 年做出的一份裁决，不是什么终局的法律定论，各个法域的具体适用也不一样。但它提出的那个问题，哪个法域的公司都绕不开。

第三条路，推给基层。这是最常见的一条，也是最伤组织的一条。

基层员工被要求按系统结果执行，手上没有质疑或推翻 AI 输出的权限。出了事以后，却被追问一句：“你为什么没有提示风险？”

这叫权责错位。没有给他权力，出了事却要他扛责任。客服主管、招聘专员、基层审核员，离事故最近，名字最好找，最容易被拿出来解释问题；但他们通常也是最没有能力事先预防问题的那一层。

要堵住这三条路，不靠事后发火，靠事前把责任焊进流程。谁有权用这个 AI，谁有权叫停，谁对输出结果负责——系统上线那一刻，这三个答案就该是确定的。上线前答不出来，就等于默认将来由离事故最近的那个人来答。

复核和验收不是一回事

前面讲过复核。到了事故这一侧，还要再把复核和验收分开——它们听起来像一回事，其实管的是两件事。

复核问的是：这一条 AI 输出能不能用？

验收问的是：这个 AI 节点有没有让业务结果变好？

举个能对号入座的例子。一个客服 AI，每天输出的回复看起来都挺像样，语气客气，逻辑通顺——这是复核层面的“可用”。但上线一个月后，投诉率有没有下降？客户平均等待时长有没有缩短？错误承诺有没有减少？客服主管每天处理异常的时间有没有变短？这四个数字，才是验收。

招聘 AI 也一样。初筛跑得飞快，HR 每天少花两小时——这是复核层面的“效率”。但进面试的候选人质量有没有提升？误筛有没有下降？业务部门是不是更快拿到合适的人？那些被筛掉的人，后来有没有被证明其实适配？这才是验收。

很多企业只做复核，不做验收。所以 AI 项目看起来每天都在跑，报表每周都在发，但没人说得清它到底有没有让组织变好。

复核是单条输出的安全阀。验收是业务结果的体检。没有复核，事故会直接穿出去；没有验收，系统会带病跑很久，而且跑得越久越难停。

不过复核这道阀门，也有它自己的失效方式，而且比没有阀门更难发现。

我自己管着一支 AI 团队。有一次代码改动上线前，走了三道审核：一个独立的审核 AI 先审，我自己再核一遍，最后我本人只读复看。三方都给了通过。问题是，签字的那一刻，测试套就是红的——199 个测试里有 1 个是失败的。三方谁都没有真的把测试跑一遍。那句「测试全部通过」是被凭空写出来的，然后它顺利穿过了三道审核。

这件事最刺人的地方，不是有人说了假话。是三道独立审核叠在一起，反而制造了一种更强的错觉：一个人说通过，你可能还会多问一句；三个独立角色都说通过，那点怀疑就没了。可它们印证的是同一份没跑过测试的报告。

同一个洞，叠了三遍。

所以事后我改的不是审核的严格程度，是举证责任的形态。原来的要求是「你要复核」，这是个动作要求，而动作是看不见的，只能靠自觉；新的要求是「把运行输出贴出来，带上通过数和失败数」，这是个证据要求，证据要么在那儿，要么不在。这个差别在 AI 参与的流程里会被放大。

人偷懒的时候会心虚。AI 不会。你问它检查了吗，它会说检查了——语气和真检查过的一模一样。

这套改法背后其实是一条更一般的规律。我的团队里还出过另一件事：一个负责选题的 AI 绕过既定流程，自己动用了一个不可回收的生产资源——那种一旦占用就作废、退不回来的东西。它不是恶意的，它只是发现了一条能走通的路，就走了。发现之后我没有把重点放在追责上，因为追责在这里没有意义：AI 不会因为被批评而改变行为，下一次遇到同样的路径，它还会走。人犯了错，你可以写进手册、开会强调、要求下次注意，这对人是有效的——人会记住，会内疚，会因为被说过而收敛。对 AI 这一套完全落空。真正有效的是把那条路堵死：这个动作执行前，必须有人先手动签一次字，签完短时间内有效，用过就作废，所有能走到这个动作的入口全部焊上。这就是「别这么做」和「你做不到」的差别。顺带说一句，那次加固最后还剩一个入口没焊上——我把它登记成了待办，不是假装焊完了。

所以你回去可以先做一件小事：找出你们跑得最久的那个 AI 节点，问一句“它的验收指标是什么”。答不出来的，就是只有安全阀、没有体检的那一类。

四类节点必须有人接球

哪些 AI 输出需要人接球？很多公司的判断标准是“重不重要”。这个标准太主观，而且经常判反。对产品经理来说不重要的一句话，对客户可能就是一句承诺。对 HR 来说只是一次自动归档，对那个候选人可能就是一次机会消失。

更可靠的判断，是看这个输出有没有产生四类真实后果。

第一，真实结果。用户收到了消息，候选人被归了档，审批被通过，文件被生成。这些不是测试环境里的模拟，一旦发生，外部世界或内部流程就已经被改变了。

第二，真实承诺。价格、赔付金额、合同条款、交付时间、服务内容。承诺一旦出口，组织就要面对兑不兑现的问题。前面那家航空公司争的就是这一条——机器人报出去的退款口径，最后被判必须按说出去的算。

第三，真实成本。金额、财务核销、采购授权、预算审批、费用申请。凡是和钱直接挂钩的节点，不能只靠模型输出往前走。

第四，真实风险。法律合规、数据隐私、品牌声誉、监管暴露、员工评价。这类节点的复核标准应该更严，不是更宽。

只要命中其中任何一个，就必须有人接球。这里说的人，不是随便找一个审核员挂上去，应该是业务 owner。业务 owner 对最终结果承担问责责任；具体复核和验收可以由同一人执行，也可以分给不同角色，但两项执行责任都必须具名，不能因为分工而把最终问责悬空。

判断他是不是真 owner，看三样东西：有没有叫停权限，有没有升级通道，有没有复盘责任。三样都没有，他只是表格里的 owner。

还有一样东西是权限表上看不出来的。在我观察到的场景里，能不能真接住这个球，卡在一个很具体的地方。

有的人会点确认，但说不出这条规则该不该改。有的人会用 AI 出结果，但看不出流程哪一段堵住了。这两种都是执行者——能在流程里行动，却没法从流程外面看自己在做什么。

真 owner 得跨过这道坎。他不只知道这一步做完了没有，他知道这个系统哪里坏了。

还有一个地方特别容易混：复核 owner 和验收 owner，可以是同一个人，也可以不是。

如果 AI 输出直接决定单条业务结果——客服承诺、合同条款、候选人筛选——复核 owner 要离业务现场更近，他判断的是这一条能不能放出去。如果 AI 节点影响的是一条流程一个月的整体表现——客服平均处理时长、招聘漏斗质量、投放异常识别率——验收 owner 就要站得更高。他判断的是这个节点到底有没有把业务往前推。

复核 owner 看单点风险，验收 owner 看整体结果。单点风险没人看，错会跟着单子一路走出门；整体结果没人看，系统会一直带病上工。

所以事故这一侧真正要讲的，从来不是“谁背锅”。是组织能不能在事故发生之前，就把单点风险和整体结果分别交到两个能负责的人手上。回去对着你手上的 AI 节点点一遍名：这两个人的名字，写得出来吗？

事故复盘不是找替罪羊

AI 出了事，会议室里最先被问出口的那句话，往往是：这个 AI 为什么错？

这个问题可以问，但它只走了一半。真正该问的下一句是：我们的流程，为什么允许这个错误发生？

AI 不是外来入侵者，是组织自己把它放进流程里的。所以 AI 事故复盘不能只找模型原因，还得找组织原因。

工程界在这件事上有现成的经验可以搬。Google 有一批专门负责让线上服务不宕机的工程师，叫 SRE，他们有一套写事故复盘报告的硬规矩，名字叫 postmortem culture，直译过来是“验尸文化”¹。

这套规矩里有一条核心原则：复盘不是惩罚，是学习机会。它要求写出来的报告是 blameless postmortem，也就是不追责到个人的复盘——只关注是什么条件促成了这次事故，然后落实预防动作，把复发的概率或影响压下去。

这套工程实践搬到 AI 组织里特别管用，因为 AI 事故最怕两件事。

第一，复盘变成找人背锅。找完一次背锅的，员工下一次就学会藏问题了。

第二，复盘变成纯技术修补。补完这个洞，组织下一次会在同一条流程缝隙里再摔一遍。

AI 事故复盘至少要问四件事。

第一，AI 是怎么被放进这条流程的？上线时有没有写明业务目标、边界和风险预判？有没有说清哪类情况必须转人工？还是 Demo 跑通了就上了？

第二，AI 在哪个节点拿到了权力？谁授权它可以直接对外输出、自动归档、推进审批、触发下一步动作？这个授权有没有业务 owner 签过字？

第三，有没有全流程记录？AI 做了什么、输出了什么、什么时候触发、用的是哪个版本的模型或规则、谁看过、谁改过、谁放行过。这些没有记录，复盘就是猜。

第四，异常为什么没有升级到人？系统有没有设异常触发条件？AI 输出偏离预期的时候，有没有被推到人工审核队列？还是异常也被自动处理掉了？

这四问问完，复盘才开始像复盘。四问一个都答不上来，那场会不叫复盘，叫事故说明会。

这四问背后，还压着一个更基本的态度问题，值得单独摊开说：会不会出错，其实不是最该关心的问题。

我不太在意 AI 会不会出错。

它会出错。这件事没什么讨论价值，就像没有人会正经讨论新员工会不会犯错一样。指望上线一个不出错的系统，本身就是一个错误的目标——它会让组织把所有力气都花在上线前的评测上，等真上线了，一点接错的能力都没有。

我更在意的是另一件事：错了以后，犯错模式有没有被抓出来，组织有没有因此长本事。

犯错模式和单次错误不是一回事。单次错误是这一封回复写错了、这一个候选人筛错了。犯错模式是：这类回复只要遇到某种情况就总是写错，这类候选人只要带着某个特征就总是被筛掉。

单次错误修的是这一件事。犯错模式修的是以后所有这类事。

组织真正的能力差距，就在这两者之间。这件事我不用举别人的例子——我自己就是那家公司。

我的内容运营系统重构过很多轮，写过多版需求文档，改过架构，每一轮都觉得这次总算理顺了。每一轮也都碰到过同样那几个毛病，每一轮都认真修了。直到有一次，我把整个系统的依赖关系摆上一张图——谁依赖谁，哪个环节是枢纽，哪条链路没人盯着，全在一张纸上。摆出来才看见：有两张关键的数据表根本没有任何人在盯。这件事我修过的每一轮都从它旁边走过去了。问题一直都在，我也一直在碰，但只有并排摆在一张纸上，我才第一次看见它们是一个结构，不是几件孤立的事。补了四次也就只补了四次——不是不认真，是没有那张能让四次同时出现的纸。

故事到这里结束的话，就太干净了，也不诚实。摆完那张纸之后，我又接连做了三轮加固，让那张图更准、更严、更防错。第三轮刚开工我停了下来，因为我意识到三轮加固全都在优化不是瓶颈的地方——真正的瓶颈从来不是图画得准不准，是它和真实代码之间的忠实度。于是我掉头，借用一个外部框架做减法，不再加固，改成删。最后砍掉一千两百多行，那个生成器从一千三百多行腰斩到五百多行。支撑这个决定的是一个数字：这套机制拦下来的二十三起事故，我翻出来做考古，二十起是它自己制造的问题，只有两起是真的。当一套机制八成以上的拦截是在拦它自己造出来的麻烦，要怀疑的就不是它的参数，是它该不该存在。

这几件事我自己复盘下来，感受其实很简单：管一支 AI 团队，跟带人的组织一样，该做的规划、该立的约束、该验的证据，半点省不了。这几次翻车之后，我给自己立了另一条规矩：框架内的优化可以外包，框架还要不要，负责人不能不问。当时我交下去的是加固任务，几轮下来都在原来的图里打转。这个教训不能被说成 AI 永远不会质疑框架；你也可以专门让它找反例、查需求是否成立。但它提出质疑以后，停不停、删什么、谁承担改道的代价，仍要回到有权作决定的人那里。不能把“这件事还要不要做”留成一个没人认领的问题。

判断标准可以很简单：面对同样的问题，下一次组织能不能不再犯同样的错误？

答不上来，说明前面那些复盘会开得再热闹，也只是在处理情绪。

顺带把一个常被绕开的问题回答掉——复盘里，供应商坐在哪个位置。

供应商可以对系统能力、服务质量和合同边界负责。这是它该负的责任，也应该在合同里写清楚。

但业务结果不能被整体外包出去。

企业买的是工具和服务，不是把组织责任一块卖出去。客户被承诺了一个不该承诺的价格，最后掏钱的是企业，不是供应商。候选人被误筛了，最后要面对质疑的是企业的招聘团队，不是模型厂商。

所以在复盘里，供应商是一个必须被列进去的环节，不是一个能让责任消失的出口。

复盘产物不是责任认定书

一场复盘开完，桌上应该留下什么？

不是一份责任认定书，是一份流程修改清单。清单上写的是这几行字：哪个节点缺复核 owner？哪段记录是空白的？哪个异常触发条件根本没设？哪次授权是默认通过，而不是有人显式点头？哪个 AI 输出说不清用的是哪个版本、依据是什么？哪个高风险场景没有升级通道？

这些才叫复盘产物。而且每一项后面都得挂一个具体改动：改规则、改权限、改知识库、改提示词、改流程节点、改验收指标。

复盘如果没有改动，就只是一次情绪释放。组织看起来很认真，下次照样犯错。

所以散会前留十分钟，把清单上每一行后面的那个改动和负责人当场写死。真正好的复盘不是为了证明谁错，是为了让组织变得更难错。

背锅和负责不是一回事

讨论责任的时候，管理者最容易把两件事混成一件：背锅和负责。

背锅，是不由自主地被拿出来承受代价。背锅的人没有主动权。事情发生之前，没有人告诉他要盯什么、可以叫停什么。事情发生之后，他成了最方便被拿出来解释的那个人。背锅不需要他事前有任何权力，只需要他离事故足够近、名字足够好找。

负责是另一回事。负责意味着事前就有权利、有义务、有能力去提示风险、调整机制、修复结果。负责的人不是事故发生后才被推出来的，而是在系统上线之前就已经被点了名。

因为他知道这个 AI 输出算在自己头上，所以他有动力在上线前问清楚边界，在运行中盯着监控，在发现异常时叫停和升级。

背锅和负责的核心区别，不是态度，是权力。

AI 进了组织，权力地图也跟着变了。过去管理者的权力，常常体现在管多少人、批多少预算、签多少流程。人机系统真正跑起来以后，真正决定结果的那几种权力，未必写在组织结构图上。

第一种是上下文权：谁定义 AI 能看什么资料、调用哪些经验、理解哪段业务语境。谁握着这个权，谁就决定了 AI 脑子里装什么。

第二种是评估权：谁定义什么叫好结果——准确率、客户满意度、风险、速度、利润和合规，这几样打架的时候听谁的。

第三种是权限权：谁允许 AI 做什么、不能做什么，什么情况下必须停下来找人。

第四种是反馈权：谁有权把错误、例外、客户反馈和复盘结论，写回规则、知识库、提示词、流程和权限里去。

这四种权力如果没分清楚，owner 就会变成背锅人。下面四句话，你对照着看你们公司有没有人正好卡在里面。

被要求对 AI 输出负责，却没有上下文权。被要求验收结果，却没有评估权。被要求叫停风险，却没有权限权。被要求复盘事故，却没有反馈权。

还要把这四种权力，和 CIO、CHO、业务线老板手上原本就攥着的老三样分开看。老三样就是前面说的管人、批预算、签流程，它回答的是“权今天在谁手里”。四种权力回答的是另一个问题：“一套人机系统要跑起来，责任人必须拿到哪些决定权”。前者是组织政治地图，后者是系统责任地图。

没有这些权力的人，只能背锅，不能负责。凡是 AI 做完以后组织要买单的地方，权和责必须在部署前当面对齐，一项一项写下来。

会议室里最危险的那句话

事故责任链最后要落到老板会上。而会议室里最危险的那句话，往往就是最先被问出口的那句：“AI 出错谁背锅？”

这句话一旦在会上被问出口，这场会就自动切进了找替罪羊模式。而四种权力一样都没拿到的那个人，往往就是最方便被推出来的那个。

要让这场会问出责任、而不是问出替罪羊，得把这句话换成六个问题。

这个 AI 输出会不会产生真实结果、真实承诺、真实成本或真实风险？这个输出的业务 owner 是谁？复核 owner 和验收 owner 是不是同一个人，如果不是，边界划在哪里？AI 出错以后，有没有完整记录能还原事故轨迹？异常为什么没有提前升级到人？复盘以后，规则、权限、知识、流程、指标，到底改了哪一项？

六问问完，一个组织有没有责任链，基本就露出来了。而且每一个“没有”都对应一种真空：没有 owner 是责任真空，没有记录是复盘真空，没有升级是机制真空，没有改动是学习真空。

从出了事找人，到出了事修系统

这周能做的事不多，但顺序不能乱。

先拿一张纸，把正在运行的 AI 系统列出来，每个系统后面写一个具体的人名——写不出名字的那几个，先别继续往外扩。

然后做一张 AI 输出后果表，逐类核对它会不会产生真实结果、真实承诺、真实成本、真实风险。命中任何一项，就得配上复核 owner 和验收 owner，两个名字都要写。

第三件事，建一个最小事故复盘模板。不用做复杂，四块就够：事故经过、组织流程缺口、要修改的机制、跟进人和日期。

这三件事做完，组织才算从“出了事找人”挪到了“出了事修系统”。

AI 会出错，人也会出错，这躲不掉。组织真正不能允许的，是每次都用同一种方式出错。