---
title: "黑箱转向（七）：AI 生成代码出错，谁负责"
url: https://lingming.blog/posts/2026/the-ethics-of-the-black-box/
date: 2026-03-07
lastmod: 2026-08-31
tags: ["AI 治理","软件责任","软件供应链","可追溯性","生成式 AI"]
categories: ["软件工程","人工智能"]
description: "AI 生成代码导致事故时谁负责？本文区分作者、版权、来源、组织问责与法律责任，并提出可审计、保护隐私的证据链。"
---

# 黑箱转向（七）：AI 生成代码出错，谁负责


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

回答“模型写的”过于简单；回答“最后点合并的人承担一切”也同样简单。[上一篇]({{< relref "/posts/2026/the-new-engineer-from-coder-to-constraint-designer.md" >}})说明工程师的任务正在扩展到约束和验证。本篇进一步区分几种经常被混在一起的责任问题。

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

## 先拆开五个不同问题

### 文本作者是谁

这关乎一段表达如何产生。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 生成代码让文本作者身份变得不再简单，却没有创造一个无人负责的自然真空。真正危险的是组织允许责任链变得不可行动：每个人都参与一点，却没人有权停止、解释、通知和补救。

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

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

## 延伸阅读与参考资料

- [NIST SP 800-218：Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [SLSA：Provenance and Build Terminology](https://slsa.dev/spec/v1.1/terminology)
- [欧盟：Directive (EU) 2024/2853 on Liability for Defective Products](https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX%3A32024L2853)
- [欧盟委员会：Navigating the AI Act](https://digital-strategy.ec.europa.eu/en/faqs/navigating-ai-act)
- [NIST：Generative AI Profile for the AI Risk Management Framework](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)

*上一篇：[《黑箱转向（六）：从编码者到约束设计者？》]({{< relref "/posts/2026/the-new-engineer-from-coder-to-constraint-designer.md" >}})；下一篇：[《黑箱转向（八）：三种黑箱，三种控制》]({{< relref "/posts/2026/redefining-control-in-the-age-of-generative-systems.md" >}})。*