数据驻留与区域控制

当一项隐私或行业法规要求数据必须留在某个司法管辖区内时,一个诚实的工程问题是:哪个系统、哪些数据,运行在哪里?一个只回答“我们是合规的”、却不说明应用运行在哪里、数据存储在哪里、哪些分处理商能接触到它的供应商,并没有回答任何你的传输影响评估能够使用的问题。数据驻留应该得到和这些页面上其他任何控制措施一样的证据标准:明确的地点、明确的选项,以及同时说明这两者的文档。

Ciao 的答案是结构性的。这个平台运行在 Kubernetes 之上,拥有隔离的 Pod 和多区域支持——而对驻留敏感的项目而言更重要的是,应用完全不必运行在 Ciao 的云上。部署到你自己的云账户、一个私有 VPC,或在另行约定条款下的本地环境,能把应用及其数据放进你已经掌控、监控并对其负责的边界和区域之内。这个选择是按项目做出的,而不是按供应商关系做出的:一个受监管的工作负载可以运行在你自己的欧盟云账户内,而约束较少的团队可以使用 Ciao 云,两者处于同一份协议和同一套治理模型之下。

正确答案取决于你选择的部署选项,这正是这个页面给你一张表格而不是一句口号的原因。在 Ciao 云上,区域选项会在采购过程中与企业团队一起确认。在你自己的云账户或私有 VPC 中,应用及其数据运行在你选择并治理的区域内。在本地部署中,它们运行在你的设施内。在每一种形态下,模型推理都受零保留期合约治理,模型供应商的驻留特性会作为分处理商讨论的一部分被审阅。

请留意这种表述拒绝去做什么:它没有为所有客户声称一个统一的答案,因为根本不存在这样一个答案。驻留形态是按项目选择的,正确的验证方式也因形态而异——这是表格里的一行,而不是一句宣传语。向任何供应商提出同样的问题,并坚持要求同样形式的答案。

把驻留方面的声明当作采购文档来对待。具体的区域信息、分处理商所在地和数据流细节,属于安全资料包和 DPA——两者都可通过联系页面按需索取——NDA 下的 SOC 2 Type II 报告则涵盖了它们背后经审计的控制环境。如果你的项目对驻留有严格要求,请在第一次对话中就说明:这些部署选项的存在,正是为了让平台能够满足这项要求,而不是与之争论。

对于需要在驻留要求和交付速度之间取得平衡的项目,实用的做法是完成一次评审、记录下被批准的形态,并在后续的构建中重复使用这个决定——后续项目继承这个形态,而不必重新讨论它。