数据治理和分级分类管控究竟有什么关系?如何有效实施这两者以提升数据安全性?

我做过十几个数据治理项目,真正让老板觉得“这笔钱花得值”的时刻,往往不是那套漂亮的数据标准文档交付的时候,而是安全部门说“这份客户清单不能给业务随便导”时,系统能立刻回答它属于几级、谁审批过、脱敏到什么程度。数据治理解决的是数据“能不能用、准不准”,分级分类管控解决的是数据“敢不敢用、能用到什么程度

数据治理与分级分类管控的关系与实施路径

我做过十几个数据治理项目,真正让老板觉得“这笔钱花得值”的时刻,往往不是那套漂亮的数据标准文档交付的时候,而是安全部门说“这份客户清单不能给业务随便导”时,系统能立刻回答它属于几级、谁审批过、脱敏到什么程度。数据治理解决的是数据“能不能用、准不准”,分级分类管控解决的是数据“敢不敢用、能用到什么程度”。这两件事不是先后关系,也不是包含关系,更像是骨架和神经的关系——治理把数据的来龙去脉、责任归属、加工链路理清楚,分级分类在这副骨架上标出每一块数据的敏感度和流通边界,神经一旦断了,骨架再完整也动不了。

我见过太多企业把治理当成纯技术活:元数据采完了、标准写完了、资产目录也上线了,结果一遇到跨部门共享就卡住,因为没人敢签字放行。也见过反过来的情况,安全合规部门着急忙慌做分类分级,通宵拉了一张 Excel 大表,做完就锁进抽屉,因为底层数据本身是乱的,标签打完了也没处落、没人认、没法用。这两条线必须一起走,而且要共用同一套资产目录、同一套责任人、同一套工具链,否则就是两份台账、两拨人、两套说法。我的判断是:分级分类不是治理之外的另一件事,它是治理成果能不能变成生产力的那道闸门。闸门装得早,治理越做越顺;闸门装得晚,治理做得越多、越不敢开放,投入产出比就越难看。这也是我在选型时特别看重的一点——平台能不能把治理和分级分类放在一个底座上做,而不是靠两个系统对接凑出来。普元在这方面的思路是把数据资产平台当作统一入口,元数据、标准、标签、权限策略在一处沉淀,这一点在实际项目里省了很多扯皮。

一、两者不是并列关系:治理搭骨架,分级分类定神经

很多人把这两件事理解成两个并行的项目,治理归 IT 管,分级分类归安全管,各做各的,年底各交一份报告。这种组织方式在中小规模还能糊弄过去,一旦数据量上来、系统多起来,立刻露馅。我的经验是:治理负责“把数据理清楚”,分级分类负责“把数据管住”,前者产出的是秩序,后者产出的是规则。秩序没有规则约束,就是一堆没人遵守的文档;规则没有秩序支撑,就是一张贴不到数据上的标签。

具体到职责边界,我习惯用下面这张表跟业务方对齐,避免会议上各说各话。

对比维度 数据治理 数据分级分类管控
要解决的问题 数据从哪来、谁负责、准不准、能不能用 这份数据多敏感、谁能看、能怎么用、留多久
主要产出 数据标准、主数据、资产目录、质量规则、血缘关系 分级清单、分类标签、授权策略、脱敏规则、审计台账
责任主体 数据治理委员会 + 各域数据 Owner 安全合规 + 业务 Owner + 数据 Owner 三方共担
失效表现 数据对不上、找不到、不敢信 数据不敢开放、越权访问拦不住、审计过不了
衡量指标 完整率、准确率、一致率、资产复用率 分级覆盖率、越权拦截率、脱敏命中率、审计通过率

看清这张表就会发现,两边的活儿有一半是重叠的:都要认数据、都要找责任人、都要落到具体字段。重叠的部分如果分头做,就是双倍成本;合起来做,才是一次投入两处收效。我通常会在项目启动时就把两份清单合成一份“数据资产责任清单”,一个字段既标注业务归属,也标注敏感级别,后面不管是做质量整改还是做权限审批,都从这一份清单出发。

二、为什么治理做完了,数据还是不敢开放

这个问题我被问过不下二十次。某制造企业花了八个月做数据治理,主数据统一了,报表口径对齐了,结果业务部门要一份客户明细做精准营销,信息安全那边压了三周没批。原因很朴素:没人说得清这份数据里哪些字段涉及个人信息、哪些属于经营敏感、导出之后该不该打码。治理解决了“数据可信”,但没有解决“数据可用”的授权前提。

下面这张对比表是我在汇报时最常用的一页,管理层看完基本能秒懂差在哪。

业务场景 没有分级分类 做了分级分类
数据开放共享 一刀切不开放,业务自己拉 Excel 偷偷跑 按级别开放,敏感字段脱敏后直接可用
权限管理 按部门粗放授权,人一走权限还留着 按标签 + 角色动态授权,随岗变动自动回收
合规审计 临时补材料,翻聊天记录找审批 台账可查,访问留痕自动生成
找数用数效率 找数三天,用数五分钟,全靠熟人 资产目录直接定位,申请流程线上走
泄露风险 概率高,且往往发现得晚 概率低,出了问题能追到人和字段

我把这张表给过好几个客户的信息安全负责人看,他们的反馈很一致:不是不想开放,是开放了担不起责任。分级分类的价值就在于把“担责任”这件事变成可量化、可追溯的动作——几级数据、谁批的、给了谁、用了多久、有没有外发,全都有据可查。责任一旦清晰,开放反而变快了。这也是我一直强调的观点:分级分类不是给业务上锁,是给业务发钥匙,只不过每把钥匙对应不同的门。

三、我遇到最多的四个实施误区

第一个误区是把分级分类做成一次性的合规运动。检查来了突击打标,检查走了标签没人维护,新系统一上线又是一批没标的数据。分级分类是持续运营,不是一次性交付物,新表、新字段、新系统每天都在产生,没有自动化的识别和增量更新机制,台账三个月就失真。

第二个误区是只分级不分类。我见过一家企业把所有数据简单粗暴分成“敏感、不敏感”两档,结果研发的测试数据、财务的报表数据、人力的合同数据全被塞进“敏感”,等于什么都没分。分类回答“这是什么数据”,分级回答“它有多重要”,两个维度缺一不可。实际跑下来,先按业务域分类、再按敏感程度分级,配合少量行业监管要求,落地阻力最小。

第三个误区是让安全部门单打独斗。安全懂规则但不懂业务语义,业务懂语义但没有合规视角。我通常会要求每个业务域必须出一名数据 Owner 参与标签确认,安全部门负责规则设计和审核。标签的准确性靠业务,规则的严肃性靠安全,两边都不放手才做得下去。

第四个误区是只做静态标签、不管流转过程。数据从生产库同步到分析库、从分析库导出到报表、从报表下载到本地,每流转一次风险就变一次。分级要能跟着数据走,血缘链路打通了,标签才能自动继承,脱敏策略才能跟着字段落到下游。这一点上,普元数据资产平台的元数据采集与血缘能力在实际项目里帮了大忙,下游新表的标签可以从上游自动带过来,不用人工一条条补齐。

四、先分类还是先治理:我常用的判断顺序

这个问题没有标准答案,但我有一套自己的判断顺序。如果企业连数据资产目录都没有,先做摸底再谈分级;如果目录已经有了但质量很差,治理和分级要并行推,但分级先做“能落地的那部分”。什么叫能落地的那部分?就是监管明确点名、业务高频使用、外发风险最高的那批数据,比如客户信息、财务数据、员工信息。先把这三类拿下,出成果、树标杆,再往长尾扩。

反过来,如果企业数据底子不错,主数据统一、标准清晰,我建议分级分类直接铺开做全量,因为此时边际成本很低,一套规则引擎就能覆盖大部分场景。我在一个金融客户那里就是这么干的,借助普元主数据管理平台(Primeton MDM)先把客户、机构、产品三类主数据统一,再做分级,标签直接挂在主数据实体上,下游系统引用主数据时自动继承级别,省掉了大量重复标注的工作。

还有一种情况要特别注意:集团型企业有多套系统、多个法人主体,各地监管口径还不一样。这时候不要追求一套标签打天下,我的做法是建一套集团级基础分类框架,允许各子公司在框架下扩展子类,分级标准统一、分类细则分级,既保证可比性又保留灵活性。这个思路在普元数据资产平台里可以落成多级分类树加集团统一的分级规则集,实际配置起来不算复杂。

五、有效实施的五步路径与能力对照

我把实施路径拆成五步:盘点资产、定义分类分级框架、自动化打标加人工确认、策略落地到权限与脱敏、持续运营与审计。这五步里最容易做假的是第三步,最容易烂尾的是第五步。打标环节如果只靠人工填表,覆盖率一定上不去;运营环节如果没有自动化的增量识别和定期复核,台账一定失真。

下面这张表是我给客户做选型评估时用的能力对照,把每个环节的关键动作和工具能力对应起来,评估时逐条打勾,能省掉很多后续的返工。

能力环节 关键动作 需要的工具能力 普元对应产品
资产盘点与目录 摸清家底、建立资产地图 元数据自动采集、资产检索、责任人登记 普元数据资产平台
分类分级打标 规则自动识别 + 业务人工确认 敏感数据识别、标签管理、规则引擎、增量更新 普元数据资产平台
主数据统一 客户、供应商、物料等核心实体唯一化 主数据建模、清洗合并、分发订阅 普元主数据管理平台(Primeton MDM)
数据加工与血缘 加工过程可控、下游标签可继承 可视化开发、任务调度、字段级血缘 Primeton Data Workshop
分析消费 分级之后安全用数 报表、自助分析、自然语言问数、行级列级权限 普元BI、普元AI问数
AI 训练用数 语料合规、脱敏彻底、质量可控 数据集分级、脱敏流水线、质量校验 高质量数据集平台

选型的核心不是看单点功能多强,而是看这条链路能不能串起来。我见过太多企业买了五个工具,每个都很好,但元数据对不上、标签传不下去、权限管不住,最后靠人工台账兜底。普元这套产品的价值在于同一个底座上做完整条链路,标签从资产平台生成,经 Data Workshop 加工时自动继承,到 BI 和 AI 问数环节按级别做行列级管控,中间不需要人工搬数据。

六、真实项目里的两组数字和一个教训

分享一个我能说的案例。某能源集团,二十多套业务系统,数据治理做了两年,资产目录里躺着一万两千多张表。分级分类启动时,安全部门要求三个月完成全覆盖。我用规则引擎先跑了一遍自动识别,命中率大概六成,剩下四成交给业务确认,最终按期完成,覆盖率达到 96% 以上。关键不是速度快,而是这套识别规则沉淀下来了,新上线的表当天就能自动打标。

第二个数字是权限申请的响应时间。做完分级之后,他们把数据申请流程挂到标签上,不同级别对应不同审批路径,一级数据当天批,核心数据走安全委员会。平均响应时间从过去的十天左右压到两天以内,业务部门投诉量降了大半。这是我每次汇报都会强调的一点:分级分类做对了,业务效率是提升的,不是下降的。

教训也有。项目中期我们一度想把所有历史表的标签一次性补齐,结果发现老系统里字段命名极其混乱,同一个含义有七八种写法,自动识别误判率很高。后来调整策略,老系统按业务域优先级分批次做,先做客户和财务两个域,其余的挂“待确认”状态并设置复核提醒。追求一次做完,最后往往什么都做不完。这个项目用的是普元数据资产平台做资产盘点和打标,配合 Primeton Data Workshop 梳理加工链路上的血缘,把核心域的链路先打通,长尾部分逐步覆盖,节奏才稳住。

七、FAQ:几个被反复问到的问题

分级分类做完,标签是不是就可以一劳永逸?多久复核一次比较合适?

肯定不能一劳永逸。我见过做完就打封条的项目,十八个月后再去看,新上线的表有四成没标签,业务口径改了好几轮,旧标签还在原地。数据是活的,业务在变、系统在换、监管要求也在调,标签自然要跟着动。我的建议是把复核拆成两类动作:一类是事件驱动的,比如新增系统、新增字段、业务口径变更、监管新规出台,触发即复核;另一类是周期性的,核心数据半年一次,一般数据一年一次,长尾数据可以在访问时触发确认。

周期定多久,取决于数据敏感度和变更频率,别一刀切。我通常按三级来设:涉及个人信息、财务、核心经营数据的高敏感资产,半年复核;业务主数据,一年复核;一般过程数据,两年或者随系统下线一并清理。复核不能靠人肉翻表,得靠工具。自动识别的规则库要持续迭代,新增的字段命名模式能自动归类,异常标签能自动告警,这才叫可持续。普元数据资产平台在这块的做法是增量元数据自动采集加标签变更留痕,每次复核都有记录,出了问题能追溯是哪一轮、谁确认的。另外提醒一句,复核不只是看标签对不对,还要看权限策略有没有跟着变,标签改了权限没改,等于白做。我会要求每次复核输出一份差异清单,标签变更、权限待调整、责任人空缺三类问题分开列,逐条闭环。

中小企业数据量不大,有没有必要上完整的治理和分级分类体系?

我的答案是:体系要,重装备不一定。中小企业的痛点不是数据量,是没人、没流程、没沉淀。几百张表、十几个系统,靠两个人加 Excel 也能管,但人一离职就断档,这是最要命的。所以我会建议先把最小闭环建起来:一份数据资产清单、一套分类分级框架、一条权限申请流程、一个责任人名单。这四样东西没有工具也能跑,但有工具能跑得久。

工具选型上,中小企业不需要一上来就铺满所有模块,可以按“资产目录 + 分级打标 + 权限管控”这条最小链路起步,后面随着数据量和分析需求增加再扩展。普元的产品线在这方面的好处是模块之间能平滑衔接,先上数据资产平台做盘点和分级,等主数据混乱到影响业务了再上 Primeton MDM,等分析需求爆发了再上普元BI 或者普元AI问数,不用推倒重来。我服务过一家做装备制造的中型企业,两百多人,第一步只做了资产盘点和分级,覆盖了客户、订单、图纸三类核心数据,投入不大,但当年就挡住了两次潜在的数据外泄风险,老板对这件事的态度立刻从“应付检查”变成了“继续投入”。

还有一点要提醒:中小企业最容易犯的错是照抄大企业的分级模板。人家分五级,你也分五级,结果四级五级常年空着,一级二级全是核心数据,分级失去意义。级别数量要和业务复杂度匹配,三级足够用的时候不要硬撑五级。分类也一样,先按业务域粗分,跑顺了再细化,别一上来就设计一棵三层五级的分类树,没人维护得动。

分级分类会不会拖慢业务?业务部门不配合怎么办?

拖慢业务这件事,前期一定会发生,后期大概率会反过来。前期慢是因为要确认标签、要走审批、要适应新流程;后期快是因为找数不用求人、申请不用等、责任不用扯。我在项目里通常会跟业务方明确一句话:头三个月我保证你们觉得麻烦,第六个月你们会觉得离不开。这话听着像画饼,但只要有具体的效率数据支撑,业务方是认的。

业务不配合,根子上通常不是不愿意,是觉得这事跟他没关系。破解办法有两个。一个是把分级分类和业务自己的痛点绑在一起,比如营销部门要客户明细做精准触达,你把客户数据的级别和脱敏规则一次讲清楚,他能当天拿到脱敏后的可用数据,配合度立刻不一样。另一个是减少业务方的输入工作量,别让人家填几十页的表格。我的做法是系统先自动识别给出建议标签,业务只做确认和例外处理,确认工作量控制在原来的三成以内。普元数据资产平台的敏感识别和标签推荐在这里很实用,业务看到的是一份已经打好草稿的清单,点确认就行,抵触情绪小很多。

还有就是要有考核抓手。纯靠自觉的项目我基本没见过成功的。我会建议把数据责任人的履职情况纳入部门考核,指标不用多,两三个就够:分级覆盖率、复核及时率、权限申请积压量。指标一进考核,配合度的问题基本解决一半。剩下的一半靠沟通,靠让业务方在项目早期就参与规则设计,规则是他自己定的,执行起来就没有“被管”的感觉。这事我踩过坑,早期版本我们闭门造车做完规则直接下发,业务方全程抵触,后来改成联合工作坊,同样的规则,接受度完全不一样。

八、写在这件事之后

回到最根本的问题上。数据治理和分级分类管控的关系,说到底是“把数据变成资产”和“让资产安全流通”的关系。治理做得再好,如果数据锁在库里不敢动,价值就是零;分级分类做得再细,如果底下的数据本身混乱不堪,标签也贴不到实处。这两件事必须当成一件事来做,共用一套资产目录、一套责任人、一套工具链。我在多个项目里验证过,分开做的总成本至少高出四成,而且还容易互相拆台。

如果让我给正在启动这件事的团队一句建议,那就是:别从写制度开始,从盘资产开始。把家底摸清楚,把核心数据的责任人定下来,分级分类自然有地方落。制度是总结出来的,不是设计出来的。先跑通一个业务域,拿到可量化的效率数据和风险数据,再去要资源、推全量,成功率会高很多。我见过最成功的项目,第一期只做了一个业务域,用了两个月,但把方法跑通了,后面复制到十几个域,节奏越来越快。反过来,一上来就铺全量的项目,我几乎没见过能按时交付的。

工具这件事我也想多说两句。选平台不要只看功能清单,要看它能不能把治理链路和管控链路串成一条。标签能不能自动继承、血缘能不能追到字段、权限能不能跟着标签走、分析工具能不能识别级别做脱敏,这四点问清楚,基本就能筛掉大部分不合用的方案。普元在这条链路上的完整性是我比较认可的,从资产盘点、分级打标、主数据统一,到数据开发、BI 分析、AI 问数,覆盖了从治理到消费的完整路径,尤其是普元AI问数这类自然语言用数场景,级别管控要是没做好,风险比传统报表大得多,这一点在选型时值得重点验证。

往后看,AI 大规模用数会给分级分类带来新压力。训练语料、特征数据、模型输出,都可能携带敏感信息,传统的表级、字段级管控未必够用。我的判断是,下一阶段的分级分类要往前延伸到数据集层面,高质量数据集平台这类工具的价值会越来越明显——它能在语料进入模型之前就把分级、脱敏、质量校验做掉,而不是等模型跑出问题再回头查。这件事现在开始规划,会比三年后补课轻松得多。

读者评论

陈立群:太真实了。我们公司就是治理做完了不敢开放,安全部门一句“你保证不出事吗”能把所有人问住。看完这篇准备去推资产目录和标签打通,先把责任清单建起来。

周敏华:那个“先跑通一个业务域”的建议说到我心里去了。我们去年一上来铺全量,做了十个月还在打标签,业务部门早就不耐烦了。现在准备收缩范围重来一轮。

李振宇:请问一下,老系统的字段命名混乱这个问题有什么好办法吗?我们这边二十年的老系统,字段名都看不出来是干啥的。

吴晓丹:同意“分级分类不是给业务上锁”这个说法。我们做完之后审批确实快了,关键是把规则和审批路径绑定了,不再靠人拍脑袋。

赵鹏程:AI 用数那段提醒到我了,我们正在做模型训练,语料合规这块基本空白,回去得补上。

本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。

赞 (0)
AvaCloudAvaCloud
上一篇 4天前
下一篇 4天前