✨ 要点🔬 技术摘要
想象一个这样的世界：在医院里做出生死抉择的软件、决定谁能获得贷款的算法，以及筛选求职申请的系统，都在被时刻监视着。多年来，关于人工智能的讨论一直集中在这些系统是如何构建的，以及它们在启动前是否公平。但现在出现了一个同样关键的新问题：在部署之后会发生什么？一旦这些系统在现实世界中运行，谁来负责监督它们、发现它们何时出错，并在它们伤害到人类之前进行修复？这就是“部署后问责制”的领域。它关乎的不是代码本身，而是那些让代码保持受控的人类和组织流程。如果一个系统开始犯下危险的错误，公司能立即察觉吗？他们是否有停止错误的计划？他们会告知受影响的人吗？如果没有这些安全网，即使是设计得最精密的科技，也可能成为一种无法管理的伤害来源。
一组研究人员着手调查这些安全网在实践中是否真的存在。他们没有研究理论性的规则或公司的承诺；相反，他们审视了人工智能系统在现实世界中的失败案例。他们在 2 {此处原文为 2020 年至 2026 年，应为原文数据} 期间收集了 480 起人工智能系统造成伤害的具体事件数据。这些事件涵盖了从医疗错误到偏见招聘决策的各个方面，数据来源于一个追踪此类事件的公共数据库。随后，研究人员根据三套旨在监管人工智能的主要规则对每起事件进行了衡量：欧盟的《人工智能法案》、美国国家标准与技术研究院的一项自愿性框架，以及侧重于隐私保护的《通用数据保护条例》。他们旨在寻找公司履行这些规则要求的具体证据，例如持续监测其系统、报告严重事故或在问题发生前评估风险。
结果揭示了一个残酷的现实：安全网在很大程度上是缺失的。当研究人员寻找公司在发布系统后对其进行监控的证据时，几乎一无所获。在近 80% 的案例中，没有任何证据表明正在进行所需的持续监测。对于涉及隐私和风险评估的规则，差距甚至更大；在超过 99% 的相关案例中，没有任何公开记录显示曾进行过正式的风险评估。这幅图景并非表现为公司违反了特定法律，而是表现为完全缺乏能够证明其遵循任何规则的文档和流程。研究人员发现，当这些系统失效时，公开记录很少显示有人在观察、有人在制定应对计划，或者有人在承担责任。
或许最令人警醒的发现是关于这些失败是如何被发现的。在绝大多数情况下，问题并不是由运行这些系统的公司发现的。相反，它们是在损害已经造成之后，由记者、研究人员或公众揭露出来的。研究发现，当一家公司拥有内部系统来监测错误并在问题公开化之前将其拦截时，结果会截然不同。在极少数由公司自行发现问题的案例中，这些公司更有可能遵守规则、快速响应并修复问题。这表明，在问题爆发前洞察问题的能力，是决定一家公司能否有效治理其技术的最重要因素。仅仅在纸面上拥有一项政策是不够的；组织必须具备实际观察事物出错的能力。
研究人员认为，目前的人工智能治理方式过于被动。它在等待灾难发生，然后试图管理其后果。他们提出了一种新的思维方式，将重点转向系统运行前及运行期间。这种方法包括四个步骤：在系统启动前进行彻底检查、对其性能进行持续观察、为可能发生的故障准备好清晰的计划，以及确保在不同标准下所有规则都得到执行。研究表明，如果公司能够实施该计划中的哪怕一部分——特别是内部监测自身系统的能力——它们在处理人工智能风险方面可能会看到巨大的改善。证据显示，管理这些系统的工具和规则是存在的，但使之发挥作用所需的日常习惯和监测流程却是缺失的。在组织建立起观察自身创造物的能力之前，修复人工智能失败的责任将继续落在公众身上，而不是建造它们的人身上。
技术摘要：AI 治理中的部署后问责机制
问题陈述
尽管 AI 治理框架不断涌现，但目前仍缺乏关于部署后问责机制（特别是监控、事件报告和影响评估）在 AI 系统失效时是否真正被激活的实证证据。虽然诸如《欧盟 AI 法案》、NIST AI 风险管理框架 (RMF) 和 GDPR 等监管工具定义了检测和补救损害的“蓝图”，但目前尚不清楚该蓝图在实践中是否发挥作用。目前的学术研究多为规范性研究，侧重于原则或风险分类，而非实证评估特定的监管义务是否在现实世界的 AI 事件中被触发。本研究通过将 AI 事件视为对部署后问责制的“压力测试”，旨在解决治理意图与操作现实之间的差距。
研究方法
本研究对 2020 年至 2026 年间 AI 事件数据库 (AIID) 中记录的 480 起真实世界 AI 事件 进行了跨监管的实证分析。样本是从最初的 1,365 条记录中，通过基于正则表达式的筛选和人工审核精简而来的，以排除恶意滥用、虚假信息及非治理相关的纠纷。
编码与分析：
框架映射： 将事件针对三个监管体系中的 九项特定部署后条款 进行编码：
《欧盟 AI 法案》： 第 72 条（上市后监控）和第 73 条（严重事件报告）。NIST AI RMF： GOVERN 4（问责制）以及 MANAGE 1–4（监控、响应、沟通、退役）。GDPR： 第 22 条（自动化决策）以及第 33–34 条（违规通知），外加第 35 条（数据保护影响评估）。
操作化： 利用对 AI 事件报告文本和结构化元数据的自动内容分析，将每个事件归类为针对适用条款的合规 、部分合规 、不合规 或证据不足 。“证据不足”被视为一种治理信号，表明缺乏公开文档。分析策略： 分析计算了按框架、行业、风险类别和地理位置划分的合规率。至关重要的是，研究对比了内部检测 （由部署组织发现）与外部检测 （由记者、用户或监管机构发现）之间的合规结果，并利用 Fisher 精确检验来评估统计显著性。
核心贡献
条款级跨监管分析： 本文提供了首次针对 480 起事件与《欧盟 AI 法案》、NIST AI RMF 及 GDPR 特定义务进行的大规模、条款级映射研究。系统性失效的证据： 研究表明治理差距是系统性的；特定的事件往往同时逃避了多个框架的监管，这表明监管多样性本身并不必然构成安全保障网。内部监控效应： 研究识别出内部监控是合规性的强相关因素，发现内部检测到的事件比外部检测到的事件更有可能显示出对治理义务的遵循。主动式 AI 治理合规框架 (PAGCF)： 基于观察到的失效模式，作者提出了一个四阶段生命周期方法论（部署前评估、持续监控、事件准备、跨框架验证），以弥合问责差距。
关键结果
1. 普遍存在的问责差距
实证数据揭示了所有框架在部署后治理方面都存在实质性缺陷：
《欧盟 AI 法案》： 77.1% 的事件缺乏上市后监控（第 72 条）的证据，且 82.9% 的适用事件未显示严重事件报告（第 73 条）的证据。NIST AI RMF： 虽然 48.8% 的事件表现出高度一致性（主要由反应性的退役/MANAGE 4 驱动），但主动机制非常罕见。持续监控（MANAGE 1）仅出现在 9.4% 的事件中。GDPR： 在 219 起适用 GDPR 的事件中，92.2% 缺乏足够的书面证据来进行确定性评估。仅有 0.4% 显示出数据保护影响评估 (DPIA) 的证据，另有 7.8% 被明确归类。
2. 系统性 vs. 特定框架失效
在分析的事件中，有 9.8% 被标记为同时在两个或更多框架下不合规。虽然框架间的重叠度较低（Jaccard 指数为 2.2–11.3%），但这种非零重叠表明，某些失效会跨越多个问责边界而未触发控制措施，这指向的是问责供应链中的协调差距，而非缺乏正式框架。
3. 内部监控效应
最重要的发现是基于检测来源的合规性差异：
《欧盟 AI 法案》合规性： 内部检测到的事件中，87.5% 为合规或部分合规，而外部检测到的事件中仅为 5.3% （约 17 倍的差异；p < 0.001）。NIST 一致性： 内部检测到的事件中有 95.8% 显示出高/中度一致性，而外部检测到的仅为 58.1% 。解读： 虽然作者因选择偏差（内部监控的组织可能整体更成熟）而对因果关系结论持谨慎态度，但这种差异的幅度表明，内部监控是有效部署后治理的关键条件。
意义与主张
本文认为，部署后问责制主要是一个执行问题 ，而非设计问题。治理的正式架构已经存在，但使之可见且可强制执行的组织常规在很大程度上是缺失的。
从反应式转向主动式： 研究挑战了“部署者会可靠地进行自我监控”这一假设。由于 95% 的事件是由外部检测到的，目前的监督功能实际上起到了事后损害控制的作用。作者建议将治理重心转向部署前评估和持续监控，因为证据表明这些领域具有最大的杠杆作用。执法 vs. 自愿主义： 研究结果表明，受处罚支持的约束性义务（如 GDPR 的执行能力）可能优于自愿性方法，但前提是必须生成特定的、可审计的记录。PAGCF 提议： 所提出的框架并非理论上的理想模型，而是直接从实证差距中推导出的设计启示。它强调，组织必须在损害变得外部可见之前，建立好证据、升级路径和问责分配机制。
作者总结道，为了让部署后问责制超越“正式的法律承诺”，组织必须具备产生及时的监控、升级和补救证据的能力。该研究呼吁未来的研究应将这些自动化编码方案与专家裁定进行基准测试，并在组织环境中试点 PAGCF。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。