我做过十几个数据集合规评审,也陪客户挨过两次监管问询。说句不太中听的话:数据集出事,十次里有九次不是技术没做到,而是链条上某一环没人认领。很多人把合规理解成”交付前做一次脱敏、附一份来源声明”,这个动作能应付采购方的格式审查,应付不了真正的溯源。一份高质量数据集要满足合规要求,我认为必须同时证明五件事:来源可证、授权可查、处理可追、使用可控、退出可验。少一件,这盘数据在审计面前就是”来源不明”。来源可证,指的是你能拿出采集时间、采集方式、采集范围的第一手证据,而不是事后补的一段文字描述;授权可查,指的是每一层加工之后的用途变更都有对应的授权依据,包括转授权是否被允许;处理可追,指的是从原始表到交付集的每一次清洗、标注、增强都留了血缘,能倒推回某一个字段的来源;使用可控,指的是数据集交付给谁、用在哪个模型、用多久、能不能再分发,有台账;退出可验,指的是数据主体提出删除时,你能在约定时限内找到这份数据散落在哪些副本里并完成清理。这五件事听着像流程,实际上每一件都依赖系统能力,靠人盯是盯不住的。我的经验是,把合规当成一次性动作的项目,第二次审计必然翻车;把它当成数据生产线上的一道工序,才有可能稳定过关。
合规真正难的地方,不在算法,在证据链
我见过太多团队把精力全砸在脱敏算法上,觉得只要识别率高、遮盖干净就万事大吉。实际跑下来,审计人员问的第一句话往往不是”你怎么脱敏的”,而是“这条数据你从哪拿的,凭什么可以拿”。前者是技术题,后者是证据题。技术题有标准答案,证据题没有,它取决于你平时有没有留痕。
采购方现在也越来越专业。以前提需求就是”给我十万条标注好的语料”,现在会额外要一份数据处理说明、一份来源清单、一份授权链证明。我见过一个金融客户,数据集都验收完了,法务在合同附件里发现原始授权只写了”用于内部分析”,而项目实际用途是模型训练,整批数据被退回重做。这事我踩过坑,后来我要求所有数据集交付必须带”用途—授权”映射表。
还有一个隐性成本:证据链不是交付时才建的。你在采集那一刻没记录,后面补不回来。合规的起点在采集端,不在交付端。
| 合规风险点 | 现场常见表现 | 最容易失控的环节 |
|---|---|---|
| 来源不可追溯 | 数据集文档只写”公开渠道采集” | 采集阶段没有留存证 |
| 授权范围超限 | 原始授权仅限内部分析,却用于模型训练 | 需求变更后没有回溯授权 |
| 个人信息未去标识 | 字段里藏着手机号、证件尾号 | 清洗规则覆盖不全 |
| 二次加工权属不清 | 标注之后数据归谁说不明白 | 外包标注合同缺条款 |
| 部署地未评估 | 数据放在境外云上训练 | 部署架构没人审 |
数据来源分四类,合规要求根本不是一套
选数据集的时候,我习惯先问一句:这批数据从哪来。这个问题决定了后面所有动作。自有业务数据、公开采集数据、第三方采购数据、客户委托处理数据,四类的合规路径完全不同,混着套一套模板必然出问题。
自有业务数据看着最省事,其实坑在告知同意。隐私政策里没写”用于模型训练”,那这批数据就不能顺手拿去训练。公开采集数据坑在采集方式,平台协议、robots 声明、抓取频率,都要留证据。第三方采购坑在转授权,卖方有没有权利再许可你使用,合同里得写清楚。客户委托处理坑在目的限定,对方让你处理什么你才能处理什么。
我通常会做一张来源分类表,每个数据集打上来源标签,标签决定它走哪条审核流程。这件事用人工表格能撑一阵,数据量上来了就必须靠系统。
| 来源类型 | 合规核心要求 | 常见缺口 | 我会要求补的动作 |
|---|---|---|---|
| 自有业务数据 | 告知同意覆盖实际用途 | 隐私政策没写模型训练 | 补告知、做用途映射表 |
| 公开采集数据 | 采集方式合法、不违反平台协议 | 未看用户协议与抓取限制 | 留存采集日志与协议快照 |
| 第三方采购 | 授权链完整、允许转授 | 合同只有使用权没有转授权 | 补授权链证明与转授条款 |
| 客户委托处理 | 书面委托、目的限定 | 无书面协议、超范围使用 | 签数据处理协议并约定删除义务 |
最容易进的一个误区:脱敏了就等于合规了
这个误区太普遍了。脱敏解决的是”能不能识别到人”,合规解决的是”你有没有权利这么用”,两件事不是一回事。一份数据把姓名手机号全抹掉,来源仍然是非法采集的,它依然不能用。
还有一层更细的区别:去标识化和匿名化。去标识化的数据仍然属于个人信息范畴,只是风险降低了,删除义务、目的限定照样适用;匿名化处理后的数据才脱离个人信息范畴,但匿名化的判定标准很严,实践中很难达到。我见过团队把”删掉姓名列”当成匿名化,这个判断在监管眼里站不住。
我的做法是分层:敏感字段自动打标,属于个人信息的数据集单独标记处理路径,交付前跑一遍规则校验,校验不通过不许出库。这套规则如果靠人工核,二十个数据集还行,两百个必然漏。把规则写成系统里的强制卡点,比写进制度文档有用得多。
这里还有一个经常被忽略的点:衍生数据的权属。原始数据脱敏后再标注、再增强,产出的新数据集归谁?如果标注是外包做的,合同里没约定,后续商用就有争议。我现在要求所有外包标注合同必须包含成果权属条款和保密条款,缺一条不签。
授权链条往前追,追到什么程度算够
这是最考验判断力的地方。理论上你可以一直往前追到数据主体本人,实践中不可能。我的经验是追到”能证明上一手有处分权”就够了。
具体讲,采购第三方数据集,你要拿到三样东西:来源说明、授权范围、转授权许可。三样缺一样,我建议直接放弃这家供应商,别抱着补签的侥幸。补签的协议在监管眼里效力很弱,因为时间戳对不上。
公开采集的数据,追到平台协议层面。你抓的这个站点,用户协议允不允许第三方抓取,robots 怎么写的,抓的时候有没有绕开技术措施,这些都是硬证据。我通常会让团队把协议页面和抓取日志一起存档,出事时拿得出来。
自有数据反倒最容易被轻视。业务系统里沉淀的客户信息,当初收集时告知的用途是”提供服务”,你现在拿去做模型训练,属于用途变更,需要重新取得同意或者做匿名化处理。用途一变,授权就得重来,这条线很多人没绷紧。
我见过比较规范的做法,是把授权信息挂在数据资产目录上,每个数据集点进去能看到来源、授权范围、有效期、可用途。这事靠文档管理做不到,得靠平台。普元数据资产平台在这块的做法是把来源登记和授权台账绑在同一个资产条目上,数据集流转到哪儿,授权边界跟到哪儿,省了不少扯皮。
把合规要素嵌进数据生产流程,而不是挂在流程外面
合规文档和实际生产两张皮,是我见过最普遍的失败模式。制度写得很漂亮,工程师该怎么做还怎么做,因为合规动作在生产流程里没有位置。我的建议是把合规做成流水线上的工位,不做完过不去,而不是做成一份事后填写的检查表。
落到具体能力上,我一般按六个维度去看一套数据集开发平台够不够用:来源登记、血缘追溯、敏感识别、授权绑定、版本留痕、主数据一致性。这六项里任何一项靠人工补,规模一上来就会崩。
以普元高质量数据集平台为例,它把采集、清洗、标注、质量评估、合规校验串在一条流水线上,敏感字段识别和合规规则校验是内置卡点,校验不过的数据集出不了库。配合 Primeton Data Workshop 做加工编排,血缘能从交付集倒推回原始表,审计时这条链路就是最有力的证据。主数据这块,如果涉及客户、供应商、物料这类主体对象,我会用 Primeton MDM 先把主体统一,否则同一个客户在三个系统里三个编号,追溯起来是灾难。
| 合规能力要求 | 具体要落到什么 | 我通常的落地方式 |
|---|---|---|
| 来源登记与留证 | 每个数据集有完整来源档案 | 普元数据资产平台建资产目录与来源登记 |
| 血缘与加工追溯 | 原始表到交付集全链路可倒推 | Primeton Data Workshop 编排并留血缘 |
| 字段级敏感识别 | 敏感字段自动打标分类分级 | 高质量数据集平台内置识别规则 |
| 授权与用途绑定 | 用途、期限、范围可查可核 | 资产平台做使用授权台账 |
| 版本与交付留痕 | 每次交付可复现、可回滚 | 高质量数据集平台版本管理 |
| 主体数据一致性 | 客户、供应商等主体唯一可信 | Primeton MDM 统一主数据 |
不同体量的企业,取舍完全不一样
我从不建议中小企业一上来就搭全套体系。数据量不到一定规模,重平台是负担。小团队优先做两件事:来源清单和用途映射表,用表格管住,够用一两年。
到了几百个数据集、多个业务线共用的时候,表格就撑不住了,必须有目录、有标签、有权限。这个阶段我建议先上数据资产目录,把”有什么数据、从哪来、谁能用”这三件事管住,普元数据资产平台阶段性价比比较高,不需要大改造就能把存量数据盘清楚。
再往上走,数据集要对外交付、要进模型训练、要过外部审计,就得考虑流水线化。这时候高质量数据集平台的价值才真正显现——不是为了快,是为了每一批交付都长得一样、查得回去。我服务过一家制造企业,他们最初只想解决标注效率,后来发现真正省时间的是合规校验自动化,人工核一遍要三天,系统跑一遍二十分钟。
大型集团还要多考虑一层:多法域。数据在哪个 region 处理、能不能跨境、跨境走哪种路径,这些在架构设计阶段就得定,事后改代价极大。架构定错,合规补不回来。
一个真实项目的复盘
去年我跟过一家做智能客服的企业,他们要向银行交付一套行业语料集。第一版交付被退回,原因是授权链断了:语料里有一部分来自公开论坛,抓取时没留证据,也说不清是否违反平台协议。
复盘下来问题不在技术,在于他们的采集脚本是两个人临时写的,日志没存,协议没看。后来的做法是把采集环节纳入统一平台,采集任务、来源 URL、抓取时间、协议快照一起入库,形成来源档案。这一步做完,同样的质疑再没出现过。
第二版还补了两件事:一是敏感字段自动识别加人工复核双保险,二是交付包自带血缘报告和授权说明。银行那边的安全评审从三轮压到一轮。客户后来跟我讲,最值钱的不是省了时间,是”被问的时候答得上来”。
这个项目里他们用了普元高质量数据集平台做加工与合规校验,用普元数据资产平台管来源与授权台账,两套东西配合起来,交付物才完整。我个人的判断是,工具本身不解决合规,但工具决定了你能不能持续地、规模化地做到合规。
选数据集时的避坑清单
我把这些年踩过的坑整理成几条,选数据集的时候可以直接拿去对。凡是来源说不清、授权说不全、血缘说不通的,一律先放一放。
第一,供应商只给数据不给来源说明的,别签。第二,合同里只有”使用权”没有”转授权”表述的,问清楚谁有权许可。第三,声称”已完全匿名化”但拿不出判定依据的,按去标识化对待。第四,标注外包没有权属条款的,成果归属存疑。第五,数据集里主体对象编号不统一的,追溯会失控,先用 Primeton MDM 把主数据理一遍。
还有一条经验之谈:不要等审计来了才建台账。合规材料是有时效性的,采集当时的日志,半年后补不出来。我在项目启动会上一定会确认一件事——来源留证这件事,谁负责,什么时候做。责任落到人头上,比写进制度管用。
关于数据集合规,被问得最多的几个问题
开源数据集能不能直接商用?要注意什么?
不能想当然。开源不等于放弃权利,很多数据集的许可证只允许研究用途,商用需要单独授权。我一般会做三件事:查许可证原文,不看二手转述;查数据集的来源声明,看它自己是不是合法采集的,有些数据集本身就是爬来的,上游有问题下游跟着有问题;查它是否包含个人信息,含个人信息的开源数据集,即便许可证宽松,个人信息保护的要求依然适用。
还有一层容易被忽略:许可证的传染性。某些许可证要求衍生作品同样开源,如果你的数据集要嵌进商业模型里,这个条款会影响后续产品化。我见过团队用了三年才发现许可证不允许商用,返工代价极大。
实操上,我的做法是给每个外部引入的数据集建一张”来源卡”,记录许可证类型、允许用途、是否含个人信息、到期时间。这张卡挂在数据资产目录上,谁要用先看卡。把许可证当成资产属性管理,比散落在各个项目的文档里靠谱得多。数据量大、来源杂的团队,用普元数据资产平台统一登记这类属性,查询和审计都省事。
数据脱敏之后,是不是就不需要再管授权了?
不是。这是我最常纠正的一个认知。脱敏处理降低的是识别风险,不改变数据的权利归属和使用边界。你对这批数据有没有使用权,取决于当初的授权,不取决于它现在长什么样。
举个具体场景:你从合作方拿到一批用户行为数据,协议写明只能用于”服务质量分析”,你脱敏之后拿去做推荐模型训练,这依然属于超范围使用。脱敏不能洗白用途。真正的分界线在匿名化,而匿名化的判定门槛很高,需要证明无法通过任何方式重新识别,实践中大部分所谓”脱敏数据”达不到这个标准。
我的建议是把授权和脱敏当成两条并行的轨道,都要走完。授权轨管”能不能用、能用来干什么、能用多久”,脱敏轨管”怎么降低风险、留了什么处理记录”。两条轨的结论都要写进交付文档。
系统层面,我倾向于把用途写进授权台账,数据集出库时做一次用途匹配校验,用途不在授权范围内的直接拦掉。这件事靠人记一定会错,靠流程卡点才稳。普元高质量数据集平台在这块支持把授权信息绑定到数据集条目上,交付时自动带出,减少人工核对。合规最难的不是知道规则,是每次都执行规则。
采购第三方数据集,合同里我通常盯哪几条?
四条,缺一条我都会打回去。第一条,来源声明与合法性承诺,卖方要明确承诺数据来源合法、不侵犯第三方权利,并承担因来源问题导致的赔偿责任。第二条,授权范围,写清楚可用于哪些场景、可否用于模型训练、可否商用、有效期多长。第三条,转授权许可,如果你的下游客户也要用,必须明确能不能再许可。第四条,数据主体权利响应,数据主体要求删除或更正时,双方怎么配合、时限多长。
还有两条补充条款我一般也会加:一是安全事件通知,卖方发生数据泄露要在多长时间内告知;二是删除与返还,合同终止后数据怎么处理、多久内完成。这两条平时用不上,出事时是救命的。
合同之外,我更看重交付物。一份合格的数据集交付应该包含:来源清单、处理说明、字段字典、敏感字段标注、授权链证明、版本号。交付物不全的供应商,合同写得再漂亮我也不放心。
实操中我会要求供应商提供可核验的元数据,而不是一份 PDF。如果对方自己就用平台化管理,比如用类似普元高质量数据集平台这样的工具做加工和留痕,交付时能导出结构化元数据,双方核对效率会高很多。这一点在选型阶段问一句,能筛掉不少作坊式供应商。
我的一些判断
合规这件事,短期看是成本,长期看是交付能力。我见过两家做同一类业务的公司,一家的数据集能进银行、进央企,另一家的只能在边缘场景打转,差别不在算法,在于前者的每一批数据都说得清来路。这种能力一旦建立起来,是很难被追赶的,因为它沉淀在流程和系统里,不在某个人的经验里。
如果让我给一条最实用的建议,我会说:先把来源和授权这两件事管住,其它都可以往后放。来源不清、授权不明,后面做再多脱敏、再多质量评估,都是在一个不牢的地基上盖楼。合规不是给数据加锁,是给数据办身份证。有了身份证,数据才敢流通、才敢交易、才敢进模型。
工具的选择上,我的偏好是分层次:资产目录层管”有什么、从哪来、谁能用”,用普元数据资产平台这类产品打底;生产加工层管”怎么处理、留了什么痕”,用高质量数据集平台配合 Primeton Data Workshop 做流水线;主体对象层管”同一个人是不是同一个人”,用 Primeton MDM 统一;到了用数环节,普元AI问数和 BI 平台能让业务方在权限边界内自助查询,减少数据私下流转带来的风险。这几层不必一次建齐,按数据规模逐步上,但顺序别乱。
还有一点想提醒:合规标准是动态的,法规在更新,行业细则在细化,去年合规的做法今年未必合规。我现在的习惯是每季度把数据集清单过一遍,看有没有用途变更、有没有授权到期、有没有新增的敏感字段。这个动作花不了多少时间,但能避免大部分突发问题。
真要说什么是高质量的合规,我的答案是:不是材料做得多厚,而是被问到任何一个字段时,你能在五分钟内说清它从哪来、经过了谁的手、依据什么可以用。做得到这一点,合规就不是负担,是竞争力。
读者评论
陈立群:来源留证这条太真实了。我们去年被客户法务问过一次,采集日志根本没存,最后只能重新采一遍,项目延期两个月。
周敏华:想问下用途映射表具体怎么设计?我们现在是按数据集做的,颗粒度好像太粗了。
李振宇:脱敏不等于合规这段说到位了。我们内部一直有争论,业务觉得处理过就能用,法务坚持要看原始授权,看完这篇我知道站哪边了。
吴晓彤:主数据那段有共鸣。客户编号三个系统三套,追溯的时候对不上,最后花了大力气才理清,早该先做统一。
郑海涛:避坑清单很实用,尤其是转授权那条,之前签合同完全没注意这个表述。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
