“Who is liable when AI goes rogue? Lawyers see new risks”这个标题这两天在圈子里转得挺多。做技术的看到这种问题第一反应往往是“我先看看是不是我们的代码写错了”但真到了事故复盘会上你会发现这个问题远比“谁的 bug”复杂得多。一个客服机器人说了不该说的话一个推荐系统把用户带进错误信息闭环一个辅助决策模型在极端场景下给出危险建议——表面上是一次 AI 行为失控实际上牵涉的却是数据来源、模型训练、部署策略、运营干预、人类审核等多条链路。律师们关注的是责任怎么划分而工程师要面对的是一个更现实的问题在事故发生之前我们有没有为“解释清楚”这件事准备好足够的技术证据。我写这篇文章不是想替律师下结论更不是给某种“免责指南”。我想从一个长期做 AI 项目落地的技术人视角拆解一下这个问题背后的工程逻辑以及我们在开发、部署和运营 AI 系统时怎么用工程手段降低“说不清谁负责”的风险。这个问题的价值在于它迫使我们把 AI 当作一个有边界的系统来管理而不是一个只要喂数据就会有结果的魔法盒子。1. 先理清AI“失控”到底是谁的失控很多人听说 AI 出问题脑海里浮现的是一台电脑突然有了自己的想法像科幻片里那样摆脱控制。现实完全不是这样。现实中所谓的 AI 失控几乎都是某个具体环节偏离了预期。这个偏差可能发生在输入侧也可能发生在模型本身还可能发生在部署和业务封装层面。1.1 失控并不等于“AI 自己想干坏事”举一个常见例子某款智能客服系统在用户反复输入敏感词汇后触发了不合适的回复。表面看是“AI 失控”但拆开看可能是训练数据没有覆盖这类极端输入也可能是对话管理模块没有做安全兜底还可能是运营阶段对线上输入没有做实时过滤。再比如一个内容推荐系统用户点击了几次极端内容系统就开始不断强化这类内容。这也不是“AI 有自己的立场”而是优化目标和数据分布共同作用的结果。如果推荐算法只优化点击率没有考虑信息多样性那它自然会顺着用户已有的兴趣走下去。问题出在目标函数上出在反馈机制上不出在“AI 意志”上。这意味着当我们讨论“谁负责”时首先要确定“失控发生在哪一层”。是输入数据被污染了是模型泛化能力不足是推理环境的异常还是产品层把模型输出直接暴露给了用户而没有加约束每一层对应的责任主体是完全不同的。1.2 责任是一个系统链条不是单一节点假设一个 AI 辅助诊断系统在某次使用中给出了错误判断导致用户受到损害。如果追溯起来你可能会发现训练数据的标注存在矛盾模型评估时没有覆盖这个亚型部署时选用了不匹配的硬件版本导致推理精度下降使用场景中医生过度信任了系统输出而没有做复核。你会发现没有一个单独的“坏人”。这是一个系统性的失败。责任链条里有数据提供方、数据标注团队、算法工程师、测试人员、平台运维、产品经理、一线使用者。任何一环做得足够好后面的风险可能都不会爆发。这件事给技术团队最大的启发是我们不能用一个“出了事再找原因”的心态来看待 AI 风险而应该在系统设计之处就把“可能在哪一层出问题”想清楚并且为每一层留下可检查、可回溯的记录。2. 从工程视角看为什么责任归属这么难传统软件出问题工程师可以打开日志定位到某一行代码或某个异常分支。修复一个 bug 虽然可能不简单但至少理由清楚、责任明确。AI 系统不是这样它在很多维度和传统软件有着本质区别这些区别直接导致责任难以划分。2.1 系统行为是概率性的不是确定性的传统软件在相同输入下通常会得到相同输出除非有状态变化而 AI 模型即使输入完全相同输出也可能因为随机种子、推理策略、并行环境等因素产生细微变化。这进一步导致一个结果用户遇到一次错误你很难稳定复现同一个错误。没有稳定复现责任判断就少了一个基础证据。我见过一个比较典型的场景一个文本分类模型在生产环境偶尔会把完全相同的两个请求分成不同类别。业务方直接判断是“AI 不稳定”算法团队排查后发现是因为推理服务里有随机采样温度参数线上配置和离线评估时不一致。这类问题如果不在日志中把推理参数记录下来复盘时几乎无从下手。模型输出的概率性不仅影响着准确率也影响着我们对“错误”的定义。一个模型在 95% 的情况下表现良好但在 5% 的情况下表现荒谬。这 5% 的荒谬不是普通 bug而是模型结构、数据分布和决策边界共同作用的结果。它可能永远无法被“修复”到 100%只能通过阈值调整、人工审核、风险兜底来降低影响。2.2 多层依赖让根因分析变得复杂一个现成的 AI 系统往往不是从零训练出来的而是基于开源模型、预训练权重、第三方 API、微调数据集、向量数据库等组件搭建。这意味着即使你自己写的代码没有问题系统也可能因为上游模型更新、API 策略变化、数据源污染而出问题。责任链条因此被拉得很长。你的模型是基于某个开源底座微调的一旦底座出现幻觉问题你的微调并不一定能够消除它你接入了某个外部大模型 APIAPI 供应商调整了安全策略你的产品行为就随之改变你使用了一个公开数据集做领域适配数据集中存在偏见你很难逐一发现。所以当律师问“谁负责”的时候技术上的答案往往不是“某个工程师”而是“多个参与方在各自环节留下的缺陷共同导致”。法律上的责任划分需要一套证据链而这套证据链在工程上对应的就是版本记录、数据记录、评估报告、发布日志、监控指标和事件复盘记录。2.3 模型的“黑盒”属性加剧了举证难度深度学习模型的内部表示很难被人类直接理解这是它被称作黑盒的原因。虽然可以借助可解释性工具生成注意力热力图、梯度归因、LIME、SHAP 等分析结果但这些工具只能给出部分解释而且解释本身也有可靠性的边界。在责任判断中你需要回答“为什么这个输入会触发这个输出”。如果模型是一个千亿参数的大模型你几乎不可能给出一个完全确定性的因果解释。你只能说“在类似样本上模型呈现出某种倾向”。这种解释远没有传统软件的逻辑链那么清晰。于是责任就很难锚定到一个具体的设计决策上。这提醒我们在部署高风险 AI 场景时不应该要求系统“永远不出错”而应该要求系统“出了错之后能解释”和“能被有效监管”。3. 团队可以在开发周期里提前布局“责任工程化”如果说法律上的责任划分需要等事故发生后由专业人士来判断那么工程上的责任准备完全可以在事故前就完成。我称之为“责任工程化”——通过一系列可落地的工程实践让系统在每次决策、每次更新、每次异常中都能留下足够用于解释和审计的痕迹。3.1 设计阶段就写清楚“模型使用边界”很多 AI 系统失败根源在于被用到了设计时没有覆盖的场景里。比如一个为新闻摘要训练的模型被接入了金融报告生成流程一个用于中文电商评论情感分类的模型被用来判断医疗评论的情绪。场景错配不是模型自己造成的而是部署决策造成的。在设计阶段团队就应该做一份“模型使用边界说明书”把以下内容写清楚预期输入的数据类型、格式、语种、长尾分布特征模型在哪些场景下经过验证在哪些场景下未经验证当前模型可接受的置信度阈值以及低于阈值时应触发的人工处理流程已知的输入扰动类型例如对抗性文本、特殊符号、超长上下文模型输出可能存在的系统性偏见或表现不佳的群体。这份说明书不是一次性文档而应该随着模型迭代和数据变化持续更新。它本质上是给未来的审计者和使用者看的。3.2 数据阶段记录“来源、分布和处理逻辑”数据是 AI 系统行为形成的土壤。模型偏见来自数据偏见模型盲区来自数据盲区。如果数据来源不清晰、标注标准不一致、抽样策略不透明那么当模型出现偏差时你很难向别人解释“为什么模型会产生这种偏好”。规范的做法是给每个数据集维护一份数据卡片至少包含数据来源和采集方式数据的时间范围、地域分布、语言分布标注规范的版本和标注人员的一致性指标数据清洗和过滤规则异常样本的保留策略数据版本与模型版本的对应关系。我在实际项目里见过太多因为数据版本混乱导致的纠纷。模型训练时用的还是旧版数据集但业务方以为线上模型理解最新政策。最后模型输出错误双方争论的焦点不是模型有没有问题而是数据集到底更新到哪一版。如果有完整的数据版本记录这类问题根本不会升级成责任之争。3.3 训练与评估阶段保留“可复现实验报告”很多人训练模型时只保留最终权重不记录超参数、随机种子、数据切分比例和评估集构成。这给后来埋下很大隐患当模型在线上出现问题时你无法确认当前线上模型是在哪组参数下训练出来的也无法复现当时的评估结论。我建议每次训练迭代都生成一个结构化的实验报告内容包括但不限于训练代码和依赖库的 Commit ID训练数据的数据集版本模型结构、超参数、随机种子训练时长、硬件信息、资源占用验证集和测试集的评估指标已知失败案例的样本记录部署模型的文件哈希值。这里的关键不是写论文而是建立“从模型产物到原始训练过程”的追溯能力。将来一旦出现事故你可以借助这份报告快速判断是数据变了还是参数变了还是部署变了。3.4 部署与监控阶段构建“全链路日志审计”日志是责任的“监控摄像头”。没有日志一切复盘都只能靠推测。AI 系统部署时要记录的不只是服务端口和调用次数还要记录影响输出行为的核心上下文。我建议至少记录以下内容请求 ID、用户 ID、会话 ID输入原文的哈希值或脱敏存储模型版本和推理参数temperature、top_p、max_tokens 等关键中间结果向量检索结果、重排结果、候选列表输出的完整内容与后处理标记命中哪些规则、触发哪些内容过滤策略如果有人工审核记录审核人、审核动作、审核时间上下游系统返回码和延迟。这些日志的保存时间不能太短。尤其是涉及用户权益、医疗、金融、教育等领域至少要保留足够长的审计期。同时要注意脱敏和权限控制不能为了审计而违反数据隐私要求——这两者不是对立的而是需要一起设计。4. 实战链路从最小可用到生产级责任治理理解了原则之后我们回到工程落地。一个 AI 系统不是上线就完事它会出现错误会被质疑会被追责。所以我更建议团队把“责任治理”当作一个持续演进的流程而不是上线前补一个检查表。下面这条链路比较适合大多数从原型走向生产的项目。4.1 第一步先跑通一次完整的事件追踪演练不要等真实事故发生后再测试自己的追踪能力。我建议团队在功能上线前做一次“模拟事故追踪”人为制造一个模型输出异常然后尝试回答以下问题这次异常发生在哪一层当时输入是什么完整记录在哪调用了哪个模型版本在哪个部署节点模型输出的原始结果和最终展示结果是否一致中间是否有规则拦截或人工干预如果用户投诉我们能拿出哪些证据如果回答不全就说明日志和追踪机制还没有到位。这个演练不用做得很复杂但能暴露很多团队以为“应该没什么问题”的漏洞。4.2 第二步把高风险场景和低风险场景分层管理不是所有 AI 输出都需要同样严格的责任机制。一个提供创意文案的助手和一个辅助信贷审批的系统风险等级天差地别。所以要对使用场景做分级高风险场景必须增加约束条件和审计要求低风险场景则可以保留更大的自治度。一个实用的分层方法是先画一张“场景风险矩阵”横轴是出错后果严重程度轻微不变得益、一般损失、严重损失纵轴是对模型输出自主性的要求完全自治、人工复核、人机共同决策。根据矩阵结果高风险场景需要人工复核机制同时要有拦截规则和紧急熔断中等风险场景需要设置置信度阈值低于阈值转人工低风险场景可以全自动但要保留反馈通道和事后追溯能力。这样做的原因是过分严格的责任机制会把产品体验拖垮完全不设防则会在事故来临时失去控制。分层管理既保证效率又保住底线。4.3 第三步设计“人机协同”中的决策留痕许多 AI“失控”发生在人机协同过程中。人类操作者本应做最终判断但因为过度信任或疲劳直接采纳了模型的错误建议。这种情况下责任划分更加复杂。工程层面能做的事情是让决策留痕。例如当模型给出建议时系统记录模型的风险提示和置信度人类操作者确认后系统记录操作者的确认动作。如果最终决策错误至少能看出当时模型给的是什么提示人类有没有注意到风险。这不是为了把锅甩给谁而是为了在复盘时得到一个更客观的事实基础。我见过一个实际案例某个 AI 审核助手把一份异常单据标记为“低风险”审核人员没有仔细检查就通过了。后来发现问题追责时发现模型输出里其实带有“confidence: 0.52”的提示但界面设计没有显著展示这个置信度。审核人员根本不知道模型自己也没有把握。这就是决策留痕没有做好导致整个流程里的人都没有获得足够信息。4.4 第四步建立线上反馈回路和定期审计机制AI 系统上线后不能一直原地不动。数据分布会变化用户行为会演变模型效果会衰减。如果不建立反馈回路系统可能在某一天突然大量出错而你根本不知道什么时候开始变的。我建议每一个生产级 AI 系统都至少具备以下反馈机制自动监测输入分布变化例如文本长度、主题分布、用户意图类别预测质量监控例如置信度均值变化、输出长度变化、规则命中率变化用户反馈收集不只是“赞/踩”还要支持用户提交具体原因定期人工抽样复盘每周或每月抽取一批预测样本由业务专家和算法工程师一起判断模型表现事件分级和告警级联到对应的责任人和负责人。这里的重点不是“防止出错”而是“尽早发现出错”。基于这些反馈机制团队可以定期生成审计报告。这份报告既是内部质量管理的依据也是未来面对外部质疑时最有说服力的技术材料。4.5 第五步事故排查遵循“输入-环境-模型-参数-日志”的顺序当 AI 事故真正发生第一反应不要是“我已经知道原因了”。很多误判都来自过早跳到了结论。我建议所有团队建立统一的事故排查链路先看现象是“输出了错误内容”还是“服务不可用”还是“接口返回慢”还是“没有触发风险拦截”现象定义得越具体后续排查越高效。再看输入原始请求是什么格式、长度、内容、上下文是否异常是正常用户行为还是恶意输入再看环境模型部署在哪台节点依赖版本是什么上游 API 是否有变更是否存在资源竞争再看模型线上模型版本和训练实验记录能不能对上模型评估集里有没有覆盖这类输入模型输出的置信度分布是什么再看参数推理参数、后处理规则、拦截阈值、超时时间是否和发布配置一致最后看业务侧产品层有没有对模型输出做二次包装有没有自动重试或缓存机制造成偏离这个顺序的核心逻辑是从“现象”到“输入”相当于从最容易被观察到的信息开始逐步向系统深处推进。这样可以避免一开始就陷入对算法原理的争论而是先锁定一个可验证的范围。5. 不能只靠工具AI 责任治理需要团队协作与流程改进最后想聊一个容易被忽视的部分。很多人以为只要我们做好日志做好监控做好记录责任问题就解决了。但实际情况是技术工具只是基础真正决定责任治理水平的是团队如何协作、如何定义边界、如何对待“AI 不是万能”这件事。5.1 技术团队、产品团队和业务方要对“模型边界”有一致认知一个模型能做什么、不能做什么只靠算法工程师自己清楚是不够的。产品经理要理解模型能力的边界才能设计出符合预期的交互业务方要理解模型问题的概率属性才能对上线的效果有合理预期市场运营也不能为了宣传效果而过度承诺。我建议在项目立项时就用一个简明文档把模型能力边界写清楚并且让所有相关方签字确认。文档不追求写多少页关键是把这几件事说透模型在哪些数据分布下是可靠的模型在哪些场景下不能保证准确当模型置信度较低时系统会怎么处理使用者应该什么时候相信模型什么时候保持警惕。一旦相关方对边界达成一致很多“AI 失控”的争议就不会发生因为大家从一开始就没有期望它在边界外不出错。5.2 把“人工复核”当作一个正式流程来设计负责任的人机系统里人工复核既是效率成本也是质量保证。很多团队为了追求“全自动”把人工复核设计成了一个无人关心的形式化流程。审核员每天面对海量数据注意力早已疲惫这时候“人”就成了系统里最弱的一环。我建议做两件事一是设置复核抽检比例。对于风险极高的决策做到全量复核对于一般场景可以按一定比例抽检但抽检策略要符合风险等级。二是给复核人员提供足够上下文。不要只展示模型的一个结论而是把输入的关键特征、模型的置信度、相似的过往案例、可能的解释原因都列出来。这样人能做出更有依据的判断。5.3 周期性的责任审计不能省团队应该把 AI 责任审计变成一个周期性动作和代码评审、测试审查并列。审计的内容包括线上模型是否和记录版本一致日志记录是否覆盖关键决策流程人工复核的效率和准确率是否在合理范围风险事件是否都完成了复盘模型边界文档是否仍然有效是否出现了新的未覆盖场景。审计的目的是发现问题而不是追责个人。我见过一些团队把审计做成了内部惩罚工具结果大家把更多精力花在隐瞒信息上而不是改进系统。那样反而会让责任风险越积越高。6. 给技术人的一张“责任准备清单”我们聊了这么多最终还是要落到几个最基本的动作上。如果你正在开发或运营一个 AI 系统可以用下面这份清单来判断自己的责任准备是否到位。它不是法律意见而是一个工程层面的自查表是否有一个文档记录当前模型的预期行为边界是否知道当前线上模型的训练数据和训练配置是否知道每次发布的模型版本、数据版本和代码版本是否记录了模型在线上所有关键输入的原始输出是否有一个明确的流程来判断低于置信度阈值的输出应该如何处理是否对高风险场景设置了人工复核并保留了复核记录是否有监控机制能够及时发现输入分布漂移或模型效果衰减是否做过模拟事故追踪演练是否让产品、技术、运营对模型的边界达成一致如果这些问题里有太多“还没有”说明你的 AI 系统在能力上可能很先进但在责任治理上还是裸奔状态。你不需要在一天之内把所有机制都建齐但需要从最重要的一两件事开始。比如先给当前线上模型补上完整的版本和评估记录然后把关键请求日志加上模型版本和推理参数。这些改动并不复杂但会在真正需要厘清责任时成为你最重要的底牌。AI 行为失控这件事短期内不可能被完全消除。这就像天气一样有概率、有极端情况。我们无法控制雷暴但可以提前准备避雷设施和应急预案。对于每一个参与构建 AI 系统的人来说理解这一点就是理解我们这个职业身上更深一层的要求我们不只是要把 AI 做出来还要让它能在这个充满规则和责任的世界里站得住脚跟。