2026 年 6 月 12 日，Anthropic 發布兩款新一代前沿模型。三日之後，它們消失了。
美國商務部工業與安全局在商務部長 Howard Lutnick 簽署下，要求該公司暫停向任何外國國民提供 Claude Fable 5 與 Mythos 5 的存取權，無論對方身處美國境內或境外。由於公司無法可靠地按國籍篩選使用者，最終選擇將兩款模型全面停用。直至 6 月 30 日，公司強化模型安全防護後，存取權才逐步恢復。這宗事件由《財富》雜誌與 CNN Business 等媒體報道。
在那十八日之內，所有建基於這兩款模型的機構，手上並非一個效能下降的模型，而是完全沒有模型。
若你認為自己的機構規模太小，不會受前沿模型的地緣政治影響，不妨想像一個更平淡的版本：供應商宣布退役你發票核對流程所依賴的那個模型版本，給你九十日通知期，而繼任模型的行為差異足以令你原有的驗證結果失效。這個版本不是意外，而是按時間表發生，並且正在發生。
什麼是 AI 模型退役？
AI 模型退役，是指供應商終止某個特定模型版本的服務，該版本此後不再接受請求。所有依照該版本校準的工作流程、提示詞、評估基準與控制措施，都必須遷移至一個行為並不相同的繼任模型。這是由供應商主導的產品終止事件，而非你自行安排的軟件升級。
對董事會而言，關鍵差異在於控制權。當你退役一套內部系統，日期、備援方案與測試視窗都由你決定。
當模型供應商退役一個模型，你收到的只是一則通知。日期是它定的，繼任者是它選的，而行為差異沒有文件記載，因為沒有任何人能夠完整描述兩個語言模型在你特定用例上的落差。
因此，模型退役應歸入「關鍵供應商變更條款」這一風險類別，而不是「瀏覽器更新」那一類。
為何模型壽命縮短至約六個月？
模型壽命已由約十八個月縮短至約六個月。根據追蹤 Anthropic、OpenAI、Google 與 Amazon Bedrock 的公開生命週期日曆，2025 年 12 月之後發布的模型，由發布至公布退役的間距約為 181 至 213 日。
成因是競爭節奏。自 2023 年以來，主要模型發布的頻率大約增加了三倍，而供應商不願意同時為五個世代維持推論算力。
每退役一個舊模型，就釋放算力給最新的模型。這對供應商是理性選擇，對客戶則是一筆開支。
實際後果是一道簡單算術。若模型壽命為六個月，而一個受管治用例的驗證週期需時八星期，那麼你有接近三分之一的生產時間都在重新驗證。
大多數企業並未為此編列預算。它們編列的是項目預算，而不是汰換週期預算。
2026 年 6 月的停用事件證明了什麼？
它證明了模型的可用性，可以被一個並非你供應商、亦與你毫無合約關係的第三方移除。商務部的指令在模型發布三日內，因一項越獄疑慮而令兩款商用模型全球下線，而沒有任何客戶擁有異議的立場或合約上的補救途徑。
值得注意的是，這並非技術故障，亦沒有任何服務水平協議涵蓋這種情況。
這是針對供應商的監管行動，而供應商的合規方式，是為所有人關掉產品，因為部分合規在操作上並不可行。
美國戰略與國際研究中心與 TechPolicy.Press 均把這宗事件定性為先例，而非異常。一旦政府證明了自己能夠要求撤回一個模型，這根槓桿就長期存在。
對香港企業而言，這添加了一類你的業務持續計劃幾乎肯定沒有命名的風險：你以 API 形式消費的外國軟件服務，其可用性受地緣政治左右。
為何這是董事會層面的風險，而非 IT 問題？
因為它把營運依賴集中於一個你無法審計的供應商，時間表不由你掌握，而相關流程正日益觸及客戶與受規管記錄。當模型消失，暴露的並非一個壞掉的整合介面，而是一條沒有操作者的業務流程。
德勤《2026 年企業 AI 現狀》報告指出，34% 受訪機構已進入以 AI 深度轉型的階段，意即重塑核心流程或創造新產品，而非只在旁邊做實驗。
深度轉型正是令退役變得危險的原因。一個停下來的試點只是不便。
一條停下來的理賠分流、客戶開戶審查或月結對帳流程，則是一宗附帶監管後果的事故。
董事應該能夠提出、並且獲得答案的問題其實很簡單：若某個指名模型下一季被撤回，我們哪些流程會停止運作，恢復需時多久？
什麼是模型依賴清單？
模型依賴清單是一份登記冊，把每一條生產流程對應到它所呼叫的具體模型版本、供應商、合約上的延續性承諾、受影響的業務流程，以及在繼任模型上重新驗證所需的時間。這份文件，是把模型退役由未知轉為受管風險的關鍵。
大多數機構嘗試編製時才發現無法完成。各團隊各自採用模型，沒有人記錄版本。
一份可用的清單，須為每條流程記錄六個欄位：
--- 生產環境中確切的模型識別碼，包含版本，而非只有供應商名稱
--- 它支援的業務流程，以及該流程是否面向客戶或受規管
--- 供應商公布的退役日期，或註明並無公布
--- 合約實際承諾的可用性與通知期
--- 重新驗證所需的人日，以量度取得而非估算
--- 指名的備援模型，以及它是否曾在真實流量下測試
最後一項是大多數清單誠實地失守之處。指名一個備援模型很容易，真正跑過的卻極少。
如何建立模型延續性框架？
模型延續性框架包含四層：抽象層，讓流程呼叫路由層而非直接呼叫供應商；可攜性，把提示詞與評估集當作有版本的資產管理；每條受管治流程都有經測試的備援；以及事先批核的重新驗證預算，而非在事故中才申請。
由抽象層開始。若應用程式碼內寫死供應商端點，每次遷移都變成一個工程項目。經由中介層路由，則變成一次配置更改。我們關於AI 閘道是什麼、企業為何現在需要它的指南，詳細說明了這個控制點。
可攜性是一種紀律：把提示詞、檢索配置與評估集視為有負責人、有版本的資產，而不是由建構功能的人隨手貼進程式庫的文字。
經測試的備援，是機構最常略過的一層。一個從未處理過生產流量的備援，只是一個假設，不是一項控制。
重新驗證預算則屬治理決定，而非技術決定。若六個月的模型壽命已成規劃前提，那麼每條受管治流程每年兩次重新驗證，就是 AI 在生產環境運作的基本成本。每年一次批核，遠比在壓力下批核便宜。
香港監管機構對模型退役有何期望？
香港監管機構早已把模型生命週期視為受監督的活動。金管局《監管政策手冊》SB-1 模組「模型風險管理」於 2024 年 1 月修訂，涵蓋模型開發、驗證、持續監察與退役，並視之為一個持續循環而非一次性審批。
金管局亦於 2026 年 5 月底至 6 月初發出通函，提醒認可機構檢視其網絡風險管理、事故應變、復原測試及第三方韌性安排，是否足以應對不斷演變的 AI 相關風險。
「第三方韌性」正是此處的關鍵詞。模型供應商就是第三方，而它的退役時間表就是一道韌性題目。
2026 年 3 月，金管局、證監會、保險業監管局與強積金管理局聯合推出跨金融界別的 GenA.I. Sandbox++ 計劃，顯示監管層對生成式 AI 的關注是協調一致，而非各自為政。
在金融服務以外，《個人資料（私隱）條例》仍然適用於你的流程送往模型的任何個人資料，而更換模型即是更換資料處理者安排，值得記錄在案。我們關於AI 與私隱條例合規檢查的文章，說明了這份記錄應包含什麼。
忽略模型延續性會出什麼問題？
五種失效模式反覆出現，而且全部在退役通知到達之前已經可見：
--- 靜默版本漂移。團隊呼叫供應商的別名而非鎖定版本，別名指向新模型，輸出品質改變，卻沒有任何部署紀錄或工單。
--- 提示詞耦合無文件。針對某個模型行為調校數月的提示詞，在繼任模型上表現退步，而調校理由無人保存。
--- 評估債務。原本的準確率基準只在上線時跑過一次、從未自動化，於是沒有東西可以在替代模型上重跑。
--- 單一供應商集中。所有受管治流程都押在同一供應商，一宗監管或商業事件即可同時影響整個組合。
--- 預算突襲。遷移成本從未列入營運計劃，重新驗證於是與新項目競爭資源，並且落敗。
這五項事前修正都很便宜，在通知與關閉之間那九十日修正則很昂貴。
未來 30 日應該做什麼？
三項行動已能帶來大部分保護：即使不完整也要先建立模型依賴清單；把每個生產呼叫鎖定至明確的模型版本而非浮動別名；並選一條受管治流程，在備援模型上完整跑一次，看看究竟哪裡會斷。
清單是首要，因為你無法管理未曾列出的東西。一份只列出五條最關鍵流程的不完整登記冊，價值高於明年才交付的完整版本。
版本鎖定在每個整合介面只是一行改動，卻能消除整個靜默漂移的風險類別。
備援測試則是真正改變想法的一步。團隊往往發現繼任模型需要不同的提示結構、產出不同格式、在不同邊緣個案上失敗。在受控測試中發現，只是一個平常的星期二；在關停期間發現，就是一份董事會文件。
這一切都不需要龐大計劃，只需要有人承擔這道題目，以及一個為答案撥款的決定。若你想要一個有結構的起點，先評估組織實際站在哪個位置，通常比內部審計更快，而我們關於企業 AI 自建還是採購的框架，在備援問題演變成採購問題時尤其有用。
策略要點
模型退役不是一個工程部門會默默吸收的技術問題。它是一項帶著六個月倒數的供應商集中風險，帶有你的業務持續計劃尚未認識的監管面向，以及一筆無人放進預算的營運成本。
能夠妥善應對下一次 Fable 5 事件的機構，並非擁有最好模型的那些，而是能夠用一頁紙回答「哪些流程依賴哪些模型、模型停止會怎樣」的那些。
那一頁紙需要兩星期製作，卻是你 AI 組合中最便宜的保險。
科技週期總是反覆教同一課，而這一課永遠關於依賴。懂AI，更懂你 UD相伴，AI不冷。
本文由 UD 企業 AI 團隊審閱。
下一步
建立模型依賴清單，由誠實地看清你的組織今日站在哪個位置開始。UD 團隊手把手帶你完成每一步，由 AI 準備度評估、備援設計、遷移規劃到持續治理，28 年服務香港企業的經驗，全程陪你走。
