AI 事故报告制度：让每一次翻车都变成公共学习

航空业是人类历史上安全记录最好的复杂系统之一，它的秘密不是「飞机不出事」，而是每一次事故与险情都被系统性地记录、分析并转化为全行业的改进——强制的事故调查、匿名的自愿报告系统（如美国的 ASRS：飞行员可以匿名报告自己的失误而不受处罚）、以及数十年积累的事故知识库。AI 正在借鉴这套制度：AI 系统的事故（错误决策、歧视输出、安全事故、真实伤害）同样需要被记录、共享与学习——否则每个组织都在独立重复同样的翻车。AI 事故报告制度（incident reporting）因此成为 AI 治理基建的关键一块，本文讲清它的设计、义务与文化的三重结构。

制度设计：事故数据库与报告义务的全球拼图

数据库层：学术与公民社会先行——研究者与机构维护的 AI 事故数据库（收录数百到上千起 AI 相关事故：从自动驾驶事故、算法歧视到深度伪造伤害）为行业提供了「事故模式」的公共数据；这些数据库的功能与航空业的事故库同构：让「再次发生同类事故」的组织无法以「不知道」自我开脱。义务层：监管正在把报告变成法定义务——欧盟 AI Act 要求高风险 AI 系统的部署者与提供者报告严重事故（造成死亡、严重健康损害、基本权利重大干扰的事故与故障）——这是 AI 领域第一次出现跨行业的强制事故报告义务；其他辖区的义务零散但方向一致（部分司法辖区的算法问责立法包含影响报告，金融与医疗行业的既有监管把 AI 故障纳入既有的事故报告框架）。企业层：头部实验室的内部实践——发布前的红队报告、部署后的滥用监测、以及部分公开的威胁情报与事件复盘（本库收录的 Anthropic 威胁情报报告解读即是样本）。三层结构合起来，AI 事故的知识正在从「散落在新闻里」走向「制度化的沉淀」——但与航空业相比，差距依然是一个时代：AI 的事故定义、报告门槛、免责机制都还在第一版。

设计难点：AI 事故的三个特殊问题

AI 事故报告照搬航空模板会遇到三个 AI 特有的设计难题。难题一：什么算「事故」？航空事故有物理判据（坠机、伤亡），AI 的伤害常是弥散的、累积的、难以归因的——一个推荐系统的长期偏见伤害、一个模型的系统性谄媚误导（本库《欺骗性对齐与谄媚》）、一个招聘算法对某群体的累积筛选偏差——它们没有「事故现场」，只有统计意义上的伤害。现行框架的处理是双轨：严重事故（有明确的直接伤害）走强制报告；弥散伤害靠学术数据库与研究者（如「审计」与「影响研究」）补充——两轨的接口还不顺畅。难题二：报告会不会成为呈堂证供？航空业的匿名自愿报告（ASRS 模式）之所以有效，核心设计是免责：报告失误不用于处罚，只用于学习——飞行员才敢说出真话。AI 的报告义务如果没有对应的免责设计，企业的理性选择是「能不报就不报」（报告=自认责任=诉讼证据）——欧盟 AI Act 的严重事故报告义务与既有产品责任法的衔接，正是企业最关心的实操问题；没有审慎的免责设计，强制报告只会催生「合规式最小报告」。难题三：AI 事故的「险情」比例极高。航空的事故与险情（near miss）比例是金字塔形（大量险情支撑少数事故的预防）；AI 的「险情」（差点造成的错误决策、被红队拦下的攻击、用户举报的模型失误）数量极庞大且高度分散在各家企业的日志里——如何让险情的知识跨越企业边界流动（竞争者之间凭什么共享？），是比事故报告更难的组织问题。当前的过渡方案：行业级的威胁情报共享（针对攻击型险情，头部实验室已有实践）、与研究界共享脱敏案例（学术数据库的角色）。

报告文化：制度之上的组织习惯

制度是骨架，报告文化（reporting culture）是灵魂——这个概念来自航空与医疗安全研究，对 AI 组织同样适用。报告文化的三个成分：心理安全（一线员工发现模型问题敢不敢说——「说了会被追责」的文化里，险情永远在内部消化掉直到变成公共事故；本库《作业拉锯战》之外的管理学共识：报告者的保护是企业安全体系的第一原则）；无责复盘的技术化（事后复盘的焦点是「系统为什么允许它发生」而不是「谁搞砸了」——blameless postmortem 的工程文化在 AI 安全场景的移植）；闭环的可见性（报告的问题被修复后，向报告者与组织公开「你报告的问题改变了什么」——闭环可见性是报告持续流入的燃料，没有闭环的报告制度会枯竭）。对 AI 组织的实操建议按规模分层：大厂建「模型事故的分级响应与复盘制度」（严重事故走事故指挥官机制，险情走匿名自愿通道）；中小企业至少做三件——留存模型问题的日志与案例（未来监管与诉讼的史料）、把「别人的事故」读进团队的入职材料（事故数据库的定期研读）、建立内部的问题报告通道并公开闭环。报告文化的终极逻辑与航空业相同：安全不是「不出事」的状态，是「出事后系统变得更难再出同样的事」的能力——而报告，是这个能力的唯一入口。

事故数据库的样本：AI 事故长什么样

AI 事故数据库（收录数百起案例）里的事故形态，值得抽样呈现——它们让「AI 事故」从抽象概念变成具体的形态库。形态抽样：自动化决策的伤害类（算法招聘的性别偏见、信贷评分的群体歧视、福利系统的错误停发——决策系统的系统性偏差造成大规模权利损害）；生成内容类（深伪的名誉侵害、AI 客服的荒唐回复造成的损失、生成内容的版权与诽谤争议）；物理系统类（自动驾驶的事故、机器人的误操作——与物理世界交互的 AI 事故，直接伤亡的可能）；安全类（提示注入的真实欺诈、模型越狱后的有害输出、模型泄露的隐私数据）；系统交互类（本库「1200 个智能体」式的涌现事件、AI 系统之间的意外耦合）。抽样后可读出的模式：事故的频率分布极不均匀——「已造成真实伤害的记录」集中在自动化决策与物理系统，「安全与涌现类」的记录以险情为主（大事故未发生但险情频密）——这个分布本身就是风险的地图：伤害已发生的领域（决策类）需要的是问责与救济制度，险情频发的领域（前沿能力类）需要的是预防与报告制度——两类的制度需求不同，用同一套「事故报告」框架套所有形态，正是制度设计的第一个陷阱。

从「事故」到「险情」：AI 安全的前移

事故报告制度真正的成熟标志，是险情（near miss）报告的兴起——本篇正文用航空业的 ASRS 做了类比，这里把这个类比展开到底。险情的定义：没有造成实际伤害、但「差一点」的事件——航空业统计里，险情与事故的比例是金字塔形（成千上万的险情托着少数事故），险情的价值在于它是「免费的教训」：不需要付出事故的代价就暴露了系统的漏洞。AI 领域的险情形态：红队拦下的攻击（本库《AI 红队测试入门》的产出——每一次成功拦截都是一个免费教训）、评测发现的危险能力（发布前评测测出的生化增量——本库《生化风险》的评估产出）、内部的模型异常（监控发现的输出漂移、用户举报的模型失误）。险情报告的制度设计要点：匿名与免责（险情的报告者往往「有份」——设计失误的工程师报告自己的失误，无免责则无报告）、分级与聚合（险情的个体价值低、聚合价值高——模式识别需要量）、与外部的选择性共享（内部险情的脱敏分享——行业级的险情库是稀缺品）。AI 行业与航空业的差距现在可以量化：航空业的险情报告制度运转了半个世纪，AI 行业的险情报告刚刚开始出现雏形（实验室的内部机制）——这个差距本身就是 AI 行业安全成熟度的度量：什么时候「内部险情的匿名报告」成为行业标配，AI 的安全文化才算真正及格。

小结

AI 事故报告制度收成四条：全球拼图的三层结构——学术事故数据库打底、欧盟 AI Act 的严重事故强制报告开义务先河、头部企业的内部实践先行；AI 特有的三个设计难题——弥散伤害的「事故」定义、报告与法律责任的免责衔接、险情共享的竞争壁垒；报告文化是制度的灵魂——心理安全、无责复盘、闭环可见，缺一则报告枯竭；安全不是「不出事」的状态，是「出事后系统更难再出同样的事」的能力。航空业用百年把事故变成了教材，AI 的这本教材刚刚开始写——每一个被认真记录的事故与险情，都是给它添的一页。

参考资料

欧盟 AI Act 严重事故报告义务条款（Art. 73 相关）
AI Incident Database 与 AIAAIC 数据库 —— 公共 AI 事故知识库
本库前篇：《AI 红队测试入门》《欺骗性对齐与谄媚》《深度研究｜Anthropic 威胁情报报告全解》