# AI主权进入运营时代：从技术所有权到企业可逆性与持续控制

## 核心定义
> 企业 AI 主权是指企业在供应商、模型、监管或基础设施发生变化时，仍具备数据迁移、模型替换、工作负载转移和持续运营的能力。

## 核心洞察（TL;DR）
- 企业 AI 主权建设不应是一次性项目，而应建立持续运营能力。
- 企业应根据业务风险和战略价值，对数据、模型和基础设施实施不同程度的控制。
- 企业 AI 主权建设是一个持续运行的 Control Plane，而非一次性项目。

## 关键事实与数据
- 仅 9% 的受访高管非常了解自身 AI 供应商、模型和基础设施依赖。
- IBM 调查中，72% 的高管愿意承担约 20% 的额外成本以维持多个 AI 供应商。
- IBM 研究显示，将 AI 训练和运营数据迁移到另一个环境平均需要 145 天。
- IBM 建议 Tier 1 系统在数据、模型和运行时三个层面拥有经过测试的替代方案。
- IBM 强调，AI 主权不应结束为一次性项目，而应进入日常运营。

## 正文
# 从“选择性 AI 主权”到可执行运营体系：企业 AI 主权建设方法、运行机制与实施手册

IBM 商业价值研究院提出的“选择性 AI 主权”框架，真正值得企业采用的并不是“主权”这一概念本身，而是一套围绕依赖关系、业务关键度与切换能力重新设计 AI 运营体系的方法。报告数据显示，仅 9% 的受访高管非常了解自身 AI 供应商、模型和基础设施依赖，71% 认为更换主要 AI 供应商或模型存在明显困难。 当 AI 从聊天辅助工具逐步进入风险决策、客户运营、供应链和业务流程，模型依赖便不再只是技术问题，而开始成为业务连续性、利润率和战略选择权问题。

因此，企业 AI 主权建设不宜被理解为一次性的“国产化”“私有化”或“多模型接入”项目。更准确的实施目标，应当是建立一种持续运营能力：企业能够知道关键 AI 系统依赖什么，能够判断这些依赖发生变化后的业务影响，并且拥有已经验证的数据迁移、模型替换、运行环境切换和业务降级机制。

## 首先建立正确的实施目标：企业需要的是选择权，而不是全面所有权

IBM 的核心判断是，全面控制整个 AI 技术栈既不现实，也不具备成本效率。企业应根据业务风险和战略价值，对数据、模型和基础设施实施不同程度的控制。 这意味着 AI 主权项目不能从“哪些东西必须自己建设”开始，而应从“哪些依赖一旦失效，会给企业造成不可接受的损失”开始。

实践中可以把主权建设理解为一类企业风险投资。对于会议总结、翻译、一般内容生成等商品化能力，快速采用外部服务通常更加经济；对于欺诈检测、交易风险、核心决策、价格策略或关键运营流程，则需要额外投入备用模型、可迁移数据、运行环境冗余和故障切换能力。

因此，一个较为合理的主权投入原则是：

**主权控制成本，应与潜在中断损失、迁移成本、供应商锁定风险和监管风险相匹配。**

IBM 调查中，72% 的高管愿意承担约 20% 的额外成本以维持多个 AI 供应商，从而获得战略灵活性。 这里真正购买的并不是第二个供应商，而是未来可以改变技术路线的选择权。

## 第一步：建立企业 AI 资产与依赖关系图

AI 主权项目最容易出现的错误，是从采购第二个模型或者建设私有模型开始。IBM 的研究实际上表明，更优先的问题是“可见性”：企业首先必须知道自己的 AI 系统到底依赖什么。

一套生产级 AI 应用通常至少存在六类依赖：

业务应用 → Agent/Workflow → 模型 → 数据与知识 → 基础设施 → 外部服务。

其中模型依赖又可能包含 Foundation Model、Embedding、Reranker、Moderation、OCR、Speech 等服务；数据层还可能包含原始数据、Chunk、向量索引、知识图谱、Prompt、Evaluation Set 和 Agent Memory。只盘点“使用了 GPT 还是 Claude”，远远不足以解释真实的系统依赖。

IBM 对 CIO/CTO 的行动建议同样要求企业绘制第一层级系统的完整依赖关系图，覆盖数据、模型、编排和计算，并识别造成锁定的不可移植连接点。

实际操作中，每个生产 AI 系统至少应建立以下记录：

* 业务负责人和技术负责人；
* 对应业务流程与收入、风险或运营影响；
* 使用的模型及模型供应商；
* Embedding、向量数据库和数据处理组件；
* Prompt、Agent、工具与外部 API；
* 数据所在区域及数据流向；
* GPU、云平台或本地计算环境；
* 专有 SDK、数据格式与不可移植接口；
* 当前备用模型和备用运行环境；
* 预估切换时间与切换成本。

最终得到的不是传统 CMDB，而是一张 **AI Dependency Graph**。它应该能够回答：如果某个模型明天停止服务，会影响哪些系统；如果某地区禁止某项服务，哪些业务会停止；如果供应商涨价 50%，企业有哪些替代选择。

## 第二步：按照业务关键度建立 Tier 1、Tier 2、Tier 3 分类

IBM 将 AI 系统分为三个层级，这一方法可以直接作为企业 AI 主权运营体系的骨架。第一层级是任务关键型或差异化系统，第二层级是重要但非差异化能力，第三层级则是运营或商品化服务。

第一层通常包括直接影响收入、风险、客户权益或者核心生产活动的 AI。IBM 举出的典型类别包括欺诈检测、专有算法和核心决策平台。对于这类系统，企业需要经过验证的数据迁出路径、备用模型、备用环境和故障演练，而不能只依赖合同中的灾备承诺。

第二层包括客户服务 AI、人力资源分析、供应链优化等重要但通常不形成企业核心差异化优势的系统。企业可以接受受管理的供应商依赖，但必须保持架构模块化、数据可迁移以及供应商行为和模型变化的持续监控。

第三层则包括转录、普通翻译和常规自动化等商品化能力。对这类系统投入完整双活、私有模型和复杂迁移机制反而可能损害经济效率。IBM明确指出，只要供应商依赖是企业有意识的选择并受到治理，就可以接受。

企业在实施时不宜仅通过“高风险/低风险”完成分类，还应至少考虑六个因素：

**业务关键度 × 数据敏感度 × 可容忍中断时间 × 供应商集中度 × 切换复杂度 × 监管要求。**

这样才能防止所有项目都因为“重要”而进入 Tier 1，最终使选择性主权重新演变成全面冗余。

## 第三步：数据主权要验证“能否重建”，而不仅仅是“能否导出”

IBM 研究显示，受访企业估计，将 AI 训练和运营数据迁移到另一个环境平均需要 145 天，68% 的高管认为数据驻留和主权要求已经形成挑战。 这说明企业的数据迁移能力通常远低于想象。

AI 系统的数据资产与传统软件明显不同。一个 RAG 系统即使可以导出全部 PDF，也未必能够在新环境恢复原有能力，因为系统真正依赖的可能还包括解析结果、Chunk 结构、Embedding、向量索引、元数据、知识图谱、Prompt、人工反馈和 Evaluation Set。

因此，数据主权测试至少应该验证三件事：

**Portability：数据能否完整迁出。**

**Reconstructability：迁出以后能否重新构建等效 AI 系统。**

**Lineage：是否能够解释这些派生数据从哪里产生、被哪些模型和系统使用。**

对于 Tier 1 系统，应定期执行真实的数据导出演练，而不是仅确认供应商 API 文档中“支持 Export”。IBM 对 CIO/CTO 的建议也明确提出创建关键数据内部镜像或影子副本，并测试从供应商环境提取数据。

## 第四步：通过 Evaluation 验证真正的模型可替代性

“同时接入三个模型”并不能证明企业拥有模型主权。IBM 调查中，57% 的高管表示，替换核心 AI 模型需要重大解耦甚至系统重建。 造成这一问题的原因通常不只是模型 API，而是模型周围不断积累的 Prompt、工具调用、结构化输出、SDK、微调数据和业务规则。

因此，模型切换应被定义成一个可测试流程。

第一步建立生产任务 Evaluation Set，用真实业务任务衡量任务完成率、事实正确率、工具调用成功率、延迟、成本和安全表现；第二步将备用模型运行在同一 Eval Set 上；第三步计算功能差异和需要修改的 Prompt、Workflow 或 Tool Schema；第四步记录完成生产切换需要的工程时间和重新验证时间。

这使企业能够得到真正有意义的指标：

**Model Switching Time**：模型切换所需时间。

**Model Revalidation Time**：重新完成生产验证所需时间。

**Validated Alternative Coverage**：拥有经过验证备用模型的 Tier 1 系统比例。

如果第二模型从未经过完整业务 Evaluation，它只能被称作“候选供应商”，不能被视为生产级备用方案。

## 第五步：建立 Model Gateway，但避免把 Gateway 本身变成新的锁定点

Sri Lanka Telecom 在 IBM 报告中的实践非常具有工程参考意义。企业面对超大规模云厂商模型更新和服务变化带来的反复改造，通过建立 AI Gateway 抽象模型依赖，使应用能够在不同模型和供应商之间切换，并尽量降低应用层改造。

企业级 Gateway 至少应承担统一模型协议、身份认证、模型路由、成本控制、日志记录、速率限制、策略执行以及供应商切换等职责。进一步成熟以后，还可以连接 Evaluation、Observability 与 Routing，通过任务类型、成本、延迟和模型效果进行动态调度。

但一个需要特别注意的问题是：**Gateway 自身不能形成新的深度锁定。**

如果所有 Prompt、Agent 状态、策略规则和 Evaluation 数据都绑定在某一个专有 Gateway 平台，企业只是把模型锁定转移成平台锁定。因此 Gateway 的接口、日志格式、模型配置以及路由规则也应具备可导出和可重建能力。

## 第六步：为 Agentic AI 增加 Execution Sovereignty

IBM 原报告主要围绕数据、模型和基础设施三个主权层级展开。随着 Agent 逐步进入实际业务操作，还需要增加一个实践层面的扩展：Execution Sovereignty，即执行主权。

一个只回答问题的模型出现错误，主要影响信息质量；一个能够调用 CRM、ERP、支付接口或数据库的 Agent 出现错误，则可能改变真实业务状态。因此企业必须明确 Agent 的运行权限、工具边界、人类审批、失败回滚和审计机制。

建议将完整 AI 主权控制域扩展成：

**Data → Model → Runtime → Execution → Governance**

Execution 层至少需要定义：

Agent Identity
Tool Permission
Action Boundary
Human Approval
Rollback Mechanism
Audit Trail
Emergency Stop

这里的核心原则仍然与 IBM 的选择性主权一致：不同业务系统采取不同程度的控制。用于办公辅助的 Agent 可以拥有较宽松的操作权限；能够修改订单、资金或生产系统的 Agent，则需要更严格的身份、审批和回滚机制。

## 把主权建设成一个持续运行的 Control Plane

当企业完成资产盘点、分级、迁移和模型切换能力之后，AI 主权不应结束为一次性项目，而应进入日常运营。

一个成熟的 **AI Sovereignty Control Plane** 可以由现有企业技术能力组合形成，并不一定需要采购单独的软件产品。它通常连接：

Model Gateway
AI Asset Inventory
Dependency Graph
Data Catalog
Evaluation
Observability
Policy Engine
IAM
Runtime Orchestration
Audit Logging

这一控制平面的任务，是持续回答五个问题：

企业现在依赖谁？

依赖什么？

如果这个组件失效会影响什么？

替代方案是什么？

替代方案是否真正验证过？

因此，企业 AI 主权成熟度不应该用“支持多少模型”衡量，而应逐步建立以下运营指标：

**Dependency Visibility**：关键 AI 系统依赖关系覆盖率。

**Vendor Concentration**：关键能力的供应商集中度。

**Data Exit Time**：完成关键数据迁出的时间。

**Model Switching Time**：切换核心模型需要的时间。

**Validated Alternative Coverage**：具有真实验证备用方案的 Tier 1 系统比例。

**Fallback Success Rate**：故障切换演练成功率。

**AI Recovery Time**：AI 服务异常后的恢复时间。

这些指标一旦进入季度经营和风险报告，AI 主权才真正从架构原则进入企业运营。

## 故障演练比合同中的“可切换”更加重要

IBM 在行动指南中反复强调“经过测试的替代方案”。CEO 被建议在 60 至 120 天内开展 AI 中断模拟，COO 应实施故障切换演练和降级运行，董事会则应要求提供实际切换能力证据，而不仅是合同保证。 

一次完整的 Tier 1 AI 故障演练可以模拟：

主要 Foundation Model 不可访问；

供应商 API 性能明显下降；

Embedding 服务停止；

某一区域云服务不可使用；

模型新版导致任务成功率下降；

数据无法继续跨境传输。

企业随后验证系统是否能够切换备用模型、进入降级模式、转移工作负载或回退到人工流程。

这里最重要的产物不是演练是否“成功”，而是获得真实的 Switching Time、业务降级程度和人工干预量。这些数据才能支持 CFO 判断所谓“主权溢价”是否具有经济价值。

## 采购体系需要加入 Exit Capability

IBM 向 CFO 提出的建议十分具有现实意义：Tier 1 系统应报告切换时间与切换成本，合同应包含可执行的数据迁出权和退出 SLA，并持续统计经过验证的替代方案覆盖率。

因此，AI 采购模板需要在传统 Price、Security、Availability SLA 之外增加 Exit Capability。

采购团队可以重点确认：

数据是否完整属于客户；

派生数据能否导出；

模型变化是否提前通知；

历史模型版本是否可以继续使用；

服务终止后提供多久迁移期；

是否协助数据导出；

API 是否遵循公开标准；

微调数据与模型 Adapter 是否能够迁出；

日志与 Evaluation 数据是否能够完整导出。

一个企业级 AI 服务商是否成熟，未来越来越需要通过“客户能否顺利离开”进行判断。

## 实施路线：30～60 天建立可见性，60～120 天验证可切换性

IBM 提出的时间框架可以直接转化为企业项目路线。

### 30～60 天：建立基线

首先完成所有生产 AI 系统盘点，并建立 Tier 1、Tier 2、Tier 3 分类。针对 Tier 1 系统绘制完整 Dependency Graph，确认模型、数据、工具、编排和基础设施依赖，同时记录供应商合同、数据迁出机制和预计 Switching Time。

这一阶段不应急于改造系统，重点是回答：“我们的关键 AI 风险到底在哪里。”

### 60～120 天：完成第一轮验证

针对 Tier 1 系统选择最关键的一至两个依赖进行真实演练。完成一次数据导出、一次备用模型 Evaluation 和一次供应商或运行环境故障模拟。

IBM 对 CIO/CTO 的目标是最终让迁移从“数月”缩短到“数周”，并要求 Tier 1 系统在数据、模型和运行时三个层面拥有经过测试的替代方案。

这一阶段的核心成果应是一组实测数据，而不是新的架构 PPT。

## 需要警惕的五类实施误区

第一类风险是把“AI 主权”理解成全面私有化。这样容易导致企业投入大量 GPU、模型训练和基础设施成本，却没有解决真正的业务风险。

第二类风险是把多供应商数量当成主权指标。供应商越多，并不一定意味着切换越容易，反而可能显著增加集成和治理复杂度。

第三类风险是只有架构备用，没有 Evaluation。第二模型如果没有通过业务测试，就不存在真正的生产替代能力。

第四类风险是只治理原始数据，而忽略 Embedding、索引、Prompt、Agent Memory 和 Evaluation Set 等派生 AI 资产。

第五类风险是 Control Plane 自身形成新的锁定。企业需要持续检查 Gateway、Agent Platform、Observability 和知识平台是否存在不可迁出的专有状态。

这些问题共同说明，主权不能通过产品采购直接获得，它最终是一种经过架构设计、合同治理和运营演练共同形成的组织能力。

## 如何解读 IBM 报告中的经济数据

IBM 报告指出，当 AI 执行位置与数据位置不匹配时，Token 处理成本可能达到 2.8 倍，并针对一家年收入 200 亿美元的代表性企业测算出约 5,000 万美元的年度额外成本。 但研究方法明确说明，这属于本地与远程部署场景的模型测算，并不是企业实际发生的财务数据。

同样，报告提出端到端控制能力较强的组织可保护高出 55% 的 AI 相关业务价值，其基础是对受访企业进行 MCA、Ward 聚类与 ANOVA 分析，再比较预期避免的停机损失。 

企业使用这些数据时应把它们视为风险方向和经济机制的证据，而不应直接转化成自身 ROI 参数。真正的企业主权投资预算，最终仍需基于自身中断损失、迁移时间、模型调用规模和业务关键度测算。

## 从 AI Governance 走向 AI Resilience Engineering

IBM 的研究最终指向一个比“主权”更长期的企业能力：AI Resilience Engineering。

当 AI 只是实验工具时，企业可以通过治理委员会、采购审批和安全评估进行管理；当 AI 进入生产系统以后，仅靠制度已经不足够。风险控制必须写入 Gateway、Evaluation、Policy、IAM、Runtime 和故障回退机制之中。

此时企业真正需要建设的是一种类似 Site Reliability Engineering 的 AI 运营能力：

持续发现依赖；

持续评测模型；

持续验证替代方案；

持续测试数据可迁移性；

持续进行故障演练；

持续降低恢复和切换时间。

AI 主权由此不再是一项合规建设，而逐渐成为企业数字运营体系中的可靠性工程。

## 成熟的 AI 主权，是能够持续利用外部创新，同时保留改变路线的能力

IBM“选择性 AI 主权”框架最有价值的启示，是帮助企业摆脱“自主还是外购”的二元判断。企业完全可以广泛采用最先进的商业模型、公有云和外部 AI 服务，同时对真正重要的系统保留数据迁移、模型替换和业务连续性能力。

最终需要建立的不是一个封闭 AI 技术栈，而是一套经过验证的企业选择权体系。

对于普通能力，可以追求成本和效率；对于重要系统，应管理依赖；对于任务关键系统，则必须建立真正经过验证的替代能力。

因此，衡量一家企业 AI 基础设施是否成熟，一个越来越重要的问题并不是：

**“你们使用了多少个模型？”**

而是：

**“如果明天其中任何一个关键模型、供应商或运行环境不可用，你们知道哪些业务会受到影响，并且真的能够切换吗？”**

当企业能够用清晰的 Dependency Graph、Evaluation 数据、Switching Time 和真实故障演练回答这个问题时，AI 主权才真正成为一种可运营、可衡量并能够保护企业长期战略自由的生产能力。

## 关注「哈希泰格」服务号

![关注哈希泰格公众号二维码](/logo/qrcode_for_gh_f9203b130c32_344.jpg)

<FAQ
  title="常见问题解答 (FAQ)"
  faqItems={[
    {
      question: "什么是 AI 主权，企业是否必须拥有完整的 AI 技术栈？",
      answer: "AI 主权并不意味着企业必须自行拥有模型、算力和全部软件，而是指在供应商、模型、监管或基础设施发生变化时，企业仍具备数据迁移、模型替换、工作负载转移和持续运营的能力。其核心是保持关键 AI 系统的控制权、选择权与运营可逆性。"
    },
    {
      question: "为什么选择性 AI 主权比全面自主建设更适合企业？",
      answer: "全面控制整个 AI 技术栈成本高且通常没有必要。选择性 AI 主权根据业务关键度、数据敏感性、连续性要求、供应商集中度和切换成本配置不同程度的控制能力，使企业把冗余、迁移和替代能力优先投入任务关键型 AI 系统，在风险控制与投资效率之间取得平衡。"
    },
    {
      question: "采用多个 AI 模型或供应商是否就意味着拥有 AI 主权？",
      answer: "并不意味着。多供应商如果缺乏统一接口、模型抽象、数据标准、评测体系和治理机制，反而可能形成 Integration Lock-in。真正的模型主权要求企业能够通过 Model Gateway、Evaluation、Routing 和标准化 Runtime，在经过验证的时间和成本范围内完成模型或供应商切换。"
    },
    {
      question: "Agentic AI 为什么需要进一步考虑执行主权？",
      answer: "Agentic AI 不仅生成内容，还可能调用 API、修改业务数据、审批订单和执行工作流，因此企业还需要控制 Agent 代表谁行动、能够调用哪些工具、拥有哪些权限、何时需要人工确认以及失败后如何回滚。执行主权由此成为数据、模型和基础设施主权之外的重要控制维度。"
    },
    {
      question: "企业如何把 AI 主权从治理理念转化为可执行的运营能力？",
      answer: "企业可以建立 AI Sovereignty Control Plane，统一管理 AI Asset Inventory、Dependency Graph、Model Gateway、数据目录、Evaluation、Observability、Policy Engine、IAM 和 Runtime Orchestration，并持续度量 Model Switching Time、Data Exit Time、Vendor Concentration、Fallback Coverage 和 Recovery Time 等指标。"
    }
  ]}
/>

---
## 引用与溯源
**来源**：哈希泰格 (HaxiTAG)
**原始链接**：[https://haxitag.com/articles/ai-sovereignty-control](https://haxitag.com/articles/ai-sovereignty-control)
**来源索引（站内可追溯）**：[麦肯锡](https://haxitag.com/search?q=%E9%BA%A6%E8%82%AF%E9%94%A1)、[普华永道](https://haxitag.com/search?q=%E6%99%AE%E5%8D%8E%E6%B0%B8%E9%81%93)、[Gartner](https://haxitag.com/search?q=Gartner)、[IDC](https://haxitag.com/search?q=IDC)、[Forrester](https://haxitag.com/search?q=Forrester)
**版权声明**：本文由哈希泰格 AI 引擎优化生成，引用请注明出处。