简短答案
AI本身不能成为替组织承担责任的主体。责任应按真实控制分配：决定采用和用途的人或机构对最终服务与补救负责；供应商对其产品、承诺与缺陷负责；部署团队对数据、权限、测试和监控负责；专业决策者对不能委托的判断负责；操作者只对其有能力、有信息且有权限控制的部分负责。受影响者不应被迫在复杂供应链中寻找“到底是哪一个模型错了”才获得纠正。
“AI做的”不是责任解释
一项贷款被错误拒绝、一封邮件泄露资料或一次付款转错账户时，说“算法决定”没有回答谁选择了系统、谁设定权限、谁批准用途、谁忽略警报以及谁能补救。技术描述不能代替组织责任。
AI没有资产用来赔偿，不能接受专业纪律，也不能被要求向受影响者解释和修复。法律责任会因司法管辖、合同、行业和事实而异，本文不是对具体案件的法律意见；但治理上可以确立一个清晰默认：对外提供服务或作出决定的组织不能把基本责任转嫁给模型。
澳大利亚政府关于AI法律环境的材料指出，现有隐私、消费者、反歧视、公司、知识产权和行业法律都可能适用于AI活动。采用AI不创造一个没有现有义务的真空。Australian Government: The legal landscape for AI in Australia
先区分责任的不同含义
“谁负责”至少包含五个问题。谁有义务预防；谁能在运行中控制；谁调查原因；谁向受影响者提供纠正或赔偿；谁承担内部纪律、合同或法律后果。答案可能不是同一个人。
例如采购团队选择供应商，技术团队配置系统，业务经理批准自动化，员工处理异常，供应商运行模型。一次事件可能由多个控制失效共同造成。需要分配而不是寻找一个方便的替罪者。
责任还分为面向受影响者和组织内部。客户应面对一个明确的服务责任方；该机构之后可以按合同向供应商追偿。不能先让客户理解整个模型价值链。
采用机构对用途和最终结果负首要责任
组织决定在哪个场景使用AI、提供什么数据、赋予哪些权限、接受什么风险并把结果交给客户或员工。它通常最接近受影响者，也最能暂停使用、纠正记录和提供补救。因此对外责任不能以“第三方模型产生”轻易排除。
这不意味着组织为供应商所有隐藏缺陷承担唯一责任。它意味着机构必须进行与风险相称的尽职调查、测试、人工控制、监控、申诉和事件响应，并成为受影响者可以找到的责任入口。
若组织无法理解产品最基本的数据处理和限制，仍把它用于高影响决定，缺乏理解本身就是治理问题。无法审计的供应商可能不适合该用途。
供应商对产品能力、限制与承诺负责
模型或应用供应商控制训练、系统设计、更新、安全机制、日志和服务条款。它应准确描述适用范围与已知限制，提供必要文档和事件支持，不应以模糊“AI可能出错”免除可预见缺陷或不真实营销。
采购合同应明确数据用途、保留、子处理商、安全、版本变更、服务水平、事件通知、审计信息、知识产权、赔偿、终止与数据返还。责任上限和免责声明需要与最坏用途相称，由具备专业能力的人审查。
组织也不应购买一个通用工具后把供应商宣传当作本地验证。供应商负责产品层，采用者负责具体配置与使用层；两者可能同时有责任。
部署和工程团队对技术控制负责
把模型接入真实数据和工具的人控制权限、检索、提示、验证、版本、监控和停止机制。若代理因共享管理员账号能删除全部文件，问题不只是模型理解错，也是权限架构错；若更新没有回归测试，行为变化导致损失，是变更管理问题。
技术负责人应记录风险假设、测试范围、已知失效模式和部署批准。发生事件时保存证据、限制影响并帮助重建轨迹。不能把所有错误解释成模型不可预测，从而忽略可确定控制。
但工程师不应单独承担组织选择高风险用途的责任。业务与治理负责人必须批准目标、损失预算和自动化边界。
业务与专业决策者保留不能委托的判断
医生、律师、财务负责人、安全工程师、招聘经理或政府决定者若使用AI辅助，仍需履行适用专业和组织职责。AI可以提供材料，但不能通过生成建议接过法律授权、职业义务或对个人作出理由充分决定的责任。
真正监督需要能力、证据、时间和否决权。若组织安排一天审核上千项，批准者只看到AI摘要，就不能在事后把所有错误归给最后点击的人。系统设计剥夺了有效控制。
责任应跟随控制。某人只能对合理有能力发现和改变的事项承担对应责任；组织必须为培训、工作量和升级路径负责。
一线员工不应成为默认替罪者
员工可能输入错误、无视清晰警告或越权使用工具，这些行为需要处理。但如果政策模糊、工具被默认开放、绩效压力鼓励快速接受、审核资料缺失，个人错误也是系统条件的结果。
事件调查应问为什么控制允许错误到达外部，而不只问谁点了按钮。采用“公正文化”有助于区分诚实失误、培训缺口、流程设计和故意违规，让员工愿意报告险情。
如果每次事故后都处罚最后操作者，团队会隐藏问题，组织也不会修复架构。反之，完全取消个人职责会让规则失去意义。明确可执行职责与合理后果才平衡。
受影响者需要一个简单的申诉与补救入口
个人不应被要求证明模型内部机制才可以纠正错误。通知应说明AI是否对重要结果产生实质影响、使用了哪些相关数据、如何纠正事实、谁可以重新决定以及申诉时限。
补救可能包括暂停行动、恢复服务、更正记录、重新人工评估、通知第三方、退款或赔偿。先恢复受影响者，再进行组织之间的责任分配。否则复杂供应链会成为拖延工具。
OAIC关于商业AI产品的隐私指引强调组织仍需对个人信息处理负责，包括准确性、透明度、安全和对AI辅助决定的适当人工监督。OAIC: Guidance on privacy and commercially available AI products
合同不能解决所有责任
供应商与客户可以在合同中分配成本和义务，但合同未必约束受影响的消费者、员工或公众，也不能覆盖不能依法排除的责任。内部写上“用户自行负责AI输出”也不会自动免除组织设计和监督义务。
合同仍很重要，因为它决定谁提供日志、多久通知漏洞、模型更新如何沟通、谁协助调查和怎样退出。若供应商拒绝提供高风险用途所需的信息，采用者应降低用途或选择其他方案。
个人使用免费服务时通常缺少议价和审计权，更不应把它接入重要自动决策。低成本订阅可能把风险与可控性不对称地留给用户。
开源模型不会消除责任
开源可以提高检查和控制，也把更多部署选择交给使用者。模型提供者、微调者、托管方、应用开发者和采用机构仍分别控制不同部分。许可证条款只是起点，不能替代安全测试、数据治理和对外责任。
自托管还增加基础设施、补丁、访问、日志和模型更新责任。没有外部供应商不等于没有供应链，训练数据、库、权重、硬件和集成仍有来源。
责任地图应按控制点绘制，而不是按“开源/闭源”二分。
用RACI之外的“控制—证据—补救”表
传统RACI能标记负责人、批准者、咨询者和知情者，但AI流程还需要三个字段：每个角色能控制什么；用什么证据证明控制运行；失败后能提供什么补救。
例如付款代理：业务所有者批准用途和限额；财务批准具体付款规则；工程团队实施权限与去重；安全团队监测账户；供应商提供模型和事件支持；操作员处理异常。对每项列出日志、测试、批准记录、停止权限和恢复动作。
避免多个角色都标记“负责”却无人有最终决定。每个风险应有一个明确所有者，每次外部决定应有一个对受影响者可见的责任机构。
事件发生后按时间顺序调查
先保护人和系统：停止扩大、保存必要证据、撤销危险权限、纠正紧急结果。然后重建从输入到行动的轨迹，包括来源、模型与提示版本、工具参数、批准和回执。
分析直接原因、促成条件和治理原因。直接原因可能是模型误读金额；促成条件是没有确定性上限；治理原因是团队以演示为依据上线且无人批准损失预算。只修提示会留下更深缺口。
最后分配补救、系统修复、通知和合同追偿，并把结论反馈到测试和使用规则。事故报告应关注可重复防护，不宜虚构模型的“心理动机”。
NIST框架怎样帮助分配责任
NIST AI风险管理框架把治理作为贯穿映射、测量和管理的功能，并强调责任结构、文档和持续风险处理。它不是法律责任裁判，但可以帮助组织证明谁应做什么、如何监控及何时停止。NIST AI Risk Management Framework
对于生成式AI，价值链尤其重要：基础模型、数据、插件、应用和采用机构相互依赖。每方都应披露与其控制相称的信息，采用机构再把这些信息转成具体用途控制。
我的判断：责任应与控制匹配，补救应面向受影响者集中
内部可以存在复杂的共同责任，外部不应出现责任真空。谁向人提供服务或作出决定，谁先提供可访问的纠正入口；之后再依据控制与合同向其他方分配成本。
把所有责任推给最后操作者，会忽略系统设计；把所有责任推给供应商，会忽略采用用途；把责任推给AI，则是让一个不能补救的工具成为屏障。成熟治理承认多方原因，同时保持一个清晰的对外负责人。
责任检查表
- 谁决定使用AI处理这个具体用途和风险级别？
- 谁控制数据、模型版本、提示、工具权限、测试与监控？
- 谁拥有最终业务或专业决定，是否具备真实否决权？
- 供应商合同是否覆盖数据、变更、事件、日志、审计与退出？
- 一线人员的职责是否与培训、资料、时间和权限相匹配？
- 受影响者是否能知道AI作用、纠正数据、获得人工复核与补救？
- 每个关键控制是否有证据、负责人、停止和恢复机制？
- 事故后能否区分直接、促成和治理原因，而不只找一个人承担？
结论
AI造成损失时，责任不能留给AI。采用机构对用途、外部结果和补救负首要责任，供应商、工程团队、业务决定者和操作者按各自控制承担相应义务。对内可以细分，对外必须有清晰入口。责任与控制匹配、补救先于推诿，才能让AI供应链复杂而不产生责任真空。
相关问题
继续阅读本系列： 《AI可以相信到什么程度？》全部文章
了解 Geoffrey Chen 的更多信息
订阅后即可通过电子邮件收到最新文章。