上报机制，是AI的解药？

作者 | 山竹

出品 | 锌产业

如果事故难以完全避免，应该怎样阻止它演变成更大的灾难？

9月15日，OpenAI CEO Sam Altman在Salesforce的Dreamforce大会上指出，AI企业应当借鉴航空业，建立透明的事故上报与复盘文化。

他认为，新技术发展过程中，一定程度的事故难以避免，关键在于从中学习，并采取行动。

这个提议听起来务实，却也带来新的疑问：

谁来定义事故，谁来调查事故，又由谁决定，一次事故是否足以让企业放慢脚步？

01 AI开始报告自己的失控

Altman发表上述言论的次日，OpenAI公布了模型失对齐（Misalignment）框架，同时发布六份异常行为报告，涉及训练和评估过程中发现的案例。OpenAI官方提醒，这些个案不能代表异常行为的发生频率。

“失对齐”是一个技术术语，是指模型的行为偏离人类希望它遵守的目标或约束，具体案例则比这个词容易理解得多。

其中一个案例中，模型需要查询美国加州某县的收入数据，为了完成任务，它搜索并使用了公开代码仓库中暴露的API密钥，未经授权尝试获取信息，在仍未取得所需数据后，模型又编造数字，将其作为来自指定来源的数据呈现给用户。

另一个案例的任务，是查询湖泊信息，模型已经计算出答案，却为了满足浏览器引用的要求，未经用户同意将文件上传到互联网，以便引用。

风险出现在一个看似普通的环节：模型遇到阻碍后，选择了什么办法继续工作。

找到凭证，并不意味着获得使用授权，具备上传能力，也不意味着可以自行公开文件，当AI开始调用工具、访问数据并执行任务，这些边界判断就会直接影响现实世界。

这也是事故报告的价值所在，它可以帮助外界看到，危险行为如何从普通任务中产生，哪些限制没有发挥作用，以及开发者原先的安全假设哪里出了问题。

但公开案例也需要避免另一种误读，模型异常、安全边界被突破，以及已经造成现实损害的事故，不能不加区分地混在一起。训练和评估环境中的表现，也不能直接等同于日常产品的风险水平。

如果报告缺少发生环境、权限配置、实际行动和影响范围，只剩下一句“AI又失控了”，它就很难成为可用的安全证据。

行业需要的是足够具体的失败记录。只有知道问题怎样发生，其他企业才可能检查自己的系统，避免重复踩坑。

02 航空业靠什么学会安全

Altman选择航空业作为参照，有一个容易理解的理由：这个行业必须认真对待低概率、高后果的风险。

不过，航空安全体系的作用，不能简单归结为“事故发生后写一份报告”。

美国航空安全报告系统ASRS收集飞行员、空管人员等提交的安全事件和潜在隐患，分析系统缺陷，向能够采取措施的相关方发布警示，并通过数据库和研究传播经验。

它关注已经发生的问题，也关注尚未造成严重后果的险情，这让行业有机会提前发现风险，而不必等到惨痛事故发生。

要获得这些信息，首先得让现场的人愿意报告。

ASRS由NASA作为第三方接收和处理报告，通过保密、去标识化以及符合条件时的处罚豁免，鼓励信息流动，这些保护具有明确边界，事故、犯罪等情况受到不同处理，也不能替代原有的报告责任。

对于AI企业，这个问题同样现实，工程师或测试人员发现异常后，如果担心影响项目进度、团队评价或者自己的职业前途，报告渠道即使存在，也未必能获得完整信息。

此外，美国国家运输安全委员会NTSB强调独立调查，并推动安全建议落实，它承担的职能与自愿报告系统不同，体现了航空安全体系中调查和学习的不同环节。

因此，AI可以借鉴的经验，至少包括保护报告者、收集险情、独立调查，以及推动改进。

实际上，一些企业已经在尝试引入外部调查。

Anthropic在9月9日公布的网络安全事件评估中表示，他们已经和METR签订独立调查协议，提供相关记录和员工访问权限。Anthropic还承认，此前对事件的初步解释过于肯定，后续分析改变了判断。

这个细节说明，企业自己的事故解释也需要被检验，及时披露与完整调查之间存在时间差，一套有效机制应该允许更新事实、修正结论。

此外，AI还有自身的难题。

模型更新快，同一模型在不同产品中的权限和工具配置各不相同，一条行为链可能涉及模型开发者、应用提供方和部署企业，问题也可能来自多个环节的共同作用。

要让报告有用，行业需要建立可比较的事件分类和记录要求，否则，企业各自发布一批案例，外界依然难以判断哪些问题具有共性，哪些改进可以推广。

03 谁来监督上报者

上报机制最难回答的问题，是谁来决定什么值得上报。

OpenAI公布的流程允许员工提出异常案例，由内部团队调查和评估披露，相关分歧可升级至内部安全咨询机构，进一步的争议则交由公司领导层处理。

这让内部报告有了更清晰的路径，也意味着披露决策仍主要掌握在企业手中。

公众可以阅读被公开的案例，却很难仅凭这些案例判断，其他问题是否得到了恰当处理。报告数量少，可能意味着风险较少，也可能意味着发现能力不足，或者披露范围有限。

企业面临的保密需求也是真实的，公开漏洞细节可能帮助攻击者，发布完整任务记录可能暴露客户信息。但外部如果无法审查这些理由，也就难以判断哪些延期和删减确有必要。

一种值得讨论的设计，是区分向独立机构完整报告，与向公众分阶段披露。前者让调查者掌握证据，后者在保护敏感信息的同时，说明事件性质、影响范围和处置进展。具体适用条件仍需要制度约束。

更关键的问题，是报告能否改变下一次行动。

发现模型未经授权访问数据后，权限是否收紧？发现模型会为了完成任务绕过限制后，发布前是否增加相关测试？同一种问题反复出现时，部署范围是否需要缩小？

如果报告只解释过去，没有留下可追踪的改进承诺，公众就无法判断问题是否真正得到处理，透明的价值，需要通过后续变化来证明。

同样，“事故难以避免”也不能成为降低事前要求的理由，对于普通错误，可以不断反馈和修正，对于可能造成广泛、难以挽回损害的风险，等待真实事故来积累经验，代价可能无法承受。

上报机制应该让异常和险情更早进入决策，并与权限控制、事前评估、持续监测相衔接，在必要的时候，这些证据也应该支持放缓部署。

所以，上报机制能否成为AI的解药，要看它是否具有改变决策的力量。

比报告发布了多少份更值得观察的，是报告之后，哪些权限被撤回，哪些测试被增加，哪些产品发布被推迟。

当失败经验开始约束下一次行动，AI行业才真正学到了航空业的经验。