空客在选择主权云供应商时，没有把“主权”停留在宣传口号上，而是将抵御非欧洲域外法律影响的能力，与技术能力一起纳入招标评分。最终入选的是 Scaleway。空客同时强调，这项选择是对多云战略的补充，并不意味着退出 AWS。
这件事值得工程和采购团队关注，因为它展示了一种更可执行的做法：不要只问数据中心在哪里，而要把司法管辖、远程运维、密钥控制、供应链和退出能力拆成可评分、可举证的控制项。
数据驻留不等于可验证的主权
“数据存储在欧洲”只能回答数据静态落点的问题，无法单独回答谁可以访问数据、哪国法律可能要求供应商交付数据，以及客户能否发现或阻止这类访问。
评估主权云时，可以沿着几条控制链继续追问：
- 法律实体：签约主体、母公司和关键分包商分别受哪些司法辖区约束？
- 运维访问：支持人员从哪里登录生产环境，是否采用临时授权、双人审批和完整审计？
- 密钥控制：密钥由谁生成和持有，供应商能否在客户不知情时解密数据？
- 控制平面：身份系统、工单、遥测和备份是否依赖其他司法辖区内的服务？
- 供应链：身份认证、邮件、可观测性和客服 SaaS 是否形成新的域外暴露面？
- 退出机制：数据、日志、密钥和配置能否以开放格式导出，并在合同终止后被验证删除？
这些问题也解释了为什么相关评估正在从大型云平台扩展到小型美国 SaaS 厂商。一个只处理告警、代码扫描结果或客户工单的工具，同样可能接触敏感元数据。
评分模型必须同时看能力和证据
空客案例的关键不是简单增加一个“是否主权云”的复选框，而是让域外法律防护进入正式评分。实际采购中，可以把每个要求拆成三个部分：权重、供应商自评分、证据可信度。
例如，“客户持有密钥”不能只凭问卷得满分。评审团队应要求架构图、密钥管理策略、操作审计样本和合同条款，并确认供应商管理员是否仍存在绕过路径。没有证据的高分陈述，应在模型里被折扣。
下面是一个可以直接运行并继续改造的最小评分脚本。它不是空客招标表的复刻，而是一种实践示例。运行前将供应商名称、分数和证据系数替换为真实评审结果：
from dataclasses import dataclass
@dataclass(frozen=True)
class Criterion:
name: str
weight: int
score: int # 0-5: control maturity
evidence: float # 0-1: evidence confidence
criteria = [
Criterion('technical capability', 30, 4, 0.95),
Criterion('extraterritorial-law protection', 25, 4, 0.80),
Criterion('customer-controlled encryption keys', 15, 5, 0.90),
Criterion('privileged-access governance', 15, 3, 0.75),
Criterion('portability and exit', 10, 4, 0.85),
Criterion('subprocessor transparency', 5, 3, 0.70),
]
mandatory = {
'extraterritorial-law protection': 3,
'customer-controlled encryption keys': 4,
}
failed = [
item.name for item in criteria
if item.name in mandatory and item.score < mandatory[item.name]
]
weighted = sum(
item.weight * (item.score / 5) * item.evidence
for item in criteria
)
print(f'adjusted score: {weighted:.2f}/100')
if failed:
print('decision: reject')
print('failed gates:', ', '.join(failed))
else:
print('decision: proceed to legal and technical validation')
执行命令：
python3 sovereign_cloud_score.py
这里有两个容易被忽略的设计点。其一，关键控制应设置准入门槛，避免供应商用低价或一般技术能力抵消严重的法律风险。其二，evidence 会降低仅有承诺、缺少审计材料的得分，但它不能代替法务意见和现场技术验证。
主权云更适合作为多云中的信任边界
空客将这项采购描述为补充多云，而不是离开 AWS，这给架构设计留下了现实空间。团队不必把所有工作负载一次性迁移到单一平台，可以按数据敏感度和控制要求划分部署位置。
可以这样实践：把公开网站、无敏感数据的构建任务留在现有云上；把受监管数据、核心身份信息或敏感工程资料放入经过主权控制验证的环境；跨云只传递经过最小化和脱敏的数据。架构评审还应明确 DNS、CI/CD、身份提供商、日志平台和备份服务的位置，因为这些共享组件可能重新引入原本想隔离的司法辖区风险。
多云也有成本。团队需要维护两套权限模型、网络连接、监控和故障响应流程，还要定期测试数据迁移。主权要求如果没有对应的工作负载分类，很容易变成昂贵但模糊的平台标签。
采用前的核验清单
将域外法律风险纳入采购评分只是起点。签约和上线前，至少应完成以下核验：
- 让法务团队检查签约实体、母公司控制关系、政府数据请求流程和通知限制。
- 由安全团队验证客户管理密钥、特权访问审批、不可篡改日志及紧急访问流程。
- 获取完整分包商清单，并把新增分包商通知和反对权写入合同。
- 对身份、遥测、客服、备份和灾难恢复路径做端到端数据流映射。
- 用真实样本执行一次导出、恢复和删除演练，记录耗时、费用与格式兼容性。
- 约定持续审计频率，因为股权、服务依赖和法律环境都可能变化。
主权不是供应商永久拥有的属性，而是一组需要持续证明的法律、组织和技术控制。空客的做法提供了一个清晰方向：把它放进评分表、要求证据、设置硬门槛，再让多云架构承担不同风险等级的工作负载。