为了复现一次错误回答，把整段提示词、检索原文和工具响应全部保存，似乎是最省事的办法。但当这些记录进入集中日志、告警消息和导出文件后，企业可能建立了另一套权限更宽、删除更难的业务数据库。日志治理的关键决策，是哪些证据值得留下，以及谁能在什么条件下看到它。
从日志数量转向数据副本的责任
传统接口日志常以路径、状态和耗时为主；AI 排障还可能涉及用户问题、文档片段、生成答案与工具参数。一次业务请求因此产生多种内容副本，且可能被不同平台保存。这个变化不意味着每家企业都应该采购新的安全产品，而是意味着采集范围不能继续由开发人员临时打印什么来决定。
既有的企业 AI 故障定位方法回答怎样留下足够证据。本篇进一步讨论这些证据的生命周期：如何决定采集、处理、访问、导出与删除边界。诊断充分性与数据暴露程度需要共同验收，单纯增加日志或一律关闭日志，都可能把问题转移给下一位处理者。
OpenTelemetry 官方指南明确指出，工具本身不能判断某项数据在具体业务中是否敏感，并要求实施者审查采集库实际输出。[1] 企业因此需要字段责任人：业务团队解释信息含义，平台团队控制采集路径，安全与数据负责人确定访问和保留规则。开源组件提供处理能力，不替企业作出这些决定。
按排障问题决定字段，而不是先采全再过滤
本文建议把采集申请写成四个问题：这个字段用于回答什么故障问题；没有原值是否仍能诊断；原值必须由谁查看；何时不再需要。无法回答的自由文本字段，不宜直接进入日常遥测。能够用错误类型、文档修订号或校验状态回答的问题，就不应默认附带整份文档。
可建立三类记录。第一类是一般运行证据，例如阶段状态、耗时与受控版本号；第二类是可关联但受限的业务标识；第三类是确有必要的原文证据，放在权限更严格、用途更明确的位置。分类依业务判断，不是自动把所有元数据认定为无敏感信息：文件名、查询条件和客户编号也可能暴露商业活动。
字段允许清单适合结构稳定的记录，新增字段先审查再输出。自由文本则要结合规则、实体识别和业务词表，但不要用它们替代采集最小化。OWASP 的日志指南列举了通常不应直接记录的凭证、连接字符串和商业敏感信息，并强调限制日志读取权限。[2] 实施时应把这些原则转成实际字段策略，而不是在制度里写一句“已脱敏”。
脱敏位置决定原始内容已经经过了哪里
应用侧在生成遥测之前移除内容，可以减少敏感值经过队列和网络的机会；采集器侧处理有利于集中管理，但它无法撤销原值此前进入应用文件或缓冲区的事实；存储侧遮罩常常只改变查询显示，不等于原始值没有保存。选型时要画出每个副本的位置，不把三种处理方式当作等价功能。
OpenTelemetry 文档列出删除或修改属性、过滤记录和转换字段等处理能力，同时提醒可预测小空间中的标识即使被哈希，仍可能被猜测匹配。[1] 因此，哈希结果不自动等于不可关联或匿名。确需跨请求关联时，可以设计有范围的代号机制，并保护映射与密钥；具体方案要按关联需求和攻击面审查，不能只换一个字段名。
Presidio 官方仓库说明它结合实体识别、正则和可定制规则，并明确不保证找到所有敏感信息。[3] 这意味着检测器没有命中，只能说明本次规则没有识别出来。企业内部项目代号、非标准格式、混合语言和截图内容应分别准备样本，不能把一组手机号测试通过推广为全部内容安全。
用两个验收方向约束投入
下面是构造场景，不是壹典项目或实测：一套维修助手每天产生 1000 份诊断记录，其中 100 份测试记录被人工标注为含有禁止输出的内容。若处理后仍有 3 份残留，样本中的记录级遗漏比例是 3%。这个比例只描述该组带标注记录，不代表真实生产总体泄露概率，更不能证明未标注记录没有问题。
还要测误删。假设另有 200 份不含禁止内容、却包含诊断所需设备型号的记录，其中 20 份被错误移除了型号，相关样本的诊断信息损失比例为 10%。如果只优化敏感信息命中率，团队可能把有用证据一并抹掉，导致每次故障都要求重新开全量调试。
建议把验收拆为禁止内容残留、诊断任务可完成性、处理延迟和异常路径行为。分别记录样本来源、语言、字段类别、规则版本及未覆盖范围。采购比较应使用同一测试集，并增加企业自有格式；不能拿不同测试集的准确率直接排名。对高后果字段，可设置阻止输出的硬条件，而不是用总体平均值抵消一次严重遗漏。
临时排障应是有期限的访问，不是永久开关
需要原文时，可以采用本文建议的临时排障流程：绑定具体故障单、限定业务范围与时间窗、指定查看人员、记录用途，自动到期关闭增强采集。日常日志仅保存受控证据引用；查看原文时重新检查业务权限，不能认为有日志平台账号就有权阅读所有客户内容。
导出也必须纳入范围。告警邮件、企业消息、下载表格、排障截图与第三方工单可能脱离原平台权限。可以让告警携带故障类型和受控链接，避免直接粘贴完整载荷；必要导出应记录责任人、用途和到期处置。加密解决一部分存取风险，但不能替代减少副本、限制接收者与控制用途。
保留与删除要按实际政策处理，不能在本文中替所有企业规定统一天数。应同时列出主日志、搜索索引、队列、导出及备份的处理方式与例外。若有必须保留的审计记录，应明确它与可删除调试正文的区别；删除正文不应悄悄抹去必要的操作事实，也不能把备份暂时不可逐条删除说成已经全部清除。
上线前同时演练漏采、漏脱敏和失效
准备只含虚构敏感标记的受控请求，分别经过成功、异常、超时和重试路径；检查应用日志、采集器、存储与告警出口，确认没有哪条异常路径绕过字段策略。新增字段、嵌套对象和超长文本也应覆盖。检查者要能指出检测范围，不能仅凭界面搜索不到某个值就作全面结论。
再模拟检测服务不可用、队列积压和规则加载失败。对于高敏感正文，可以停止输出该载荷并留下不含原值的失败状态；关键业务审计是否阻断交易，应由业务后果与独立记录能力另行决定。不要在失败时回退为原文透传，也不要为了保护日志而无条件中断所有业务。
最后让值班人员用处理后的记录完成一次故障判断，检查是否仍能定位阶段、版本与待核对事项。只有数据暴露边界与诊断能力同时可解释，日志治理投入才有可验收的价值。先从一个高价值入口完成闭环，再扩展到更多链路，比一次性收集所有内容更容易验证收益与代价。