日志留存与数据流向：接入前的尽调清单

把业务请求发到第三方中转，等于把数据交给一个额外的处理方。是否可接受，取决于六个具体问题能不能得到明确答复。

第一是留存时长。请求与响应是否记录、记录多久、以什么形式存储。多数站点会保留调用日志用于计费与排障，时长为 7 天到 90 天不等。留存越久，暴露面越大。

第二是存储地域。服务器在境内还是境外，决定了数据是否需要按跨境传输评估。同一家站点可能有多地节点，需要确认默认路由与是否可指定。

第三是是否用于训练。条款里如果只写“可能用于服务改进”，实际含义往往包含模型微调。需要的是明确的不用于训练的承诺，以及可验证的开关。

第四是删除机制。用户能否主动删除历史记录，删除后多久生效，备份中是否同步删除。没有删除入口的站点，只能靠留存期自然过期。

第五是子处理方。中转通常还会调用上游厂商，上游也有自己的留存政策。数据实际经过几方，需要站点明确列出，否则无法评估最终去向。

第六是访问控制。内部员工能否查看请求内容，是否有审计日志。这一项很难从外部验证，但可以从工单流程推断：如果客服能直接复述你的请求内容，说明内容对人工可见。

这六项不必都完美，但必须知道答案。对敏感业务，更稳妥的做法是在发送前做脱敏，把不可外发的字段在本地替换掉，这样即使链路出问题，损失也可控。

对无法满足要求的场景，技术上还有两条折中路线：一是在本地做字段级脱敏后再发送，二是把敏感任务改成本地小模型或私有部署。前者成本低但需要维护脱敏规则，后者一次性投入高但边界清晰。选择哪条，取决于数据敏感度与调用量，不必一刀切。