主权 AI 的混合架构：把模型能力带进本地，而不是把敏感数据送出去

对受严格监管的企业和政府机构来说，AI 基础设施过去常常是一道二选一：把数据留在本地，还是使用公有云中的先进模型与算力。如今，混合云和分布式云正在改变这个前提。组织可以把推理服务、模型和管理能力部署到自己的数据中心或边缘环境，同时继续利用云端的软件生命周期和弹性资源。

这并不意味着只要安装一套本地集群就自动获得了“主权”。真正的主权 AI，需要同时回答数据在哪里、谁能访问、系统依赖谁，以及外部网络中断后还能否运行。

主权问题不只是数据驻留

数据驻留通常是讨论的起点，但不是终点。来源调查显示，在超过 1,400 名高级 IT 负责人中，48% 正在优先建设支持数据驻留、访问控制和本地数据安全法规的基础设施；52% 的组织已经采用混合云方式承载 AI。

这些投入主要在应对三类风险：

• 司法管辖风险：法规可能变化，知识产权需要保护，跨境数据访问请求也可能影响数据处理方式。
• 经济独立风险：关键系统如果完全依赖境外基础设施供应商，价格、服务范围或供应关系的变化都可能影响连续运营。
• 地缘政治风险：全球网络、供应链或政策出现波动时，本地关键服务仍需要保持可用。

因此，评估主权能力不能只检查数据库所在区域。模型权重、提示词、向量索引、推理日志、遥测数据、身份系统和软件更新通道，都属于需要纳入控制面的资产。

两种部署模式解决不同问题

Google Distributed Cloud 将 Google Cloud 的部分基础设施和 AI 能力带到客户自己的数据中心或边缘环境，并提供两类部署模式。

隔离模式（air-gapped）面向不能连接 Google Cloud 或公共互联网的环境。系统可以在完全断网的条件下运行，也不能被 Google 远程关闭。这种模式适合涉密网络、关键基础设施和对外部依赖有明确禁令的场景，但组织需要自己设计更新介质、漏洞修复、模型导入和运维审计流程。

连接模式（connected）运行在组织已有硬件上，并使用由 Google 管理的软件生命周期。它降低了版本维护和平台运营成本，但外部连接、管理权限、遥测范围以及故障时的本地自治能力仍需要写进架构和合同要求。

GDC 提供面向 AI 工作负载优化的基础设施，可以选择 Gemini 或开放模型，并在本地运行推理服务和 AI Agent。这里的关键变化不是简单地把服务器搬回机房，而是让模型靠近受控数据运行。

混合架构应该按数据敏感度分层

比较稳妥的做法，是先对工作负载和数据分类，再决定部署位置，而不是要求所有 AI 任务使用同一种基础设施。

一个典型请求链路可以分成四层：本地身份认证、策略网关、推理服务和审计存储。策略网关负责阻止敏感字段外流；推理日志写入本地不可变存储；只有经过分类和脱敏的任务才允许转发到公有云模型。

这种设计还能减少供应商锁定。应用不直接绑定某个模型 SDK，而是调用组织内部统一的推理端点。底层模型可以是 Gemini，也可以是经过审批的开放模型。

可以这样实践：为本地推理端点建立网络边界

下面是一个可改造的 Kubernetes 示例。它创建独立命名空间，并默认禁止 AI 工作负载的所有出站连接，只允许应用访问同一命名空间中的本地模型服务。

示例假设集群已安装支持 NetworkPolicy 的网络插件。部署到生产环境前，请把命名空间、标签和端口改成实际值。

apiVersion: v1
kind: Namespace
metadata:
  name: sovereign-ai
  labels:
    environment: restricted
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: sovereign-ai
spec:
  podSelector: {}
  policyTypes:
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-local-model
  namespace: sovereign-ai
spec:
  podSelector:
    matchLabels:
      role: ai-agent
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              role: model-server
      ports:
        - protocol: TCP
          port: 8080

保存为 sovereign-ai-network.yaml 后执行：

kubectl apply -f sovereign-ai-network.yaml
kubectl get networkpolicy -n sovereign-ai
kubectl describe networkpolicy allow-local-model -n sovereign-ai

应用层也应通过统一端点调用模型。下面假设本地推理服务提供兼容 OpenAI 风格的 HTTP 接口；路径和模型名需要按实际平台修改。

export MODEL_BASE_URL="http://model-server.sovereign-ai.svc.cluster.local:8080/v1"
export MODEL_NAME="approved-local-model"
export MODEL_TOKEN="replace-with-a-secret-manager-reference"

curl --fail-with-body "$MODEL_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $MODEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL_NAME\",
    \"messages\": [
      {\"role\": \"system\", \"content\": \"Do not disclose restricted data.\"},
      {\"role\": \"user\", \"content\": \"Summarize the approved internal policy.\"}
    ],
    \"temperature\": 0.1
  }"

网络策略只是第一道边界。生产系统还需要短期凭证、双向 TLS、请求级授权、日志脱敏、模型制品签名，以及禁止通过 DNS、代理或遥测通道绕过出口限制。

落地前检查真正的自治能力

采用主权 AI 平台时，可以从以下问题开始评审：

• 断开公共互联网后，推理、身份认证、密钥管理和审计还能运行多久？
• 模型权重、向量索引、提示词和日志分别存储在哪里？
• 平台供应商能否远程停止服务或撤销许可证？
• 软件更新是否可离线导入，更新包能否验证签名并回滚？
• 哪些遥测信息会离开本地环境，能否关闭或做字段级过滤？
• 应用是否依赖专有模型接口，还是能够切换到经过审批的其他模型？
• GPU、存储、备件和运维人员是否存在单一供应来源？
• 合规控制是否通过技术策略持续执行，而不只是写在架构文档中？

混合架构并不会自动消除司法、供应链和地缘政治风险，但它提供了更细的控制粒度。组织可以把敏感推理留在本地，把适合弹性扩展的任务放到公有云，并为关键服务保留断网运行能力。真正值得建设的不是一座孤立的 AI 机房，而是一套经过分类、可审计、可替换，并能在外部环境变化时继续工作的 AI 运行体系。