AI 供应商突然受管制：香港企业要把模型风险当成运营风险
2026 年 9 月 5 日更新：Anthropic 表示，6 月实施的出口限制已于 6 月 30 日解除，并在 7 月 1 日宣布恢复 Fable 5 和 Mythos 5 的访问。下文保留 6 月 13 日发表时的讨论。阅读 Anthropic 的更新。
如果公司客服、报表、软件修改或网络安全检查已经依赖某个 AI 模型，最麻烦的情况未必是模型答错，而是明天突然用不了。这不是假设题。2026 年 6 月，多家海外媒体报道称，美国政府对 Anthropic 的 Fable 5 和 Mythos 5 采取出口管制，Anthropic 随后暂停相关模型访问。
对香港企业来说，这件事的重点不是某家 AI 公司与美国政府关系如何，而是 AI 供应商面临的地缘政治风险，已经成为企业实际的运营风险。过去选择 AI 工具，很多公司主要看功能、价格、速度和隐私条款；现在还要多问一个问题：如果供应商因为政策、合规或地缘政治原因突然限制服务，我们的日常工作会停在哪里？
发生了什么？
根据 Axios 报道，美国商务部长 Howard Lutnick 向 Anthropic 表示，Mythos 5 和 Fable 5 的出口、再出口或向外国人士转移都需要许可证，包括在美国境内的外国人士。Wall Street Journal 也报道称，限制范围令 Anthropic 选择暂停所有客户对这两个模型的访问，以降低合规风险。
Financial Times 的报道进一步提到，政府关注点与 jailbreak 漏洞及关键基础设施网络安全风险有关。Business Insider 早前则报道，Fable 5 是 Anthropic 推出的公开 Mythos-class 模型，带有较强防护；Mythos 5 则是较少限制、面向可信网络安全使用者的版本。
这些细节仍要留意后续官方文件和公司声明，但企业不需要等法律争议完全清楚才行动。只要一个供应商的核心模型可以因政策变化而即时受限，公司就应把 AI 供应商风险放入运营连续性计划。
为什么香港公司也要关注？
香港公司未必直接使用 Fable 5 或 Mythos 5，但很多团队已经在日常流程中使用美国 AI 供应商：客服草稿、销售邮件、文件摘要、代码修改、会议记录、合规初审、漏洞分析、管理报表。这些工具表面上只是 SaaS 订阅，实际上可能已经参与客户服务、交付、信息安全和内部决策。
例子：一家软件公司用 AI coding agent 协助处理客户系统改动。如果模型突然降级或停用，开发团队未必完全停工，但 bug fix 时间、测试覆盖和交付节奏都可能受影响。若公司向客户承诺了维护服务水平，就要知道这种依赖是否已经进入服务风险。
例子：一家专业服务公司用 AI 整理合同和客户会议记录。如果主要 AI 工具受地区限制，团队可能临时转用另一个平台，但 prompt、文件格式、访问权限和审批记录未必可以即时搬走。换工具不是登录另一个网站那么简单。
第一个检查：哪些工作已经依赖指定模型？
很多企业低估 AI 依赖，因为它不是传统系统上线项目。没有采购会议，没有 IT ticket，没有架构图，同事已经开始把 AI 放入日常工作。
可以先做一张简单清单：
流程 | AI 现在做什么 | 如果停用会怎样 | 风险等级
客服查询 | 分类、草拟回复、摘要投诉 | 回复变慢，但可人工处理 | 中
销售跟进 | 草拟邮件、整理 CRM notes | 跟进节奏下降 | 中
软件维护 | 生成 patch、review code、写测试 | 交付延迟，技术风险上升 | 高
网络安全 | 分析漏洞、整理修补建议 | patch 判断变慢 | 高
合规文件 | 摘要条文、初步分类 | 需要人工复核更多文件 | 中至高
这张表不用一开始很完美。重点是把“大家都用一点”变成可管理的运营资料。当管理层知道哪些流程受影响，才可以决定是否需要备援模型、内部工具或供应商承诺。
第二个检查：模型备援不等于随便多开一个账户
不少公司听到备援，就以为买多一个 AI 工具便可以。实际上，AI 备援要看三件事：输入资料、工作规则和输出写回。
客服例子：如果主模型负责读取 CRM 资料、订单状态和 WhatsApp 对话，再生成回复草稿，备援模型也要有同样资料权限、同样提示词规则、同样敏感资料遮罩和同样写回 CRM 的流程。否则一转工具，前线同事可能要人工复制资料，风险反而更高。
软件例子：如果 AI coding agent 连接 Git repository、issue tracker 和 CI/CD，备援方案不只是换一个聊天模型。公司要确定哪些 repo 可以被读取、是否只可在 feature branch 工作、测试结果如何保存、pull request 由谁审批。
模型备援的实际目标，不是保证完全一样快，而是确保关键工作不会因单一供应商限制而完全停顿。
第三个检查：审批和记录要留在公司系统
AI 供应商风险最容易失控的地方，是审批和记录留在供应商平台里。当平台政策改变、地区限制出现、账户被暂停或合同终止，公司可能失去重要上下文。
较稳妥的做法，是让 AI 产生建议，但关键决定留在公司自己的系统：
客户折扣和退款：在 CRM 或 ERP 批核
合同条款：在文件管理或审批系统确认版本
系统修改：在 issue tracker、pull request 和 CI/CD 留记录
网络安全修补：在资产清单和 patch ticket 留原因及日期
管理报表：在 BI 或数据仓库保留数据来源
例如物流公司用 AI 分析延误个案，AI 可以整理时间线和建议赔偿方案，但最后是否赔偿、赔多少、谁批准，应留在 ticket system。这样就算 AI 工具日后不能用，公司仍然知道每宗个案的决策理由。
第四个检查：采购 AI 时要问地区和政策风险
以前采购 SaaS，常问 uptime、资料加密、隐私条款和价格。采购 AI 工具时，还要加几条问题：
服务是否可能按地区、国籍、客户类型或使用场景限制？
如果某个模型停用，供应商会否自动降级到另一个模型？会否通知？
prompt、workflow、agent 设定和对话记录能否导出？
企业资料是否可选择不作训练用途？保留多久？
供应商能否提供服务变更、模型替换和安全事件通知机制？
合同有没有清楚写明资料删除、导出和终止后安排？
对香港中小企业来说，未必每个问题都可以得到完美答案。但只要供应商完全答不到，或者答案只停留在销售简报，公司就应把它视为风险，而不是等事故发生才补救。
第五个检查：先为三类工作建立 fallback
不是所有 AI 工作都需要同等级备援。较实际的做法，是先保护三类工作。
第一类是客户面向流程，例如客服、报价、预约、售后和投诉。这些流程停顿会直接影响收入和信任。即使 AI 停用，也要有手动处理模板、负责人和回复时限。
第二类是系统交付流程，例如 app 修改、网站表格、内部报表和 integrations。这些流程要保留人工开发、测试和上线路径，不要让团队完全依赖单一 coding agent。
第三类是风险和合规流程，例如漏洞分析、文件审查、供应商评估和 incident response。AI 可以加快整理，但判断和证据要留在人和公司系统手上。
一个简单的 AI 连续性架构
企业不一定要建立很复杂的平台，但至少要把 AI 放在工作流之中，而不是把工作流全部放入 AI 平台。
这个架构的重点是：AI 可以被替换，但公司流程、审批和记录不应被供应商锁住。当主模型不能用，备援模型或人工流程仍然可以接上；当供应商政策改变，公司仍然有自己的资料和决策记录。
30 日内可以先做的事
第一星期，盘点各部门正在使用的 AI 工具，包括个人账户和公司账户。不要只问 IT，客服、市场、销售、行政和开发团队都要问。
第二星期，选出三条最重要 AI 工作流，例如客服回复、软件维护、漏洞分析或合规文件摘要，写清楚主模型、输入资料、输出位置和审批人。
第三星期，为每条工作流设计 fallback：可以转用哪个模型？可以暂时人工处理吗？有哪些模板和系统记录必须保留？
第四星期，更新采购和供应商问题清单，把地区限制、模型替换、资料导出、保留政策和服务变更通知加入评估。
结语：AI 工具越重要，越要可替换
Fable 5 和 Mythos 5 的报道提醒企业一件事：AI 工具不只是功能选择，也受政策、合规和地缘政治影响。香港公司不需要因为一宗海外新闻就停止导入 AI，但需要停止把 AI 当成没有运营风险的普通工具。
下一步可以先问一个很直接的问题：如果明天公司最常用的 AI 模型停用，哪三个流程会最先受影响？这三个答案，就是 AI 风险管理的起点。
规划实施项目
从具体任务出发，确认可用数据、访问权限和人工审核要求，再评估 AI 的接入方式。