更新授權問題：AI 智能體被修補時的問責

軟體在不斷更新。安全補丁修復漏洞，錯誤修復糾正異常行為，功能發布改變能力。在大多數軟體場景中，這種更新節奏是一種明確的進步：新版本更好，部署它是一種直接的技術行為，除版本號和變更日誌外無需特殊的問責基礎設施。

AI智能體不符合這種模型。當智能體的參數被更新時，其行為會改變——不是像軟體補丁那樣以可讀、可列舉的方式改變具名函數，而是以分布在模型中且無法透過閱讀差異檔案完全審計的方式改變。更新前存在的智能體與更新後存在的智能體，在有意義的層面上是不同的智能體。它們可能對相同的輸入產生不同的輸出，可能對相同情況進行不同解讀，可能在之前具有隱性權威的決策上存在分歧。

這就是更新授權問題：誰有權更改AI智能體、在什麼約束下更改，以及對那些與已消失版本建立信任關係的人負有什麼問責義務。

為何軟體模型不夠充分

標準軟體更新框架將權限賦予開發人員、運營者和管理員。它假設更新是改進，用戶從中受益，對軟體變更的適當回應是通知用戶並繼續進行。同意通常最多是選擇退出：除非用戶採取行動阻止，否則系統將自動更新。

當智能體佔據重要角色時，這種模型就會失效。夜間修補的企業IT系統第二天早上可能表現不同，但這種差異不太可能影響任何人的護理、安全態勢或安全性。部署在其決策具有現實影響力的領域中的AI智能體，不能以同樣的條款更新。這種變化不是表面的。智能體的委託人——無論是患者、安全管理員還是硬體操作員——與該智能體特定版本的行為建立了關係。在沒有明確權限和通知的情況下更改行為，不是更新，而是委託人未授權的替換。

後量子交叉點：權重更改後的認證身份

在後量子交叉點，AI智能體可能參與密碼學操作：生成、驗證或證明金鑰和簽名。它在這些操作中的行為是下游系統信任的一部分。如果智能體的權重被更新——即使出於完全良性的原因，例如改善其在相鄰領域的推理——也無法保證其在密碼學操作中的行為保持不變。更新後的智能體可能以不同方式證明，可能接受之前拒絕的輸入，或拒絕之前接受的輸入。

問責差距是具體的：智能體的密碼學身份可能在更新過程中不會改變，即使智能體的行為已經改變。信任智能體證明的下游系統無法知道產生該證明的實體與最初經過審查的實體存在實質性差異。在後量子過渡期間，整個密碼學棧的信任假設都在積極修訂中，悄然改變的智能體就是悄然改變的信任錨。

在這個交叉點上的更新授權需要明確的行為連續性證明——不僅僅是版本號的更新，而是一個有文件記錄的、可驗證的聲明，表明智能體在密碼學操作中的行為已經過測試，並確認在之前接受的範圍內。缺乏該證明，更新就會使原始信任失效。

硬體交叉點：韌體策略與靜默行為漂移

在硬體交叉點，AI智能體可能管理或解釋硬體裝置的輸出——決定哪些韌體狀態是可接受的，哪些認證是有效的，哪些感測器讀數值得發出警報。這些是嵌入在智能體行為中的策略決策。當智能體被更新時，這些策略可能在沒有任何明確公告的情況下改變。

困難在於硬體治理策略通常不會從智能體的一般行為中單獨提取和列出。它們是從模型的訓練中湧現出來的，而不是在配置檔案中列舉的。這意味著已認證智能體硬體治理決策的操作員，如果不對更新後的智能體進行全面重新評估，就無法針對其重新進行認證。在實踐中，這很少發生。更新被部署；硬體治理策略發生變化；認證不再反映智能體實際所做的事情。

在這個交叉點上的更新授權要求將硬體治理決策視為可單獨審計的表面。改變智能體硬體策略的更新必須附帶明確的變更文件，說明改變了什麼以及原因——並且必須在更新後的智能體被信任管理具有安全或保障影響的硬體之前觸發重新認證。

護理交叉點：依賴、同意與患者所知的智能體

在物理世界護理交叉點，更新授權問題具有最直接的人類後果。依賴AI智能體的護理對象——已對其行為建立期望、根據其指導校準了自身回應、並同意與其持續關係的人——與該智能體特定版本的行為建立了信任。這種信任不是永久賦予智能體開發者的；它是在同意時向智能體的行為方式賦予的。

當智能體被更新時，護理對象在任何有意義的意義上都不再是與同一關係的同一方。他們同意的智能體已不再存在。他們可能不知道更新發生了。即使被通知，他們也可能無法從行為層面理解發生了什麼變化。他們撤回同意、尋求第二意見或校準其對更新指導依賴的能力，受到與最初參與智能體時相同因素的約束：首先導致他們尋求AI輔助護理的條件。

在這個交叉點上的更新授權要求將更新視為同意事件。對護理關係中智能體行為的實質性變更需要以護理對象能夠理解的形式進行通知，提供確認繼續同意的機會——在行為變化重大的情況下，還需要提供在他們能夠做出知情決定之前保留在先前版本上的權利。

三個交叉點上更新授權的要求

共同主線是更新授權不能被視為純粹的內部治理事項。由此產生三個要求。

首先，在重要角色中AI智能體的更新必須附帶行為影響評估——一個有文件記錄的、可測試的聲明，說明更新改變了什麼、保留了什麼，其粒度足以讓依賴先前版本的委託人理解其依賴是否仍然有效。

其次，批准更新的權限必須與行為變化的範圍相稱。影響密碼學認證、硬體策略決策或護理指導的變更需要開發團隊以外利益相關者的簽字同意——在適當情況下，包括依賴受影響最大的委託人。

第三，更新後智能體的審計跟蹤必須在更新之間保持連續。在每個版本邊界重置問責記錄的智能體，是無法對其整個部署弧線負責的智能體。審計跟蹤必須向前延續，每次更新都記錄為命名的變更事件，而不是記錄的替換。

將更新視為軟體發布，對軟體有效。部署在其決策具有分量的領域中的AI智能體，不是發布流程設計時所針對的軟體。更新授權問題的核心認識是：更改此類智能體是一種需要其自身問責結構的行為——不是智能體部署治理的更輕版本，而是同等級別的治理。