周五上线前，给客服助手写一份少留数据的日志政策

客服助手上线前，先确定日志要回答的问题

假设你的小团队周五要上线一个客服助手。遇到请求失败，你想知道是超时、额度不足，还是程序出错；但你不需要因此保存客户整段对话。隐私友好的日志政策，就是提前约定：为了排障和运营，我们记录哪些信息，谁能查看，多久删除，哪些内容绝不进入日志。

它不等于“完全不记日志”，也不只是隐私声明里的一句话。它应该直接指导开发者设置日志字段、配置监控平台和处理故障。第一版不必很长，但每一项都要能落实到代码或操作流程。

用字段白名单代替“先全部保存”

先列出真正需要回答的问题，再选择字段。例如，判断接口是否稳定，通常只需要请求标识、时间、状态码、耗时、用量和内部错误分类，不需要提示词或模型回复。采用白名单，意味着没有明确批准的字段默认不记录。

• 默认记录：随机生成的请求标识、接口路径模板、响应状态、耗时和重试次数。
• 按需记录：租户的内部代号、模型标识和用量；这些字段仍可能关联用户，需要限制用途。
• 默认禁止：接口密钥、授权请求头、完整提示词、模型回复、上传文件和支付信息。
• 单独评估：IP 地址、设备标识和完整网址。查询参数可能包含邮箱、令牌或搜索内容，不要直接保存。

内部代号也不是匿名化。只要有人能把它重新对应到客户，就仍应按照可关联个人的数据管理。不要把“换成一串字符”当作隐私风险已经消失。

在数据进入日志系统之前清理

脱敏最好发生在应用写出日志之前，而不是等日志进入搜索平台后再隐藏。检查异常堆栈、请求追踪工具和 SDK 的调试输出：即使业务代码没有主动记录正文，异常对象也可能附带请求内容。

优先采用结构化字段，避免把整个请求对象转成字符串。确实需要清理文本时，可以过滤邮箱、手机号和密钥格式，但不要依赖正则表达式识别所有敏感信息。更可靠的办法仍是尽量不采集正文。上线前，用虚构的邮箱、测试令牌和聊天内容触发一次失败，确认它们没有出现在任何日志出口。

把保留期限写成可执行的删除规则

“只保留必要时间”无法指导值班同事操作。可以先拟定一个示例：普通排障日志保留七天，临时调试日志保留二十四小时，长期趋势只保留经过隐私评估的汇总数据。这些数字不是通用标准，应根据实际排障需求、合同和适用法规调整。

删除范围还要覆盖检索索引、对象存储、导出文件和备份。备份如果无法逐条删除，应说明到期轮换时间，以及恢复后如何重新执行删除。为自动清理设置失败告警，并指定负责人，避免政策写了七天，存储桶却一直累积。

让日志访问和临时排障都有边界

不是每位开发者都需要查看生产日志。按照岗位授权，记录访问行为，定期撤销离职或转岗人员的权限。工单、聊天群和个人电脑也不应成为日志的长期副本。

如果常规日志无法定位问题，不要悄悄开启全量记录。规定临时排障的审批人、采集范围、截止时间和删除方式；优先使用测试账号与合成数据。确需收集用户内容时，先确认适当的告知、授权或其他合法依据，并让调试开关自动到期，而不是依赖某个人记得关闭。

接入模型中转时，把外部数据路径也写清楚

如果团队需要按量调用多个模型，可以考虑 RelayVano，并注册账号用于测试接入。应用自身少记日志，并不代表中转服务、模型服务商或监控工具也不保留数据。上线前应分别核实它们的数据用途、日志期限、访问安排和删除机制；不能仅凭接入方式推断隐私保障。

最后，把政策压缩成一张团队能核对的清单：字段白名单、禁止内容、清理位置、保留期限、访问角色、例外审批和负责人。每次新增 SDK、监控工具或模型调用路径，都重新检查一次。真正有效的隐私友好日志政策，不是承诺永远没有风险，而是让每一份被留下的数据都有明确理由和退出时间。