AI犯错以后，为什么找到责任链比找到错误更难？

Geoffrey Chen

《AI进入工作之后》· 第一季“从回答问题到参与工作”· 第十篇

一家机构用AI生成客户续约通知。系统读取客户记录、计算新价格、起草邮件，再由工作人员批量批准发送。后来发现，一批客户收到错误价格。

技术人员很快找到直接原因：价格工具读取了过期费率表。

但责任问题没有因此结束。谁把旧费率留在知识库？谁决定AI可以读取它？为什么系统没有检查生效日期？批量批准的人是否看得到计算依据？产品供应商有没有说明工具局限？管理者为什么允许邮件在没有抽样核对的情况下发送？客户投诉以后，谁有权暂停系统并更正合同？

错误点可能只有一个，责任链却穿过数据、模型、软件、流程、人员和管理决定。把问题说成“AI算错了”，会让所有真实行动者同时隐身。

这也是AI进入工作后最棘手的组织问题之一：系统表现得像一个统一助手，责任却分散在许多彼此不掌握全貌的人和机构之间。

错误原因与责任不是同一个问题

事故分析首先要找到发生了什么。输入数据错误、检索失败、模型误解指令、工具执行异常、接口映射错误或人工批准疏忽，都可能成为原因。

责任分析则进一步问：谁有义务预防、发现、停止和补救这种错误？

一个人可以不是错误的技术原因，却仍承担管理责任。例如，模型供应商没有制造客户的旧费率表，但部署机构有责任管理自己的业务数据。相反，部署者按说明使用系统，如果供应商隐瞒已知局限，责任也不能全部推给用户。

责任至少有几种不同形式：

  • 设计责任：系统是否为预期用途建立适当控制；
  • 数据责任：输入来源、质量、版本和权限是否得到管理；
  • 部署责任：组织是否选择了相称的使用场景和自动化程度；
  • 操作责任：人员是否按照流程使用、复核和报告异常；
  • 监督责任：管理者是否分配资源、设定责任人并监测风险；
  • 补救责任：错误发生后谁联系受影响者、恢复状态并防止重演。

这些责任可能由不同主体承担。事故调查的目的不是赶快找到一个“背锅的人”，而是恢复完整链条，使每一种义务都有实际承担者。

AI界面会制造“单一行为者”的错觉

用户面对一个名字、一个聊天框或一个代理头像，很容易把输出归给“AI”。但一次回答背后可能包括基础模型、系统提示、检索服务、第三方工具、组织数据、权限策略和人工批准。

每一层都有不同控制者。基础模型提供者决定模型训练、默认安全与文档；应用开发者选择提示和工具；部署组织提供数据并设定流程；操作者提出任务并采用结果；管理层决定资源和风险容忍度。

如果没有事先记录这些关系，事故后每一方都可以指出自己无法控制的部分：供应商说数据来自客户，客户说模型由供应商提供，员工说系统是公司批准的，公司说员工应当复核。

欧盟AI治理框架区分模型提供者、系统提供者和部署者等角色。官方说明强调，通用模型提供者应向下游提供能力与限制信息，而部署高风险系统的机构仍需按说明使用、监测运行并安排有效的人类监督。European Commission：《Navigating the AI Act》

具体法律义务取决于司法管辖区和用途，但这种角色区分具有一般意义：使用第三方模型不会把部署者的工作流程责任外包出去，部署者的存在也不会取消上游提供者对模型文档和已知风险的责任。

“有人复核”为什么经常无法定位责任

组织常用一句话解释安全措施：“最后有人复核。”

但谁复核、复核什么、根据什么、拥有多少时间、能否拒绝，往往没有说明。

如果工作人员只看到最终价格，没有看到费率来源，他无法检查上游数据。如果一天需要批准几千封邮件，他可能只能确认格式。如果绩效指标奖励速度、拒绝AI结果却需要额外解释，所谓复核者会自然倾向于接受。

有效人工监督至少需要四个条件：

  1. 复核者具备相关知识；
  2. 能看到作出判断所需的证据；
  3. 有足够时间进行真实检查；
  4. 有权停止、推翻并要求补充。

缺少任何一项，“人工在环”都可能只是把自动结果转化为组织决定的签名步骤。责任被写在员工名字上，控制能力却没有同时交给他。

NIST AI风险管理框架要求明确记录角色、责任和沟通线，并强调领导层对AI开发和部署的风险决定承担责任；它还把申诉、推翻、事故响应、恢复和变更管理纳入部署后监测。NIST AI Resource Center：《AI RMF Core》

这说明责任不能只停在最后点击按钮的人。制度设计者和管理层必须为有效复核创造条件。

没有记录，就没有可恢复的责任链

事故发生以后，组织至少需要重建：

  • 用户或系统提出了什么任务；
  • 当时使用哪个模型、版本和配置；
  • 系统检索了哪些资料；
  • 调用了哪些工具，返回什么结果；
  • 哪些自动检查已经运行；
  • 哪个人看见什么内容并作出批准；
  • 输出改变了哪个外部系统；
  • 受影响者何时提出异议。

如果只保存最终邮件，原因调查只能依赖猜测。如果保存所有底层日志却无法把它们与业务决定对应，人也难以理解。

因此，记录需要同时服务技术追踪与组织问责。它不仅要有模型调用，还要有业务对象、来源版本、批准步骤和变更结果。敏感数据当然不能无限记录；隐私与安全要求决定保存范围和期限。但“因为日志可能敏感，所以什么也不保留”同样会使纠错失去基础。

美国政府问责局的AI问责框架把治理、数据、性能和监测列为相互关联的原则，强调管理者、监督者和第三方评估者需要把抽象原则转成可操作实践。U.S. GAO：《Artificial Intelligence: Key Practices to Help Ensure Accountability in Federal Use》

责任链只有在系统正常运行时就被设计和记录，事故后才找得到。

指定一名负责人，为什么仍然不够

澳大利亚政府《负责任使用AI政策》2.0版要求适用机构设置负责官员、维护AI用例责任、登记内部用例、进行影响评估并培训人员。Australian Government：《Policy for the responsible use of AI in government》

指定负责人很重要，因为它避免“大家都有一点责任”等于没有人负责。但负责人不能成为吸收所有风险的单点。

他需要获得系统清单、技术与业务支持、暂停权限、事件报告和管理层资源。每个具体用例仍需明确产品所有者、数据所有者、技术维护者、复核者和事故响应角色。

一个可操作的责任结构可以采用“谁负责执行、谁最终负责、谁提供意见、谁必须知情”的区分，但不能停留在表格。每个角色要与实际权限、能力和时间匹配。

补救能力是责任是否真实的检验

许多组织在上线前讨论准确率，错误发生后却没有清楚补救路径。

如果客户指出价格错误，客服能否暂停自动邮件？能否查看AI使用的费率版本？谁有权重新计算？已经付款的人怎样退款？错误是否会反馈到知识库与测试中？

一个只会找出“模型这次答错了”的系统还没有完成纠错。补救至少包括：

  • 阻止错误继续传播；
  • 恢复受影响记录或交易；
  • 通知受到实际影响的人；
  • 保留异议和处理过程；
  • 修正上游数据、规则或权限；
  • 增加能够捕捉同类问题的测试；
  • 评估是否需要限制或停用该用例。

责任最终表现为有人能够采取这些行动，而不是事故报告里出现一个名字。

不要把责任错误地集中到普通使用者

AI工具经常附带提醒：“请核查结果。”这对用户是合理警示，却不能成为上游设计者免除所有责任的通用条款。

普通员工无法审计基础模型，无法看到供应商内部测试，也不能修复公司数据治理。他只能对自己有能力和权限控制的部分负责。

同样，供应商不能为每个客户如何使用产品承担全部责任。客户若把一般写作工具接入高风险决定、提供错误数据或取消人工检查，部署选择属于客户。

合理责任不是全部推向模型供应商，也不是全部推向最后用户，而是沿控制能力分配：谁选择、谁知道、谁能改变、谁就应承担相应义务。

结论：AI不会承担责任，责任也不能停在一句“人类最终负责”

AI错误常能被定位为某个错误输入、错误调用或错误输出。责任链更难，是因为它横跨模型提供、应用设计、数据管理、组织部署、人员复核和事故补救。

把责任交给“AI”没有意义，因为AI不能接受处分、赔偿客户、改变治理结构或承诺不再发生。只说“人类最终负责”也不够，因为这没有指出是哪一个人、为了哪一环、获得什么权限。

更明确的原则是：

每一项AI工作都应在上线前确定谁提供模型，谁设计系统，谁拥有数据，谁批准用途，谁复核结果，谁能够停止，以及谁负责补救。

当错误发生，调查不仅要修正那次输出，还要检查责任是否与控制能力匹配。没有证据却被要求签字的人不是真正监督者；拥有部署决定权却把风险推给基层人员的管理者也没有履行责任。

找到错误可以恢复一次结果。找到并修复责任链，才可能防止系统再次以同样方式失败。

主要资料

继续阅读：浏览《AI进入工作之后》系列文章

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。