你的AI供应商风险评估有个盲区,华盛顿一纸禁令把它捅穿了
美国防部将Anthropic认定为供应链风险,总统令限六个月内让联邦机构停用Claude。这类资质认定机制英国早已运作多年,而你的采购流程从未为它定价。
新加坡一家软件公司持有ISO 27001认证,通过政府数字化转型项目拿到合约,合同条款要求它为自身供应商的网络安全风险负责;它调用Claude的方式是通过Amazon Bedrock,原因很简单,云团队当年批准的就是这条通道。公司的AI供应商风险评估表覆盖能力、价格、安全态势与偿付能力,每一栏都是绿灯。这几栏谁都看不见华盛顿刚刚发生的事,而这家公司离冲击波比自己以为的要近得多。
把已确认的事实和仍在传闻阶段的报道分开,因为两者的传播速度完全不同。已确认、有据可查的是:2026年8月,美国防部将Anthropic及其产品认定为供应链风险,即刻生效,根据一项总统令,联邦机构,不只是军方,所有机构,必须在六个月内逐步淘汰Claude。同样已确认的是,被切断的合约规模上限为2亿美元,这是一个合约上限,而非已经到账的资金。仍属报道阶段、目前只靠一家媒体信源支撑的是:《华尔街日报》报道称(Anthropic未予证实),在缉捕尼古拉斯·马杜罗的行动中,美方通过Anthropic与Palantir的合作使用了Claude。整个事件里,没有任何一处公开指控代码被植入后门或遭到污染。如果《华尔街日报》的报道属实,那么一家深度嵌入客户最敏感任务的供应商,仅仅因为一场关于使用条款的争议,就被拉入了风险名单。
围绕这件事的许多细节,谁拒绝了谁、谁向谁通了气,仍有争议,难以厘清。但对美国以外的所有人来说,真正重要的不是这场争吵,而是背后那套认定机制,因为英国已经把类似的机制运作了好几年。
Anthropic被拉黑,只是个例吗?
把美国防部这次行动当作一个数据点来看,因为真正值得关注的是趋势本身。英国把华为清出本国网络,靠的不是劝说,而是立法:《2021年电信(安全)法》授权大臣发布“指定供应商指令”,强制运营商把点名的供应商设备从网络中拆除。《2023年采购法》则赋予大臣一份中央除名名单的权力,凡是因“强制排除”条款被列入名单的供应商,采购机构必须将其挡在适用的公共合约之外。而美国《第889条》则展示了“污点”能传多远:根据该规则的B部分,只要一家企业在其任何业务环节中使用了受管制的中国电信设备(华为、中兴等被点名企业),美国政府机构就不得与其签约,不论这些设备是否触及政府相关业务本身。资质认定不是美国的一时兴起,而是两套法律体系里都在运转的活机制,而在这个月之前,它点名的对象一直是外国企业。
把两类问题分开看。眼下被强制规定的范围很窄:美国联邦机构停止使用Claude。目前没有任何公开规定强迫某个承包商、云平台或海外客户做任何事。至于连锁反应,资质流转条款、审计问题、客户悄悄开始降低风险敞口,这些都还只是推测。但这类推测是有先例的推测,因为《第889条》已经把这种“污点”写成了一整套合规制度,触角伸向任何想向美国政府销售产品的公司,而声誉层面的审查往往比立法跑得更快。正确的姿态既不是恐慌,也不是无视,而是把它定价。
更值得注意的是,当“认定”标签从针对外国对手转向一场美国国内的商业纠纷时,发生了什么变化。供应链风险这套理论最初的逻辑是:敌对国家可以胁迫本国供应商,所以代码本身可能背叛你。这一次,没有人提出这样的理论。这次被管理的风险性质似乎完全不同:不是“这家软件可能被动过手脚”,而是“这家公司可能会说不”。如果资质认定可以因为不听话而触发,而不是因为发现了缺陷,它就不再是一项安全管控措施,而变成了一张谈判筹码,而每一个大买家,不论公营还是私营,现在都亲眼看到了这一步棋是怎么走的。
认定风险会如何传导到美国以外的企业?
大多数情况下,通过合约传导。路径一是美国路径:如果你身处美国联邦承包商的供应链任何一环,禁令会以“资质流转条款”和年度合规声明的形式抵达你手上;一个针对AI供应商、类似《第889条》“你的业务里是否在任何地方使用这家供应商”的问题,足以把海外分包商的模型技术栈也纳入审查范围,因为B部分对电信设备已经是这么运作的了。路径二是各国自己的本土机制,管道往往早就铺好了。以英国为例,DEFCON 658条款要求处理国防相关信息的供应商评估自身分包合约中的网络风险,并把要求的管控措施逐级下沉到供应链;英国国家网络安全中心(NCSC)的供应链安全指南要求每一个认真的采购方审查“供应商的供应商”;Cyber Essentials认证更是许多政府合约的标配门槛。这些机制目前都还没有点名任何一家AI供应商,它们之所以重要,是因为一旦“认定”真的发生,它就会顺着这些既有管道传导:如果某个监管机构把一家AI供应商列入除名名单,适用的采购项目就必须强制排除它,而这个问题会通过上述条款一路传到分包商手上。路径三才是任何供应商台账都看不见的那条:许多企业根本不是直接向Anthropic采购Claude,而是通过Amazon Bedrock或Google Vertex AI调用。你的合约对象是平台,第三方模型按平台自己的节奏在目录里上架和下架,一项针对模型开发商的认定,会以你从未协商过的目录变更形式抵达你这里,而被认定的那个名字,压根不会出现在你的供应商登记册上。
AI供应商风险评估该如何纳入认定风险?
先承认这个尴尬的事实。常规尽职调查打分的是能力、价格、安全态势与偿付能力。资质认定风险不落在任何一栏里,而且它恰恰集中在这些指标表现最好的供应商身上,因为最容易被卷入政治性拉黑名单的,正是那些规模最大、与政府关系最深的头部实验室。你的评估框架不仅看不见这个风险,它还在把你推向这个风险。
然后,像财务主管为制裁敞口定价那样为它定价:低概率、高严重性、绝不能忽略。四个问题能解决大部分问题。集中度:这家供应商有多依赖有能力认定它的强势客户?你又有多依赖这家供应商?利益冲突:供应商公开宣称的政策,和它最大客户的野心,是不是正朝着彼此相撞的方向走?波及范围:如果认定明天就落地,你的哪些合约、认证、资质流转条款会把这个“污点”传导到你身上,包括那些你早就忘记还嵌在链条里的分销商?切换耗时:不是PPT上那个乐观的迁移预估,而是包含评估、安全审查、以及重新培训相关人员在内的诚实数字。
这些答案会直接指向可以采取的行动。让提示词、评测集和数据管道保持可迁移,退出通道要时刻保持顺滑。对那些一旦六个月停摆就会真正伤筋动骨的工作流,做好双供应商备份。集成程度越深,越要谨慎:换掉一个聊天机器人,以天计;换掉一个深度嵌入核心系统的智能体,以月计,这正是我们主张从第一天起就设计可替换模型的安全智能体系统的原因。这些大多是动笔写第一行集成代码之前就该打好的地基,与我们在动工前先备好AI就绪度中提出的纪律是同一套逻辑,只是把它再往供应链上游延伸了一层。
“红线”靠不住
有一种诱人的反制策略:挑一家宣称原则与你自己价值观相符的供应商,理由是“讲原则的供应商不会给你意外”。但这次事件恰恰说明相反的道理。剥开那些有争议的细节,只剩两种可能:要么这家供应商声称的底线在商业压力下弯曲了,要么它为了守住底线,付出了失去旗舰级政府关系的代价。不管走哪条分支,买家学到的教训是一样的:供应商公开的红线,是它谈判时的筹码,不是给客户的保证书,而且在你签完合约之后,它完全可以朝任何一个方向移动。
什么会让我改变看法?如果认定很快被撤销,一年内没有第二家、第三家跟进,大西洋两岸都没有再出现AI供应商被列入除名名单或指定供应商名单,那么以上这些就只是一场风波,前面这些论证就是过度反应。但在下这个赌注之前,先看清这道不对称的风险结构。把认定风险写进你的技术战略,成本不过是尽职调查里多问几个问题,再加上一些你本来就该做的架构卫生工作。而身处拉黑名单下游的代价,是被迫按别人的时间表仓促迁移。当下行风险如此不对称时,一个已经发生的案例就足够了。而我们已经有了一个,时间是2026年8月,法律条文告诉我们,这种事完全可以规模化重演。
常见问题
政府的供应链风险认定,会波及只是在使用该供应商产品的其他企业吗?
只有在法律工具真正触及你时,才会直接波及:美国机构必须停用Claude,而《第889条》证明华盛顿有能力禁止那些“在业务任何环节使用受管制供应商”的承包商。除此之外,压力主要来自合约与声誉层面:资质流转条款、认证续期,以及你的客户自己的供应商审查,而这些往往比任何一部法律跑得都快。
第三方AI风险管理除了安全和价格,还应该覆盖什么?
大多数框架都漏掉了三件事:集中度(有多少关键工作流依赖单一模型供应商)、可迁移性(切换所需的真实时间与成本,包括重新评估和再培训)、以及政治敞口(这家供应商有多依赖那些有能力拉黑它的客户)。这三项应该按工作流逐一打分,而不是按供应商笼统打分。
使用开源权重模型能不能消除认定风险?
能消除一部分敞口,因为没有人能关掉你自己托管的模型权重,但也会带来新的敞口:你要接手供应商原本承担的补丁、评测和合规工作,而你技术栈里的托管方或工具供应商,依然可能被列入认定名单。这是一种权衡,不是一种豁免。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。