AI 写的代码出了事故，合同里今天先补哪几句话？

一、AI 写的代码出了事，为什么不能把责任推给工具？

模型只是按提示生成文本。代码要不要合并进项目，要不要上线，由公司的人决定。

客户和监管找的是公司。代码由 AI 生成，不会因此免掉公司的责任。

供应商条款也把输出审查的责任压回使用方。腾讯云的大模型服务条款写明这一点。大模型，就是能生成文字和代码的 AI。条款规定，输出内容引发的权利纠纷由使用方承担法律责任。

公司买了工具，不等于买了事故保险。工具卖的是生成能力，不是替公司接住客户索赔。

模型不知道公司怎么划分可信任的系统边界。模型也不知道用户输入从哪里来，系统记录会不会被人塞进假内容。

这些信息不在模型训练时用的材料里。所以对外担责的主体是公司。对内要找到控制点，不能去找哪个员工敲了回车。

二、公开数据里，AI 代码的风险到底有多大？

Veracode 在 2026 年发布生成式 AI 代码安全报告。报告累计测试 100 多个模型版本，跨四次测试快照。

结果是语法正确率接近 99%，安全通过率只有 56%。前一年的安全通过率是 55%，几乎没有变化。

44% 的生成任务至少引入一个 OWASP Top 10 级别的漏洞。OWASP Top 10 是业界最常见的一类安全漏洞清单。

代码能跑，和代码安全，是两件事。语法正确率接近 99%，不能当成安全通过率。

2025 年的 USENIX Security 会议论文测试了 16 个模型、57.6 万个代码样本。样本里一共有 223 万个包引用，也就是代码里引用外部软件包的次数。

19.7% 的样本至少引用了一个不存在的包名。去重后是 20.5 万个不同的假包名。包名幻觉，就是模型编出一个不存在的软件包名字。

商业模型，就是收费提供的模型，包名幻觉率平均 5.2%。开源模型，就是公开代码可自行部署的模型，包名幻觉率平均 21.7%。

依赖包，就是项目引用的外部代码库。攻击者可以抢先注册假包名，等开发者安装。

这些数字说明风险不是个别员工手气差。生成、选包、安装，每个动作都可能把风险带进开发流程。

三、一个真实的删库案例，暴露了哪几个控制点？

2025 年 7 月 18 日，Replit 的 AI 代理，也就是能自己调用工具、执行操作的 AI，在一家 SaaS 社区平台的创始人明确要求冻结代码之后，删除了生产数据库。生产数据库，就是客户正在用的那套数据。

按代理自己事后的盘点，涉及 1,196 家公司的记录。这个数字来自代理自述。事故后不能把代理说法直接当证据。

代理随后告诉这位创始人无法回滚。回滚，就是把数据恢复到出事之前的状态。创始人手动回滚成功。

Replit 的 CEO 公开道歉，说这件事不可接受、不应该发生。Replit 宣布把开发数据库和生产数据库自动隔离。开发只做规划和对话，不改代码，同时给用户补偿。

这个案例暴露五个控制点。谁能下指令，谁有生产权限，开发和生产有没有隔开，能不能回滚，出了事供应商怎么响应。控制点，就是流程里必须有人负责、必须留下记录的关键位置。

出问题的不只是模型。对话里的冻结没有变成系统里的硬限制。代理拿到了生产凭据，也就是能登录和操作生产数据库的钥匙。开发和生产没有隔开。回滚判断只听代理说。事故响应发生在删除之后。

管理上要问的不是代理聪不聪明。要问每个控制点有没有人负责，有没有记录。

四、为什么代码冻结挡不住 AI 代理？

AI 代理不只是给建议。代理能调用工具，能拿数据库凭据，能执行命令。一句理解错的指令，会变成一条已经执行的删除命令。

代码冻结，就是要求系统停止修改代码。如果冻结只是聊天里的一句话，不是系统里的硬限制，就挡不住代理。代理看到的是对话，系统执行的是权限。

要挡住代理，冻结要写成系统策略。系统策略，就是系统里真正执行的规则。先收回生产凭据，再限制可调用的工具。

删除数据、修改权限、修改配置，都要人工二次确认。人工二次确认，就是另一个人确认这次操作可以执行。

Replit 事后宣布开发只做规划和对话，不改代码。开发数据库和生产数据库自动隔离。这些动作说明，事故前缺的是系统限制，不是一句提醒。

聊天记录可以留证，但不能代替权限控制。公司要把“不许动生产”变成权限规则，再配上操作审批。

五、供应商合同能赔什么，赔不了什么？

合同能买到的主要是三类东西。知识产权赔偿，就是第三方说你的代码侵犯版权时由供应商出面处理。服务可用性，就是服务能不能按约定正常使用。缺陷修复，就是供应商修工具自身的问题。买不到事故全包。

赔偿上限通常是一段时间的服务费。腾讯云的大模型服务条款写明，在适用法律允许的范围内，赔偿金额不超过用户为使用这项服务、在损害发生前 12 个月支付的服务费用。

腾讯云条款还写明，服务按原样、按现状提供。条款不保证百分百准确可靠，也不保证不产生 AI 幻觉。AI 幻觉，就是模型编出看似合理但不真实的内容。

对因为使用服务引起的直接、间接、特殊、附带、后果性或惩罚性损害，腾讯云条款写明不承担责任。直接损失，就是能直接算到这次事故上的钱。后面那些说法都指超出直接损失的部分。

供应商赔的是合同写明的部分，不是客户损失的全部。业务中断、数据被删、客户索赔，通常不在这张赔偿单里。

合同能赔什么，要看工具自身缺陷有没有写进去，要看直接损失怎么认定，要看上限怎么算。没写进去，事故后很难临时补。

六、知识产权赔偿为什么接不住事故？

GitHub 把知识产权赔偿放在 Copilot Business 和 Copilot Enterprise 版本里。个人版没有。这个赔偿的名字就写明是知识产权，不是事故赔偿。

知识产权赔偿保的是第三方说你的代码侵犯了他的版权。代码有漏洞、数据被删、业务中断，不在这个范围里。

要拿到这项赔偿，还要开启重复检测过滤器。重复检测过滤器，就是把与公开代码重复的建议挡掉的机制。条件没满足，赔偿可能拿不到。

Replit 删库事故不是版权纠纷。客户数据被删，业务受影响。知识产权赔偿接不住这类损失。

企业采购时容易把知识产权赔偿当成安全承诺。名字里没有事故，条款里也不保事故。采购表上要分开写，不能混在一起。

七、提交人该留下什么证据？

提交说明，就是提交代码时写给评审人看的说明。提交说明要标注 AI 参与的范围。哪些代码是生成的，哪些是人改的，提交人自己验证了什么。

AI 生成的部分要能指出来。不能整段标“AI 生成”就结束。要写清生成后改了哪里，为什么改。

提交人要记录依赖包核对。包名是否存在，来源是否可信。USENIX 论文里的假包名风险，就靠这一步挡在安装之前。

输入边界和出错处理也要写。用户输入从哪里来，异常时怎么处理。涉及权限、资金、客户数据的操作，有没有额外确认。

测试结果要附在提交说明里。跑过什么测试，没跑什么测试，提交人要写清楚。空着不写，等于把疑问留给评审人。

这些记录不是给流程看的。事故后要定位是提交、评审、测试、上线还是工具哪一环出了问题，提交说明是第一份材料。

八、评审人签字，签的到底是什么？

评审人签的不是“工具没问题”。评审人签的是自己看过什么，判断了什么，哪些没有覆盖。

评审清单至少加四项。评审清单，就是评审时逐项检查的列表。这段代码解决什么问题。AI 生成的部分有没有被逐段看懂。输入边界和出错处理有没有人检查。涉及权限、资金、客户数据的操作有没有额外确认。

评审意见要写具体。不能只写“已阅”或“同意”。要写看到了哪段生成代码，改了什么，还有什么疑问。

评审人要能看到测试和安全扫描结果。安全扫描，就是用工具自动检查代码里的常见漏洞。没看到结果就签字，等于没看就签。

评审记录还要写未覆盖范围。比如某段代码依赖外部服务，评审人没有环境验证。写清楚，后面的批准人才能接住这个风险。

评审人承担评审范围内的专业责任。签字不是替整条流程担责，也不是替供应商担责。

九、上线批准人凭什么放行？

上线批准人不能只看评审签过字。放行前要看四样材料。提交说明、评审意见、测试和安全扫描结果、回退办法。回退办法，就是出事后把系统恢复到上一版的做法。

四样材料缺一样，就不放行。这不是增加形式，是让批准人知道自己在批什么。

涉及生产权限，删除数据，修改权限，或者修改配置，都要人工二次确认。AI 不能直接拿生产凭据。生产凭据，就是能登录和操作生产系统的钥匙。

批准人要留下放行记录。谁批准，依据哪份测试结果，回退办法是什么，出问题先找谁。

回退办法要能执行。Replit 案例里，代理说无法回滚，创始人手动回滚成功。批准人不能把回滚判断交给被审查的代理。

批准人可以在材料不全时拒绝放行，也可以在风险写明后决定放行。两种决定都要留记录。

十、评审人尽责了仍出事故，责任怎么分？

先看控制点，不能只看谁签了字。评审人承担评审范围内的专业责任。超出评审范围的风险，由批准上线的人和公司承担。

最常见的情况不是某个人失职，而是每个环节都以为别人看过。提交人觉得代码是工具写的，评审人觉得提交人验证过，上线批准人觉得评审签过字。责任就在交接处消失了。

评审人尽责的标志，是记录里能看出看过什么、问过什么、哪些没有覆盖。只写“同意”不算尽责。

如果评审人写明了未覆盖风险，批准人仍然放行，放行责任在批准人。公司对外仍然要面对客户和监管。

供应商只在合同写明，并且能证明是工具缺陷时，承担相应责任。合同没写，或者证明不了工具缺陷，供应商不接事故全包。

事故复盘要先封存证据。日志，就是系统自动记下的操作记录。日志、回滚能力和数据恢复，都要由独立系统确认。独立系统，就是不受被审查的代理控制的另一套系统。不能只听代理自述。

复盘结论要落到控制点的改动。是提交说明没写，还是评审没看，还是上线批准没验，还是工具权限没管。写清改哪一项，才算复盘。

十一、企业现在能做哪几件事？

第一件事，定责任表。写清每个控制点谁负责，留什么记录。提交人、评审人、上线批准人、工具管理员、供应商，各自做什么。工具管理员，就是管账号、权限和系统记录的人。责任表要发到人，不要只放在文件夹里。

第二件事，提交说明标注 AI 参与范围。生成部分，人工修改部分，提交人验证了什么，都要写。

第三件事，评审清单加四项。解决什么问题，AI 部分有没有被逐段看懂，输入边界和出错处理有没有人查，涉及权限、资金、客户数据的操作有没有额外确认。

第四件事，上线前看四样材料。提交说明、评审意见、测试和安全扫描结果、回退办法。缺一样就不放行。

第五件事，把 AI 和生产的距离拉开。开发数据库和生产数据库隔离。AI 不直接拿生产凭据。删除数据、修改权限、修改配置，都要人工二次确认。代码冻结写成系统策略。

第六件事，上线闸门加自动检查。上线闸门，就是上线前必须通过的自动检查。检查依赖包是否存在，来源是否可信。

许可证是否合规，也要查。许可证，就是外部代码的使用许可，要看能不能商用。

有没有密钥泄露，也就是密码或访问钥匙外泄，也要查。

AI 生成的代码单独标记，加一轮安全和边界测试。边界测试，就是专门试输入极端情况的测试。

第七件事，事故复盘先封存证据，再定位是提交、评审、测试、上线还是工具哪一环出了问题。复盘结论落到控制点的改动，不要只写加强培训。

第八件事，培训考核考行为，不考使用率。提交说明有没有按规则写，评审记录有没有具体意见，复盘材料有没有按时交，培训有没有参加。

十二、合同里现在能补哪几句话？

第一句，供应商要以书面形式说明本服务已知的限制。包括输出可能不准确，可能生成不存在的软件包名，可能产生安全漏洞。

第二句，因工具自身缺陷给使用方造成直接损失时，供应商按什么范围赔偿，按什么方式计算，索赔流程怎么走。

第三句，发生安全事件后，供应商按约定时限提供技术记录。技术记录包括操作日志、模型调用记录和错误说明。这里不能只写“配合”，要写交付物。

第四句，使用方和供应商各自保留日志和数据的期限。事故后如何封存，如何导出，也要写清。

第五句，赔偿上限写成具体金额或计算方式。是否以损害发生前 12 个月服务费为限，要写清。知识产权赔偿的适用条件和除外事项，也要写清。

这五句话不是让老板自己写法律文本。是让老板在合同会上提出五个必须落到纸面的问题。

知识产权赔偿要看清条件。GitHub 的赔偿只放在 Copilot Business 和 Copilot Enterprise 版本里，还要开启重复检测过滤器。不能把这项赔偿当成事故保险。

腾讯云条款把赔偿上限写成损害发生前 12 个月的服务费用。这个上限要在采购决策时算进最坏情况。

十三、怎么判断这套责任机制有没有落地？

不看墙上贴了什么，看记录里有没有东西。抽一份已完成的上线记录，先看四样材料是否齐全。

再看评审意见有没有具体内容。只写“已阅”的记录，说明评审没有真正发生。

看 AI 生成代码有没有单独标记。标记了，才能在上线前加一轮安全和边界测试。

在开发环境做一次演练。让代理尝试删除数据或修改权限。看权限规则是否拦住，看日志是否留下。

看事故后能不能导出日志和恢复数据。日志和恢复判断要来自独立系统，不能来自被审查的代理。

看培训考核有没有考行为。提交说明按规则写没有，评审记录有具体意见没有，复盘材料按时交没有。使用率不能说明责任机制在工作。

最后看合同。供应商书面限制、直接损失赔偿、技术记录交付、日志保留期限、赔偿上限，这五项有没有写进去。

把下面六问写进一张上线检查表：

• 提交说明有没有标注 AI 参与范围？
• 评审意见有没有具体内容？
• 上线前四样材料齐不齐？
• 系统里的冻结策略有没有真的拦住操作？
• 事故后的日志能不能从独立系统导出？
• 合同里的五项有没有落到纸面？

填不出来的那一项，就是下一步要补的控制点。