平台说不留存内容，客户要问的是这四件事
一、“不留存”是一个开关，不是一句承诺
一家模型服务平台宣布要上线数据内容不留存机制，任何用户都可以申请开通，生效后平台不对输入和输出做静态存储，相关数据只用于完成当次调用。这是一条好承诺，但承诺越具体，越需要被核验而不是被相信。客户把这句话转述给自己的下游之前，真正要问的是四件事：什么不留、哪里还留、谁生效、怎么证明。这四件事问不清，同一个开关很容易被理解成它字面并没有覆盖的东西。洹拓替客户评估这类隐私条款时，从不从“留不留”开始，而是把这四问当成一套固定动作。因为“留不留”是一句可以被真心实意说错的话：平台方未必有意误导，但它的开关设计者想的往往只是推理链路那一层。把这四问拆开，是把一句宽泛的好意还原成一组能被逐条确认的事实。
二、先把“留存”拆成四类分别确认
留存不是一个笼统动作，至少要拆成四类，一类一类确认，因为“不留存”这句话通常只落在其中一类上。
- 推理链路上的临时缓存：为了完成这一次调用而短暂存在内存或临时介质里的内容，不留存针对的多半就是这一类。
- 用于安全审核的内容送检：请求被送到内容安全环节做检查，这一段算不算留存，要看它被记在哪一层、留多久。
- 用于效果分析或训练回流：调用内容被采下来做统计或者喂回训练，这是敏感度和误读都最高的一类。
- 计费与排障所需的元数据：为了出账和定位故障而必须保留的那些字段。
最常见的误读就在这里：把“不留存”默认理解成四类全不留，而这句话一般只覆盖第一类，其余三类各有各的处理口径，不能从三个字里顺推出来。安全送检和效果回流这两类尤其要单独追问，因为它们往往由平台的另一套流程掌管，不在这个开关的作用范围里；把它们算进“不留存”，是签了合同才发现口径对不上。
再说措辞边界。“静态存储”强调的是不长期落盘，但不等于不落日志。请求标识、调用时间、内容长度、返回码这些元数据大概率还在，而元数据本身有时足以反推内容类别——一段调用有多长、发生在什么时候、成没成功，凑起来就能大致判断这是哪一种用途。把“不留存”听成“什么都不留”，越界正是从这一层措辞开始的。
三、谁享受、从什么时候起
“谁生效”问的是作用域。这个开关可以按四种粒度里的任一种定义：按账号、按密钥、按接口，或者按工作空间。粒度决定了同一账号下不同应用能不能一起享受——按账号最省事，按接口最细但要逐个配。最容易漏的是密钥维度：开关绑在某个密钥上，新签发的密钥不会自动带上这条策略，等有人拿新密钥跑了一批生产调用，才发现这一路根本没进不留存的作用域。这也是为什么按账号定作用域比按密钥定作用域更稳——密钥会随环境、随团队不断新增，账号数量却相对可控，作用域挂在越少的对象上，越不容易出现“某条路径忘了开”。
“生效”问的是时点，三个问题要有明确答案：申请之后隔多久才真正生效；生效之前已经提交的那批数据怎么处理，是补做一次清理还是就此了断；生效之后能不能随时读回当前状态。最贵的一类事故几乎都写作“我以为开了”，它往往出在第二个和第三个问题没人确认，而不是出在开关本身。
四、怎么证明：三条核验路径与审计三件
“怎么证明”决定了这件事能不能落到合同和纠纷层面。可核验的路径有三条：一是有没有配置读回的接口或视图，能把当前作用域和开关状态查出来；二是调用返回里有没有带一个策略标识，能把某一次调用和某一条策略对上；三是有没有按周期出具的留存状态声明，能在事后证明一段区间内的口径。控制台截图不能当长期证据，它只证明按下快门那一刻的界面，既证不了那一刻前后配置没被改动，也证不了别的密钥是否同样状态。
审计侧要留下三样东西：开关的变更历史、每一次变更的操作者、以及每次调用携带的策略标识。真出了分歧，靠这三样说话，而不是靠一句“我们申请过”的记忆。这三样最好落在我们自己的日志里而不是只依赖平台侧的记录——平台能读回的是它的状态，我们要能独立证明“某次调用当时走的确实是这条策略”，两者对得上才算证据链完整。
还有一条例外要写明而不是藏着：命中安全策略被拦截的内容，通常会因安全环节的要求而保留，这一类不在不留存的覆盖范围内。它必须如实进入内部风险告知，否则客户以为全链路都不留，等合规复核才发现有一段一直在留。
五、合同文本要和技术口径对齐
技术开关和合同条款要对得上。协议里只写一句“平台不留存客户数据”是不够的，开关的名字、作用域和例外条款都要落到合同正文，让文本口径和技术口径指向同一件事；两边一旦不一致，以哪个为准也要提前约定，不能留到出事再争。
对做转售和集成的我们，更要紧的是上下两层要一致。把上游的不留存写进自家隐私政策之前，先确认自己这一层到底留不留。上游不留、我们却把调用内容存进了自建日志或数据库，两层承诺就是打架的，而最后把话写给终端客户、因此要担违约责任的是我们。承诺宁可写窄，也不要写一套做一套。更稳妥的写法是把自家这层的留存口径单独列清楚：哪些字段我们留、留多久、为了什么，然后说明上游那一层按它的不留存处理——两层各说各的、都能核验，比一句笼统的“全链路不留存”经得起查。
六、上线前的六项自查
在把这条承诺写进任何一份对外文档之前，六项要逐条过一遍。
| 自查项 | 判据 |
|---|---|
| 作用域 | 开关按账号、密钥、接口还是工作空间生效，新密钥是否自动纳入 |
| 生效时点 | 从申请到生效的间隔，生效前已提交数据如何处置 |
| 状态可读回 | 能否随时查出当前处于哪一档、覆盖哪些调用路径 |
| 策略标识入日志 | 每次调用是否带上可与策略对上的标识 |
| 例外条款 | 安全拦截内容等仍保留项是否写进风险告知 |
| 合同对齐 | 合同是否把开关名、作用域、例外写死并与技术口径一致 |
一张表跑完，客户要确认的其实不是“你留不留”，而是“你凭什么证明你不留、又凭什么让我下游也信”。一个不留存开关能不能被核验，直接决定了它值不值得被写进交付承诺里——能被读回、能对上的承诺才站得住，只有界面截图的承诺，出了分歧第一时间塌的是它。我们给客户做这类集成时的底线是一句话：拿不到可核验证据的承诺，就按“会留存”来设默认风险，而不是按宣传语来设。