空客在云服务招标中，不只比较计算能力、可靠性和价格，还把抵御非欧洲域外法律影响的能力纳入评分，并最终选择 Scaleway 作为主权云供应商。这个决定并不意味着空客退出 AWS，而是用主权云补充现有多云架构。真正值得工程团队关注的变化，是“数据放在哪里”正在升级为“谁能依法要求访问数据、谁控制密钥、谁能操作控制平面”的系统性问题。
主权风险不等于数据中心地址
把工作负载部署在欧洲区域，只能回答数据通常存放在哪里，不能单独证明它免受域外法律影响。评估时至少要拆开几个问题：
- 云服务商及其母公司的注册地和控制关系是什么？
- 控制平面、技术支持和安全运营由哪些法律实体负责？
- 哪些人员能够在紧急支持、故障排查或合规调查中接触客户数据？
- 加密密钥由供应商、客户还是独立第三方控制？
- 日志、备份、遥测和工单附件是否会流向其他司法辖区？
- 供应商收到政府数据请求时，是否有通知、质疑和透明度报告机制？
- 合同终止后，数据和密钥能否被验证删除？
因此，“欧洲机房”更适合作为一个证据项，而不是主权合规的结论。供应商仍需拿出架构图、分包商清单、访问日志、合同条款和密钥管理方案，让采购、法务和安全团队能够交叉验证。
不必在主权云和 hyperscaler 之间二选一
空客将这次选择描述为对多云战略的补充，而不是离开 AWS。这种定位更贴近大型系统的现实：不同工作负载面对的法律风险、迁移成本和平台依赖并不相同。
可以按数据和操作风险划分部署位置：
| 工作负载 | 更值得关注的因素 | 可考虑的部署策略 |
|---|---|---|
| 公开网站与静态资源 | 全球分发、抗攻击、成本 | 继续使用成熟 hyperscaler/CDN |
| 内部协作与普通业务系统 | 身份边界、SaaS 分包商、日志位置 | 多云部署并强化合同和访问控制 |
| 受监管数据与敏感研发资料 | 域外访问、密钥控制、运维人员辖区 | 主权云或隔离环境，客户持有密钥 |
| 跨境分析任务 | 数据最小化、匿名化、派生数据 | 在本地脱敏后只输出必要结果 |
这种分层方式避免了“一次性搬走所有系统”的高风险迁移，也能把主权云容量优先留给真正敏感的资产。不过，多云会增加身份管理、网络连接、可观测性和灾难恢复的复杂度，团队必须明确由谁承担这些运营成本。
把法律风险变成可审计的采购门槛
下面是一份可以这样实践的招标策略示例，并非空客实际采用的权重。关键点是把不可妥协的条件设为硬门槛，再对其余能力评分，避免供应商用低价格抵消无法接受的法律风险。
将以下内容保存为 tender-policy.yaml，再按组织所在司法辖区和法务意见调整：
policy_version: 1
hard_gates:
- id: customer_controlled_keys
requirement: Customer controls production encryption keys
required_evidence:
- key-management architecture
- key revocation test
- id: support_access_logging
requirement: Every privileged support session is approved and logged
required_evidence:
- access workflow
- sample immutable audit log
- id: subprocessors_disclosed
requirement: All subprocessors and processing locations are disclosed
required_evidence:
- current subprocessor register
- contractual change-notification period
scored_criteria:
technical_capability:
weight: 30
evidence:
- availability history
- recovery exercise report
extraterritorial_law_protection:
weight: 25
evidence:
- corporate control structure
- government request policy
- legal challenge procedure
security_operations:
weight: 20
evidence:
- privileged access controls
- incident response report
portability:
weight: 15
evidence:
- export formats
- tested exit plan
commercial_terms:
weight: 10
evidence:
- five-year cost model
minimum_total_score: 75
评审过程也不应只接收供应商填写的“是/否”。可以把每项证据记录为 provided、verified、expired 或 missing，并要求关键证据有负责人和复核日期。下面的命令可先检查 YAML 格式，再交给内部采购系统处理：
python -m pip install pyyaml
python - <<'PY'
from pathlib import Path
import yaml
policy = yaml.safe_load(Path("tender-policy.yaml").read_text())
weights = policy["scored_criteria"]
total = sum(item["weight"] for item in weights.values())
assert total == 100, f"weights must total 100, got {total}"
assert policy["hard_gates"], "at least one hard gate is required"
print("Policy is valid")
print("Hard gates:", len(policy["hard_gates"]))
print("Scored criteria:", ", ".join(weights))
PY
在正式实施中，评分程序还应保留评审人、证据版本、利益冲突声明和每次改分记录。否则，再精细的权重也可能退化成无法解释的采购结论。
风险已经延伸到小型 SaaS
域外法律风险并不限于大型云平台。一个规模不大的美国 SaaS 也可能处理源代码、设计文件、客户名单、身份信息或事故工单，并通过日志平台、客服系统和分析工具继续向外传递数据。
审查 SaaS 时，可以先追踪实际数据流，而不是只看供应商主页上的“数据驻留”标签：
- 列出上传的原始数据、元数据、日志和备份。
- 标出身份提供商、邮件、监控、客服和 AI 功能涉及的分包商。
- 验证管理员访问是否需要客户批准，是否产生不可篡改日志。
- 检查客户管理密钥是否真正阻止供应商解密，而不只是提供一个独立密钥名称。
- 用退出演练验证数据导出、账号关闭、备份到期和密钥吊销。
“主权”本身不是安全认证。供应商位于欧洲，也不代表它自动具备成熟的漏洞管理、备份恢复和事故响应能力；反过来，技术能力很强，也不能消除企业控制关系和法律管辖带来的风险。
落地时保留三条边界
采购团队可以从一类高敏感工作负载开始试点，同时保留现有多云平台。上线前至少确认三件事：法律风险是否由法务形成书面判断，技术声明是否由安全团队通过证据验证，退出计划是否真正演练过。
评分表适合帮助组织做出一致决策，但不能把法律问题伪装成一个精确数字。硬门槛负责阻止不可接受的方案，评分负责比较合格供应商，持续审计则负责确认供应商在合同签署后仍然满足承诺。只有这三层同时存在，主权云才会从采购标签变成可运行、可验证的工程控制。