一把 key 上聚合站到底记了什么：在发敏感数据前先摸清提示词与响应的留存范围
本文拆解一次 LLM API 请求在聚合站与上游厂商两层的留存痕迹，包括提示词、补全、请求头和时间戳，并给出用一把 key 推断留存边界的方法，帮助你在发送敏感数据前评估风险。
请求链路：一次调用经过哪几层
当你用聚合站的一把 API key 发起请求时，数据通常会经过至少两层：聚合站的网关和上游模型厂商的 API。理解每一层可能留下什么记录，是评估敏感数据风险的第一步。
- 聚合层：负责鉴权、计费、路由到不同模型。这一层能看到完整的请求体和响应体，也可能记录元数据（时间、模型、token 数、状态码）。
- 上游厂商层：实际执行推理的模型服务。这一层同样能接触提示词和补全，并可能按厂商自己的策略留存日志。
关键点：聚合站无法替上游厂商承诺留存策略，上游厂商也看不到聚合站的日志。两层的留存边界需要分别推断。
聚合层可能记录什么
聚合站作为中间人，出于计费、排错和滥用防护的需要，通常会记录以下内容：
- 请求体：提示词、系统消息、函数调用参数。是否完整留存取决于实现，可能只记录哈希、摘要或采样。
- 响应体：模型返回的补全内容，同理可能完整留存或只记录元数据。
- 请求头：API key 的标识（通常不是明文）、User-Agent、客户端 IP、请求 ID。
- 时间戳与用量：请求时间、延迟、输入输出 token 数、模型名称、状态码。
这些记录的目的不同，留存时长也不同。计费数据往往保留较久，调试日志可能短期滚动删除。
上游厂商层可能记录什么
上游厂商能直接看到提示词和补全，其留存策略由厂商自己的条款决定。常见情况包括：
- 滥用监控日志：部分厂商会短期保留请求内容用于安全审查，时长从数天到数月不等。
- 计费与用量记录：通常只保留 token 数和模型信息，不包含内容。
- 训练用途：是否用你的数据训练模型，取决于厂商和账户类型，需要查阅具体条款。
聚合站无法改变上游厂商的留存行为，因此敏感数据是否发送，最终取决于你对上游厂商的信任程度。
用一把 key 推断留存边界
你无法直接查看聚合站或厂商的日志，但可以通过受控实验推断留存边界：
- 构造唯一标记：在提示词中嵌入一个随机字符串（如 UUID），确保它只出现在这一次请求中。
- 观察回显与关联：如果聚合站提供请求历史、日志查询或用量明细，检查该标记是否出现在可查看的记录中。这能告诉你聚合层至少留存了什么。
- 测试删除与导出：如果平台提供数据删除或导出功能，尝试删除后再查询，观察标记是否消失，推断留存周期。
- 分模型对比：用同一标记分别调用不同上游模型，对比聚合站记录的内容差异。如果某些模型的请求体不被记录，说明聚合层可能按模型做了差异化处理。
- 检查响应头与错误信息：部分聚合站会在响应头中返回请求 ID 或上游追踪 ID，这些 ID 可能关联到上游日志，可作为进一步询问的依据。
注意：这些方法只能推断聚合层可见的部分，无法穿透到上游厂商的内部日志。
发敏感数据前的检查清单
在把敏感数据交给任何 API 之前，建议逐项确认：
- 聚合站的隐私政策是否明确说明请求体留存时长和用途。
- 上游厂商的条款是否允许将数据用于训练，以及滥用监控日志的保留期。
- 是否支持关闭内容日志或选择不留存的模型路由。
- 是否有数据删除请求渠道，以及响应时间。
- 你的合规要求是否允许数据经过聚合层和上游两层。
如果以上任何一项无法确认，最稳妥的做法是不发送敏感数据，或在发送前做脱敏处理。
小结
一把 key 背后的留存边界由聚合层和上游厂商层共同决定，两层各自独立。通过嵌入唯一标记、观察平台记录和测试删除，你可以推断聚合层至少留存了什么，但上游厂商的内部日志仍需依赖其条款和信任。在发送敏感数据前，先摸清这两层的边界，再决定是否发送。