Grok 的数据处理与安全政策怎么读：从默认保留到 ZDR

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

xAI 官方安全 FAQ 里真正有决策价值的只有三块：一是「未经你明确许可，xAI 不会用你的 API 输入输出做训练」这句原文，二是默认状态下请求与响应会被加密存放一段固定的审计期、到期自动删除，三是 Zero Data Retention（ZDR）这个开关——它不是「更安全的默认值」，官方在文档里用警告框明确写了「对多数客户我们不建议开启 ZDR」，因为它会连带关掉有状态 Responses API、Files 与 Collections、Batch API、延迟补全、按 API Key 的请求日志等一批依赖服务端存储的能力。所以读这份政策的正确顺序是：先确认默认条款能不能满足你的合规要求，不能再谈 ZDR，而不是上来就把最严的挡位拉满。

先把「训不训练」和「存不存」两件事分开

这两件事经常被混着讲，但官方文档是分开写的，而且结论不一样。

关于训练，安全 FAQ 里是一个 NOTE 提示框，原文的意思是：未经你的明确许可，xAI 绝不用你的 API 输入或输出做训练。注意限定词是「明确许可」，也就是说这是一个默认关闭、需要你主动同意才打开的口子，而不是「你可以来关掉」的默认开启项。

关于存储，是另一件事：默认情况下所有 API 请求与响应都会存放在 xAI 的服务器上，文档明确写了是「加密存放（encrypted at rest）」，目的是在怀疑滥用或误用时可供审计，到期后自动删除。文档在开发者版与控制台版两处 FAQ 里都写了同一个保留期天数，我这里不抄具体数字——保留期属于会变的策略参数，以官方安全 FAQ 当前版本为准。文档同时补了一句：xAI 不会拿这批审计数据做训练。

把这两条并排放，你会发现一个很实际的结论：如果你的顾虑是「我的 prompt 会不会进模型」，默认条款已经把这条堵上了；如果你的顾虑是「我的数据不能在对方磁盘上落地哪怕一分钟」，那默认条款不够，得往下看 ZDR。这个区分做不出来，就会出现一种很浪费的情况：为了一个其实不存在的训练风险，把一堆好用的功能关掉。

ZDR 到底关掉了什么：这张清单要先算账

ZDR 的定义在文档里是三条：请求输入（也就是你的 prompt）与输出（模型生成的 token）永不落盘；作用域是团队级，不能只对某一个 API Key 开；在支持的环境下由团队管理员在控制台自助开关。开启之后上面说的审计保留期对该团队不再适用。

代价写在紧跟着的那张表里，官方逐项给了「为什么不可用」的理由。按我的理解归一下类：

依赖服务端会话状态的：有状态 Responses API 失效，store_messages、previous_response_id 这一套没法用，对话历史必须由客户端自己存。文档还专门提醒，涉及 agentic 工具调用的状态要记得启用 use_encrypted_content——这条很容易漏，因为它不是「关掉一个功能」，而是「换一种把状态带回来的方式」。

依赖服务端存文件的：Files API 与 Collections API。ZDR 开启后新的上传和用 file_id 挂附件都会被挡，但已有的文件和集合还能查看和删除。这也解释了开启流程里那个看起来很怪的前置条件（见下一节）。

依赖排队存请求的：Batch API 与延迟补全（deferred completions）。Batch 的请求要先存下来等着被处理，延迟补全是先返回一个请求 ID、结果存着等你来取，两者都和「不落盘」直接冲突。文档特别澄清了一点：客户端侧的并发请求（比如用 AsyncClient）不受影响——并发和「批量排队」是两码事，别搞混。

依赖服务端托管产物的：图像与视频生成的存储输出。ZDR 下没有 xAI 侧的输出存储，图像只能返回 base64 格式、不能用 URL 形式，视频必须由你自己提供 output.upload_url 让 xAI 把结果传到你的地址；文档还写了图像生成会被限制在 grok-imagine 系列且不含 agentic 图像生成，控制台 playground 里的视频生成同样不可用。

日志类：按 API Key 的请求日志记录不再保留，而且开启 ZDR 时，已有的按 Key 请求日志开关会被清掉。语音 agent 的对话历史也不再持久化。

顺带一提，Batch 那一行原文里带了价格性描述，本文按站内惯例不抄——只需知道 Batch 接口按低于标准价计费，具体比例看官方定价页。

开启流程里那个反直觉的第二步

官方给的开启步骤是四步：以团队管理员身份登录控制台并在团队选择器里选对团队；删掉该团队下已有的 Files 和 Collections；进团队设置找到 Zero Data Retention 那一行点 Enable；在确认弹窗里逐条确认（包括「被删除的 User Content 无法恢复」这一条）并接受企业条款与隐私政策。

第二步是最容易卡住的地方，控制台会在存量文件或集合没清空时直接禁用 Enable 按钮。这个设计其实说得通——既然承诺不落盘，就不能留着历史落盘物，但对操作的人来说是个硬前置：你得先决定那些已上传的语料还要不要，要的话先自己备份到本地或自有对象存储。别在变更窗口里现场发现这件事。

开启之后不需要改代码，团队下所有 API Key 的请求自动生效，关掉也是同一行点 Disable。如果你压根看不到 ZDR 这一行，文档给了三种可能：你不是团队管理员、你所在环境还没放开自助 ZDR、或者你的团队签的是单独约定留存条款的企业协议——最后这种情况官方让你联系销售邮箱确认。

怎么确认它真的开了：认响应头，不认截图

这一节是全篇最有工程价值的部分。官方给了四种确认方式，其中只有一种能被程序自动校验：

• 团队设置里 Zero Data Retention 那一行会显示 Active 徽标
• 控制台团队选择器里团队名旁边会挂一个 ZDR 徽标（悬停提示是 Zero Data Retention）
• 每个 API 响应都会带一个 x-zero-data-retention 响应头，取值是 "true" 或 "false"，你的应用可以据此在程序里确认当前是否处于 ZDR 状态
• 审计日志里仍然能看到管理类事件（建 Key、改团队等），但请求与响应的内容不会出现

如果你要给审计方拿证据，前两条是人看的截图，第三条才是能进你自己监控体系的东西。合理做法是在调用侧把这个响应头采下来，作为一条配置漂移告警——毕竟 ZDR 是团队级开关，某个管理员在控制台点一下 Disable，你的代码不会有任何报错，只有这个头会从 true 变成 false。把它接进 API 调用成本与状态监控 那套面板里，比每季度人工去后台看一次靠谱。

审计日志：能查到人做了什么，查不到模型说了什么

安全 FAQ 里关于审计日志的原文很短：团队管理员可以查看用户交互的审计日志，列出所有用户与 API 服务端的交互，入口在控制台的 Audit Log 页。管理员可以按 Event ID、Description 或 User 过滤，文档举的例子是按 Description 匹配 ListApiKeys；也支持按时间范围筛选。

要注意它的边界：审计日志的定位是管理面事件，不是内容留存。ZDR 那一节已经说清楚了——administrative events 照常记，请求与响应的内容不记。所以如果你的合规要求是「所有对模型的提问都要可回溯」，靠平台侧的审计日志是拿不到的，得在你自己的网关层做落盘，这反而是自建日志的正当理由。

密钥这条线：官方建议和泄漏之后的自动处置

密钥管理这一段官方给的建议本身不新鲜——把 Key 当密码或信用卡信息对待、不要在同事之间共用（避免越权无法追溯）、用环境变量或密钥管理工具存放、不要提交进公开仓库、定期轮换。这些和站内 API Key 安全管理 讲的通用做法是一致的，不必重复。

真正值得记住的是两条 Grok 特有的操作细节。

第一，怀疑泄漏时的处置顺序有个坑：登录控制台后先确认你在正确的团队视图下，因为 API Key 是绑定到具体团队的。选错团队你会在列表里找不到那把 Key，然后开始怀疑人生。找到之后在 API Keys 表格里点那一行的竖排三点，Disable key 是临时停用、Delete key 是永久删除，再用 Create API Key 建新的并更新应用。临时停用这个挡位在排查时很有用——你不确定是不是这把 Key 出问题时，先停用观察，比直接删掉留有余地。

第二，xAI 与 GitHub 的 Secret Scanning 计划有合作：如果扫到泄漏的 Key，官方会直接禁用它并发邮件通知你。这意味着一种你可能没预料到的故障形态——线上突然大面积鉴权失败，原因不是你改了什么，而是有人把 Key 提交进了公开仓库、被扫到后平台侧自动封了。排 401/403 时把「查一下邮箱有没有平台通知」列进检查清单，能省不少时间。轮换节奏怎么定，可以参考 API 密钥轮换。

资质、企业口子与国内团队的现实约束

合规资质部分官方写得很克制，只有三条：SOC 2 Type 2 已合规；签了保密协议的客户可以去 Trust Center 查最新的认证与数据治理信息；HIPAA 相关的 BAA（业务伙伴协议）走一份问卷，团队审阅后再跟进。换句话说，除了 SOC 2 Type 2 这条能公开引用，其余细节都在 NDA 之后——你要给内部合规评审交材料，得先走商务流程拿 Trust Center 访问权，别指望公开文档里能扒到审计报告。

企业侧还有一条链路值得连着看：mTLS 双向认证。文档把它标为企业功能，需要联系官方支持邮箱开通，开通时要提供团队 ID、PEM 格式的 CA 证书，以及你系统所用客户端证书的 Common Name。开通后唯一的改动是把域名换成 mTLS 专用的接入域名，路径不变，请求里带上客户端证书与私钥即可，官方明确说所有既有功能（模型、工具、流式）行为一致。对「每个请求都要有密码学身份证明、光有 API Key 不够」的零信任场景，这是官方给的正规路径。

至于国内团队最关心的区域可用性问题：xAI 的安全 FAQ 与控制台 FAQ 这两页里，我没有找到关于中国大陆可用性的任何说明，因此这里不做推断。要给国内业务选型，务实的做法是按 国产模型 API 的可达性与合规取舍 那套框架，先确认数据出境与备案口径能不能过，再决定是走境外模型的企业采购路径还是换国内合规服务方。这一步没结论就先别写代码。

最后：这份政策该怎么用

给一条我认为最实用的读法——把它当成一张「先关问题、再关功能」的决策表：合规方问「会不会拿去训练」，答案在默认条款里，不需要动任何开关；问「数据能不能不落盘」，那就得同时把 Files、Collections、Batch、有状态 Responses 这几项的替代方案一起端上桌，因为 ZDR 是团队级的一刀切，没法只对某一个 Key 生效。真正的风险不在于选错挡位，而在于开了 ZDR 却没人告诉业务方 Batch 用不了了，等到跑批那天才发现。开之前先把这张功能失效清单发给用得着它们的人确认一遍，比开完再回滚省事得多。