什麼是模型退役？企業低估的 AI 供應商風險

2026 年 8 月 5 日，Claude Opus 4.1 正式退役。10 月 23 日，約十個 OpenAI 模型同日下線。而在你的組織裡，某個八個月前由部門主管簽核通過的工作流程，正在呼叫其中一個模型，卻沒有人記錄下究竟是哪一個。

問題的全貌就在這三句話之內。技術運作正常，供應商也已公開退役日期，真正的落差完全在組織管理層面。

本文將說明模型退役是什麼、2026 年哪些日期至關重要、一次被迫遷移的真實成本，以及那份能把退役通知從突發事故變成日程安排的一頁清冊。

什麼是 AI 模型退役？

AI 模型退役，是指供應商按既定時間表停止提供某個模型版本。退役日之後，指向該版本的 API 呼叫會失敗，或被靜默轉接到後繼版本。你的生產系統當初據以建置、測試與核准的那個模型，將不再存在，而時間表由供應商決定，不是你。

大多數企業把底層模型當成基礎設施，如同一套五年後仍會存在的資料庫引擎。

但它並非基礎設施。它是一份帶有到期日的供應商合約，而 2026 年的到期日，來得比採購流程能夠消化的速度更快。

兩類退役的影響截然不同。硬性退役會直接回傳錯誤，雖具破壞性但至少可見。靜默升級則把流量轉往行為不同的新版本，危險程度高得多，因為沒有任何東西發出明顯的故障訊號。

為什麼模型退役週期越來越短？

退役窗口收窄，原因是前沿實驗室現在每隔數月就推出後繼模型，無法在經濟上持續服務每一個舊世代。2025 至 2026 年的產業觀察顯示，單一模型版本的典型可用壽命約為六個月，較以往約十二個月大幅縮短。供應商端迭代加速，換到你這邊就是被迫遷移加速。

商業邏輯相當直接。維持舊模型服務，意味著為不斷萎縮的用戶群保留推論算力，而同一批晶片本可運行更便宜、更強的後繼版本。

通知期反映了這股壓力。根據 OpenAI 公開的退役政策，一般可用模型至少提供六個月通知，特殊變體約三個月，預覽版本則約兩星期。Anthropic 則公開承諾對公開模型提供至少 60 天通知。

而 60 天，比香港多數金融機構的變更審批週期還要短。

這才是真正的問題所在。供應商的做法合理且透明，落差出現在 60 天通知窗口與一套需要一個季度才能核准生產變更的企業治理流程之間。

2026 年有哪些 AI 模型退役，日期是什麼？

多項重大退役落在 2026 財政年度之內，而近期日期已全部公開。任何在生產環境運行這些版本的組織，面對的是固定期限，而非規劃假設。以下清單依據 2026 年上半年供應商公告與退役追蹤資料整理。

--- 2026 年 2 月 13 日：GPT-4.1、GPT-4.1 mini、GPT-4o 與 o4-mini 自 ChatGPT 移除。

--- 2026 年 3 月 9 日至 31 日：Azure OpenAI 標準部署開始自動升級舊模型，並於月底到達生命週期終點。這屬於靜默升級，而非回傳錯誤。

--- 2026 年 7 月 23 日：Codex 與深度研究類模型變體退役。

--- 2026 年 8 月 5 日：Claude Opus 4.1 退役。

--- 2026 年 10 月 23 日：約十個 OpenAI 模型同時退役，涵蓋 GPT-4 世代與 o 系列。

10 月那個日期值得特別留意，因為它是一次集群退役，而不是單一下線。一家在不同時期建置了四條 AI 工作流程的企業，可能發現其中三條所依賴的模型，全部在同一週到期。

集群退役正是把一次可控遷移，變成與年末封版期正面衝突的原因。

一次被迫的模型遷移，真實成本是多少？

遷移的直接授權成本通常為零，後繼模型的每token單價往往更便宜。真正的成本是回歸風險：所有曾對舊模型驗證過的提示、檢索管道與下游自動化，全部必須重新驗證。這些是工程時間、測試時間與合規簽核，並非供應商支出。

遷移成本可拆成四個財務團隊一貫低估的項目。

--- 提示重新調校。針對某個模型行為優化過的指令，在後繼版本上經常表現下滑，輸出格式要求嚴格的情況尤甚。

--- 評估基準重建。如果準確度只是非正式地量測過，就沒有基準可與新模型比較，團隊只能靠猜測。

--- 監管重新核准。在受規管行業，對用於客戶決策的模型作出實質變更，可能觸發新一輪內部驗證。

--- 輸出偏移修補。後繼模型可能產出更長、結構不同或語氣保留度不同的答案，令下游消費系統失效。

這裡有一個值得放進同一份商業方案的實質好處。後繼模型在完成同等工作時往往更便宜，而在 Claude Opus 世代之間遷移，據報可顯著削減每token帳單。一次被迫的遷移，仍然可能降低營運支出，這正是讓預算申請得以通過的論點。

要量化這項取捨，前提是有一套可運作的評估基準。若你的組織尚未建立，可先參考 什麼是 AI Eval，以及企業如何量測 AI 是否真正有效，再以 AI FinOps 框架控制企業 AI 支出接上成本面。

如何建立模型生命週期清冊？

模型生命週期清冊，是一份持續維護的單一清單，列出組織在生產環境中呼叫的每一個模型版本、負責人、用途，以及到期日。這是最低限度的控制措施。沒有它，沒有人能在一週之內回答董事會那句「10 月 23 日會有什麼壞掉」。

五個欄位能讓清冊真正有用，而不只是擺設。

--- 呼叫點。發出請求的具體應用、工作流程或代理，而非部門名稱。

--- 已鎖定版本字串。準確的模型識別碼，包括供應商提供的日期後綴。

--- 具名業務負責人。一位為遷移決策負責的人，而不是一個委員會。

--- 已公告退役日期。取自供應商官方退役頁面，每月更新一次。

--- 評估狀態。是否已存在一套可即日對候選替代模型執行的計分測試集。

第五個欄位，正是區分「兩週內完成遷移」與「花一個季度爭論」的關鍵。有計分測試集的團隊，直接跑一次後繼模型、比較結果、產出證據。沒有的團隊，只能靠意見。

清冊同時回答了集中度問題。多模型運作現已成為標準做法：AvePoint 2026 年企業 AI 策略分析指出，81% 的資訊科技主管在測試或生產環境中運行三個或以上模型家族，較一年前的 68% 上升，而 37% 已在生產環境運行五個或以上。三分之二的組織形容自己正積極避免單一供應商依賴。

然而，運行多個模型並不自動等於韌性。在沒有清冊的情況下運行多個模型，只意味著多個你看不見的到期日。

哪些合約條款能保護你免受退役衝擊？

四項條款能把退役從營運危機轉為可管理的供應商事件：版本鎖定權、明確的最低通知期、遷移支援承諾，以及輸出等效性補救機制。只以每token價格談判 AI 合約的採購團隊，等於把這四項全部放棄。

在續約時逐項明確提出。

--- 版本鎖定。在約定期限內留在指定版本的權利，令週期中途的能力變更不會毫無預警地出現。

--- 通知下限。高於供應商公開預設值的合約最低通知期，長度須配合你自身的變更審批週期。

--- 遷移支援。具名技術協助，以及兩個版本同時可呼叫的並行運行窗口。

--- 實質性補救。當後繼版本在你已驗證的測試集上產出實質不同的輸出時，有明確的處理路徑。

版本鎖定帶著一個必須坦白說明的取捨。鎖定保護你免受意外變更，同時也保證你最終必然停留在一個已被安排退役的版本上。鎖定買到的是可預測性，不是永久性。

與之對應的架構做法，是在應用程式碼與模型 API 之間建立一層抽象層，讓更換供應商成為路由設定調整，而非重新建置。這與令 MCP 成為企業策略級整合決策的整合紀律，屬於同一套思維。

模型退役對香港各行業的影響有何不同？

暴露程度取決於模型輸出與受規管義務或合約義務的綁定緊密程度。市場推廣團隊可以在一個下午內吸收輸出偏移。持牌機構卻不行，因為模型嵌在一項有文件記錄的控制措施之內，而監管人員隨時可能查問。

三個香港場景展示了這個範圍。

--- 金融服務。一家持牌法團以模型摘要客戶合適性紀錄，再由顧問簽核。模型版本已寫入內部控制文件。一次靜默升級改變了摘要長度與語氣保留方式，控制描述與實況不再相符。補救工作是文件覆核，而非改程式。

--- 物流。一家貨運代理從三種語言的報關文件中擷取欄位。後繼模型處理繁體中文縮寫的方式有所不同，令一批測試時未被抽樣的文件擷取準確度下降。錯誤要到數週後才以下游報關更正的形式浮現。

--- 專業服務。一家會計師事務所以鎖定版本執行文件初審。退役日期落在最繁忙申報期之前三星期。遷移技術上簡單，營運上卻不可行，因為高峰期根本沒有重新驗證的人力。

三個場景的共通點是時間問題，而非技術問題。若有九十天的可見度，每家機構都能從容遷移；只有十四天，就無法安全遷移。

個人資料為香港營運者再加一層考量，因為處理個人資料的模型一旦更換，內部紀錄可能需要相應更新。實務基準可參考 2026 年個人資料條例合規檢查對香港企業的意義。

忽視模型退役會出什麼問題？

五種失敗模式反覆出現，而每一種都可事先看見。它們共享同一個根因：模型被當作永久的技術事實，而不是一項有具名負責人與覆核日期、附帶到期日的供應商承諾。

--- 未鎖定的預設值。團隊從未指定版本，供應商的靜默升級改變了行為，而數星期內沒有人把事故與模型變更聯繫起來。

--- 無人認領的試點。一個成功的概念驗證移交給營運部門，卻沒有記錄使用哪個模型。退役通知寄到，沒有人說得出它影響什麼。

--- 與封版期正面相撞。退役日期落在年末變更封版期之內，只能在緊急例外與服務中斷之間二選一。

--- 消失的基準。準確度只在工作坊上展示過，從未編成測試集，因此無法向風險委員會證明遷移是安全的。

--- 單一供應商懸崖。所有 AI 工作流程都用同一家供應商，一個退役週期同時擊中全部流程。

一家在同一供應商上運行發票擷取、客戶郵件分流與貨運異常摘要的物流營運商，並不是有三個 AI 項目。它只有一個戴著三頂帽子的集中依賴。

未來 30 天應該做什麼？

先盤點，再談合約，最後才是架構。大多數組織並不需要新平台來管理退役風險。它們需要知道自己在運行什麼、由誰負責、何時到期，這是一項四星期的工作，而非一個資本項目。

--- 第一週。盤點每一個生產環境 AI 呼叫點，逐一記錄準確的模型版本字串。

--- 第二週。將每個版本對照供應商官方退役頁面，標記 180 天內到期的項目。

--- 第三週。為每個呼叫點指派一位具名業務負責人，並確認是否已有計分評估集。

--- 第四週。把四項合約條款加入下一次 AI 供應商續約，並以日期而非形容詞向風險委員會匯報。

這個月的產出只有一頁：呼叫點、負責人、到期日、評估狀態。正是這一頁，令下一次退役通知成為日程安排，而不是事故。

策略要點

模型退役不是 AI 問題。它是一般的供應商生命週期管理，只是套用在一個你的組織尚未歸類為供應商的供應商身上。

能夠從容應對 10 月 23 日集群退役的企業，並非 AI 預算最大的那些。而是能夠隨時交出一頁清冊、為每個呼叫點指出負責人，並在同一個下午對替代模型跑完計分測試的那些。

供應商的日期是固定的。你的準備程度，是唯一你能控制的變數，而它建立於通知郵件到達之前，不是之後。

懂AI，更懂你 UD相伴，AI不冷。UD 服務香港企業 28 年，讓我們明白一件事：技術決策很少是最難的部分，最難的是圍繞它的營運紀律。

由 UD 企業 AI 團隊覆核。

在下一個退役日之前，先弄清楚你在運行什麼

模型生命週期清冊要有用，前提是它真實反映你的組織今天如何使用 AI。UD 的 AI 準備度檢測會盤點你現有的 AI 佈局、依賴關係與準備落差，我們手把手帶你完成每一步，從盤點、供應商條款覆核，到評估基準與遷移規劃。28 年香港企業服務經驗，全程陪你走。