主权人工智能：模型、数据、基础设施与依赖关系的控制

主权人工智能是指一个国家、公共机构、组织或其他明确权威机构对其所依赖的人工智能系统保持有效控制的能力：包括其数据、模型、基础设施、软件栈、运营者、法律风险敞口和战略依赖。主权并不等同于将数据托管在一个国家、运行一个开放模型、使用欧盟云服务提供商或将服务器与互联网断开连接。这些做法可以支持主权，但决定性的问题是：该组织能否在不对某个外部行为者产生不可接受的依赖的情况下，做出、执行并维持关键的人工智能决策。

主权人工智能的真正含义

主权从根本上讲是依赖关系下的决策权。一个组织可能在技术上拥有其数据，但仍然依赖某个控制模型访问、定价、身份、加密密钥、软件更新或唯一可用推理端点的供应商。

因此，主权架构要问的是：哪些依赖是可以接受的，哪些必须保持可替代性，哪些能力必须直接控制。

欧盟委员会当前的技术主权定义很有用，因为它结合了两个理念：开发/控制关键技术，以及减少外部依赖。这比将主权视为简单的地理托管更接近工程现实。

最简单的例子

考虑两家公司，它们都将客户文档存储在德国。

公司 A 将每个提示和文档发送到一个专有云模型。模型版本可能变化，供应商控制推理服务和密钥，而应用程序没有经过测试的备用方案。

公司 B 也使用云模型，但将其数据和检索层置于自己的控制之下，可以路由到本地托管的开放权重模型，拥有应用程序密钥和身份，记录供应商/模型依赖关系，并拥有经过测试的迁移路径。

两者都可能满足数据位置要求。公司 B 拥有实质上更多的主权，因为如果外部供应商变得不可用或不可接受，它保留了更多有意义的选择。

实用的主权评估

1

1. 定义权威主体

明确谁的主权重要：组织、公共行政部门、国家、欧盟、业务部门或受监管环境。

2

2. 识别关键人工智能能力

列出模型、推理、检索、数据、工具、身份、存储和运营服务。

3

3. 映射依赖关系

对于每项能力，识别供应商、司法管辖区、所有权、许可、更新路径和技术锁定。

4

4. 分类控制程度

确定哪些是直接控制、合同控制、可替代或实际上属于外部控制。

5

5. 识别不可接受的依赖

找出可能阻碍连续性、暴露受保护数据或消除战略选择的依赖。

6

6. 增加替代方案或更强的所有权

在合理的情况下，使用开放标准、本地模型、可移植数据、内部密钥、多供应商路由或主权基础设施。

7

7. 测试退出和连续性

证明组织能够在所定义的主权要求下迁移、故障转移或继续关键运营。

8

8. 随时间重新评估

供应商所有权、法律、模型许可、基础设施和地缘政治条件都可能发生变化。

简单例子止步之处

在国家或欧盟层面，主权人工智能所包含的远不止一个企业部署：半导体供应、高性能计算、研究能力、人才、数据集、云基础设施、模型开发和产业生态系统。

在企业规模下，同一概念会变得更窄：组织自身必须控制或能够替换哪些AI依赖项？

架构应始终说明主权主体和范围。不说明对谁主权、对什么主权以及针对哪种依赖的“主权AI”，对工程而言过于模糊。

当前欧洲技术主权框架

欧盟委员会目前将技术主权定义为欧洲在数字世界中独立行动的能力，即通过开发和掌控关键技术、数据和基础设施，同时减少对非欧盟供应商的依赖。

2026年技术主权一揽子计划明确覆盖从芯片到基础设施、软件、云和AI的整个价值链。这很重要，因为AI系统可能在模型层以下存在依赖：加速器、虚拟机监控程序、容器平台、云控制平面或专有库都可能成为战略依赖。

欧盟委员会还在利用AI工厂和AI超级工厂扩大欧洲算力。当前AI超级工厂政策描述的是在欧洲建设和运营的基础设施，以增强韧性、战略自主权以及在欧洲基础设施上开发先进AI的能力。

CADA将主权变为分级保证问题

拟议的CADA框架在概念上尤其有用，因为它拒绝二元主权标签。它将主权视为在位置、法律/公司控制和供应链控制方面不断提高的保证。

它也是拟议的欧盟监管/采购框架，而非通用的全球技术标准。不应在不理解实际风险模型的情况下，将这四个级别机械地照搬到私有架构中。

主权AI的主要控制维度

数据主权必要但不充分

数据主权涉及根据适用法律、组织权限和政策对数据的控制。位置可能很重要，但控制还包括加密、访问、保留、复用、训练权和删除。

如果外部模型提供商在合同上被允许保留提示或基于提示进行训练，其主权风险不同于在更严格限制下临时处理数据的提供商——即使两者的端点位于同一地区。

RAG会增加派生工件，如分块、嵌入、索引和缓存答案。主权数据控制应包括这些派生数据，而不仅是原始文档。

模型主权关乎控制和可替代性

专有API模型可能极其强大，但对权重、训练过程、模型退役或未来定价的控制却十分有限。

开放权重模型可以提供更多的运营控制，因为权重可以独立托管，但具体的许可证、分词器、训练来源、架构、微调权利和运行时要求仍然很重要。

因此，模型主权并不等同于“开放模型”。相关问题是，在所需的法律和技术条件下，哪些模型工件可以被拥有、修改、评估、部署和替换。

开源是主权工具，而非主权本身

欧盟开源战略明确将开源与更多控制、更少锁定、更强安全性和可复用数字构建块联系起来。

开源可以减少依赖，因为源代码可以由替代供应商检查、修改和运营。开放标准也可以降低迁移成本。

但是，仅在一个不可替代的云控制平面上运行的开源软件仍然可能留下重大依赖。同样，在无法独立采购、支持或运营的硬件上运行开放模型权重，可能只能提供部分主权。

基础设施主权深入到云区域之下

“托管在欧洲”这一说法并未完全描述基础设施控制。相关问题包括公司所有权、管理访问权限、密钥控制、法律管辖权、支持人员、软件供应链，以及如果外国母公司或供应商改变条款，服务能否继续。

当前拟议的CADA级别正是做出了这种区分：欧盟数据位置是比第三国独立性、欧盟所有权/控制或完整软件供应链控制更低的保证级别。

对于某些工作负载，公共云仍可能与所需的主权级别一致；对于其他工作负载，可能需要自运营基础设施或特殊治理的云安排。

计算主权是容量加控制

AI系统严重依赖加速器和大规模计算。如果一个组织拥有模型和数据，但没有可接受的计算路径，实际主权仍然可能失败。

欧盟的AI工厂/超级工厂投资明确旨在增加欧洲AI计算能力和战略自主权。这表明计算本身被视为一个主权层，而不仅仅是采购细节。

在企业规模上，等价的问题是，在提供商中断、配额限制、价格冲击或政策变化的情况下，关键推理工作负载能否继续。

硬件和半导体依赖仍然存在

即使是自托管AI，通常也依赖于全球采购的GPU、CPU、内存、网络设备、驱动程序和固件。

因此，主权很少意味着完全的硬件独立。更现实的控制包括供应链可见性、库存/维护策略、第二来源选项、可互操作的运行时，以及避免与特定硬件的应用合同产生不必要的耦合。

欧洲技术主权一揽子计划明确包含半导体政策，因为底层硬件依赖可能会制约整个人工智能技术栈。

软件栈主权

在硬件与应用之间，存在着驱动程序、操作系统、容器运行时、推理引擎、数据库、向量存储、编排框架和可观测性工具。

主权评估应确定这些组件中哪些可以在不重新设计业务应用的情况下被替换。

开放接口在这些边界处尤其有价值，因为它们降低了更换某一依赖项而无需替换整个系统的成本。

提供商抽象是一种主权机制

提供商抽象可防止应用逻辑与某一模型供应商的API、认证流程或消息格式变得不可分割。

抽象并不会使模型变得等同。不同模型具有不同的上下文窗口、工具语义、安全行为、延迟和质量。因此，面向主权的路由需要明确的能力测试和回归测试。

目标是实现可信的退出，而不是假装每个提供商都可以互换。

多模型路由可以降低战略依赖

一个能够在本地模型、区域提供商和前沿云模型之间路由合适任务的平台，比硬编码到单一端点的平台拥有更多选择。

策略可以决定敏感数据保留在本地或主权基础设施上，而已批准的低风险任务可以使用外部前沿模型。

这种混合设计可以提高主权，而无需每个工作负载都使用相同的本地托管模型。

身份和加密密钥控制是主权层

一个应用可以拥有自己的服务器，却依赖一个可以暂停访问的外部身份提供商，或依赖一个受另一司法管辖区控制的密钥管理服务。

因此，关键主权评估应包括IAM、PKI、HSM/KMS控制、服务凭证和管理账户。

“客户管理密钥”可以改善控制，但确切的密钥保管和服务架构很重要。仅凭一个标签不足以确立独立性。

运营主权意味着运行系统的能力

如果只有一个供应商能够部署、修补、诊断或恢复软件制品，那么拥有这些制品是不够的。

运营主权需要文档、内部知识、可观测系统、备份/恢复流程以及足够的专业知识来维护或迁移平台。

这就是为什么主权既包括服务器，也包括技能和生态系统能力。对不可替代的外部专业知识的依赖，可能与对 API 的依赖一样真实。

司法管辖区不等于物理位置

服务器可以物理上位于一个国家，而提供商仍受另一个国家的法律拥有或控制。

确切的法律后果取决于合同、公司结构、数据类型和适用法律，因此主权架构应涉及法律专业知识，而不是从数据中心地图推断法律豁免。

从架构角度来看，司法管辖区是与位置、所有权、运营商访问和技术控制并列的一个依赖属性。

主权 AI 是一个供应链问题

每一个导入的模型、容器、软件包、驱动程序和设备都会增加一个外部依赖。

最强的架构知道哪些依赖是关键、哪些可以替代、哪些需要可信更新渠道，以及哪些没有现实的替代方案。

所提出的最高 CADA 保证级别对软件供应链透明度和控制的强调反映了这一现实：即使生产数据从未离开该地区，主权也可能通过更新路径失效。

主权 AI 不需要气隙

气隙 AI 解决的是连接/隔离问题。主权 AI 解决的是控制/依赖问题。

主权系统可以保持互联网连接，并使用精心选择的外部提供商，同时保留有效控制和退出选项。

相反，如果气隙系统依赖于无法替代的专有外国软件、许可证、硬件或更新流程，它仍然可能不是主权的。

主权 AI 与私有 AI

不同的主要问题

	私有 AI	主权 AI
主要问题
数据重点
可以使用云吗？
需要开源吗？
需要隔离吗？

当主要需求是保密性而非战略自主性时，私有AI可以完全满足要求。当提供商控制、司法管辖、连续性或依赖风险本身成为需求的一部分时，主权就变得相关了。

自托管AI并不自动意味着主权

自托管可以直接控制推理位置，并且通常可以控制模型文件和日志。

但自托管技术栈仍可能依赖于某个专有运行时、某个GPU供应商、外部许可证服务器、外国更新基础设施，或某个禁止所需修改或再分发的模型许可证。

因此，自托管是一种可能的主权控制手段，而不是整个技术栈主权的证明。

供应商框架：NVIDIA的四大技术支柱

NVIDIA当前的主权AI技术指南围绕四大支柱组织该主题：数据/基准、模型、硬件基础设施和框架。

这是一个有用的技术分解，尤其对于国家模型建设项目而言。NVIDIA还围绕本地数据集、特定国家的语言/文化以及位于国境内部的基础设施来界定主权AI。

由于NVIDIA是主要的基础设施供应商，这应被解读为供应商视角，而非中立的全球标准。本文中更广泛的依赖/控制模型还额外包括所有权、司法管辖、身份、供应链和退出权。

实用的企业主权成熟度模型

工作负载默认不需要最高级别。所需的控制应取决于后果、监管、保密性、连续性需求和战略重要性。

成熟度模型的意义在于揭示依赖仍然存在于何处——而不是把主权变成营销徽章。

当退出不再可信时，供应商锁定就变成主权风险

锁定并不总是坏事。团队接受专有依赖，是因为它们提供了速度、质量、支持或经济性。

当依赖具有战略关键性，且组织无法在其所需的连续性窗口内现实地迁移时，它就成了主权问题。

因此，退出需要被设计和测试，而不仅仅是在合同中描述。

可信退出计划包含哪些内容

可移植性并不等同于主权——但它是主权最有力的机制之一

一个能够迁移数据但无法复现模型行为的系统，可能仍被锁定。

一个能够切换模型端点但无法迁移身份、检索数据或审计记录的系统，可能仍存在关键依赖。

主权要求关键能力的可移植性，而不仅仅是导出某一个数据库。

开放标准和协议边界降低替换成本

诸如普通 HTTP API、OAuth/OIDC、OpenTelemetry 和可互操作的数据格式等标准，即使实现仍为专有，也能降低依赖。

AI 特定协议也能在选定的边界上提供帮助，但没有任何协议能够消除提供商特定行为或法律依赖。

标准的主权价值是实际的：它是否能让组织在不重写整个平台的情况下替换某个组件？

主权是一项治理决策，而不仅仅是技术设计

组织必须决定哪些依赖是可接受的，以及谁可以批准它们。

AI 治理可以对模型/提供商进行分类，按风险层级定义主权要求，要求退出证据，并为第三国或云使用设定条件。

因此，主权要求应出现在架构决策、采购、风险管理和运营测试中，而不仅仅出现在政策声明中。

采购在很大程度上决定了实际主权

合同可以规定数据使用、保留、支持、可移植性、模型弃用通知、子处理者、访问管辖权和终止协助。

但合同承诺不能替代技术可移植性。如果不存在替代实现，退出条款在运营上可能仍然薄弱。

面向主权的采购应同时评估法律控制和技术可替代性。

混合AI可以比全本地设计更具主权性

主权有时被错误地等同于“一切都在本地运行”。

混合架构可以将敏感数据和权威知识保留在受控基础设施上，同时为经批准的任务使用外部前沿模型，并采用基于策略的路由和经过测试的回退方案。

如果可以在不丧失关键组织能力的情况下移除外部模型，那么混合平台可能比名义上本地化但锁定于单一专有运行时的技术栈拥有更强的实际主权。

主权不能替代安全

控制基础设施并不能自动使其安全。主权环境仍然需要漏洞管理、最小权限、事件响应、备份、安全供应链和可审计性。

如果检索或授权不正确，本地控制的模型仍可能将一个租户的数据泄露给另一个租户。

主权回答的是谁控制系统；安全回答的是该控制是否被安全地行使。

主权与监管合规是不同的

一个由欧盟托管、欧盟控制的AI技术栈仍然可能违反《人工智能法案》、GDPR或特定行业要求。

同样，一个合规的系统可以使用外部提供商，但仍然只有有限的技术主权。

监管和主权可以相互加强，但它们是独立的架构/治理维度。

原始实现证据：面向主权的构建模块

Aaasaasa AI Client：提供商、模型、运行时和权限是可分离的

Aaasaasa AI Client将代理/客户端、提供商、提供商特定模型、连接位置和权限策略分离。提供商可以包括Ollama、LM Studio/OpenAI兼容服务和专用云路径。

该架构明确区分本地运行时和本地推理：本地代理运行时可以使用云模型，而Direct Ollama聊天可以执行本地推理。

这种分离与主权相关，因为提供商依赖成为一个显式配置层，而不是硬编码到业务应用程序中。

中央权限也是应用/会话策略，而不是模型的属性。即使模型/提供商选择发生变化，这也能将操作权限保持在应用的控制之下。

真相源研究引擎：本地证据权威

真相源研究引擎围绕持久化来源、快照、哈希、声明和来源追溯进行设计，而不是让模型输出成为权威。

这种模式在知识层与主权相关：即使推理模型可以被替换，组织证据仍然是一个独立受控的工件。

因此，该项目展示了一个有用的依赖原则：将权威数据/证据与解释它的模型保持可分离。

构建主权依赖图

该表的价值不在于确切的列；它迫使战略依赖变得可见且可测试。

然后，架构审查可以区分便利依赖与威胁连续性、机密性或监管目标的依赖。

何时需要更强的人工智能主权

主权应当适度。目标不是在所有地方最大化本地所有权；而是保留足够的控制以应对后果和威胁模型。

常见的主权人工智能失败模式

常见误解

实用的主权人工智能设计序列

从战略依赖向外设计

1

1. 定义主权主体

说明控制权是要求用于企业、公共机构、国家、欧盟领域还是其他权威机构。

2

2. 定义关键能力

确定哪些AI功能不能丢失或受外部控制。

3

3. 分类数据和司法管辖区

映射数据位置、法律控制、保留和允许的处理。

4

4. 映射模型依赖关系

记录权重/API所有权、许可证、版本、微调和替换选项。

5

5. 映射基础设施和控制平面

记录计算、云、密钥、身份、网络和操作员访问。

6

6. 映射软件和供应链

识别专有运行时、开源、软件包、注册表、更新和关键供应商。

7

7. 选择控制机制

在合理的情况下应用本地推理、区域提供商、开放标准、开源或更强的所有权。

8

8. 构建提供商/模型抽象

在可移植性重要的地方，避免业务应用程序硬编码单一供应商。

9

9. 独立保存权威数据

确保知识、来源和业务记录在模型替换后仍然存在。

10

10. 定义退出标准

为关键依赖设置最大可接受的迁移/连续性时间。

11

11. 测试替换和恢复

运行现实的故障转移/迁移演练，而不是信任架构图。

12

12. 定期重新评估

供应商所有权、政策、价格、法律、模型支持和技术生态系统会发生变化。

主权AI架构检查清单

限制和权衡

更强的主权可能会增加成本，因为必须直接或在受限的提供商生态系统内维护更多的基础设施、运营和专业知识。

对于某些工作负载，本地或区域替代方案可能落后于前沿模型能力。因此，主权政策应支持基于风险的路由，而不是强制将较弱的模型用于每项任务。

在现代半导体和软件供应链中，绝对独立很少现实。架构应识别并减少不可接受的依赖，而不是声称不可能的自给自足。

如果采购规则变得过于僵化，主权也可能减少生态系统选择。当前的欧盟政策明确试图在加强自主权的同时保留开放市场和伙伴关系。

如果没有团队能够修补、监控或迁移系统，那么系统在纸面上可能是“主权”的，但在操作上却很脆弱。

什么会改变这个答案？

欧盟提出的CADA主权框架可能会在立法过程中演变，因此在采购或法律决策之前应重新检查确切的保证级别要求。

提供商所有权、模型许可、地缘政治条件和半导体供应链可能会在没有任何应用程序代码更改的情况下实质性改变主权评估。

稳定的架构原则是，主权取决于对关键依赖的有效控制和可信替代方案，而不是一个地理或品牌属性。

相关规范知识

主权AI位于几个部署和控制概念之上：私有AI保护敏感处理，气隙AI隔离网络域，AI治理分配决策权，LLMOps操作模型/提供商变更。

提供商抽象和模型路由是减少依赖的实用机制，而真相源架构使组织证据独立于任何单一模型。

企业AI架构决定了这些主权要求属于平台、应用程序、身份、基础设施和运营的哪个位置。

常见问题

主权 AI 常见问题

什么是主权 AI？

主权 AI 是指国家、公共机构或组织等特定权威实体对关键 AI 数据、模型、基础设施、软件、运营和依赖关系保持有效控制的能力。

主权 AI 等同于数据主权吗？

不。数据主权只是其中一个组成部分。AI 主权还包括模型控制、算力、软件供应链、身份、运营者、司法管辖以及替换关键提供商的能力。

主权 AI 是否要求所有内容都在本地托管？

不。如果所需控制水平、法律保障、可移植性和连续性得以保持，主权架构可以使用外部或云服务。

主权 AI 是否要求开源模型？

不。开源或开放权重可以提高控制和可移植性，但在依赖关系和许可可接受的情况下，仍可使用专有组件。

自托管 AI 是否自动具备主权？

不。自托管控制推理位置，但仍可能依赖外部身份、专有运行时、外国硬件、许可证或更新基础设施。

主权 AI 与气隙 AI 有何区别？

气隙 AI 涉及物理/网络隔离和受控传输。主权 AI 涉及对整个依赖链的有效控制。两者可以独立存在。

云 AI 服务能否具备主权？

有可能，取决于所需的主权级别以及谁控制位置、提供商所有权、管理访问、密钥、供应链、司法管辖和退出。

为什么提供商抽象对主权很重要？

它减少了应用程序对单一模型提供商的耦合，并创建了技术迁移路径，尽管行为差异仍需评估。

如何衡量实际 AI 主权？

映射关键依赖关系，并测试如果提供商、司法管辖区或供应链依赖变得不可接受，数据、模型、工作负载和运营能否在所需时间内继续或迁移。

关于主权 AI 最大的误解是什么？

认为主权是单一属性，例如欧盟托管、本地推理、开源或气隙。实际上，它是一个多层控制和依赖问题。

术语表

关键主权 AI 术语

主权 AI

设计为使特定权威实体对关键数据、模型、基础设施、运营和依赖关系保持有效控制的 AI 能力。

技术主权

通过控制关键技术、数据和基础设施，同时减少战略性外部依赖，在数字领域独立行动的能力。

战略依赖

其丧失、控制或变化可能实质性威胁连续性、安全性、自主权或政策目标的外部依赖。

数据驻留

描述数据物理或逻辑存储/处理位置的要求；比主权范围更窄。

数据主权

在适用法律、组织和司法管辖权威下对数据的控制。

模型主权

对模型访问、权重、许可、修改、版本控制、部署和替换的控制程度。

基础设施主权

对关键工作负载所需的算力、托管、控制平面、运营和基础设施司法管辖的控制。

运营主权

在不对外部运营者产生不可接受依赖的情况下部署、维护、观察、恢复和迁移系统的能力。

提供商抽象

将业务逻辑与提供商特定 API 分离的应用程序架构，以便更安全地更改模型/提供商依赖。

退出策略

将数据、工作负载和运营能力从外部依赖中移出的可测试计划。

供应链主权

在关键软件、模型、硬件和更新依赖中的透明度、控制和可替代性程度。

战略自主

在没有不可接受的外部约束或依赖的情况下做出和执行关键决策的能力。

结论

主权 AI 不是一个产品类别，也不是一个部署位置。它是一个架构和治理目标：对重要的 AI 能力保持有效控制。

最强的主权设计将数据与模型分离，将业务应用与提供商分离，将权威与模型能力分离，将关键运营与不可替代的外部依赖分离。

最简短的可靠规则是：主权不是由模型运行在哪里证明的；而是由谁控制关键堆栈、保留哪些依赖关系，以及当这些依赖变得不可接受时组织能否继续或改变方向来证明的。

主要和当前来源

以下来源区分了欧盟官方技术主权政策、当前拟议的云/AI 主权保证级别、欧洲算力倡议以及供应商技术框架。本文中的企业主权成熟度模型明确为原创综合，并非欧盟或行业标准。

欧盟委员会 — 加强欧洲技术主权

欧盟当前对技术主权的定义：通过控制关键技术、数据和基础设施，同时减少对非欧盟提供商的依赖，实现独立行动。

欧盟委员会 — 关于欧洲技术主权的通讯

2026 年政策方案，涵盖从芯片到基础设施、软件、云和 AI 的技术价值链。

欧盟委员会 — 云和 AI 发展法案

当前拟议的欧盟框架，定义了位置、第三国独立性、所有权/控制权和软件供应链控制四个云/AI 主权保证级别。

欧盟委员会 — 欧盟开源战略

当前政策将开源与更大的控制、更低的锁定、安全性、复用和技术主权联系起来。

欧盟委员会 — AI 工厂

当前欧盟 AI 算力基础设施倡议，将 AI 工厂和超级工厂与欧洲能力和技术主权联系起来。

欧盟委员会 — AI 超级工厂征集

2026 年倡议，旨在扩大欧洲 AI 算力、韧性和战略自主，基础设施在欧洲建设和运营。

EuroHPC JU — AI 超级工厂

EuroHPC 当前对大规模主权 AI 计算基础设施和技术独立的框架。

NVIDIA — 构建主权AI模型

围绕数据/基准、模型、硬件基础设施和框架组织的供应商技术框架；可作为行业视角参考，并非通用标准。