本地部署不是「数据不出门」：它是企业 AI 的控制权设计

结论

企业谈本地部署，最常说的理由是"数据不出门"。这个理由没错，但它只讲对了五分之一。数据留在本地只解决了数据存在哪里的问题,没有解决谁能访问、按什么规则处理、出问题能不能查、模型换代时能不能自主决定这四个更难的问题。汉兴的判断是：本地部署的真正价值是控制权设计——身份、策略、数据、运行、升级五项控制权的组合,而不是一句"数据不出门"能概括的合规姿态。

发生了什么

微软的 Sovereign Cloud（主权云）官方页面把这套控制权拆解得比多数企业自己想的更细。页面开宗明义：目标是让组织在保持云与 AI 能力的同时，把控制权留在自己手里。它把控制权分成三类。第一类是数据控制：可以选择数据存储和处理的地域，数据在静态、传输和使用状态下都有加密保护，客户可以自带并管理自己的密钥存储在硬件安全模块上。第二类是运营控制：欧洲云服务的运营访问由欧洲本地人员审批，并有防篡改日志记录;组织可以用内置治理工具让云环境对齐监管标准；所有访问都受审批与日志管控，组织可以审计每一次访问。第三类是软件与身份控制：客户可以选择让 Copilot 这类 AI 服务在本国境内处理数据、在本地完成模型训练或推理；加密机制默认阻止云运营商访问数据，除非客户明确授权。

值得注意的是,微软把解决方案分成三个层级，其中"主权私有云"被描述为：在混合或完全断网的环境下，让敏感工作负载运行在本地控制之下。这句话直接点出了一个关键区别：数据留在境内(数据residency)和工作负载运行在自己控制之下(operational control)，是两件不同的事。前者回答"数据物理上在哪"，后者回答"谁能决定这套系统怎么运行、什么时候升级、出了问题谁来处理"。

同一时期，McKinsey 在 2026 年 4 月 2 日发布《Building the foundations for agentic AI at scale》，从企业规模化 agent 部署失败的角度给出了印证。文章的数据是：全球近三分之二的企业已经试验过 agent，但规模化到能产生实际价值的不到十分之一；十分之八的企业把数据方面的限制列为规模化 agent 的主要障碍。文章指出，agentic AI 需要持续协调多个模型和数据源、往往不经过人工干预，这要求比过去更严密、更自动化的治理才能保证可靠性和可控性；能支撑不断提升的自主性、协同和实时决策的数据架构，通常表现为模块化、可互操作的框架，让 agent 能可靠地访问它需要的数据,同时保证安全。

两份文件从不同角度指向同一个结论：企业在 agent 时代真正稀缺的不是存储数据的地方,是能够审计、能够授权、能够在出问题时立刻叫停的控制机制。

为什么这对企业重要

"数据不出门"是一句容易被合规部门认可、也容易被销售当作卖点的话,但它解决的问题范围很窄。它能回答监管机构问的"数据存在哪个司法辖区"，回答不了业务方真正担心的问题：agent 用了我的数据做了什么决策，这个决策能不能追溯；供应商升级了底层模型，我的业务流程会不会突然表现异常，我有没有权利说不升级；一旦出现数据滥用或误判,责任链条能不能查清楚,由谁承担。

这些问题，任何形式的部署——本地也好，云端也好——都需要正面回答，但本地部署给了企业一个额外的选项：把回答这些问题所需要的控制权，直接握在自己手里，而不是委托给供应商的服务条款。微软自己的三分类已经说明,数据控制只是三类控制权里最容易被大众理解的一类,运营控制和身份控制同样重要,却经常被"数据不出门"这句简化的口号盖过去。

汉兴的判断

本地部署的价值不是"数据不出门"，是身份、策略、数据、运行、升级五项控制权的组合设计。少谈控制权、只谈数据存放地点的本地化项目，本质上只解决了监管合规里最容易过审的那一层。

这是一个可以被反对的判断。反对的版本是：多数企业没有能力自己运营五项控制权,与其把治理能力分散到自己不擅长的领域，不如把控制权委托给专业云服务商的合规体系，企业只需要管好自己的业务逻辑。这个反对成立的前提是企业信任委托关系能覆盖自己的全部风险敞口。我们不完全同意，理由是：agent 拿到执行权限之后,一旦决策出错，追责链条最终仍然会落回企业自己身上,委托出去的是运营复杂度，委托不出去的是责任。企业至少需要清楚知道这五项控制权各自被谁握着、以什么条件收回。

我们把这五项控制权拆解成一个原创框架，用于评估任何一个部署方案——不论本地还是云端——的控制权成熟度。

```企业 AI 部署的五项控制权 [1] 身份控制 Identity 问题：谁能以什么身份访问系统与数据 [2] 策略控制 Policy 问题：哪些操作被允许，谁能修改这些规则 [3] 数据控制 Data 问题：数据存在哪里，谁能读取、导出、删除 [4] 运行控制 Operations 问题：系统运行状态谁能监控，出问题谁能叫停 [5] 升级控制 Upgrade 问题：底层模型或版本升级，企业有没有否决权与灰度选择权```

配套的原创判据，我们称为控制权自主度：

```控制权自主度 = 企业可自主决定的控制项数 ÷ 五项控制权总数```

一个纯 SaaS 订阅模式，五项里企业通常只对第一项有部分自主权；一套本地部署但仍依赖供应商远程运维和强制升级的系统,自主度也可能只达到三项;只有当身份、策略、数据、运行、升级都由企业自己决定收回条件的部署，才是完整意义上的"控制权在自己手里"。

一个中国企业的情境（示例推演）

以下情境用于说明框架的用法，不对应任何真实客户，数据为示例推演。

一家华北制造企业为满足内部合规要求，把客服和生产排程的 AI 系统部署在自己的数据中心，对外宣称"数据不出门"。半年后遇到两个问题：一是模型供应商推送了一次版本更新，排程系统的输出逻辑发生变化，企业事先毫不知情，直到生产计划出现异常才发现是模型换了版本；二是内部审计想核查某次异常审批是谁触发的，发现系统日志只记录了最终结果，没有记录是哪个身份、在什么策略下触发的操作。数据确实没有出门,但企业对系统实际发生了什么，几乎没有控制权。

按五项控制权重新设计：升级控制上，与供应商约定版本更新必须经企业确认才能生效，不再默认推送；身份控制上，每一次系统操作都绑定具体的用户身份而不是笼统的"系统账号"；运行控制上，建立独立于供应商的监控看板，异常时企业自己就能第一时间叫停。这三处改动都不涉及数据物理位置的变化,解决的是"数据不出门"这句话本来就没有覆盖到的问题。

反方观点与适用边界

这个判断在两类情况下需要调整。

第一类，企业自身没有运营能力,委托反而更安全。 中小企业如果没有专门的安全运维团队,强行把五项控制权都收回自己手里，可能因为运维能力不足而制造出比委托给专业云服务商更大的风险敞口。对这类企业，更现实的路径是选择运营控制和身份控制透明度高、可审计的云服务商，而不是勉强上马本地部署。

第二类，两份来源本身的局限。 微软的 Sovereign Cloud 页面是产品介绍性质的官方材料,五项控制权拆解是汉兴基于其三分类做的延伸,不是微软官方使用的框架；McKinsey 的文章聚焦的是 agent 规模化的数据基础，不是专门针对本地部署与云部署的比较研究,文中的三分之二与十分之一等数字描述的是全球样本，不能直接套用到中国企业的分布上。

企业现在应该做什么

给 CEO：审视现有的"数据不出门"类项目，问一个问题——升级控制和运行控制握在谁手里。 如果答案是供应商而不是企业自己，这个项目的合规叙事和实际控制权是脱节的。

给 CAIO：用五项控制权框架给每一个在跑的 AI 系统打分,列出自主度最低的两项，作为下一季度的治理优先项。 这比笼统地要求"加强数据安全"更容易落地，因为每一项都对应具体的合同条款或技术改动。

给 FDE：在本地部署项目的交付清单里，把升级机制和运行监控写成明确条款，而不是默认沿用供应商的标准服务协议。 企业对底层模型更新有没有确认权、系统异常时企业自己能不能直接叫停，应该在项目启动阶段就谈清楚，而不是等出问题才发现权利不在自己手里。

证据、来源与公开边界

• Microsoft，《Discover Microsoft Sovereign Cloud》。https://www.microsoft.com/en-us/sovereignty
• McKinsey & Company / QuantumBlack，《Building the foundations for agentic AI at scale》，2026 年 4 月 2 日。https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/building-the-foundations-for-agentic-ai-at-scale

本文引用的控制权分类、数据统计与治理论述均来自上述两份官方文件原文。文中的中国企业情境为示例推演，不对应任何真实客户。五项控制权框架与控制权自主度指标为汉兴原创，未经第三方验证，微软官方分类为三层，本文延伸为五项以对应企业实际治理需求。

元信息

栏目 Enterprise AI　作者 汉兴 AGI 实验室　版本 v1.0　成稿 2026 年 8 月 12 日