安全与合规
ABetterChoice 的合规姿势直接来自它的 Warehouse Native 部署模型： 你的原始数据从不离开你的数据仓库，因此平台需要被审计的"数据面"被刻意收得很小。
你需要审阅的文档
| 文档 | 什么时候需要它 |
|---|---|
| 数据驻留 | 安全评审里回答"我们的数据物理上放在哪里"。 |
| 隐私政策 | 审阅 ABetterChoice 如何处理账号级别的个人信息。 |
| Cookies 政策 | 审阅 ABetterChoice 控制台的浏览器侧追踪。 |
运维责任分工
因为 ABetterChoice 直接从你的数据仓库读取数据， 责任模型沿着一条少见地清晰的边界划分：
- 客户（你） 拥有数据仓库、原始数据、IAM 授权以及仓库凭证的生命周期。
- ABetterChoice 拥有控制平面（控制台、统计引擎、调度、结果表写回）、SDK 以及你在控制台中创建的 API 密钥。
具体后果：
- 在 BigQuery 连接 中回收授给 ABetterChoice 的 IAM 角色， 平台对你仓库的读取立即中断。
- 在 API 密钥 中 Deactivate 某把密钥， 对应 SDK 的全部请求立即被拒绝。
- 在 用户角色和权限 中删除某位成员， 对方的控制台访问立即吊销。
暂未覆盖的能力
下列能力在路线图上，但当前尚未普遍可用。 如果你的安全或采购流程必须依赖它们，请在采用平台前先和支持团队对齐时间表：
- 企业级 SSO 与 SCIM 自动化用户开通。
- 控制台内自助式的用户数据删除（GDPR / DSAR）流程。
- 可下载的合规材料包（SOC 2、ISO 27001）。
短期内推荐的最佳实践：
- 把敏感数据始终留在你既有的仓库与安全边界内。
- 把 ABetterChoice 控制台当作控制平面对待——严格控制成员名单，并通过 变更管理 审计每一次变更。
- 像管理其他服务凭证一样，把 API 密钥纳入同一个轮换节奏。