我现在接触的每一家企业，都正处于将AI融入产品或运营的某个阶段。内部协助工具、欺诈检测、客服机器人。野心是真实的，节奏也很激进。
但在我的对话中反复出现的，不是一个技术问题，而是一个治理问题。
团队在构建AI系统时需要数据，通常量很大，而且必须足够真实，模型才能学到有用的东西。那这些数据从哪来?大部分来自生产数据库。也就是那些存着客户姓名、财务记录、健康数据、政府标识信息的系统，正是这些企业在生产环境中花了数百万去保护的东西。
数据被提取出来，进入开发环境，再流入数据湖，然后进入训练流水线。可能还会经过第三方标注服务，或者某个外部承包商能访问的共享笔记本，而在这条链路的某个环节，理应有人问一句：这些数据到底该不该离开生产边界?
几乎没有人在问。
实际情况是什么样的
去年我和一家中型贷款机构的工程管理层合作过，他们对团队快速搭建起一套欺诈检测模型感到自豪，这完全可以理解，模型表现也不错，但当我们一起梳理数据流向时，发现了一个CSV文件，里面大约有20万条真实客户记录(姓名、账号、交易历史，还有一列部分脱敏的政府身份证号)，这批数据八个月前就被导出用于"初始训练"了。
这个文件现在至少存在于三个我能确认的地方，可能还有更多我查不到的：数据科学团队共用的一个云文件夹，两台属于已经转去其他项目的数据科学家的笔记本电脑，还有一台在另一个国家的承包商机器上——那个人被请来做过一轮标注，之后访问权限从未被撤销。导出操作当时是经过审批的，但后续的清理从来没有执行，数据就这样悄悄地变成了永久存在。
严格来说，没有人做错了什么，CISO没有被征询过意见。隐私团队在六个季度前就对原始用例签了字，之后便默认数据还在它该在的地方，数据工程师觉得治理是别人的事。数据科学家觉得，"我们有隐私团队管这个。"每个人都在做自己那份工作，而这些工作之间的缝隙，就是那20万条真实客户记录最终躺在一个承包商笔记本电脑上的原因。
这就是我反复看到的模式，而且并非因为谁在鲁莽行事。安全团队在盯外部威胁，隐私团队在管理面向客户系统的同意授权和监管申报，数据工程在维护流水线运转。没有人被告知：判断生产数据是否应该因AI工作而离开生产边界，是他们的职责。
为什么这种事一直在发生
我认为原因是这样的，如今企业里大多数AI开发流程，都是从数据科学笔记本演化而来的，而那里唯一的设计目标就是实验速度。治理本应后来跟上，但"后来"从未到来。现在，生产数据集已经在暂存环境里待了一年多，标签上写着"临时"。
AI工作与传统软件测试的不同之处在于，它产生的副本数量极其庞大。一个开发者测试应用时，会把生产数据拉进一个测试数据库。多出一份副本，可控，但AI工作流产生的是一条链：数据被提取、转换、采样、拆分为训练集和评估集，经过多轮模型迭代，有时还会导出到外部平台做标注或基准测试，每一步都可能产生新副本，每一份副本都是敏感数据存在于比原始环境更弱保护下的又一个位置。
而且风险并非理论上的，安全研究人员已多次证明，大语言模型能够记住训练数据的片段，并在被以正确方式提示时原样复现。Carlini等人关于GPT-2的那篇原始论文，通过查询模型就提取出了真实姓名、电话号码和邮箱地址。后续团队用一种发散攻击对生产环境的ChatGPT做了同样的事，迫使模型逐字输出训练数据片段。如果模型是用原始客户记录训练的，那些记录就可能在模型输出中浮现。数据不会只是消失在权重里，它会残留。
这种残留带来的财务代价，在IBM 2024年数据泄露成本报告中体现得很清楚：全球数据泄露的平均成本为488万美元，其中40%的泄露涉及跨多个环境存储的数据，35%涉及影子数据。AI流水线中每一份未被追踪的敏感数据副本，都在为这个统计数字添砖加瓦。
监管机构不会等行业自己跟上，GDPR第25条已经要求在处理个人数据时实施数据最小化和假名化，且不区分面向客户的系统和内部模型开发。欧盟《AI法案》第10条进一步对高风险AI系统明确了数据治理义务，包括记录训练数据的来源和处理方式。当监管机构问起某个模型的训练数据从何而来、个人信息是否得到妥善管理时，"我们得去问问数据科学团队"不会是一个能接受的回答。
好的做法是什么样的
令人欣慰的是，修复这些问题的技术并不新奇，甚至算不上特别新。真正的挑战一直是：让这些技术成为默认路径，而不是团队想起来才去选择的额外动作。
我过去六个月工作中的两个例子。
我合作过的一家医疗客户，一直在用从EHR中提取的原始患者记录训练内部分诊和排班模型，我们帮他们把整个AI开发环境迁移到了合成数据流水线上，新流水线生成的记录在统计上高度忠实，保留了模型需要学习的分布和关系，但不包含任何真实患者信息。数据科学家拿到了比以前更干净的数据集，隐私团队获得了一条清晰的数据血缘断点。工程投入以周计，而非以季度计。
我辅导过的一家银行，在欺诈检测模型重建中遇到了同样的问题：原始客户数据从生产环境直接流入模型开发环境，我们把导出这一步替换成了实时脱敏——当数据科学家把记录拉进笔记本时，真实姓名会变成逼真但虚构的名字，账号会变成脱敏后的令牌。
这里有一点经常在讨论中被忽略：那个欺诈模型实际上根本不需要任何真实的身份信息就能完成工作，它需要学的是行为模式——比如客户交易的频率、倾向使用哪类商户、某笔消费与其正常支出相比如何。换个角度想：要识别一笔欺诈交易，模型需要知道的是"这个客户通常在工作日早上花40美元买咖啡，现在凌晨3点出现了一笔来自另一个国家的4000美元消费"。客户叫Priya Sharma还是叫一个脱敏后的替代名，对这个信号没有任何影响。
用脱敏数据训练的模型进入测试后，准确率与团队之前用原始生产数据得到的结果相差不到一个百分点，模型行为一致，爆炸半径却大幅缩小，团队没有因此损失任何一个sprint。
这两个案例都不是什么科研项目，数据脱敏和合成数据生成，是软件测试领域已经用了二十年的技术，它们之所以没有成为AI开发的默认选项，不是技术原因，而是因为从来没有人把"它们应该成为默认"这个问题当作自己的责任。
我会推动什么
如果我从大多数企业今天所处的位置出发，我会推动三件事。
绘制真实的数据流向图，不是文档里写的那种，是实际的那种。和数据工程团队、ML团队一起走一遍，追踪生产数据在模型开发过程中的去向。包括云存储桶、Jupyter笔记本、导出到第三方标注平台的数据、承包商的笔记本电脑。这个练习几乎总是令人不舒服的，因为它会把数据暴露在没人知道、也没人在监控的地方。
把脱敏或合成设为硬性关卡，而非建议。如果团队需要真实感数据来训练模型，他们应该默认获得经过脱敏或合成的真实感数据。原始生产数据跨越开发边界，应该需要走例外审批流程，而不是默认无人反对就通过。
把数据溯源纳入你几乎肯定已经在做的AI风险审查。如果企业已经在审查模型的偏见和性能漂移，那它也应该审查训练数据的来源以及是否得到了负责任的处理。这些是同一件事，把它们当作两件分开的事来对待，正是这个缺口持续扩大的主要原因。
这件事拖得越久，副本积累得越多，清理就越难，等到监管机构或一次数据泄露迫使你正视这个问题时，企业面临的暴露面就越大。
企业网D1net(www.d1net.com)：
国内头部to B IT门户，旗下运营国内头部的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。
版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。
恒正网提示：文章来自网络，不代表本站观点。
