认证滞后问题：当批准版本并非实际运行版本时的问责

当AI智能体在高风险领域造成损害时，任何问责程序中最先提出的问题之一表面上很简单：造成损害的版本是否是被批准的版本？在成熟的工程学科中——制药、航空、医疗器械——这个问题有明确的答案。经批准的制品是固定的，部署记录显示运行了哪个版本，问责可以从那里推进。

对于AI智能体，答案几乎总是复杂的。认证需要时间。模型持续改进。某个版本进入认证程序与该程序结束之间的差距可以是十二、十八或三十六个月。在此期间，模型的开发者通常已经发布了几个后续版本，这些版本具有可测量的更好性能、更低的错误率，并修复了经认证版本仍存在的失败模式。当批准到来时，运营商面临的是任何认证框架都没有被设计来解决的困境。

滞后创造的两难困境

使用经认证的版本在狭义上是可辩护的——认证有记录，版本有文档，审批机构已对其进行验证。但经认证的版本可能存在较新版本已纠正的已知局限。部署较旧、较差的模型仅因为它已获认证，而更好的版本存在，是一种认证框架使其看起来谨慎但可能为被服务人员产生更差结果的选择。

使用未认证的更新则引入了不同的问责差距。运营商可能部署更新是因为它真正降低了风险——例如修复了与安全相关的失败模式——但随后发生的任何损害都发生在认证边界之外。运营商无法指向外部验证。问责记录显示的部署偏离了经批准的版本，任何调查都将花费大量精力于该偏离是否造成损害，而非关于智能体实际行为的实质性问题。

两条路都不干净。认证滞后将关于模型质量的问题转化为关于流程合规的问题，这两个问题对不同时间的不同各方有不同的答案。

在后量子安全交叉点

密码学标准历来有漫长的认证周期。向后量子算法的过渡正在跨越以年计算的时间线上展开，标准机构在其审查的算法实际部署很久之后才完成审查。处理后量子密钥操作的AI智能体如果是针对早期威胁模型认证的，今天就是在对抗认证过程未检查的演变后的威胁格局。认证提供了合法保护；它不提供对认证审查完成后出现的威胁的实际安全保证。利用经认证威胁模型中差距进行的攻击所造成的损害，落入认证机构范围、部署者范围和供应商范围之间的空间——每方都指向其他方。

在硬件交叉点

硬件认证——针对AI加速器、嵌入式控制器、工业计算平台——涉及针对特定固件版本和运行条件的漫长测试。安全补丁和固件更新是维护任何已部署系统的常规部分。当发现关键漏洞时，运营商会打补丁，而打了补丁的固件通常不是经过认证的固件。另一选择——运行未打补丁、有漏洞的固件，因为打了补丁的版本还没有完成重新认证——在大多数操作环境中不是可行的选择。然而，运行了打补丁的、未认证固件的系统的问责记录，在结构上与运行了未经授权修改的系统的记录相似。在认证审计中，改善了安全的补丁和引入了漏洞的修改看起来是一样的。

在照护交叉点

医疗AI面临这个问题最尖锐的版本。获得市场授权的设备或软件智能体已经针对定义的预期用途、定义的患者群体和特定模型版本进行了审查。真实世界的部署很少保持在这些边界内。患者群体发生变化，预期用途扩大，新模型版本发布，运营商将智能体与原始授权未考虑的其他系统集成。在每一步，经授权的制品与运行中的系统之间的差距扩大。当损害发生并开始问责程序时，调查人员必须重建哪个版本在运行、其授权涵盖了什么，以及许多偏离授权边界的行为中哪些促成了结果。这在理论上是可处理的；在实践中，回答这些问题所需的记录很少以必要的精确度维护。

问责架构的要求

认证滞后问题没有简单的解决方案。更快的认证减少了滞后但不能消除它；模型将继续比任何机构审查流程更快地改进。结构性解决方案是将认证不视为对固定制品的时间点批准，而是视为认证机构、部署者和智能体版本历史之间的持续关系。

这需要当前框架在很大程度上缺乏的三件事。首先，部署记录必须包括版本证明——关于哪个确切版本在何时运行的密码学证据，以无法被事后修改的形式保存。其次，变更影响评估必须区分使认证失效的变更与次要更新，对分类决定有明确的问责。第三，认证边界必须在问责程序中明确：调查人员应被要求说明智能体行为的哪些方面在经认证的范围内，哪些不在，然后再将损害归因于其中任何一个。

经认证的版本和部署的版本很少是相同的。将两者视为可互换的问责框架留下了一个认证机构和部署者都没有完全拥有的结构性差距——而那个差距正是大多数棘手问责问题所在的地方。