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 年香港企业服务经验，全程陪你走。
