Post-Deployment Accountability in AI Governance: A Cross-Regulatory Empirical Analysis of AI Incidents

想象一下人工智能（AI）的世界是一座巨大且繁忙的城市，机器人被雇佣来做各种各样的事情，从诊断疾病到审批贷款。长期以来，人们最大的担忧仅仅在于这些机器人的构建方式——确保它们足够聪明、公平，并且大脑中没有错误的程序代码。但最近，科学家和律师们意识到，制造一个机器人仅仅是故事的一半。真正的挑战在于机器人开始工作之后会发生什么。这个领域被称为“部署后治理”（post-deployment governance）。这就像是造出一辆完美的汽车与实际在路上驾驶汽车之间的区别。你可以在工厂里造出一辆完美的车，但如果你没有每天检查刹车的技师、一个真正起作用的速度表，以及一个应对引擎起火的明确计划，那么这辆车对每个人来说都是一种危险。

这篇论文深入探讨了那个“工厂之后”的阶段。它研究了政府和组织为了确保 AI 安全而制定的三套主要规则：欧盟《人工智能法案》（EU AI Act，一套来自欧洲的严格法律）、美国 NIST AI 风险管理框架（NIST AI Risk Management Framework，一份自愿性指南）以及 GDPR（保护个人数据的规则手册）。核心问题不仅是“这些规则是否存在？”，而是“当事情出错时，它们是否真的有效？”作者们想要观察的是，当一个 AI 系统出错时，负责人是在进行观察、报告问题并修复它，还是仅仅在希望没人注意到。

---

重大的 AI 真相核查

想象你是一名侦探，正在调查一座城市，在 2020 年至 2026 年间，有 480 个不同的机器人引发了事故。有些机器人给出了错误的医疗建议，有些不公平地拒绝了贷款申请，还有些导致了交通拥堵。你的任务是检查警察报告，看看机器人所有者是否遵循了他们应该遵守的规则手册。

这篇论文的作者正是这样做的。他们研究了 480 起真实的 AI 灾难，并根据上述三大主要规则手册中的九项具体规则进行了对照检查。他们在寻找“证据”——比如显示有人在监视机器人的日志、记录机器人故障的报告，或者关闭机器人的计划。

大惊喜：“幽灵”规则
结果有点可怕。事实证明，对于大多数这类事故，安全规则基本上都是“幽灵”。它们在纸面上存在，但在现实世界中却找不到任何痕迹。

• 欧盟《人工智能法案》： 这本规则手册规定，高风险机器人需要一个“上市后监测器”——基本上就是一台 24 小时监控机器人的安全摄像头。研究发现，在 77.1% 的事故中，完全没有任何证据表明有人在进行监视。这就像是在开车，却没有刹车，也没有人检查仪表盘。
• GDPR（数据保护）： 这条规则规定，如果你以风险方式使用个人数据，必须进行“数据保护影响评估”（启动前的安全检查）。研究发现，99.6% 的事件完全没有进行过此类安全检查的记录。
• NIST 框架： 该指南建议你应该有一个在出错时进行修复的计划。虽然一些公司最终确实关闭了损坏的机器人（约占 57.5% 的情况），但他们通常是在损失造成且新闻已经上了电视之后才这么做的。他们并不是在主动修复，而是在收拾残局。

“系统性”故障
作者还检查了这些失败是随机错误，还是整个系统都出了问题。他们发现，9.8% 的事故是同时违反了两项或多项规则手册的失败。这表明问题不仅仅是某一本规则手册不好，而是我们管理 AI 安全的整个方式缺少了一些关键的齿轮。这就像一辆车同时没有刹车、没有方向盘，也没有安全带。

秘密武器：“内部侦探”
这是故事中最有趣的部分。研究人员注意到，由公司自身团队发现的事故与由外界（如记者、愤怒的用户或研究人员）发现的事故之间存在巨大的差异。

• 内部检测： 当公司自己发现问题时，他们更有可能遵守规则。对于欧盟《人工智能法案》，87.5% 的这类由内部发现的事故显示出合规性。
• 外部检测： 当外界发现问题时，合规率降到了微不足道的 5.3%。

这表明，那些在办公室里拥有自己的“侦探”、每天都在监视机器人的公司，才是那些能及早发现问题并遵守规则的公司。那些在新闻报道之前都不知道出问题的公司，则是那些未能通过安全检查的公司。作者认为，拥有内部监控系统是判断一家公司是否表现良好的一个重要线索，尽管他们承认这并不能证明该行为是“原因”（也许优秀的决策本身就具备两者）。

提议的解决方案：PAGCF
由于目前的系统主要是响应式的（在损坏后才进行修复），作者提出了一个新的计划，称为主动式 AI 治理合规框架（PAGCF）。想象一下，这是为机器人驾驶员准备的新训练手册。这个计划不再只是对碰撞做出反应，而是包含四个步骤：

1. 部署前评估： 在机器人开始运行之前，检查其安全装备并制定计划。
2. 持续监控： 对机器人进行 24 小时实时监控，以便在问题演变成事故之前将其捕捉。
3. 事件准备： 准备好“消防演习”。明确知道如果机器人出现故障，应该联系谁以及该说什么。
4. 跨框架验证： 确保你同时遵守所有的规则手册，而不仅仅是其中之一。

这对我们意味着什么
论文总结道，我们不能仅仅编写更多的规则并寄希望于它们奏效。规则已经存在，但没人使用它们。最大的教训是，我们不能再等待新闻告诉我们某个 AI 坏掉了。我们需要建立能够“在 AI 工作时”对其进行监视的系统。作者建议，如果公司能率先开展这种“内部监控”，他们就能从几乎没有安全合规性跃升到拥有超过 85% 的合规性。

这并非万灵药，作者也谨慎地表示，这仅是基于他们在数据中“观察到”的情况，而非保证的解决方案。但信息很明确：如果我们希望 AI 是安全的，我们需要停止做一个只会清理残局的人，而要成为预防混乱发生的人。