受监管行业的 AI 选型，已经不在 benchmark 层了

AI 落地 / 模型治理 / 反贩卖焦虑

一道治理闸门挡在 benchmark 记分牌前

这两天 AI 圈有个模型事件，特别适合拿给保险、银行、医疗这些受监管行业当教材。

6 月 9 日，Anthropic 发布 Claude Fable 5。按官方模型页，它是当时最强的广泛发布模型之一，1M 上下文，输入 / 输出价格是 10 / 50 美元每百万 token。

「要不要从 Opus 4.8 升上去？」 「新模型分数又高了，我们保险 / 银行系统该不该跟？」

但到了 6 月 12 日，这个问题已经不再是「该不该升级」。

Anthropic 发布官方声明：美国政府以国家安全为由发出出口管制指令，要求暂停任何外国国民访问 Fable 5 和 Mythos 5。Anthropic 表示，为确保合规，它必须突然为所有客户禁用这两个模型，其他 Anthropic 模型不受影响。

这件事最值得看的地方，不是「某个模型翻车了」。

我的判断是：它把受监管行业 AI 选型里最容易被忽略的那一层，直接拍到了桌面上。

你在比模型分数，而真正决定你能不能上、敢不敢上、上了还能不能稳定跑的东西，根本不在能力层。它在治理层——真实业务数据能不能离开境内受控环境、数据怎么留、厂商行为怎么变、外包商默认值会不会替你做选型、政策风险会不会直接拿走可用性。

先说结论：受监管行业的 AI 选型，真正的闸门不在 benchmark 层，而在它前面的 governance 层。能力当然还要比，但你得先过了治理这一关，才轮得到比分数。

第一个闸门：数据边界

Fable 5 在 6 月 12 日已经被禁用，所以它现在不是一个「升级建议」，而是一个很好的案例。

它发布时最容易被忽略的一条约束是：这类 Mythos-class / Covered Model 需要 30 天数据留存。Claude Help Center 的口径很清楚：提交给这些模型的 prompts 和 outputs 会为 trust and safety 目的保留 30 天；这个要求影响的是已经配置了零数据留存（ZDR）的组织、Claude Enterprise 里的 ZDR 场景，以及通过 AWS / Google / Microsoft 等平台使用 ZDR 的场景。

翻译成人话：对于「必须零留存」的那一类数据，那个当时最强的模型，本来就不能直接按原来的 ZDR 方式接入。

但这里不能反过来推中国保险业。

在中国保险公司的生产语境里，真实客户、保单、理赔、核保、交易和健康相关数据，第一问不是「能不能接受 30 天留存」，而是「这条数据有没有资格进入境外模型链路」。答案通常应该先按「没有」处理。国家网信办的数据出境规则保留了安全评估、标准合同、个人信息保护认证等合规路径，并不等于所有数据在法律上永远绝对不能出境；但对保险 AI 生产系统来说，把真实业务数据发给境外 SaaS 或境外模型 API，不应被写成一个普通架构选项。

所以 Fable 5 在这里的意义不是让你判断「要不要接受留存」。它真正提醒的是：即使在海外企业语境里，最强模型也会被留存、安全监控和访问政策约束；放到中国保险业，这道闸门还要再往前移一层——先判断数据边界和部署形态。

反常识一：「最强模型」不等于「你该上的模型」。对中国保险业，第一道关不在 benchmark，甚至不在「厂商留存多久」，而在数据边界。凡是包含真实客户、保单、理赔、核保、交易和健康相关信息的数据，默认不进入境外模型 API。

只有公开材料、合成数据、不可逆脱敏样本、非生产研发数据，或已经走完合规出境路径的数据，才轮得到继续讨论模型能力和留存策略。

这里真正该做的是流量分层，但分层顺序要改：先分「真实监管业务数据 / 非真实或可公开数据」，再分「境内私有化、境内专有云、境内合规模型服务、境外模型服务」，最后才分「留存策略」。真实保险业务数据要留在境内受控链路里，用境内模型、私有化部署、专有云或经过合规审查的服务形态承接。这是 Harness 设计，不是事后补丁。没有这层数据边界，贸然升级就是在制造合规暴露。

第二个闸门：厂商行为和可用性漂移

Fable 5 事件还有第二层。

发布后不久，围绕 Fable 5 系统卡里「前沿 LLM 开发请求」的限制，社区出现了争议。媒体报道和公开讨论显示，部分安全措施一开始并不对用户可见。随后 Anthropic 改口，把相关处理改成可见 fallback 到 Opus 4.8，并承认一开始的权衡没有做好。

这段事实很容易被写成标题党，但那样反而会把真正的问题写丢。

我不想把它写成「厂商在背后使坏」。这不是一篇情绪文。更准确的说法是：任何托管模型的行为，都会随着安全策略、版本更新、政策要求和商业边界变化而变化。差别只在于，这种变化是清楚告诉你、可审计、可回滚，还是你生产系统出了问题才发现。

6 月 12 日的禁用声明把这个问题又放大了一层：有些变化甚至不只是模型厂商自己决定的。出口管制、国家安全、区域访问、供应商政策，都可能直接改变你可用的模型集合。

反常识二：对架构师来说，这不是「Anthropic 好不好」的问题，而是工程问题。正确的问题是：如果某个托管模型在关键请求上改变了行为，或者某个模型突然不可用，你的系统能不能检测到、降级、切走？

这跟幻觉不一样。幻觉是随机错误，你可以用 eval 抓。而行为和可用性漂移，是你依赖的外部组件发生了变化。很多企业的 Harness 里有输出质量监测，有敏感词，有合规模板，但没有一层「行为一致性 + 可用性回归」。

做法不复杂：挑一组你业务里最关键的请求做 golden set，周期性跑，尤其在厂商版本更新、政策变更、模型访问状态变化后跑。跨版本 diff，质量掉了告警；模型不可用，自动切到经批准的替代模型；切换后的输出再进同一套审计和人审流程。

第三个闸门：外包商默认值

前两条是模型本身。这一条更隐蔽：很多时候，替你做选型的根本不是你。

把最近几条已核到的一手信息摆在一起看：

2026-06-11　DXC × Anthropic：多年期全球联盟，官方新闻稿称 Claude 会进入 DXC 为银行、保险、政府等客户运营的系统。

2026-06-12　TCS × Anthropic：TCS 将 Claude 提供给 56 个国家的 50,000 名员工，并面向金融服务、医疗、公共部门等受监管行业做产品。

DXC 那条新闻稿说，DXC 会培训数万名 Claude-certified FDE，把 Claude 带进它为大型银行、航空、保险、制造和政府机构运营的系统。新闻稿还说，DXC OASIS 这个 AI-native 运维编排平台 2026 年 4 月推出，Claude 是默认基础模型之一，OASIS 已服务 50 多个 DXC 客户。

这些数字我得标清楚：它们是新闻稿里的厂商口径，不是第三方独立核验。比如「50 多个客户」跑了多久、深度如何、生产占比多少，我们从新闻稿里看不出来。该当营销口径看，不要当成审计事实。

TCS 那条也很典型：官方新闻稿说 TCS 会把 Claude 提供给 56 个国家的 50,000 名员工，并面向金融服务、医疗、公共部门等受监管行业做 Claude-powered 产品。它还提到 Diligenta，也就是 TCS 在英国的寿险和养老金业务，会用 Claude 改善超过 2,200 万保单持有人的客户体验。

这些案例放在一起，结构含义比单个数字更重要：许多大型保险公司、银行的核心系统，本来就由 DXC、TCS、Infosys、Accenture 这类外包商或系统集成商长期托管运维。当这些外包商先和某个 LLM 厂商绑定、培训队伍、沉淀工具链、把默认模型嵌进自己的交付平台，甲方的 AI 选型就很容易被「默认方案」牵着走。

反常识三：业界讲 AI + 保险 / 金融，默认假设「企业自主选型 AI 工具」。但现实里，当你核心系统的运维方先押注了某一家，基础设施层的 AI 选型重心，就可能从甲方挪向乙方。

这里也要讲句公道话：联盟不等于锁定。保司完全可以在外包合同里写明 vendor neutrality，保留多模型与切换权；把核心系统交给某家外包商托管，本来也是企业自己的选择。真正该警惕的不是「被锁定」这个词，而是没人在合同里提前写清楚切换权。等想换的时候，才发现成本已经高到换不动。

三个变量，收成一个判断

三个治理变量汇成一道前置闸门，闸门之后才是 benchmark

数据边界、厂商行为、可用性漂移、外包默认值——这些东西都发生在 benchmark 之前。能力再强，过不了这些治理变量，也落不了地，或者落地后爆雷。

监管背景：别赌日期，先补治理

EU AI Act 正式文本里，多数规则从 2026 年 8 月 2 日起适用，Article 6(1) 及其对应义务从 2027 年 8 月 2 日起适用。Annex III 也明确把「用于自然人的寿险和健康险风险评估与定价」列为高风险 AI 系统。

这里我特意不把网上流传的「延期到 2027 / 2028」说法写成确定事实。发文前只按正式法规文本说。等延期有正式文本，再更新判断。

对架构师来说，关键不是赌哪一天生效。关键是方向已经很清楚：寿险、健康险、信贷、公共服务、医疗这些场景里的 AI，会越来越多被放进可审计、可解释、可追溯、可问责的框架里。现在不把治理层的选型纪律建起来，到生效日就是被动改造。

给架构师的治理层选型三问

治理层选型三问 checklist

下次再有人问你「上不上最强模型」，别先看分数。按这三问过一遍：

第一问 · 数据：这个 workload 是否包含真实客户、保单、理赔、核保、交易或健康相关数据？如果包含，先排除境外模型 API，进入境内私有化 / 专有云 / 本地化 / 已审查合规服务链路；如果不包含，才继续看厂商留存政策。

第二问 · 行为可监测：能检测到模型在关键请求上的质量漂移、策略变化和可用性变化吗？不能，就先补响应一致性基线监测和降级路径。

第三问 · 自主权：模型选型是自己定的，还是被外包商 / 合作网络的默认值牵着走？合同里有没有 vendor neutrality、多模型接入和切换权？

三问全过，再去比 benchmark。三问里有一问过不了，那个最强模型对你就不存在。

几个冷静的提醒

一，别被「最强」「刷新 SOTA」推着升级。对受监管行业，能力提升经常是噪音，治理约束才是信号。一个真实业务数据不能进入其链路、不能监测其行为、不能保证可用性、还不是你自己真正选的模型，benchmark 再高也跟生产系统无关。

二，别把厂商透明度当成你的监控方案。厂商可以很透明，也可能来不及透明；政策变化甚至可能让它自己也被动。你的生产系统要有自己的 golden set、回归评测和降级路径。

三，警惕「外包商帮你把 AI 都搞定了」的省心叙事。省心的代价，可能是你交出了基础设施层最关键的选择权。省下来的力气，迟早会在 vendor lock-in 上加倍还。

今天就做的一件事

不用改架构，不用换模型。

打开你正在用、或者正打算上的那个大模型方案，先查两件事：真实客户、保单、理赔、核保数据有没有离开境内受控环境？推理日志、prompt、文件附件、人工支持和故障排查链路有没有出境？

这两件事过了，再查第三件：它对你这类数据默认留存多久？支不支持零留存？如果模型突然不可用，你批准过的 fallback 是谁？

然后问自己一句：这几条，我们立项时有人确认过吗？

如果答案是「没有」，那你刚刚摸到了受监管行业 AI 选型真正的第一道关。它从来不在 benchmark 那一页。

在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。

关注「模型之外的事」

进入一个带你解读 AI 落地、模型治理与产业真实约束的频道。

点击文章顶部账号名，关注公众号

不追热点，只拆能不能落地、哪里会卡、该怎么选。

© THE END