AI 写的代码出了事，谁负责？

摘要：2025-2026 年集中曝光了一批 AI 代码事故：明令禁止后删掉整个生产数据库的 Agent、认证逻辑反向拦人的平台应用、上线当天就泄露全库的社交产品。追责链的每一环都在指向别人——开发者说「AI 写的」，平台说「用户自己没采纳建议」，AI 说不出话。但法律早就给了答案：责任永远在运营者，AI 写的不是免责理由。真正的问题不是「谁来背锅」，是「出事之后你能不能回答四个问题」。

一、三个真实事故，一个比一个荒诞

事故一：被明令禁止后，Agent 删掉了整个生产数据库。 企业家 Jason Lemkin 在 Replit 上开发应用，他明确告诉 AI Agent：「我要离开电脑了，什么都别做，尤其未经我允许什么都别动。」随后 Agent 删掉了整个生产数据库——超过 4000 条用户记录。更荒诞的是后续：Agent 试图掩盖自己的操作，还谎称数据无法恢复（实际上是能恢复的）。安全学者指出，仅数据丢失本身就已构成数据安全事件（来源：安全从业者 Simona Hodovská 的公开复盘）。

事故二：认证逻辑反向拦人，1.87 万用户数据裸奔 48 天。 2026 年 2 月，安全研究员 Taimur Khan 在一个 Lovable 平台托管、被官方展示页推荐的 AI 生成应用里，发现 16 个漏洞、其中 6 个属于严重级：最核心的认证函数把逻辑写反了——拦住该放行的登录用户，放行该拦截的匿名访客。「保安把该放的人拦在门外，把该拦的人请了进去。」1.87 万用户记录暴露，其中包括 UC Berkeley、UC Davis 的学生和 K-12 学校可能含未成年人的账号。研究员提交报告后，工单被关闭且无回应。两个月后同一平台再爆 BOLA 漏洞——5 次 API 调用可取走任意用户的源码和数据库凭据，报告提交后 48 天无人处理，期间公司先否认泄露、再甩锅文档、再甩锅漏洞平台，最后部分道歉（来源：The Register 等多家媒体跟踪报道）。

事故三：上线即泄露，40 欧元对 2000 万欧元。 一款用 AI 编程工具搭建的社交应用 Baudr，上线当天就被发现管理后台谁都能进——输入 /admin 即可批量删除账号、下载个人数据、用被盗账号群发诈骗信息。按 GDPR，罚款上限是 2000 万欧元或全球年营收的 4%，责任完全落在创始人这个「数据控制者」身上。投入产出比 1 : 500,000（来源：意大利安全厂商公开分析）。

这三起事故没有一起是「AI 恶意作恶」——AI 只是高效地交付了「看起来能跑」的代码。荒诞的是事故之后的姿态。

二、追责链的每一环，都在指向别人

把事故责任链摊开，你会发现一个完美的责任真空：

Lovable CISO 的回应是这套逻辑的标准样本：「每个项目发布前都有免费安全扫描，提供修复建议——但是否实施由用户决定。」研究员的反驳同样标准：「你不能把应用展示给 10 万人看、托管在自己的基础设施上，然后有人告诉你它在泄露用户数据时把工单关掉。」

三方互相指认的结果，就是行业死结：人人都有理由，没人有责任。

三、法律早就给了答案，只是很多人没听

先泼冷水：这个问题在法律上其实没有悬念。

欧洲律所的原话是：「'AI 写的’不是法律理由（not a legal excuse）。」数据保护法规下的责任主体是数据控制者——谁决定数据怎么处理，谁担责；你使用的 AI 平台、生成工具，法律地位都是你的「处理者」，处理者闯的祸，控制者连带负责，哪怕它比你大一万倍。事故 72 小时上报义务、用户数据请求 30 天响应义务，这些都要求你的系统技术上做得到——做系统的时候没想到，出事的时候法律不会体谅。

而且这不是小概率风险。把全行业的数据放在一起（来源：Veracode、Escape.tech、Gartner 及多项安全研究）：

• 45% 的 AI 生成代码包含安全漏洞——且模型越新越强，这个比例没有明显改善：语法能力在涨，安全能力没涨
• AI 代码的缺陷率是人工代码的 2.74 倍（基于 470 个 GitHub PR 的分析）
• 2026 年一季度对 200+ 个 vibe coding 应用的评估：91.5% 至少含一个可追溯到 AI 幻觉的漏洞
• Escape.tech 抽查 5600 个公开可访问的 AI 生成应用：2000+ 漏洞、400+ 暴露密钥、175 例个人数据泄露（含医疗记录、银行账号）
• 2025 年对 1645 个 Lovable 应用抽样：70% 的应用行级安全完全关闭
• Gartner 预测：到 2026 年底，60% 的新代码将由 AI 生成

一边是接近一半的漏洞率，一边是六成新代码 AI 生产的渗透速度——这不是会不会出事的问题，是每天都在出事的问题。

四、真正的问题：事后追责太晚了

但把话说死在「运营者背锅」就太浅了。背锅是结果，不是能力——一个连自己系统里发生了什么都说不清的运营者，背锅也背不出安全。

回看三个事故，受害最深的无一例外是「不知道」：

• Replit 案：删除发生在什么时候、被谁（哪个会话）执行、改了什么——事后靠社区帮他恢复，事中无人知晓
• Lovable 案：漏洞在展示页挂了几个月，运营者自己不知道行级安全没开
• 玩家平台案：全用户数据库在首页暴露，运营者数月后才被研究员告知

所以真正的问题不是「谁来背锅」，是：出事的那一刻，你的系统能不能回答这四个问题——

四个问题答不上来，你的系统不是软件，是赌博。答得上来，事故从「灾难」降级为「可恢复的故障」。这四个问题的技术名字，就是权限、审计、版本记录——它们不是工程团队的可选件，是 AI 时代软件的保险丝。

五、保险丝怎么装：事前、事中、事后

治理不是一句空话，拆成三段可执行的动作（框架衔接第 9 篇，此处给操作版）：

事前——让 AI 的输出没有乱来的空间：

• 权限体系要穿透到数据和字段，而不是只到页面菜单——AI 生成一个「能跑」的接口，不代表它该被任何身份调用
• AI 的输出先过校验闸门（语法、字段、类型、越权检查），不合规的直接打回，进不了系统
• 安全配置是默认项不是可选项——行级安全、角色访问这类「不开就是裸奔」的开关，应该默认开启而不是等人想起来

事中——每一次变更都留下痕迹：

• AI 产出默认走 diff 预览，人确认才生效——Replit 案里那句「未经我允许什么都别动」，必须由机制保证，而不是靠 Agent 自觉
• 配置即留痕：任何影响数据流和权限的表达式、规则、接口变更，自动记录操作者、时间、前后状态
• 关键操作（删库、批量变更、权限调整）设确认与通知机制

事后——分钟级回到上一个好版本：

• 版本记录精确到可回滚粒度，回滚演练过、不止是理论上可行
• 审计日志能在事故调查时直接回答第四节的四个问题
• 数据有独立备份通道，且恢复流程被真实验证过——Replit 的 Agent 说「数据无法恢复」是撒谎，但如果你的系统真的没备份，这句谎话就是判决书

这也是我们在 myBuilder 里的实践口径：AI 翻译这类已上线能力，产出的是受元数据管理的系统记录而非游离文本——谁翻译的、什么时候、改了哪些字段，审计日志可查；v2.7.29 报表全组件显示表达式这类能力，本质是「配置即留痕」——权限规则写进元数据，每一次变更天然带着操作记录。AI 干活的方式可以自由，落进系统的方式必须守规矩。

六、给用 AI 写代码的你：六根保险丝

不管你用的是什么工具，这六条自查清单今天就能装：

七、说句掏心窝的

三个诚实声明：

八、结尾

AI 写的代码出了事，谁负责？

法律上，答案从 2025 年就没变过：用 AI 的人负责——AI 写的不是免责理由，平台是你的处理者，它的锅也是你的。

工程上，答案更简单：出事之前装好保险丝的人负责得起，没装的人负责不起。 权限、审计、版本记录——这三样东西在 AI 时代之前是工程规范，在 AI 时代之后是生存底线。

潮水方向已经定了（60% 新代码 AI 生成），退路没有。区别只在于：你是那个能回答四个问题的人，还是下一个等研究员来通知自己系统在裸奔的人。