10 篇博文 含有标签「data-governance」

一个仅针对入站流量运行的 PII 脱敏器就像是安装在管道错误一端的单向阀。它在用户提交的姓名、电子邮件和账号进入日志之前拦截它们。但它对模型的输出无能为力 —— 而现在，模型正是在输出端积极地组合可能包含这些相同标识符的文本，这些内容可能源自 RAG 检索、工具返回、对话历史或用户从另一个租户数据中粘贴的内容。我观察过每一个上线了输入端脱敏器的团队，他们的待办事项中都有一个标记为“输出端对齐”的后续任务。大多数这类任务永远不会关闭，因为在长达六个月的时间里，没有任何事故暴露出这个缺口。六个月后，该任务经过多次重新排序，看起来更像是一个功能需求，而不是缺失的一半安全控制手段。

失败模式是恒定的：输入端脱敏被视为标准的控制手段，因为它的工程问题更简单，审计故事也更容易讲。你编写了一套正则表达式，运行了一个标注好的基准测试，证明了在固定语料库上的精确率和召回率，在特性开关后上线了它，安全评审也将其接受为 PII 边界。输出端则完全没有这些优势。模型的响应是生成性的，表面积是无限的，而且测试方法论 —— “在无限多的上下文中它不应该说什么” —— 在结构上比“我们应该从已知输入中剥离什么”要困难得多。因此，上线入口端的团队将出口端视为未来的工作，而这个未来永远不会到来，直到有客户举报另一个客户的电子邮件出现在他们的对话记录中。

你的黄金评估集（Golden eval set）是一个你的安全团队甚至不知道其存在的隐私边界。它是通过对生产环境的 Trace 进行采样构建的，这意味着它是一系列精心挑选的真实客户查询集合——通常包含姓名、电子邮件、账号、愤怒的通话记录、输入了一半的信用卡卡号——并配有标准正确回复，最后提交到评估流水线读取的任何存储桶中。

最后一部分正是评估数据具有独特危险性的原因。原始的生产 Trace 之所以敏感，是因为它记录了客户所说的话。而评估案例则以一种全新的方式变得敏感，因为它记录了客户所说的话 加上标注的正确答案。这个标签是一个衍生作品，由某人（通常是标注员或领域专家）有目的地添加。它标志着“这是标准答案”。它赋予了 Trace 原始日志从未有过的生命力——日志保留策略最终会将 Trace 轮转删除，但评估案例现在成为了一个永久的测试 fixture（固定数据），团队致力于保持其测试通过（keeping green）。

你的 AI 功能上线了。用户正在使用它。每一次会话回放、每一次点踩、每一个返回错误答案的请求，都清晰地暴露出它现在的表现与它应有水平之间的差距。信号就在眼前。问题是：你是否可以合法地利用这些信号。

这就是团队撞上合规高墙的地方。这不是一堵理论上的墙——而是实实在在的。仅在 2024 年，欧洲监管机构就开出了逾 12 亿欧元的 GDPR 罚款，OpenAI、Meta 和 LinkedIn 均在被点名之列。大多数执法行动背后有一条共同主线：以原先收集目的之外的方式使用行为数据，或收集了超出运营功能所必要的数据。监管机构并不会因为你的意图是改进模型而非投放广告就网开一面——尽管工程师们往往这样以为。

你的 AI 系统在上午 9 点将一条患者查询路由到了自托管模型。上午 11 点，该模型的 Pod 在部署时重启。请求队列积压，路由器检测到超时，随即回退到你用于通用查询的云端 LLM。请求成功完成，没有告警触发，监控面板一片绿色。而就在这次交互中，受保护的健康信息悄然流向了一个你根本没有签署《业务伙伴协议》的供应商。

这不是假设，而是几乎所有未经专门设计来防范此类问题的 AI 路由栈的默认行为。

一位产品经理在周二联系了 AI 团队：“客户想在支持代理中粘贴截图。这应该是件小事，对吧？模型已经支持图像了。” 工程主管检查了 SDK，确认视觉端点接受 JPEG 和 PNG，在功能开关（feature flag）后发布了更改，并向 10% 的用户推送。两周后，法务团队转来了一封监管机构的信函，询问为什么用户的银行账单、驾照照片以及包含另一位客户订单 ID 的截图都出现在了该代理符合训练条件的日志中。AI 团队中没人标记这次模态变更（modality change），因为没人认为模态变更 算是一次 变更。批准文本代理的隐私审查从未针对图像变体重新运行——而图像变体最终适用的授权、留存和驻留规则完全不同。

这不是一个关于粗心工程师的故事。这是一个关于大多数团队发布 AI 功能时内置的范畴错误的故事。文本输入是一个已知的、具有稳定威胁模型的细分数据类别：用户输入，用户看到他们输入的内容，工程团队在记录什么和丢弃什么方面有多年的习惯。图像是一个具有不同威胁模型的不同数据类别——它们夹带了用户看不到的元数据，捕捉了用户并非有意分享的周边内容，并以其自身的驻留和合同条款创造了存储和处理足迹。将“现在支持视觉”视为一次 UX 迭代，而它实际上是一个隐私分类事件，这就是团队如何根据监管机构的要求发现他们的 PII 清单将实际暴露程度低估了一个数量级的原因。

2025 年 5 月 13 日，纽约南区的一位联邦地方法官签署了一项保护令，用一个词取代了一家消费级 AI 公司的保留政策：永远。OpenAI 被指示保留并隔离其 Free、Plus、Pro 和 Team 等所有层级的每一份输出日志——包括用户已明确删除的对话，以及隐私法原本要求删除的对话。到 11 月，同一法院下令将其中 2000 万份去标识化的转录文本作为抽样取证（sampled discovery）提供给《纽约时报》及其共同原告。这一无限期保留义务一直持续到当年的 9 月 26 日。在这五个月里，“删除”的实际含义是“保存在隔离的保险库中，供对方当事人日后查阅”。

该命令是对每一个基于 LLM 构建产品的团队发出的警告信号。如果你的产品存储了聊天记录，你的保留政策距离被法院认为合理的任何规定所取代，仅隔着一场潜在的诉讼。工程上的问题不在于这是否会发生在你身上，而在于你的存储架构是否能够承受这种变化，而不至于让你的产品变成法务部门的责任引擎。

电子邮件的保留手册无法直接套用。AI 对话包含的内容远多于用户输入的内容，而这“多出的部分”正是取证争端的开始。

大多数团队将LLM隐私视为一个二元选择：要么将数据发送到云端并承担风险，要么在本地运行所有内容并承担成本。这两种框架都是错误的。实际上存在一个风险特征和工程预算差异显著的方法光谱——大多数团队在这个光谱上的位置是错误的，却浑然不知。

研究人员最近证明，他们可以以每条记录0.012美元的成本，以48.9%的成功率从3912人中提取真实PII。这个统计数字往往被当作学术威胁建模而被忽视，直到安全审计或合规审查落到你的桌上。问题不是是否要关注LLM隐私，而是哪些控制措施真正能改变局面，以及每种措施的实施成本。

40% 到 60% 的企业 RAG 部署无法进入生产环境。罪魁祸首几乎从来不是检索算法——HNSW 索引运行正常，嵌入质量也不错，向量相似度搜索已是成熟技术。问题发生在上下游：没有文档所有权、查询时未执行访问控制、PII 裸露在向量索引中，以及检索语料库在上线数周内就与现实脱节。这些都是治理失败，而大多数工程团队将其视为别人的问题，直到合规团队、安全审计，或某个收到了其他租户数据的用户把这变成自己的问题为止。

本文是受控 RAG 知识库的组织与技术解剖——写给拥有管道的工程师，而不是批准预算的高管。

你的 RAG 系统在上线时运行良好。三个月后，它在三分之一的用户查询中自信地给出了错误答案——而你的追踪日志显示一切正常。检索器在抓取文档，模型在生成回复，整个流水线看起来健康运转。问题是不可见的：向量存储中的每个向量依然有相似度分数，但其中一半已经指向了不再存在的事实。

这就是语料库衰减。它不会抛出异常，不会触发告警，而是在后台悄无声息地积累。等你通过用户投诉或质量下滑察觉到时，你的向量存储已经变成了一个负担。

微调模型上线六个月后，监管机构问道："哪些训练样本来自已撤回同意的用户？"你翻开一张电子表格，搜遍 Slack 归档，最终靠标注批次邮件和一份自第一个冲刺后就未更新的 README 来重建历史。这是常态，而非例外。对 44 个主要指令微调数据集的审计发现，超过 70% 的许可证标记为"未指定"，许可证类别实际应用的错误率超过 50%。溯源问题是结构性的，而且总在你最承受不起的时候爆发。

本文讲的是在需要之前就建立微调数据溯源注册表——包括模式设计、驱动需求的审计场景，以及使其可操作而不变成额外负担的生产模式。