你的影子评估集是一个合规性定时炸弹

你的 AI 技术栈中最危险的数据存储是那个无人设计的存储。这一切始于一次冲刺期间的 Slack 消息：“真实用户是捕捉真实 Bug 的唯一途径 —— 让我们把一定比例的生产流量接入评估流水线，以便我们可以每晚进行回放。”六名工程师给这条消息点了赞。九个月后，该存储桶包含了 430 万条追踪（traces），当失败率上升时，评估任务会呼叫值班人员，而失败案例会被逐字发送到一个有 40 人阅读的 Slack 频道。这些追踪包含电子邮件地址、公司内部名称、部分信用卡卡号、员工电话号码，以及用户解释其愤怒原因的客户支持对话记录。

没有人梳理过数据流。没有 DPIA（数据保护影响评估）涵盖它。上季度的隐私审查查看了模型供应商的 API；但它没有查看你的评估任务。然后，一份数据主体删除请求送达，团队发现“删除该用户的所有数据”这句话已经无法对应到他们实际能做的任何事情。

这是我在 2026 年看到的最常见的 AI 合规事件。不是模型泄露。不是供应商违规。不是 Prompt 注入。而是一个名为 eval-prod-traffic-v3 的生产对话记录存储桶，里面积累了大量敏感数据，而公司从未向用户承诺过会以这种方式处理这些数据。

没有人将其视为数据处理的“分流器”

每一个发布基于 LLM 产品的团队最终都会重新发现同一个见解：合成评估会错过那些真正关键的失败模式，因为关键的失败模式往往源于你未曾预料到的查询。一个用户请求智能体使用其发票截图来比较三个订阅层级。另一个用户粘贴了三段愤怒的客户邮件，并要求智能体草拟回复。这两类查询都不在你的黄金评估集中。

于是，有人接入了一个“分流器”。生产追踪 —— 完整的 Prompt、工具调用、工具响应、模型输出 —— 被复制到一个并行流水线中。该流水线对每个追踪进行多项指标评分，呈现回归分析，并存储最严重的失败案例供人工审查。工程团队将其视为评估基础设施。而法律团队如果听说过它，会认为这是一项全新的处理活动，实质性地扩大了公司对用户数据的使用范围。

这两种视角从未碰撞，因为该流水线不在法律团队的图表上。它被添加到了一个名为 observability-internal 的 Terraform 模块中，并继承了拥有指标看板团队的 IAM 策略。保留期则取决于底层对象存储的默认设置，通常是永久。

打破抽象的数据主体请求

第一次收到删除请求时，团队将其视为一次练习。面向用户的应用程序有清晰的删除路径：删除行、删除聊天记录、使会话失效。二十分钟搞定。然后有人想起了那个评估桶。

这就是“有损匿名化”不再显得聪明，反而显得代价高昂的地方。一种常见的模式是在持久化追踪之前运行脱敏步骤 —— 擦除电子邮件模式、掩码数字、用占位符替换名称。脱敏是不可逆的，这看起来很安全。但不可逆的脱敏也意味着从追踪回溯到所属用户的关联键已不复存在。你可以在桶中搜索用户的电子邮件，一无所获，然后得出删除已完成的结论 —— 除非该追踪仍然包含用户关于某种医疗状况的提问、他们工作的公司，以及一张因为自由文本 PII 检测确实困难而被脱敏程序遗漏的发票截图。

进行脱敏的团队做出了一个合理的工程选择。而必须执行删除请求的团队现在面临一个合理的法律问题：他们无法证明数据已消失，因为他们无法证明数据里曾经有什么。

从未书面承诺过的保留期

大多数评估流水线基于“默认保留”的原则积累数据。构建流水线的工程师假设数据受限于存储成本 —— 当有人预算耗尽时，旧的追踪最终会被清理。公司向用户展示的隐私声明则写着类似于“为了服务质量，我们会保留你的交互记录 30 天”。这两句话产生了分歧，而评估桶就是这种分歧不断积累的地方。

更好的模式是大多数可观测性供应商已经支持的：在存储层而非应用层强制执行基于标签的保留策略。Datadog、Splunk 和 Lightstep 都允许你保留一小部分高价值追踪（例如错误追踪或采样的成功案例）30 天，并在几小时内丢弃其他所有内容。同样的原理也适用于你的评估桶：工程问题不在于“我们要保留这些追踪多久”，而在于“我们要保留哪些追踪，以及默认丢弃其余追踪的规则是什么”。

如果没有这条规则，默认就是永久，而永久是任何隐私声明都无法支撑的承诺。

在追踪层进行脱敏，而非在评估时进行

架构上的修复方案是将脱敏推送到评估存储桶（eval bucket）的上游。有两种模式是有效的；第三种模式看起来有效，实则不然。

模式一（有效）：写入时的确定性令牌化（Deterministic Tokenization）。 当追踪记录被录入时，敏感实体会被一个独立服务生成的稳定令牌（token）所替换，该服务持有映射关系。评估存储桶中看到的到处都是 cust_a3f8 而不是 acme.com；存储桶无法还原原始数据。如果收到删除请求，令牌化服务会丢弃映射关系，评估数据便与用户失去了关联——在大多数监管机构的解读下，这满足了请求，且无需重写评估存储桶。这是对“我们是针对生产模式（production patterns）而非生产数据进行评估”这一说法的最诚实回应。

模式二（有效）：写入时强制执行分类的模式化跨度（Schema-typed Spans）。 每个跨度属性都携带一个敏感度类别——public、internal、pii、regulated——并在插桩库（instrumentation library）中声明。追踪管道会拒绝将受规管类（regulated-class）属性持久化到受规管存储桶之外，并在网关处拦截未分类的属性。这将隐私决策从“脱敏正则捕获到了吗”转变为“添加这个跨度字段的工程师是否声明了其中的内容”。后者是可审计的，而前者不可。

模式三（失败）：评估时的正则脱敏。 团队编写了一个脚本，在读取追踪记录进行审查时掩盖电子邮件地址和电话号码。脚本在读取时运行，因为那是它最显眼的地方。脚本不在写入时运行，因此原始数据仍留在存储桶中。六周后的 DPIA 评估认定，数据在存储桶中未脱敏存放的整个期间都已被处理（收集、存储、转换）——读取侧的清洗器并不能改变这一事实。这种调查结论往往会将一次数据处理审查转变为执法行动。

PPT 与存储桶存在分歧的法律层面

最艰难的对话发生在阅读 DPIA 的隐私律师和维护评估管道的工程师之间。DPIA 声称：“我们不使用客户交互转录文本进行评估。”存储桶却给出了相反的答案。双方的陈述都是出于诚意。律师不知道存储桶的存在，而工程师不知道 DPIA 已承诺公司采取某种立场，而存储桶的行为恰恰违反了这一点。

这就是为什么 AI 系统的 DPIA 需要在管道级别而非产品级别列举处理活动。产品是“针对支持代理的 AI 助手”。处理活动包括：针对用户提示词进行推理、为可观测性持久化追踪记录、为每日评估重放追踪记录、为人工审查持久化失败案例，以及将失败案例通知到分选频道。每一项都是独立的处理活动，具有不同的目的、接收者和保留期限。将它们全部打包在“AI 助手”下，会使评估管道在出问题之前处于隐形状态。

同样的原则也适用于变更控制流程。GDPR 的问责制原则将处理活动的重大变更视为触发 DPIA 评估的条件。“我们添加了影子评估以捕获回归”就是一个重大变更。但它很少被当作重大变更，因为它没有改变用户可见的产品，而且能注意到这一点的人通常不在部署审核名单中。

值得捍卫的合成数据底线

业界正在达成一个可辩护的共识：针对源自生产模式的合成数据进行评估，而不是针对仅对姓名做了轻微修改的生产转录文本。这种区别至关重要，因为其法律立场从根本上是不同的。

“模式合成”意味着生产追踪记录被用于（在获得同意和 DPIA 覆盖的情况下）拟合一个生成器——可以是一个小模型、一个模板群体或一个统计采样器——而评估集是从该生成器中提取的。评估集不包含任何个人记录。DSR（数据主体权利）请求不适用，因为评估集中没有数据主体的数据。代价是必须针对合成数据本身的保真度、实用性和隐私风险进行评估；这是一笔真实存在的“税费”。像 SynEval 和 SynthTextEval 这样的框架之所以存在，正是因为这种评估并非易事。

“轻微修改的转录文本”则恰恰相反。评估集仍然包含原始提示词和原始工具响应，只是将姓名替换成了占位符或缩写。在成员推理（membership-inference）文献中，针对此类数据的重识别攻击已是家常便饭。将结果称为“匿名化”更像是一种心理安慰，而非保证。监管机构已开始严肃对待这一区别；针对被证明可重识别的“匿名化”数据所做出的执法裁定，比针对公司承认是个人数据的数据所做出的裁定要痛苦得多。

如果你已经有了评估存储桶，本周该做些什么

以下三项行动的价值超过其他所有行动的总和。

梳理流程图。 画一张带有箭头的图，从“用户请求”到“模型”，再到“追踪存储”，到“评估管道”，到“Slack 失败频道”，最后到“审查期间的工程师笔记本电脑”。这是一项只需一天就能完成的练习，但几乎没有团队做过。这张图正是隐私团队需要评估的内容；它还能揭示出之前没人想到的“从电子邮件到 Slack”的隐藏路径。

在写入边界止损。 无论你采用何种脱敏制度，都要在追踪记录落入存储桶之前的写入路径上运行它。此外的任何做法都只是“纸糊的盾牌”。模式化跨度是杠杆率最高的变革，因为它们使隐私决策在插桩点变得明确，而工程师在那里真正了解字段包含的内容。

按标签类别而非总容量设置保留底线。 “保留 30 天”不是保留政策，而是存储预算。“将错误类追踪保留 30 天，成功类追踪保留 24 小时，受规管类追踪永不持久化到受规管存储桶之外”才叫保留政策。这种区别会体现在审计中，也会体现在你的 DSR 操作手册（runbook）中。

影子评估集是大多数 AI 团队在过去两年中构建的最有用的基础设施。它确实能捕获合成评估遗漏的漏洞。合规性定时炸弹不在于评估集本身，而在于工程团队对评估集的认知与公司其他部门描述评估集的方式之间的鸿沟。弥合这一鸿沟是一项并不光鲜、大多是文书工作和架构层面的工作，但它决定了下一次隐私审查是谈话还是调查。