更新授权问题：AI智能体被修补时的问责

软件在不断更新。安全补丁修复漏洞，错误修复纠正异常行为，功能发布改变能力。在大多数软件场景中，这种更新节奏是一种明确的进步：新版本更好，部署它是一种直接的技术行为，除版本号和变更日志外无需特殊的问责基础设施。

AI智能体不符合这种模型。当智能体的参数被更新时，其行为会改变——不是像软件补丁那样以可读、可列举的方式改变具名函数，而是以分布在模型中且无法通过阅读差异文件完全审计的方式改变。更新前存在的智能体与更新后存在的智能体，在有意义的层面上是不同的智能体。它们可能对相同的输入产生不同的输出，可能对相同情况进行不同解读，可能在之前具有隐性权威的决策上存在分歧。

这就是更新授权问题：谁有权更改AI智能体、在什么约束下更改，以及对那些与已消失版本建立信任关系的人负有什么问责义务。

为何软件模型不够充分

标准软件更新框架将权限赋予开发人员、运营者和管理员。它假设更新是改进，用户从中受益，对软件变更的适当回应是通知用户并继续进行。同意通常最多是选择退出：除非用户采取行动阻止，否则系统将自动更新。

当智能体占据重要角色时，这种模型就会失效。夜间修补的企业IT系统第二天早上可能表现不同，但这种差异不太可能影响任何人的护理、安全态势或安全性。部署在其决策具有现实影响力的领域中的AI智能体，不能以同样的条款更新。这种变化不是表面的。智能体的委托人——无论是患者、安全管理员还是硬件操作员——与该智能体特定版本的行为建立了关系。在没有明确权限和通知的情况下更改行为，不是更新，而是委托人未授权的替换。

后量子交叉点：权重更改后的认证身份

在后量子交叉点，AI智能体可能参与密码学操作：生成、验证或证明密钥和签名。它在这些操作中的行为是下游系统信任的一部分。如果智能体的权重被更新——即使出于完全良性的原因，例如改善其在相邻领域的推理——也无法保证其在密码学操作中的行为保持不变。更新后的智能体可能以不同方式证明，可能接受之前拒绝的输入，或拒绝之前接受的输入。

问责差距是具体的：智能体的密码学身份可能在更新过程中不会改变，即使智能体的行为已经改变。信任智能体证明的下游系统无法知道产生该证明的实体与最初经过审查的实体存在实质性差异。在后量子过渡期间，整个密码学栈的信任假设都在积极修订中，悄然改变的智能体就是悄然改变的信任锚。

在这个交叉点上的更新授权需要明确的行为连续性证明——不仅仅是版本号的更新，而是一个有文档记录的、可验证的声明，表明智能体在密码学操作中的行为已经过测试，并确认在之前接受的范围内。缺乏该证明，更新就会使原始信任失效。

硬件交叉点：固件策略与静默行为漂移

在硬件交叉点，AI智能体可能管理或解释硬件设备的输出——决定哪些固件状态是可接受的，哪些证明是有效的，哪些传感器读数值得发出警报。这些是嵌入在智能体行为中的策略决策。当智能体被更新时，这些策略可能在没有任何明确公告的情况下改变。

困难在于硬件治理策略通常不会从智能体的一般行为中单独提取和列出。它们是从模型的训练中涌现出来的，而不是在配置文件中列举的。这意味着已认证智能体硬件治理决策的操作员，如果不对更新后的智能体进行全面重新评估，就无法针对其重新进行认证。在实践中，这很少发生。更新被部署；硬件治理策略发生变化；认证不再反映智能体实际所做的事情。

在这个交叉点上的更新授权要求将硬件治理决策视为可单独审计的表面。改变智能体硬件策略的更新必须附带明确的变更文档，说明改变了什么以及原因——并且必须在更新后的智能体被信任管理具有安全或保障影响的硬件之前触发重新认证。

护理交叉点：依赖、同意与患者所知的智能体

在物理世界护理交叉点，更新授权问题具有最直接的人类后果。依赖AI智能体的护理对象——已对其行为建立期望、根据其指导校准了自身回应、并同意与其持续关系的人——与该智能体特定版本的行为建立了信任。这种信任不是永久赋予智能体开发者的；它是在同意时向智能体的行为方式赋予的。

当智能体被更新时，护理对象在任何有意义的意义上都不再是与同一关系的同一方。他们同意的智能体已不再存在。他们可能不知道更新发生了。即使被通知，他们也可能无法从行为层面理解发生了什么变化。他们撤回同意、寻求第二意见或校准其对更新指导依赖的能力，受到与最初参与智能体时相同因素的约束：首先导致他们寻求AI辅助护理的条件。

在这个交叉点上的更新授权要求将更新视为同意事件。对护理关系中智能体行为的实质性变更需要以护理对象能够理解的形式进行通知，提供确认继续同意的机会——在行为变化重大的情况下，还需要提供在他们能够做出知情决定之前保留在先前版本上的权利。

三个交叉点上更新授权的要求

共同主线是更新授权不能被视为纯粹的内部治理事项。由此产生三个要求。

首先，在重要角色中AI智能体的更新必须附带行为影响评估——一个有文档记录的、可测试的声明，说明更新改变了什么、保留了什么，其粒度足以让依赖先前版本的委托人理解其依赖是否仍然有效。

其次，批准更新的权限必须与行为变化的范围相称。影响密码学证明、硬件策略决策或护理指导的变更需要开发团队以外利益相关者的签字同意——在适当情况下，包括依赖受影响最大的委托人。

第三，更新后智能体的审计跟踪必须在更新之间保持连续。在每个版本边界重置问责记录的智能体，是无法对其整个部署弧线负责的智能体。审计跟踪必须向前延续，每次更新都记录为命名的变更事件，而不是记录的替换。

将更新视为软件发布，对软件有效。部署在其决策具有分量的领域中的AI智能体，不是发布流程设计时所针对的软件。更新授权问题的核心认识是：更改此类智能体是一种需要其自身问责结构的行为——不是智能体部署治理的更轻版本，而是同等级别的治理。