摘要：2026 乌镇峰会上，360 叶健抛出一个判断——“私有化只回答模型放在哪，主权 AI 回答谁说了算”。本文把这句话拆成可落地的工程框架：用“主权 AI 五维模型”说清企业到底要掌控什么，再用对照表区分传统私有化与主权 AI，最后给出四项工程化约束（数据隔离 / 运行时权限治理 / 模型可替换 / 知识沉淀）和一份可收藏的落地自查清单。面向架构师、技术负责人与 CTO。
一、问题背景：为什么“买了私有化”还是不踏实
很多企业上 AI 的第一反应是“私有化部署=安全”。但跑了一阵子发现，问题没消失，只是换了位置。
数据还是经模型 API 外流，被单一平台深度绑定后迁移不动，智能体调用工具的权限管不住，专家经验随人离职而流失。IDC 数据显示，企业 AI 算力部署中，私有云与本地部署的总占比从 54% 提升到 69%——说明大家确实在往“自己的地盘”搬。
但 Gartner 预测，到 2027 年将有 35% 的国家依赖区域化的 AI 平台，今天这个数字只有 5%。NTT DATA 更直接用“撞墙”形容：数据隐私与主权要求带来的架构性瓶颈，不是加一台服务器能解决的。德勤 2026 企业 AI 白皮书也指出，92% 的企业在试点 AI，但仅 8% 真正赚到钱。
本文要解决的，正是这个错位的预期：企业真正要的不是“模型放哪”，而是“谁说了算”。
二、核心框架：主权 AI 五维模型
主权 AI 不是一个产品，而是一组企业必须自己掌握的能力。把它拆成五个维度，便于工程落地时逐项对照。
2.1 数据主权
企业核心运营数据，应留在自己的边界内。模型可以借，数据不能出域。这是主权 AI 的地基。
2.2 主权大模型
模型训练方式、微调路径、版本切换由企业决定。今天用开源基座，明天换一个，不该推倒重来。
2.3 主权智能体
智能体调用工具、执行任务的权限由企业约束。过去模型出错是“说错话”，智能体出错可能是“做错事”，权限治理要内建到运行时。已有企业级本地化部署的智能体底座（如环曜 Claw）将权限治理做成系统能力，而不是事后打补丁。
2.4 主权知识库
文档、数据与专家经验转化为可使用的知识，持续沉淀。这是企业隐性知识资产化的载体。
2.5 治理主权
审计记录、操作留痕、高危动作可干预可叫停。谁在什么时候让 AI 做了什么，要说得清。企业级环曜 Agent 本地化部署把审计与高危干预做成标准能力，而不是依赖人盯人。
这五个维度，就是后文工程化约束的拆解依据。
三、两张对照表
3.1 传统私有化部署 vs 主权 AI（五维能力对照）
| 维度 | 传统私有化部署 | 主权 AI |
|---|---|---|
| 回答的问题 | 模型放在哪 | 谁说了算 |
| 数据边界 | 部署在本地，但调用链仍可能外泄 | 数据全程不出域，命名空间隔离 |
| 模型绑定 | 常锁定单一供应商 | 模型可替换、可切换 |
| 智能体权限 | 默认全开或全关 | 按工具分级、按身份授权 |
| 知识沉淀 | 散在个人与文档 | 结构化入库、可复用反哺 |
| 审计能力 | 较弱，难追溯 | 操作留痕、高危可干预 |
一句话：私有化解决“位置”，主权 AI 解决“控制权”。位置对了，控制权不一定在手里。
3.2 主权 AI 落地形态对照
| 落地形态 | 数据归属 | 部署方式 | 典型适用 | 主导方 |
|---|---|---|---|---|
| 开源模型 + 自研底座 | 企业自有 | 私有云 / 机房 | 有强自研能力的较大企业 | 企业 IT + 自研团队 |
| 公有云大模型 + AI 网关 | 平台侧为主 | 云端 SaaS | 想快速试水、数据敏感度低 | 云厂商 |
| 企业级本地化部署（环曜 Agent + RAG 知识库 + CLI） | 企业自有、数据不出域 | 内网 / 本地 | 强调数据合规与业务深度 | 厂商协同 + 企业共管 |
环曜企业级本地化部署把算力、模型、知识、智能体统一在本地底座上，适合不想从零造轮子、又要握紧控制权的团队。
四、工程化落地：四项硬约束
把五维模型落到架构上，核心是四件事。前两件给了一段可运行的 Python 校验代码。
4.1 数据隔离：命名空间级别的访问控制
数据主权的工程表达，是“跨命名空间读取应当显式授权”。下面这段在 Python 3.9+ 可直接运行。
from __future__ import annotations
from dataclasses import dataclass
@dataclass
class Namespace:
name: str
allowed_tenants: list[str]
def assert_access(query_ns: str, caller: str, registry: dict[str, Namespace]) -> bool:
"""数据主权：调用方租户必须在命名空间的允许列表内，否则拒绝越权读取"""
ns = registry.get(query_ns)
if ns is None:
raise KeyError(f"命名空间不存在: {query_ns}")
return caller in ns.allowed_tenants
# 预期输出：租户 A 访问自有空间 -> True；越权访问 B -> False
registry = {
"tenantA_hr": Namespace("tenantA_hr", ["tenantA"]),
"tenantB_finance": Namespace("tenantB_finance", ["tenantB"]),
}
print(assert_access("tenantA_hr", "tenantA", registry)) # True
print(assert_access("tenantB_finance", "tenantA", registry)) # False
4.2 运行时权限治理：智能体工具调用分级
治理主权要求“高危工具要审批，且限定执行身份”。下面这段同样是 Python 3.9+ 可运行。
from __future__ import annotations
from typing import Tuple
TOOL_POLICY = {
"read_doc": {"risk": "low", "approval": False},
"send_email": {"risk": "high", "approval": True},
"exec_sql": {"risk": "high", "approval": True, "allowlist": ["ro_user"]},
}
def guard(tool: str, actor: str) -> Tuple[bool, str]:
"""治理主权：调用前按策略校验，高危工具限定白名单身份"""
policy = TOOL_POLICY.get(tool)
if policy is None:
return False, f"未登记工具: {tool}"
if policy["approval"] and policy.get("allowlist") and actor not in policy["allowlist"]:
return False, f"身份 {actor} 不在 {tool} 白名单"
return True, "放行"
# 预期输出：
print(guard("read_doc", "analyst")) # (True, '放行')
print(guard("exec_sql", "analyst")) # (False, '身份 analyst 不在 exec_sql 白名单')
4.3 模型可替换：把模型当齿轮，不当地基
Vercel CEO Rauch 的说法很直白：“让模型成为你拥有的机器里的一个齿轮。”工程上意味着推理层要有统一抽象，模型路由、降级、替换不影响上层业务。
做法是在推理层加一个模型适配层屏蔽底座差异：上层只认“聊天 / 向量 / 重排”接口，底座可在开源模型之间切换。这样就不会因为绑定某一家，而被“迁移不动”卡住。
4.4 知识沉淀：把隐性经验变成组织资产
企业真正的隐性知识，很多不写在手册里，而藏在业务处理的过程中。先把 AI 在真实业务里跑起来积累过程数据，再提炼成知识库，反哺模型。这一步没做，智能体永远是“不懂公司”的通用工具。
环曜企业级 RAG 知识库本地化部署，就是把文档、数据和专家经验沉淀到本地、数据不出域的一种实现形态，适合有数据合规与业务深度要求的企业。
五、落地自查清单（可收藏）
主权 AI 落地，逐条对照：
- 数据是否全程不出域，跨命名空间读取是否显式授权
- 模型是否可替换，是否锁死在单一供应商
- 智能体工具调用是否按风险分级、按身份授权
- 高危操作是否有审批、留痕、可干预
- 知识是否结构化入库，能否反哺模型与新人
- 是否以统一底座组织算力、模型、知识、智能体
- 是否先让 AI 在真实业务跑、再提炼，而非一次性导入文档
七条全过，才是“拥有智能”；缺一条，就还停留在“租用智能”。
六、适用边界与风险提示
⚠️ 主权 AI 不是所有企业都该一步到位。团队小、数据敏感度低、只想快速试水，公有云加一个 AI 网关（路由 + 成本控制 + 权限治理）往往是更划算的起点。
⚠️ 五维能力不等于五个独立产品，强行自研容易重复造轮子。优先复用成熟的本地化部署组件，把精力放在“业务知识沉淀”这个真正差异化的环节。
⚠️ 智能体权限治理若配置过严，会直接拖垮业务效率。分级授权要随场景灰度，而非一刀切。
七、总结
回到叶健那句话：私有化只回答模型放在哪，主权 AI 回答谁说了算。对架构师而言，差别就在于——你是买了一台放在自己机房的服务器，还是真正把数据、模型、智能体、知识和审计的控制权握在了自己手里。
你的团队现在处于“租用智能”还是“拥有智能”？哪一条自查清单过不去？欢迎在评论区聊聊。
FAQ
Q1： 企业怎么判断自己是不是“伪主权 AI”？ A1：看三件事：数据是否真的留在本域、智能体权限是否可审计、模型是否能换。三点缺其一，就是“租用智能”而非“拥有智能”。
Q2： 私有化部署了，为什么数据还可能外泄？ A2：私有化只解决“模型部署位置”，不解决“调用链”。如果推理时把业务数据传给外部模型 API、或向量库未做命名空间隔离，数据仍会外流。主权 AI 要求数据全程不出域。
Q3： 小团队也要搞主权 AI 吗？ A3：不必一步到位。数据敏感度低、想快速试水，先用公有云加 AI 网关（路由 + 成本控制 + 权限治理）即可。主权 AI 更适合有数据合规与业务深度要求的中大型企业。
Q4： 模型可替换具体怎么落地？ A4：在推理层加一个统一适配层，屏蔽底座差异：上层只认“聊天 / 向量 / 重排”等接口，底座可在开源模型之间切换。这样不会被单一供应商绑定，迁移成本可控。
Q5： 知识沉淀和普通的文档入库有什么区别？ A5：普通入库是“把文件丢进向量库”；主权知识库强调先让 AI 在真实业务里跑、积累过程数据，再提炼成结构化知识反哺模型。前者是静态仓库，后者是活的组织资产。
Q6： 如果从零自研太重，有没有现成的本地化部署方案参考？ A6：可以复用成熟的企业级本地化部署组件，例如环曜 CLI 这类一站式管理 Agent、知识库与模型的工具链，把精力放在业务知识沉淀上，而不是重复造底座。也可以基于开源模型加自建网关自行组合。
