89TB 数据被删案复盘北京首例破坏 AI 模型案暴露三个权限漏洞TL;DR 速览案子算法工程师用旧账号登退役集群删除指令跑了 17 小时89TB数据被清除判决破坏计算机信息系统罪一审判五年十个月二审维持央视口径为北京首例破坏 AI 模型刑案三个漏洞旧集群旧账号没回收、删除没有二次审批、17 小时零告警最值钱的一课监控只盯资源不盯数据资产变化这是大多数公司的通病8 月中旬央视网披露的一起案子这两周在技术圈被反复转发。多数转发的重点停在判了五年十个月“赔了 20 多万”我关心的不是刑期是这条指令为什么能在生产集群上跑满 17 个小时。先说清楚事实链再说技术侧真正的问题。一、案件事实从接私活缺存储到89TB 归零按央视网、法治日报等公开报道案情大致是这样王某90 后算法工程师就职于北京某科技公司的AI 短剧部门。他在私下与外部人员合作承接私活需要算力训练外部 AI 模型而公司服务器的存储不够用了。于是他做了这样一件事用一个旧账号登录了一套已被通知迁移数据的旧服务器集群输入了在程序员圈子里被称作删库跑路的那类无差别强制删除指令操作完成后直接下班离开。指令没有被拦住在后台持续运行了 17 个小时直到运维人员发现异常紧急叫停。此时89TB 核心数据已被清除——包括公司自研的文生 3D 模型、大量训练数据集、渲染算法资产。用报道里的说法公司的游戏 AI 研发系统整体瘫痪恢复近 20 天才开始进入数据恢复与模型重建阶段人力加算力损失合计20.4 万余元。判决时间线是这样的2025 年 6 月北京市东城区人民检察院以破坏计算机信息系统罪《刑法》第 286 条提起公诉2026 年 3 月一审判决有期徒刑五年十个月并赔偿 20.4 万余元王某上诉6 月 26 日二审驳回上诉、维持原判。央视网对这起案子的口径是北京首例破坏人工智能模型刑事案件。二、先把入罪线说清楚这是很多人会误判的地方技术圈讨论这类案子时最常出现的一句话是删数据不就是劳动纠纷吗。不是。刑法第 286 条之下量刑档位看的是后果而后果严重的认定标准比多数人想象的低得多认定项门槛系统受影响范围造成10 台以上计算机信息系统不能正常运行累计时间1 小时以上违法所得5000 元以上经济损失1 万元以上其他情形造成其他严重后果这套门槛的关键在于它数的是系统和损失不是数据值多少钱。一台生产集群里几十个节点删除指令跑 17 小时10 台以上系统停摆 1 小时——这条线几乎是必然会踩到的。20.4 万元的经济损失认定相对 1 万元的门槛也高出很多倍。所以这案子的定性不是损失大所以判得重而是这类行为在入罪门槛上几乎没有任何争议空间。把两个对照案例并排放能更清楚地看到量刑的刻度链家一名 DBA 恶意删除公司财务数据同样是破坏计算机信息系统罪判了七年南通一名员工离职后删除公司核心数据及备份判了一年三个月。差异来自删除范围、是否连带破坏备份、是否造成业务中断等具体情节。这里我只陈述判决结果不对量刑轻重做评价——司法结论不该由技术文章二次解读。三、庭审里被驳回的那个辩解值得单独看一眼王某在庭审中的辩解是操作失误。这个辩解没有被采纳原因在证据链上聊天记录显示他在事前就在与同伙沟通外部模型的调试安排操作完成后他表现出的不是惊慌而是惋惜——“再也得不到这么强的算力”更进一步他还在对话里说过下回我还敢。这几句话把故意这件事坐实了。对做技术管理的人来说这里有个容易被忽略的点过失和故意的区别往往不在操作本身而在操作前后的沟通记录里。日志、IM 记录、工单、提交历史这些东西在事后都是证据。四、真正的三个漏洞这篇最该看的部分把动作层面剥掉这起事故能发生靠的是三个环节同时失守。任何一个环节起了作用89TB 都不会归零。漏洞一旧集群 旧账号两条后路都留着这是整条链的第一张多米诺骨牌。报道里的表述是已通知迁移数据的旧服务器集群——也就是说这套集群在公司内部已经被判定为退役状态。但它仍然满足三个条件能连通、旧账号能登录、高危命令能执行。我在实际环境里见过太多这种状态迁移公告发了新集群上线了业务切过去了但老集群没人下架——因为担心万一还有东西要查。于是它就以一种挂着但不该用的形态长期存活账号也没回收因为删了怕影响排查。退役流程里最容易被跳过的一步恰恰是最重要的那一步把机器关掉、把账号删掉。不是通知不再使用是物理与权限层面的终结。这件事的技术动作很简单难的是把它写进流程并有人负责执行——迁移项目结项时应该有一个明确的清单项叫旧环境下电与账号回收确认。漏洞二一条无差别删除指令不需要任何人点头删除类操作在生产环境里应该是默认被拦下的动作。这起案子里它没有被拦下说明权限模型是人有我有而不是最小必要。这里要说清楚一个常见误解很多人以为有权限就能删是正常的。在高危操作上权限充足不等于操作合法中间必须有一道审批。业界的成熟做法是分层的入口分层生产集群的删除类操作不通过统一跳板机就无法到达目标机器动作分层rm这类无差别操作默认禁用需要走带审批工单的受控通道或者改用带保护机制的删除方式回收站、延迟删除、软删除批处理保护对删除速率设阈值——比如单次操作删除文件数超过 N 个就自动挂起并通知双人确认高危变更要求双人复核这在金融行业是常规在很多互联网公司还是空白。说句实在的如果一条删除指令能在生产集群上启动并连续跑 17 小时那这家公司的权限治理实际上是不存在的。漏洞三17 小时零告警——监控盯错了对象这是我认为最值得所有技术团队对照自查的一条。17 小时是什么概念如果监控里有一条删除速率异常或数据资产总量骤降的告警正常情况下几分钟内就该有人被叫起来。它没有发生说明监控的指标体系里根本不包含这一类信号。绝大多数团队的监控长这样CPU、内存、磁盘使用率、网络流量、服务可用性、错误率。这些是资源与可用性指标。而删除数据这件事的表现是什么是资源指标变好——磁盘占用在下降IO 在飙升但没到阈值CPU 正常服务照常响应。在传统监控视角里这场事故的表现几乎是健康的。所以需要补的是一类数据资产指标核心目录/存储桶的文件数量与总容量基线偏离基线超过阈值即告警删除操作的审计流谁、在哪台机器、删了什么路径、删了多少实时汇聚到 SIEM 或日志平台批量操作速率单位时间删除文件数/字节数作为独立指标而不是淹没在 IO 指标里备份任务的健康度今天的全量备份成功了吗、可恢复性验证做过吗——这一条直接决定事故是麻烦还是灾难。顺带说一句备份。89TB 数据全丢、抢修近 20 天说明恢复链路是吃力的。3-2-1 原则三份副本、两种介质、一份异地/离线喊了很多年但真正做离线副本的组织并不多——尤其是离线这一条因为它额外要钱、要流程、还平时没用。可勒索软件和内部破坏这两类威胁专门打的就是在线且有权限就能删这条路。五、给两边的可执行清单技术管理者这周可以检查这五件事盘点退役资产所有已宣布迁移/下线的集群、数据库、存储桶是否真的已下电、已回收账号列一张表逐条确认。高危操作审批删除类、批量变更类操作是否有工单审批与双人复核有没有可以绕过的通道数据资产监控有没有对核心数据目录做容量与文件数基线删除速率是否有告警备份可恢复性最近一次恢复演练是什么时候有没有离线副本放在哪里离职与项目下线 SOP账号、密钥、集群访问权限是如何回收的谁签字确认对技术人员个人边界要清楚公司数据不是我经手所以我处置。删除、篡改、加密公司核心数据走的是刑事路径不是劳动纠纷路径——离职有争议可以仲裁、可以诉讼但无论什么理由都不能用删除数据来处理。这条线碰一次代价就是几年。我的判断这案子最值得记住的不是89TB这个数字而是它同时暴露的三个漏洞恰好对应三种非常普遍的工程惰性迁移项目只做了一半新的上了旧的没下、权限治理停在纸面有权限就能删没有审批、监控指标体系有结构性盲区盯资源不盯数据。这三件事单独看都不严重凑在一起就是灾难。从攻防视角看一个内部人有恶意、手里有旧账号、目标是删除——这三张牌凑齐的难度其实很低。实际经验是绝大多数公司防得住外部攻击防不住内部人删数据。原因也简单外部攻击需要绕过边界而内部人的操作是合法的登录、合法的命令、合法的路径——边界根本不管用。能管用的只有两样一是让高危动作拿不到执行许可审批 最小权限二是让发生的事立刻被看见审计 数据资产监控。技术上的做法都不贵贵的是下决心把这些流程真的跑起来。最后一句给做 AI 的同行今天的 AI 团队普遍重算力、重模型、重数据规模但数据治理的建设速度远落后于模型迭代速度。89TB 里那些自研文生 3D 模型和训练数据集是一群人按月堆出来的资产重建一次的成本远不止 20 万。资产越大、越集中越要把谁能删、怎么删、删了怎么发现、删了怎么回来这四问答完。