一句话定义：Model Removal Order（模型下架令）是监管机构或上级合规部门以书面形式发出的一份限期指令，要求某个组织在指定日期前停止使用、分发或对外提供某一特定 AI 模型，并提交"已经彻底移除"的证明材料。
它不是"把服务关掉"那么简单。可以参照食品召回：超市收到某批次下架通知后，货架上的商品要撤下，仓库库存要封存，已售出的要追溯，供应商要说明原因，最后还要提交一份签字报告。模型下架令遵循同样的逻辑，只是被追溯的对象变成了权重文件、API 调用和向量库。
执行通常分三步。
第一步是资产盘点（inventory）。这一步最容易出错，因为一个模型往往不只有一种形态：本地权重文件、云端 API 端点、微调后的 checkpoint、由它生成的 embedding 向量库、评测脚本中写死的 model ID、缓存里的推理结果，以及分散在各个业务系统里的调用密钥。盘点要给出"谁在用、用在哪、还有多少副本"的清单，否则后患无穷：你以为已经删干净了，半年后某个报表任务又把它调了起来。
第二步是替代选型（replacement）。要逐项对照：输入输出格式是否兼容、上下文长度够不够、延迟和成本能接受吗、数据是否留在合规区域、供应商有没有相应资质。选完之后必须在真实流量上跑回归测试，因为换模型最怕的不是报错，而是"不报错但结果悄悄变差"。
第三步是数据清除证据链（evidence chain）。这是最容易被低估的部分。有效证据通常包括：删除操作的时间戳日志、删除前后的目录截图、文件哈希校验值、第三方审计的确认函，以及责任人签字。核心是让一个没参与执行的第三方人员能够复核并确认"确实删了"；说"我们删了"并不足以证明这一点。
几个容易混淆的概念：
| 概念 | 发起方 | 形态 | 期限 |
|---|---|---|---|
| 模型下架令 | 外部监管或合规部门 | 强制、针对特定模型 | 明确截止日 |
| 模型弃用（deprecation） | 模型提供方自己 | 渐进、提前公告、留迁移窗口 | 通常较宽松 |
| 内容下架 | 平台或监管 | 针对某条具体输出 | 即时 |
区别的关键在于：模型下架的对象是模型本身，并非某一次回答。即便模型表现正常，也可能因训练数据来源、备案资质或供应商变更等原因被要求下架。
对从业者的实际意义：把"模型可替换性"当作架构属性来设计。不要在业务代码里硬编码模型名，保留统一的调用抽象层，记录每次调用的模型版本，定期导出资产清单。这样当指令到来时，你处理的是排期问题，而不是危机。对普通职场人来说，最直观的感受是某天常用的 AI 功能突然换了模型、风格变了、能力有增减。这往往就是下架令在上游生效了。
具体备案要求、豁免情形和申报流程，各地规定差异较大，以官方页面为准。