AI API 合规评审怎么画数据流：短期状态、客户数据与删除责任

团队把长耗时的 Responses API 请求改成 background: true 后，测试环境一切正常，到了合规评审却卡住了：项目要求 Zero Data Retention（ZDR）也就是零数据保留，而后台任务又需要服务端在稍后取回状态。这两个要求不是配置项一开一关就能同时满足的，先把数据到底在哪里停留、停留多久说清楚，才能敲定最终架构。

先区分两个容易混淆的“保留”场景

普通 Responses API 请求的应用状态有自己的保留策略；后台模式还多了一层任务协调状态。后者不属于你的业务数据库，也不属于客户端缓存，而是平台为了让后台响应可以被查询、完成或取消，临时留存的服务端数据。

这正是评审时最容易漏掉的环节：代码里没有显式写 store: true，不代表服务端完全不保存后台任务相关数据。公开的数据控制文档说明，background 模式为支持轮询逻辑，会保存响应数据约 10 分钟。

为什么 background 模式与 ZDR 会发生冲突

ZDR 的核心要求不是“我业务侧不主动读取返回结果”，而是请求数据不能按普通应用状态的方式留存在服务端。后台任务要在初始 HTTP 请求结束后继续运行，平台必须保留足够的信息来返回状态和最终响应；这条运行链路和严格的零数据保留要求天然存在冲突。

官方说明给出的判断很直接：background 模式大约保留 10 分钟用于轮询，因此不兼容 Zero Data Retention。旧版 ZDR 密钥可能仍然接受 background=true，这是版本兼容行为，不是合规承诺。上线审核时应以官方能力说明为准，而不是以请求没有报错为准。

三个字段不能替你完成合规判断

• store: false：只表达应用状态存储偏好，不能抹掉后台任务为运行而需要的短期保存。
• background: true：表示响应异步处理，不表示响应数据由你完全掌控。
• ZDR 项目密钥：项目配置可能影响默认处理逻辑，但不能改变后台模式的必要保留窗口。

上线前用数据流图做一次反推

把一次请求从输入到删除的全流程画出来，比在代码里挨个搜索参数更靠谱。至少标出用户输入、平台后台任务、轮询或回调、你的结果库和删除动作五个节点。只要其中有一段需要平台在请求结束后暂存原始输入或输出，就不能把它标成严格 ZDR 路径。

实际评审可以按下面的顺序逐一核对：

1. 请求是否必须跨越一次 HTTP 连接继续运行？如果不是，优先保持同步调用。
2. 结果是否含有个人信息、客户文档或密钥派生内容？如果是，后台模式的短期保留也要纳入数据清单统计。
3. 业务是否真的需要平台侧后台状态？如果只需要做排队逻辑，可把任务标识和业务状态放在自己的队列与数据库里。
4. 供应商、合同或组织配置是否给出明确例外说明？没有书面依据时，不要用“参数被服务端接受”代替正式审批。

严格 ZDR 项目该怎么调整

最稳妥的做法是把敏感原文留在自己的受控系统中，只向模型发送完成任务所需的最小内容，并根据项目合规要求选择同步调用或已获批准的异步能力。自建队列只能解决业务排队和重试问题，不能自动改变模型平台的保留政策，这一点要在架构图旁边明确标注出来。

如果确实需要启用后台响应能力，应先让安全、法务和供应商确认该能力是否有适用的组织级例外，再决定是否上线。确认材料至少覆盖能力范围、数据类别、最长保留时间、取消失败后的处理方式，以及发生故障时谁负责删除和告警。

常见问题

把 background 改成 false 就一定满足 ZDR 吗？

不能直接这样推断。它只去掉后台模式这一层特殊保留，仍需按项目、模型和请求类型核对官方数据控制说明。

后台模式保留约 10 分钟，能否理解成永久不保存？

不能。短期保留仍然是保留，只要存在留存时长，就不符合零数据保留的定义。

只保存 response id，不保存正文，可以继续用 background 吗？

你的数据库只保存 id 并不会改变平台处理后台响应所需的数据路径，合规判断仍要看平台侧的实际数据处理规则。

最先该查哪份资料？

先看项目适用的数据控制和保留说明，再看 Responses API 的 background 参数与组织级 ZDR 资格，最后让合规负责人确认最终结论。

把“能调用”与“能上线”分开

background 模式解决的是长请求的连接与任务体验问题，ZDR 解决的是数据处理边界问题。两者服务的目标完全不同。只要把后台状态的必要保留单独列出来，再按敏感数据类型逐项核对，评审就不会被一个成功的 API 响应带偏。