代码代理生成了一段身份验证逻辑，工程师审查后合并，企业部署到生产，攻击者随后利用其中的权限绕过漏洞。谁负责？

回答“模型写的”过于简单；回答“最后点合并的人承担一切”也同样简单。上一篇说明工程师的任务正在扩展到约束和验证。本篇进一步区分几种经常被混在一起的责任问题。

以下讨论用于工程与治理分析，不构成特定法域的法律意见。

先拆开五个不同问题

文本作者是谁

这关乎一段表达如何产生。AI 可能生成初稿，人类选择、修改和组合，团队又通过模板、测试和代码审查影响最终形态。“作者”在事实层面可能是分布式的。

版权归谁

版权是法律问题，取决于法域、人的创造性贡献、合同和具体制品。它不能仅凭 Git 提交者或模型名称决定，也不等同于事故责任。

制品从哪里来

来源记录关心模型、输入、依赖、工具、构建环境和批准过程。它提供证据，帮助复现与调查，但记录本身不会承担道德或法律责任。

谁应当解释和纠正

这是组织问责。谁有决策权、谁能停止系统、谁掌握资源、谁应通知受影响者？答案通常落在团队与机构的职责设计，而不是某个词的作者身份。

谁承担法律责任

产品责任、合同责任、过失、监管义务和雇佣关系会给出不同答案。它们取决于控制能力、可预见性、注意义务、产品角色和损害类型，不能从“代码由 AI 生成”直接推出。

把五者分开以后，所谓“作者消失导致责任真空”就不再成立。文本来源可能模糊，责任仍可以沿控制、受益和义务进行分配。

模型不是可以被追责的组织主体

当前代码模型不能被罚款、赔偿受害者、修订公司流程或接受职业处分。把错误归给“AI”只能描述因果链中的一个工具节点，不能完成规范分配。

同样，责任也不能“依附于生成过程本身”。流程可以强制留痕、阻止发布和提供调查证据，但只有人和法律组织能够承担义务并采取补救行动。

更有用的问题是：

  • 谁选择了工具并决定适用场景？
  • 谁设定了权限、数据和审查门槛？
  • 谁批准发布并从系统中受益？
  • 谁最有能力发现、预防和纠正风险？
  • 工具或模型供应商作出了哪些安全与能力承诺？
  • 哪一方违反了适用合同、专业规范或法律义务？

这些问题可能把责任分配给多方，而不是寻找唯一作者。

一条责任链怎样展开

回到身份验证漏洞的例子。

开发与审查人员需要按组织约定检查高风险鉴权变化，不能把模型输出当作可信来源。如果变更巨大、证据不足，工程师有责任缩小范围或拒绝合并。但个人责任应与其权限、时间、培训和组织压力相称。

部署组织决定把系统用于真实用户，设置开发流程、资源和风险容忍度，通常也最有能力监控、停止服务、通知用户和补救损害。它不能仅用“员工用了第三方模型”解除自己的治理责任。

AI 工具供应商可能对数据处理、产品安全、能力说明和合同保证承担责任。如果产品在合理预见的使用中隐瞒重大限制或引入供应链风险，不能自动以“只是工具”结束分析。

基础模型提供者对下游具体应用的控制较弱，但仍可能对模型开发、文档、系统性风险和适用监管义务负责。责任范围需要按具体产品关系判断。

开源或第三方组件维护者也可能进入因果链，但“代码被训练数据包含”本身不意味着原作者对后来生成的漏洞负责。

责任链因此是控制结构，不是 Git blame 的放大版。

生成代码与运行时模型需要不同审计

如果 AI 只在开发阶段生成普通源代码，安全分析的主要对象仍是最终制品：代码、依赖、构建结果和部署配置。研究模型内部特征通常不能替代静态分析、测试和审查。

如果大模型在生产环境中直接生成答案、做分类或调用工具，模型版本、系统提示、检索数据、解码设置、评测结果和运行事件才成为产品行为的重要组成部分。此时只审查外层代码又明显不够。

如果代理会在运行时修改并执行代码，还要记录每次授权、工具调用、沙箱边界、制品摘要和外部副作用。

三种场景使用同一个“AI 可解释性”标签，会把审计资源投错地方。

生成记录应该保存什么

一个可调查的证据链可以包括：

  • 工具与模型的明确版本；
  • 仓库、依赖和输入制品的版本或摘要；
  • 生成任务和关键约束；
  • 输出 diff 及其后续人工修改；
  • 审查者、批准者和例外决定；
  • 自动测试、静态分析与安全扫描结果；
  • 构建环境、制品摘要和部署记录；
  • 运行监控、回退和事故处置记录。

SLSA 把 provenance 定义为说明制品怎样生成的证明性元数据，包括构建平台和外部参数。这个思路比保存一段聊天截图更可靠：记录应绑定具体制品，能够校验完整性，并区分受信与不受信来源。

不要无条件保存全部 prompt

Prompt 和上下文可能包含源码、密钥、客户数据、个人信息与安全细节。为了审计而永久保存一切，会制造新的隐私和攻击面。

更稳妥的策略是：

  1. 先按任务风险决定记录粒度和保留期限。
  2. 对密钥与个人数据进行禁止、脱敏或隔离。
  3. 能用版本号和加密摘要证明的内容，不重复存储完整副本。
  4. 限制日志访问，并记录谁查看过审计材料。
  5. 把关键设计理由提炼进版本化决策记录，不依赖冗长对话。
  6. 明确哪些数据会发送给第三方模型和保留多久。

可追溯性本身也必须接受最小化和权限控制。

“模型为什么这样写”不是可靠免责证据

让模型事后解释一段代码可能帮助审查，但生成的解释不保证忠实重现当时内部计算。即使保存了模型输出的推理文本，它也更像一项待核验说明，而不是决定性因果记录。

事故调查更应关注可验证链条：输入了什么，产生了哪个制品，谁修改并批准，哪些测试运行，部署了什么版本，生产发生了什么。对运行时模型，还要结合系统化评测和真实事件，而不是把自然语言解释当作事实。

法律框架已经在按角色分配义务

责任并没有等待“代码作者”概念解决后才出现。欧盟 2024 年产品责任指令已经明确把软件和 AI 系统纳入产品范围，并围绕制造商控制、缺陷与损害建立责任规则。欧盟 AI Act 则区分提供者、部署者等角色，对高风险系统设置文档、监控、人类监督和事件处理义务。

这些规则会随法域、系统用途和生效时间不同而变化，但它们共同说明一件事：现代责任越来越围绕产品生命周期和控制角色分配，而不是寻找实际敲下每个字符的人。

工程架构因此确实具有制度意义。权限、日志、批准和恢复路径不仅影响可靠性，也决定组织能否证明自己履行了应有注意。但合规证据不能替代真实安全，更不能把责任悄悄下放给权限不足的个人工程师。

结语：来源可以分布，责任必须可行动

AI 生成代码让文本作者身份变得不再简单，却没有创造一个无人负责的自然真空。真正危险的是组织允许责任链变得不可行动：每个人都参与一点，却没人有权停止、解释、通知和补救。

好的责任设计不追求一个万能背锅者，而是让每个有控制力的角色拥有相称义务，让关键过程留下可信证据，并确保事故发生后有人能够采取实际行动。

代码可以由模型生成，责任不能由模型代领。

延伸阅读与参考资料

上一篇：《黑箱转向（六）：从编码者到约束设计者？》；下一篇：《黑箱转向（八）：三种黑箱，三种控制》。