零数据留存与滥用监控

ZDR 删掉了什么，又从来没碰过什么。

商用 API 的默认并不是"我们什么都不留"。通常是一个短的滥用监控窗口——各大厂商的常见数字是三十天——在此期间输入与输出会被保留，以便自动与人工复核能抓到滥用，期满后删除。是否拿你的商用 API 流量去训练，是另一个问题，且一般默认关闭；把这两件事混为一谈，是这类对话里最常见的错误。

一份零数据留存安排，为符合条件的端点移除了那个滥用监控窗口：请求被处理，什么都不落盘。它从来没有覆盖过的，是一切并非请求内容的东西——账户元数据、账单记录、聚合用量遥测，以及"发生过一次处置动作"这条记录本身。它也不向后追溯：今天启用 ZDR，并不会删掉昨天已被保留的内容。

所以准确的说法是"在这些端点上、在这些条件下、自此刻起，内容不落盘"。如果你的隐私声明写得比这更宽，那它就是错的，而一次删除请求正是你发现这一点的那一刻。

"零"如今带着例外，而且例外在变多。

2026 年的走向，正是多数政策文本还没跟上的那一块。随着前沿模型的安全计划扩张，厂商已开始要求那些 ZDR 原本会移除的留存。截至 2026 年年中，Anthropic 的条款对其"covered models"要求有限的留存与复核——提示词与输出保留三十天以支持其安全工作，在提供这些模型的每一个平台上都适用——并把这作为使用它们的条件，纵有 ZDR 亦然。被标记的流量走得更远：与疑似违规相关的内容最长可保留两年，而信任与安全的分类评分最长可达七年。

把这些数字读成一种形状，而不是一句引文，因为它们会变。真正要紧的是形状：ZDR 正在收敛于"没有例行留存"，而不是"没有留存"，而那些例外，恰恰附着在最可能敏感的那部分流量上。一个处理非常规请求的智能体——一位情绪激烈的客户、一次安全事故、一份关于安全事故的文档——更容易触发分类器，因而也更容易落进长留存那一支。这与你那份数据保护评估多半假定的相关性，正好相反。

边界是逐次调用的，而智能体调用得很多。

一个聊天机器人只发一种请求。而一次智能体任务可能触及六个端点，每一个都有自己的留存状态：

one task, six boundaries

  main reasoning model      ZDR? depends on model class
  embedding endpoint        often a different product, different terms
  reranker / classifier     frequently a third vendor entirely
  moderation / guardrail    may be outside the ZDR agreement by design
  code-execution sandbox    logs stdout somewhere; whose?
  fallback provider         the one that fires only when the first is down

栽人的是兜底那一条。一个被配置成遇 529 就切换的网关，会恰好在所有人都分神的那次厂商事故期间，把你受监管的流量路由到一家你与之既无 ZDR 安排、可能也无数据处理协议的厂商那里。切换路径需要与主路径同等的评审——见优雅降级与兜底——而最便宜的强制手段，是在你的AI 网关里放一份允许清单，拒绝任何不在批准名单上的路由，而不是一份"假定没人加过新路由"的政策文件。

因此你需要的清点，不是"我们用了哪些厂商"，而是"一次任务触及哪些端点、每一个的留存状态是什么"。从追踪里生成它，而不是从架构图里；架构图上不会有那个六月被人加进去的重排器。

你放弃的是：厂商那份副本，同时也是你的证据。

ZDR 有一项很少出现在采购对话里的代价。如果有客户报告你的智能体说了有害的话，或者你正在调查一个智能体是否被操纵着把数据外泄出去，那么厂商侧的记录，是关于"究竟发了什么、返回了什么"的少数几份独立说法之一。在 ZDR 之下，它不存在。你的日志就是唯一的故事，而它正是由那套受怀疑的系统写下的。

这是扛得住的，但前提是你有意识地作出这个决定。ZDR 是抬高而不是降低了对你自身可观测性的要求：你如今需要完整到不靠厂商也能重建一次请求的追踪、留存久到覆盖你的调查窗口、并且保护到足以作为证据可信。形态见智能体的追踪与可观测性；你要找的东西是什么，见检测智能体被攻陷。

还有一项值得点名的二阶效应。有些厂商只对通过审核的客户提供降低的滥用监控，有些则把 ZDR 档位与关于可接受使用的合同承诺挂钩。这是一笔合理的交易，而它意味着 ZDR 不是一个你一拨即成的开关——它是一段你要维持的关系，而且可以被收回。

你自己的留存才是更大的敞口，而 ZDR 对它无能为力。

团队买下 ZDR，然后在自家系统里无限期地存着：每一条提示词、每一段工具结果、每一份检索到的文档、每一次模型输出，外加智能体写进记忆里的一切。那个库里的敏感材料，比厂商那三十天窗口里曾经有过的还多，被更多人检索，而且它才是监管者或诉讼对手真正够得到的那一个。

由此有四条后果，而它们没有一条是厂商的问题：

• 工具结果承载的是别人的数据。一份检索到的文档、一条 CRM 记录、一张客服工单——这些材料不是智能体创造的，而你的追踪库如今是它们的第二份副本，落在源系统那套访问控制之外。读侧的控制是权限感知检索；写侧的控制是追踪脱敏。
• 记忆是一份你没申报过的留存。智能体跨会话持久化的任何关于用户的东西，都是个人数据，而且除非你给过它一份留存时间表，否则它没有；而删除它比删掉一行日志难得多。
• 删除请求与法律保全拉向相反方向。删除请求够得到你的库；保全则把它冻住。在两者同时到来之前先定好优先级——见留存与法律保全。
• 在写入时就脱敏。等有人打开一条追踪时才施加的脱敏，不叫脱敏。把它放进管道里做，抽样验证它确实生效，并度量漏检率，见从智能体追踪中脱敏 PII。

把这份主张做成可检验的。

一份只存在于合同里的留存姿态，是一份你会在审计当中发现它是错的姿态。三种机制能把它变成你可以演示的东西。

第一，逐模型出具声明。就你所使用的每一个模型、每一个端点，索要并归档一份带生效日期的留存行为声明，并在每个合同周期与每次采用新模型时重新索取。一封账户层面的通函，并不构成关于嵌入端点的证据。

第二，在链路上强制。把批准过的端点清单放进网关，其余一律失败关闭。然后写一个测试来证明它：一个被路由到未批准模型的请求应当被拒绝，而这个测试应当像其他测试一样跑在 CI 里。一项你从未试图击破的控制，只是一个假设。

第三，一份任务粒度的数据地图。就一条有代表性的任务，列出触及的每一个端点、每一处离开的是什么内容、留存状态如何、法律依据是什么。这份产物能用同一页纸回答一份数据保护评估、一份客户安全问卷与一位检查员的提问——而团队通常正是在做它的过程中，发现了那个重排器。