内部评估集：一个无人审查的隐私边界

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。

边界在工程端之所以不可见，是因为数据在物理上并没有移动。凌晨 2 点由聊天处理器写入对话表的一行数据，在上午 11 点被评估脚本读取。同一行。同一个数据库。同样的访问控制。唯一改变的是某人读取数据的原因，而“原因”并不是工程栈会跟踪的属性。目的限制（Purpose limitation）是一个法律概念，它存在于你的数据库 schema 中并不存在的一列里。

目的限制：工程部门从未内化的规则

为某一目的收集的个人数据不能在不告知的情况下转作他用的原则，在不同的监管体系下有不同的名称——GDPR 中的目的限制，大多数州隐私法中的“特定、明确且合法目的”条款，以及 FTC 关于 AI 公司履行隐私承诺的反复指导——但对工程的影响是一样的。你收集客户数据的合法依据是“提供客户要求的服务”。使用相同的数据来评估、调优、校准或基准测试 AI 系统则是一个独立的目的。它需要自己的合法依据，而该合法依据要么需要在客户看到的通知中披露，要么需要通过带有记录在案的平衡测试的合法利益来支持。

工程师很少遇到这条规则，因为数据工程工具没有将其体现出来。查询计划器不会警告你，将 conversations 与 eval_cases 进行关联（join）是一种目的变更。向量数据库（vector store）不知道“为 few-shot 提示词查找相似示例”和“为评估集查找相似示例”是对同一个嵌入（embedding）的不同用途。追踪查看器（trace viewer）将客户消息和标注过的评估示例视为同一种对象。基础设施抹平了法律视为关键支撑的这种区别。

结果就是法律团队最终会面临的这种局面：AI 团队花了六个月时间，针对一个“内部追踪记录”语料库来完善裁判模型，经检查发现，这些记录几乎完全由可识别的客户对话组成，其中一些包含支付详情、健康信息或客户在产品内部标记为私密的内容。这些客户都没有同意将他们的对话用作评估材料，因为根本没有人问过。

集群边界不等于隐私边界

当问题浮出水面时，AI 团队最常见的辩解通常是“但数据从未离开过集群”。这种论点误解了隐私监管的真正对象。隐私法监管的不是流出（egress）；它监管的是处理（processing）。以新目的读取数据就是处理。对 user_id 进行哈希并将该行复制到 evals 表就是处理。让裁判模型对回复进行评分就是处理。让工程师滚动查看 20 个示例以调试回归问题就是处理。这些操作都没有向 VPC 边界外发送任何数据包，这与法律问题无关。

这也是公司现有的 SOC 2 和 ISO 27001 控制措施给人带来虚假安全感的地方。这些控制措施是围绕原始目的的访问管理而设计的。它们回答了“读取这些数据的人是否正确？”这一问题。但它们没有回答“这个人读取这些数据是否是为了客户授权的目的？”这一问题。在现有的角色模型下，评估工程师几乎肯定拥有对数据库的合法访问权限。但这并不意味着这种用途是合法的。

数据集的内部性质往往还会绕过 DPIA（数据保护影响评估）流程。DPIA 应该在任何高风险个人数据处理开始之前进行，而使用可识别的客户对话来评估模型是一个教科书式的高风险处理案例——数据量大、可能涉及特殊类别、涉及下游自动化决策。但由于从内部来看并没有感到有什么新变化，因此没有触发 DPIA。隐私团队准入门户上的表格会问“你是否在增加新供应商？”，而答案是否。

触发事件总是来自客户的提问，而非审计

这种反模式的有趣之处在于它通常是如何暴露的。几乎从未有审计能发现它。审计关注的是供应商列表、数据流图和许可记录。而内部评估流水线在这三者中都是不可见的。触发事件几乎总是客户的提问——有时是 DSAR，有时是企业客户的采购团队询问其租户的对话是否被用于模型评估，有时是一个好奇的用户给支持部门发邮件，询问 AI 是否正在根据他们的消息进行训练。

加载中…