什么是数据驻留，我的消息数据存储在哪里？

你选择的区域决定了 Bird 在哪里存储和处理你的组织数据，同时也影响适用哪些跨境隐私规则。

我的数据存储在哪里？

在创建组织时选定的单一区域中。

每个 Bird 组织在注册时被分配一个区域。us1 是美国，eu1 是欧盟，区域文档说明了该分配涵盖的内容：

Every organization is assigned a region at signup. The region is detected from your location, can be changed before you confirm, and is immutable in v1. The workspace, API keys, messages, recipient data, and event logs remain in that region. They are never replicated across regions.

需要留意的关键表述是 "never replicated"。如果驻留承诺允许为了冗余或分析而在其他地方保存副本，那它就不是真正的驻留承诺。这里的数据平面在每个区域是真正独立的，这也是该选择不可变更的原因：在区域间迁移组织不是一项设置，而是一次迁移，当前 API 版本不提供此功能。

如何执行？

通过凭据和路由机制执行，确保错误能被明确暴露。

数据平面没有单一的全局端点。每个区域有自己的主机，API 密钥在前缀中标明其所属区域：bk_eu1_ 密钥属于 eu1。SDK 和 CLI 读取前缀并自动选择主机，无需额外配置。

请求被发送到错误位置时会发生什么，这才是关键：

A request that reaches the wrong region is rejected with 421 Misdirected Request instead of being forwarded. The error message names the correct host

拒绝而非转发，是使驻留可验证的设计决策。如果平台静默代理了一个误发的请求，虽然使用起来很方便，但也意味着携带个人数据的请求在无人察觉的情况下跨越了边界。而这里不会发生这种情况：请求直接失败，错误信息会指明应使用的主机。

每个响应还携带一个 X-Bird-Region 请求头，标明服务该请求的区域，这样你可以确认调用实际到达了哪里，而不必依赖配置。

哪些内容不受区域约束？

身份验证和账户管理，文档对此作了明确说明，而非隐含处理：

Only authentication and account administration (/v1/auth, /v1/admin) operate on globally replicated data, which is why they are served from the non-region host platform.bird.com.

这一点值得了解，不应忽略。登录和账户管理涉及必须在任何地方可用的身份数据，因此这两个层面在设计上是全局的，而与消息和收件人相关的一切则不是。如果你在记录自己的数据流，这个区分就是需要划定的边界。

驻留是否决定了我的消息发往哪里？

不是。将两者混淆会在两个方向上都得出错误的结论。

驻留是指你的数据在哪里存储和处理。投递则关乎你的收件人在哪里，受覆盖范围、当地法规和制裁措施的约束。eu1 组织可以向 Bird 投递覆盖的任何地区的收件人发送消息，us1 组织也可以向欧洲收件人发送消息。支持的国家和限制涵盖了投递方面的内容。

驻留真正决定的是该消息记录之后存储在哪里：消息本身、收件人数据、事件日志。这些记录通常才是数据保护问题真正关注的内容。

我应该提前决定什么？

区域，因为它是这其中唯一无法事后更改的部分。

由于分配一经确认便不可变更，区域选择应纳入创建生产组织的流程中，与其他一次性决策一并处理。在错误区域创建测试组织只是小麻烦；生产组织则意味着一次迁移。

还有两件相关事项应同时确定，因为在大多数审查流程中它们总是一并出现：约束双方关系的数据处理协议，以及提供商在哪里发布其子处理商列表。位于其他司法管辖区的子处理商属于数据传输问题，仅靠数据驻留无法解答。