事后修改问题:AI不良事件的运维响应摧毁了调查所需证据时的问责困境
运维正确性与证据正确性不是同一属性。快速修复故障但抹除事件前状态的系统,完成了其运维职责,却未能履行其问责义务——两者同时为真。
一个AI照护智能体误读了患者的生理信号,未能触发告警升级。运维团队在数小时内收到通知,推送了配置补丁并触发模型更新。到第二天早上,系统已恢复正常运行。三周后正式审查启动时,事件前的系统状态——模型版本、配置、推断上下文——已不再以任何可供调查的形式存在。
这就是事后修改问题:当针对AI不良事件的运维响应,摧毁了后续调查所需的证据状态时。这种摧毁并非出于恶意,而是标准运维操作——却与部署者接受的每一项问责义务在结构上相互冲突。
三种证据销毁模式
AI不良事件后的证据销毁以三种模式发生,每种模式单独看都有其合理性。
第一是模型替换。当AI系统产生错误输出时,正确的运维响应是更新它——在纠正后的数据上重新训练、推送新检查点、切换到不同版本。事件前的模型被覆盖或以不总能重现的方式归档。产生错误输出的那个确切模型,可能在调查人员要求查看时,已不再以可运行的状态存在。
第二是配置变更。物理世界场景中的AI智能体,其不良事件往往源于配置方式,而非底层模型缺陷。提示工程、检索阈值、告警灵敏度设置、集成参数——每一项都在不触及模型权重的情况下塑造行为。不良事件后更新配置是如此常规,以至于通常根本不触发正式的变更管理记录。导致事件的修改与修复事件的修改,可能相隔数小时,在变更日志中却无从区分。
第三是日志轮换与基础设施刷新。那些能够支撑重建的事件日志——确切的提示、检索上下文、中间输出、事件发生时的硬件状态——受标准日志保留策略约束,这些策略是为运维便利而非对抗性调查设计的。在许多部署中,九十天已属宽松。运维的默认假设是日志用于调试,而非问责。这不是同一个需求。
后量子安全交叉点
对模型权重进行后量子密码学签名解决的是篡改问题:它确立了今天生产环境中的权重就是开发者签署的权重。它无法确立今天生产环境中的权重与事件发生时的权重是否相同。已签名的模型版本是当前状态的可信记录,不是部署历史记录。
向后量子签名基础设施的迁移引入了一个特定风险。将签名基础设施迁移到量子抗性方案的组织,往往会作为迁移的一部分对现有工件重新签名——这可能切断原本可能保存事件时状态的签名链。若一个组织在不良事件和调查之间完成了签名基础设施迁移,调查所需的证据链可能已因合法安全改进的例行副作用而断裂。
机遇同样存在于结构层面。正在设计和部署的后量子签名架构,可以明确纳入版本历史保留要求。一个旨在保存而不仅是验证的签名方案——维护一个防篡改的、仅追加的签署内容和时间历史——将改变其后所有不良事件调查的证据格局。
硬件交叉点
物理照护环境中的嵌入式AI系统——床边监控、辅助设备、带推断层的环境传感器——通过设备管理基础设施接收固件更新。这些更新是自动化的,在设备级别记录不完整,且时间戳精度通常不足以支持事件前后的归因分析。
硬件证明验证当前固件是否真实且未被修改。它不提供事件时运行固件的历史记录。当设备在不良事件后数小时内收到固件更新时——这在运维上是正常的,因为行为不正确的设备应该被更新——事件前状态的硬件证明链被切断,且没有任何正式记录表明这一切断已经发生。设备现在是正确的且经过证明的,事件时状态已经消失。
物理世界照护交叉点
照护环境对证据保存产生最强的运维压力。一个知道AI系统行为异常、却为保存事件前状态供调查而选择推迟修补的照护协调员,是在做出照护领域每一种运维规范都会归类为失职的决定。保护现有照护对象的职责不能等待调查便利。
这产生了一个无法通过归咎于任何个人失职来解决的结构性问题。立即修复问题的运维指令是正确的。调查问题所需的证据仍然被销毁。调查在基于降级信息的基础上进行,问责主张在本应解决它们的证据缺失的情况下被裁定,事件的教训——导致故障的具体配置或模型行为——可能永远无法被清楚地归因。
这种不对称性随时间累积。每一个因补救过程中证据被销毁而未能被调查的不良事件,都在助长一种问责环境:部署者无法证明尽职尽责,调查人员无法重建原因,AI照护系统服务的群体无法将正式问责作为纠正机制来依赖。
迈向问责的回应
事后修改问题的解决,不在于减慢运维响应速度,而在于将运维响应与证据保存解耦。
实践要求是自动化的修改前快照:在任何模型更新、配置变更或固件部署之前,系统在运维更新路径之外的防篡改存储中,捕获并保存修改前状态。快照包括模型版本和哈希值、配置参数、近期结构化日志和硬件固件状态。该存储为一次写入且单独证明——运维团队可以更新线上系统,而更新不会触及已保存的状态。
这是工程要求,不是政策要求。政策无法保存系统从未被设计为保留的证据。将证据保存内置于物理AI系统的时机,是在部署之前——届时证据要求可以与运维要求共同被设计进去,而不是在第一次严重事件后被发现彼此对立。
在Asaptic Labs,事后修改问题被视为每个交叉点的设计要求。运维正确性与证据正确性不是同一属性,仅解决前者的系统,在履行运维义务的同时,使其问责义务在结构上无法被调查。在不可逆后果的节点上,这不是一个令人满意的结果。
事后修改问题之所以产生,是因为针对AI不良事件的正确运维响应——更新模型、修补配置、刷新固件——系统性地摧毁了任何有实质意义的调查所需的事件前状态。每种销毁模式单独看都有其合理性,累积效应却是问责在结构上无法被调查。解决方法是将运维响应与证据保存解耦:在涉及不良事件的系统发生任何变更之前,自动进行一次写入、单独证明的修改前快照。这是必须在部署前设计进去的工程要求,而不是事后可以施加的政策。