从智能体追踪里脱敏 PII

内容采集默认是关的，而打开它是一项数据处理决定。

OpenTelemetry 的 GenAI 语义约定把每一个可能装下提示词或补全内容的属性都设为「选择加入」，正是为了让内容不会因为谁忘了一个开关就出现。那个默认值，是这整件事里最后一个便宜的时刻。

• 只留元数据是安全的，而对智能体几乎无用。模型名、token 数、时延与状态，能告诉你某次运行很慢。它们说不出智能体为什么拿着错误的账号去调了退款工具——而这正是智能体追踪存在的意义所在的那一类问题。
• 智能体追踪里装着你的数据库从来没装过的类别。用户的原始措辞、检索回来的文档、工具参数、工具返回值，以及模型的推理内容。最后一项最扎手：它可能把敏感输入换个说法复述一遍，而任何基于字段的规则都抓不到。
• 爆炸半径是一家厂商，不是一张表。一旦被采集，那些内容就坐在一个 SaaS 后端里，那里有它自己的访问模型、自己的支持工程师和自己的次级处理者——而你与可观测性厂商签的那份 DPA，多半不是照着这个范围写的。
• 把举证责任反过来。打开内容采集不是一项调试上的便利；它是一个「在一套新系统里处理个人数据」的决定。就按这个来对待——在那个开关被置为 true 之前，先把合法性基础、留存期与访问名单写清楚，这正是数据治理在别处已经要求的那份纪律。
• 按环境决定，而不是按组织决定。在预发环境里对合成数据做全量采集，不花什么成本，还能回答大多数问题。生产才是那个必须把旋钮挣来的地方。

在 SDK 里脱敏，因为到了 collector 已经太晚。

常见架构把脱敏放在 collector，或作为后端的一条处理规则，而它是错的，理由一句话就能说清、却很难走回头路：到那时数据已经离开了你的进程，而在大多数部署里，也离开了你的网络。

• 到了 collector，外传已经发生。如果那条 span 是带着原始提示词上路的，那你就是先导出了个人数据、然后又删掉了它——这与「从未导出过」是两个不同的事件，义务也不同。
• 后端侧的遮蔽是展示层脱敏。原始值还在存储里、在备份里、在搜索索引里，也在厂商自己在入库时记下的日志里。一个被遮住的视图，并不会让它不存在。
• 在进程内，意味着 span 属性从构造出来那一刻就已经脱敏。在 SDK 里放一个 span processor，跑在 exporter 之前，让未脱敏的字符串只作为一次函数调用生命周期内的局部变量存在。
• 脱敏器要失败即拦截。如果脱敏器抛异常，就丢掉内容属性、保留这条 span——绝不要因为清洗器出错就把原始值发出去。这是一份谨慎的设计在生产中泄漏的最常见方式。
• 覆盖每一个落地点，而不只是 tracer。同样一分钟还会落进你的评测数据集、提示词日志表、反馈存储，以及你那个 LLM 裁判的输入。一个脱敏器、一个版本，摆在它们全部前面——数据外泄风险一再翻出来的那种失败模式，正是那个没人盘点过的落地点。

做确定性令牌化——一个遮罩会把你当初为之追踪的那份分析扔掉。

把一切替换成 [REDACTED] 是最省事的实现，而它毁掉了「有追踪」这件事的大部分价值。替换物的选择，正是脱敏究竟是一笔税、还是一份设计的分水岭。

• 确定性令牌保住了关联。带密钥的哈希意味着同一个邮箱在每条 span 里都变成同一个 usr_7f2a，于是「这个用户是不是撞了两次同一个故障」「受影响的不同用户有多少」「这是一个客户的事还是一个系统性 bug」，全都仍然答得出来，而没有任何人因此知道他是谁。
• 把类型留在令牌里。<EMAIL_7f2a> 而不是 <REDACTED>，保住了调试者需要的结构：你依然看得出这件工具是拿一个邮箱、被调在了本该放账号 ID 的位置上。
• 令牌让「删除」变得可操作。一次删除请求可以映射到一个令牌，你能拿它去追踪、评测与反馈存储里搜。换成不可逆的遮罩，你连「自己是否照办了」都确认不了——这正是对智能体记忆执行删除权最后总是沦为人工考古的原因。
• 只有当你需要重新识别时才存映射，而且要存在别处。一个独立的、带密钥的存储，有它自己的访问控制与更短的留存期。如果没人需要逆向它，那就不要留——关联靠令牌本身就成立了。
• 有意识地轮换密钥，并知道它的代价。轮换是一次隐私上的改进，同时会切断跨越那条边界的纵向关联。请按「你的分析实际回看多远」来定轮换周期。

召回率是一个你必须测出来的数字，因为自由文本没有 schema。

结构化的 PII 是容易的那一半。难的那一半，是同一个事实被一个人写在一句话里；而一个从未被测量过的检测器，是一项没有证据支撑的合规主张。

• 用真实 span 建一个带标注的语料。几百条生产 span，按实体类型逐一人工标注，放在一处受控位置。没有它，你对自己的脱敏器只有看法，没有召回率。
• 按实体类型报召回率，绝不要报总体值。「总体 97%」通常掩盖着邮箱 99%、自由文本地址与账号 60%。总体值被容易的那几类主导，对真正要紧的那几类什么也没说。
• 把它当作 CI 里的回归测试来跑。脱敏器是有版本的代码。任何让某一实体类型召回率下降的改动都应当让构建失败，就像一条挂掉的单元测试那样。
• 新工具就是新泄漏。有人加了一件返回值形态是脱敏器没见过的工具的那一天，这条路径上的召回率就是未经测试的。请把「拿它的返回值抽样跑一遍脱敏评测」和工具目录的那些步骤一起放进工具上线清单。
• 也要盯准确率，而且要用一种具体的方式盯。过度脱敏会吃掉标识符、错误码和栈帧，把一条追踪变成一页令牌。请统计「一条脱敏后的 span 不足以支撑分诊」的发生频次——你的工程师本来就知道，去问他们。

破玻璃层，以及那个让它成真的数字。

脱敏恰恰拿掉了能解释最难那类故障的细节。要把它取回来就需要第二层，而这一层要么是照着一个实测的数字定的，要么就是演戏。

• 按你的发现耗时来定 TTL，而不是按心里舒服来定。如果未脱敏的 span 存活 24 小时，而你察觉一次质量回退的中位耗时是九天，那么每一次你真正需要它的时候，这一层都是空的。请从你自己的事故历史里量出 MTTD，再把 TTL 定在它之上。
• 访问是一次带理由、带批准人、带到期的申请。具名的个人、一条关联的事故、一个会过期的会话，以及一条原则上可以出示给数据主体的访问日志。对未脱敏追踪的常驻访问权，和对生产数据库的常驻访问权是同一种授权异味。
• 授权的粒度是一条追踪，不是一整层。「这位调查人、这 40 条 span、四个小时」胜过「SRE 组可以读原始追踪」。更窄的授权几乎没有更难实现，却极大地更好辩护。
• 把这次访问记得和事故一样响。一次破玻璃读取值得告警——它是少数能把「一次调查」与那种已获批、向内的滥用模式区分开来的信号之一，后者的每一步都是逐条合规的。
• 默认把这一层留在厂商之外。脱敏后的流送到你的可观测性 SaaS；那条短命的原始流留在你自己的账号里。正是这道切分，让整个设计能用一句话向监管方、审计师或职工委员会解释清楚。

脱敏不是留存，两者谁也盖不住谁。

这两项控制经常被拿来互相顶替，而每一次顶替都留下一道真实的缝，并在最糟的时刻显形。

• 脱敏后的数据，往往仍然是个人数据。一条某个用户会话的追踪，即便令牌化了但内容完整，也经常能从内容本身被重新识别。脱敏降低的是风险等级；它很少让你脱离适用范围，所以留存政策依旧成立——见追踪采样与留存。
• 采样同样不是一项隐私控制。只留 5% 的追踪，意味着你留下的那 5% 是完整的。它减的是量，不是敏感度。
• 法律保全会盖过你的 TTL，而你该知道它盖在哪里。当一道保全令落下来，覆盖范围内的自动过期必须停下，同时又不能到处都停——这正是留存与法律保全所描述的那种协调，如今要施加在一个由你的厂商运营的存储上。
• 评测数据集比追踪活得更久，而且什么也没继承。三月被提升进回归套件的一次失败，到十二月还在那里，早已越过了追踪的过期时间，并把当时装着的东西一并带着。请在「提升」这一刻脱敏，并在脱敏器换版本时重跑一遍。
• 把删除演练一遍，而不是宣称一遍。每季度挑一位数据主体，给「把他从追踪、评测、反馈与裁判输入里移除」这件事真实地计一次时。政策与秒表之间的差距，就是那条发现。

延伸阅读：追踪与可观测性讲这些 span 里该装什么，OTel GenAI 语义约定讲本页要设闸的那些属性名，失败分类法与分诊讲脱敏绝不能挡住的那件工作，而智能体可观测性讲底下那个概念。