遭“美国政府封杀”后,Anthropic正式提起诉讼!

遭“美国政府封杀”后,Anthropic正式提起诉讼!

整理 | 苏宓

出品 | ZEEKLOG(ID:ZEEKLOGnews)

据路透社报道,当地时间周一,AI 初创公司 Anthropic 正式对美国国防部及特朗普政府提起诉讼,抗议五角大楼将其列为“国家安全供应链风险”主体的决定。

Anthropic 在向美国加州北区地方法院提交的诉讼文件中表示,这一认定“史无前例且非法”,已对公司造成“不可挽回的损害”。公司希望法院撤销该决定,并指示联邦机构停止执行相关认定。

划定 AI 应用红线,双方观点不一

正如我们此前报道,这场争端的核心在于 Anthropic 为其核心 AI 模型 Claude 设定的两条技术使用红线,与美国国防部的使用需求发生根本冲突。

此前,Anthropic 曾与五角大楼签署一份价值最高可达 2 亿美元的合作合同,Claude 也成为少数被纳入美国机密网络环境进行测试的 AI 系统之一。

对此,Anthropic 一直坚持两条底线:

  • Claude 等技术不得被用于对美国民众的大规模国内监控;
  • 不得用于全自主武器系统的作战决策。

而美国国防部认为,一旦政府采购相关技术,其有权在“任何合法用途”中使用,不应受到私营企业设置的技术限制。

2026 年 2 月下旬,五角大楼向 Anthropic 发出最后通牒,要求其在指定期限内取消上述使用限制,否则将被列为“供应链风险”。

Anthropic 首席执行官达里奥·阿莫代伊明确拒绝了这一要求。他表示,公司“无法昧着良心允许五角大楼无限制使用其 AI 模型”,并指出当前前沿 AI 系统的可靠性尚不足以支撑全自主武器等高风险应用,这类使用可能将作战人员和平民同时置于危险之中。

最终,2026 年 2 月 27 日,特朗普发布声明,要求全美所有联邦机构立即停止使用 Anthropic 的相关技术。随后,五角大楼正式将 Anthropic 列入“供应链风险”名单。

3 月 4 日,Anthropic 发文确认已收到美国国防部通知,认定其为对国家安全的供应链风险。

事态升级,Anthropic 起诉

在被列入“供应链风险”后,Anthropic 并未妥协。3 月 9 日,Anthropic 正式向美国国防部及其他联邦机构提起诉讼,指控这一认定缺乏法律依据。

起诉书指出:“Anthropic 与联邦政府签署的合同已经开始被取消。与私营部门的当前及未来合同也面临不确定性,短期内可能危及数亿美元的收入。除了直接的经济损失,Anthropic 的声誉及受宪法《第一修正案》保护的核心自由也正遭受攻击。如果没有司法救济,这些损害在未来数周乃至数月内只会进一步加剧。”

业界的声援

Anthropic 的起诉迅速得到行业回应。提交诉讼数小时后,包括 OpenAI 和谷歌 DeepMind 超过 30 名员工的联名支持声明出现在法院案卷中,其中包括谷歌 DeepMind 首席科学家 Jeff Dean。

声明指出,如果五角大楼对合同条款不满意,本可以“直接取消合同,并购买另一家领先 AI 公司服务”,无需对 Anthropic 施加惩罚性限制。

事实上,彼时在 Anthropic 被列入黑名单数小时后,OpenAI 首席执行官 Sam Altman 宣布 OpenAI 已与美国国防部达成合作,并在 X 平台表示,该机构“对安全高度重视,并希望通过合作实现最佳结果”。此举引发部分 OpenAI 员工抗议。

本次 OpenAI 和 Google 员工的联名声明进一步指出:“如果这一针对美国领先 AI 公司的惩罚性措施继续推进,无疑将影响美国在 AI 及相关领域的产业和科研竞争力,同时也会对本领域围绕 AI 风险与收益的公开讨论产生寒蝉效应。”

其提交的文件还强调,Anthropic 所设红线属于合理安全关切,必须以强有力的防护措施加以保障。在尚无明确公共法律规范 AI 使用的情况下,开发者通过合同条款和技术手段设定的限制,是防止灾难性滥用的重要安全保障。

许多签署声明的员工在过去几周也参与联名公开信,呼吁美国国防部撤回标签,并敦促公司领导层公开支持 Anthropic,拒绝单方面允许其 AI 系统被使用。

最后

目前,Anthropic 与美国国防部的诉讼尚未进入审理阶段,这场政企之间的对抗不仅关乎一家企业的商业利益,更将为全球 AI 技术的军事应用划定边界提供重要参考。

不过对于目前这种状况,Wedbush 分析师 Dan Ives 表示:“未来几个月,这可能对 Anthropic 和 Claude 在企业领域产生连锁反应,一些企业可能会暂停 Claude 的部署,直到法院做出裁决。”

Anthropic 财务主管 Krishna Rao 也在提交法院的文件中指出,政府的行动可能导致公司 2026 年收入减少数亿美元甚至数十亿美元。

参考:

https://www.anthropic.com/news/where-stand-department-war

https://techcrunch.com/2026/03/09/openai-and-google-employees-rush-to-anthropics-defense-in-dod-lawsuit/

https://www.reuters.com/world/anthropic-sues-block-pentagon-blacklisting-over-ai-use-restrictions-2026-03-09/

推荐阅读:

一天开13个会、一个Bug要修200天!前亚马逊L7爆料:这轮大裁员,AI只是“背锅侠”

48小时“烧光”56万!三人创业团队濒临破产,仅因Gemini API密钥被盗:“AI账单远超我们的银行余额”

全球26w+用户在线「养虾」:OpenClaw这一波泼天流量,到底让谁接住了?

未来没有前后端,只有 AI Agent 工程师。

这场十倍速的变革已至,你的下一步在哪?

4 月 17-18 日,由 ZEEKLOG 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开,大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题,为你绘制通往未来的认知地图。

成为时代的见证者,更要成为时代的先行者。

奇点智能技术大会上海站,我们不见不散!

Read more

Spring MVC请求处理流程源码分析与DispatcherServlet核心逻辑

Spring MVC请求处理流程源码分析与DispatcherServlet核心逻辑

目录 🎯 先说说我遇到过的真实问题 ✨ 摘要 1. 从Tomcat到DispatcherServlet:请求的"奇幻漂流" 1.1 请求是怎么到你Controller的? 1.2 DispatcherServlet的初始化:不是你想的那样简单 2. 请求处理九大步:DispatcherServlet的"工作流程" 2.1 doDispatch方法:Spring MVC的心脏 2.2 九步流程详解:每个步骤都有坑 🚨 步骤1:Multipart检查 🚨 步骤2:获取Handler 3. HandlerMapping:请求的"导航系统" 3.1 四种HandlerMapping的区别 3.2 RequestMappingHandlerMapping的匹配算法 3.3 路径匹配的性能优化

By Ne0inhk
数字身份的通行证:深入解析单点登录(SSO)的架构与艺术

数字身份的通行证:深入解析单点登录(SSO)的架构与艺术

文章目录 * 概述 * 一、什么是单点登录(SSO)? * 二、SSO 的核心价值:为何它如此重要? * 三、SSO 的基本工作原理:一次认证,处处通行 * 场景一:首次登录应用 A * 场景二:访问应用 B(无感登录) * 四、SSO 的通用语言:常见协议与标准 * 五、SSO 架构的两种主流形态 * 1. **中心化 SSO** * 2. **联邦身份** * 六、安全:SSO 的生命线 * 七、典型应用场景:SSO 在哪里发光? * 八、快速上手:从理论到实践 * 九、常见误区澄清 * 总结 概述 在数字世界日益碎片化的今天,我们每个人都在无数应用和服务之间穿梭,

By Ne0inhk
Rust异步编程实战:构建高性能网络应用

Rust异步编程实战:构建高性能网络应用

Rust异步编程实战:构建高性能网络应用 一、异步编程概述 1.1 同步vs异步的区别 💡在传统的同步编程中,代码按照顺序执行,每个操作必须等待前一个完成才能继续。例如,发送网络请求时,主线程会阻塞直到响应返回,这种方式简单直观,但在高并发场景下效率低下,因为大量线程会因阻塞而闲置。 异步编程则允许代码在等待操作完成时继续执行其他任务。当一个异步操作开始后,程序会立即返回并继续处理下一个任务,直到该操作完成后通过回调或事件通知继续执行后续代码。这种方式显著提高了CPU利用率和系统的并发处理能力。 1.2 Rust异步编程的演进 Rust的异步编程经历了几个重要阶段: * 早期阶段:依赖futures库提供基础的Future和Executor支持,但语法冗长且难以使用。 * 2018 Edition:引入了async/await语法糖的实验版本,简化了异步代码的编写。 * 2021 Edition:async/await正式稳定,成为Rust异步编程的标准范式。 * 生态成熟:Tokio、async-std等异步运行时库的发展,以及大量异步IO库的出现,使Rus

By Ne0inhk

Flutter 三方库 inject_annotation 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、严谨的编译期依赖注入架构实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 inject_annotation 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、严谨的编译期依赖注入架构实战 在鸿蒙(OpenHarmony)系统开发大型、复杂的企业级应用时,如何优雅地解耦各个业务模块?传统的构造函数注入往往会导致代码冗长且难以维护。inject_annotation 为鸿蒙开发者提供了一套基于编译期生成的、零反射的依赖注入(Dependency Injection)方案。本文将带您深入实战其在鸿蒙生态中的应用。 前言 什么是依赖注入?它是一种控制反转(IoC)的实现方式,旨在将对象的创建与使用分离。与运行时反射注入不同,inject_annotation 借鉴了 Java 端 Dagger 的设计思想,在编译阶段就生成了所有的注入代码。在注重性能和确定性的鸿蒙系统开发中,这种“预编译”的 DI 方案能大幅降低运行期开销,并显著提升代码的健壮性。 一、

By Ne0inhk