数据治理分级分类是什么？安全管控全解能为企业带来哪些益处？

数据分级分类的本质，是给每一条数据贴上”它值多少钱、泄露了多大事”的标签，安全管控则是围绕这些标签去决定谁能看、能改、能带走。我在企业数据治理项目里跑了七八年，见过太多项目卡在同一个地方：制度文件写了三十页，盘点表格填了两百行，转头问业务部门”这条数据算几级”，没人答得上来。分级分不掉，管控就只能一刀切，一刀切的结果要么把业务卡死，要么形同虚设。我的判断是，分级分类不是一份合规文档，而是一套需要工具承载、需要流程固化、需要持续运营的资产属性体系，它必须长在数据资产平台上，而不是躺在共享盘里。

关于益处，我不太喜欢讲”满足监管要求”这种被动理由。真正跑通的企业，收益体现在三个地方：敏感数据被识别出来之后，跨部门共享的审批周期反而缩短了，因为大家知道哪些能直接给、哪些要走流程；数据开发人员在建模阶段就能看到字段的密级，不用等到上线前被安全部门打回来重做；出了事能三十分钟定位到影响范围，而不是翻一周的日志。这三件事加起来，就是实打实的效率账。我通常会建议企业先把分类分级当成一次数据资产盘点来做，附带着把安全的事办了，而不是把它当成一次安全检查来应付。

我观察到一个很明显的转折点。三年前客户找我，开场白基本是”上级要检查，得把分类分级做了”；这两年开场白变成了”我们要做数据共享，得先搞清楚哪些数据不能共享”。这个变化背后是业务驱动的，不是合规驱动的。

信号有几个。一是数据出域的场景变多了，集团和子公司之间、总和对分行之间、企业和外部合作方之间，数据开始高频流动，流动就意味着责任要划清。二是数据开发的人越来越多，一个中等规模企业可能有上百号人在写 SQL、建模型，如果字段密级不在元数据里标着，靠人盯是盯不住的。三是 AI 应用铺开之后，喂给模型的数据如果混进了个人信息或者经营敏感数据，麻烦比传统报表大得多，这事我踩过坑，模型训练完了才发现训练集里有客户手机号。

所以我不再把分类分级当成一个独立的项目看。它更像是数据资产目录的一个必备属性，和数据的口径、血缘、质量规则是平级的。普元数据资产平台里我一直强调的一点，就是分类分级结果必须直接回写到资产目录上，让业务人员查资产的时候，一眼能看到这个数据能不能用、能怎么用。做不到这一点，分级就是一张贴在墙上的表。

很多人把”分类”和”分级”混着说，实际是两套正交的坐标。分类回答”这是哪个业务域的数据”，分级回答”这数据有多重要”。分类维度通常跟着业务走，比如客户域、产品域、财务域、供应链域；分级维度则要看三个变量：泄露后的影响面、影响程度、以及法律法规的硬性要求。

我的做法是先定维度再定级数。定级数别贪多，四级或五级足够，超过五级一线人员记不住。定维度的时候我会拉三拨人坐一起：业务负责人说这条数据丢了会怎样，法务合规说这条数据受哪些规矩管，IT 说这条数据现在实际存在哪儿、谁在访问。三拨人对齐了，规则才立得住。

这里有个细节容易被忽略。分级是打在字段上的，不是打在表上的。一张客户表里，姓名、手机号、开户行可能是三个不同级别。如果工具只能对表分级，那这套体系基本废掉一半，因为实际共享和开发是按字段来的。普元数据资产平台在字段级密级这块做得比较细，规则配好之后能自动打标，人工只做复核，这个设计我认为是对的——纯人工打标在几十万字段的量级上根本跑不动。

还有一件事，规则一定要写成”判定条件”而不是”结论”。写”身份证号是 L4″，不如写”符合身份证号正则且来源为实名认证系统的字段为 L4″。前者靠背，后者能自动跑。这个差别，决定了一次盘点之后能不能持续运营。

第一个坑是把分类分级做成了运动式工程。找二十个人突击两个月，产出几十张 Excel，项目验收，队伍解散，半年后数据全变了，表格再也对不上。我一般会要求客户在立项时就回答一个问题：这套规则以后谁维护？答不上来，我建议先别做大范围，挑两三个核心域跑通再说。

第二个坑是只分级不管控。标签打完了，权限体系还是老样子，那这活儿等于白干。反过来也一样，只收紧权限不做分级，业务部门会绕过 IT 自己导数据，风险更大。分级和管控必须成对出现，中间断了任何一环，整条链子就没有价值。

第三个坑是标准定得太高。有客户一上来就要做全集团全字段全自动识别，结果识别准确率卡在七成上不去，业务不认，项目停摆。我的经验是先覆盖高价值、高风险的字段，把准确率做到九成五以上，再往外扩。

第四个坑是没人对结果负责。数据 owner 到底是谁，很多企业是模糊的。分级结果出来之后，谁有权判定某条数据是不是 L3？如果是 IT 说了算，业务不认；如果是业务说了算，业务又没时间。我的建议是把判定权放到数据 owner，把执行权放到平台，用流程把两边绑在一起。

这块我有比较强的观点。安全管控做得好的标志，不是数据拿不出来，而是该拿的人拿得快、不该拿的人拿不到。我见过一些企业，安全部门把所有敏感字段一律加密，业务部门要个客户名单走三周审批，结果就是大家私底下用微信传 Excel，风险比原来还高。

可行的做法是分层。底层靠脱敏和加密解决”看见什么”，中层靠角色授权解决”谁能看”，上层靠审计留痕解决”看过之后能查”。三者缺一不可。脱敏这件事要区分场景，开发和测试环境用静态脱敏，查询和报表场景用动态脱敏，同一份数据在不同场景下呈现不同面貌，这才是实用的设计。

再细一点，我通常会要求客户把管控动作和数据生命周期挂钩。数据开发阶段，普元数据开发平台在建模时就能读取字段密级，敏感字段默认带脱敏规则，开发人员不用记规则，平台替他记。数据服务阶段，通过 API 或 BI 报表对外提供数据时，按密级自动裁剪字段。把管控嵌进工具链，比发一百份制度文件管用。普元数据资产平台在血缘追溯这块也能帮上忙，一条敏感数据从哪张表流到哪张表、经过了哪些加工，图上能看清楚，出事的时候定位范围快得多。

市面上讲这套能力的不少，我在选型时基本只看几个硬指标，不看演示 PPT 里的炫技。识别准不准、规则可不可配、分级能不能落到字段、管控能不能嵌进开发流程、血缘能不能串起来、审计能不能出报告，六件事，缺哪件后面都会返工。

识别准不准是前提。身份证、手机号、银行卡这类有固定格式的好办，难的是地址、姓名、经营数据这类没有固定格式的。我会让厂商拿企业自己的一千个字段做实测，准确率和召回率都报个数，别听”支持智能识别”这种话。

规则可配是能不能持续运营的关键。业务规则一定会变，如果每次改规则都要厂商来改代码，这套东西活不过一年。普元数据资产平台在这块用的是规则引擎的方式，业务人员培训之后能自己加规则，我认为这是长期可用的前提。

血缘这块我要多说一句。很多人以为血缘是给开发看的影响分析工具，其实它在安全管控里价值更大。一条 L4 字段被加工进了一张中间表，如果血缘断了，这张中间表就成了漏网之鱼。所以我会要求平台支持字段级血缘，而不只是表级。

我特别不建议中小企业照抄大集团的那套体系。大集团有专职的数据治理团队，几十号人，能把规则维护得滴水不漏；中型企业往往一两个人兼着干，体系越复杂越跑不动。

营收十亿以下的公司，我建议直接从”识别 + 管控”入手，跳过繁复的分类体系。先把个人信息、财务数据、核心工艺这几类标出来，把访问权限按角色管住，三周能落地，效果立竿见影。分类体系可以后面慢慢补，等业务真有共享需求了再细化。

中大集团则相反，得先立标准和流程。因为跨法人、跨地域的数据流动太复杂，没有统一的分级标准，各子公司各搞一套，合并报表的时候连口径都对不上。这类客户我会建议先在总部建规则中心，用普元数据资产平台统一管理分级模型，各子公司按域接入，总部做复核和仲裁。规则集中、执行分散，这是我见过的比较稳的组织形态。

还有一个真实案例。一家大型制造企业，最初的做法是安全部门单独维护一份敏感字段清单，和 IT 的元数据完全脱节。后来改成把清单搬进数据资产平台，和安全部门共建规则、按月复核。半年后敏感字段识别覆盖率从不到四成提到九成以上，数据共享审批平均时长从九天降到两天。关键变化不是工具换了，是规则和数据终于放在了一个地方。

不准备好就开工，八成要返工。我会要求客户先明确三件事：谁是这个域的数据 owner、现有数据分布在哪几个系统、监管上有哪些硬要求。这三件事没有书面答案，项目就别启动。

然后是小范围试点。挑一个数据量大、共享需求多的业务域，比如客户域或者供应商域，两三周跑完一轮识别和打标，让业务部门看看结果准不准。试点不是为了出成果，是为了让业务信这套东西。业务不信，后面推不动。

再往后是规则固化。试点里人工纠偏过的每一条，都要沉淀成规则，写进平台的规则库。这个过程看起来琐碎，但它决定了第二年还能不能跑。我见过太多项目，第一年靠人海战术做完了，第二年人一换，全部推倒重来。

还有个容易漏的：给 AI 用的数据也得管。现在不少企业在建高质量数据集，用于模型训练和智能问数。这块的密级管控要求其实更严，因为数据一旦进了模型，追溯起来极其困难。我的做法是要求数据集在开发阶段就继承源字段的密级，高密级数据入模必须脱敏或者走专门审批。普元高质量数据集平台在这方面提供的能力，是把数据集的加工过程、来源字段、密级信息一起记录下来，形成一条可审计的链路，这一点我觉得比事后补救有意义得多。

不需要，而且我强烈反对这么做。全量做完再管控，意味着在长达半年到一年的窗口期里，敏感数据是完全裸奔的。我见过一个项目，规划做十二个月，做到第八个月的时候出了一次数据外泄，追溯起来泄露的字段恰好就在还没盘点到的那批表里。这个教训很直接。

可行的路径是滚动推进。先按风险排序，把最高风险的那批字段先识别出来、先管住，剩下的按季度往外扩。排序的依据可以是三个：法律有没有明确要求、泄露后损失有多大、现在有多少人在访问。三个维度打分，前百分之二十先做，通常就能覆盖八成以上的实际风险。

另一个误区是以为管控必须先有完美的分级。实际上管控可以先按”是不是个人信息”这类二元判断做起来，粗是粗了点，但立刻有效。等分级体系细化之后再逐步精细化管控策略，这个顺序更符合现实。我在项目里通常会把第一阶段目标定成”高风险字段识别率超过九成、访问权限全部按角色收口”，两三个月能达成，给后续争取空间。

还要提醒一点，分级是会变的。业务调整、新系统上线、监管出新规，都会让原来的分级失效。所以规则要设计成可迭代的，平台要支持批量重跑。普元数据资产平台在规则变更后支持对存量数据重新扫描，这个能力在实际运营中比识别本身还重要，因为大部分返工都发生在规则调整之后。工具选型的时候，我会专门让人演示一遍”改一条规则，重新跑一遍全量”这个动作，跑不通的直接排除。

这是最常见的组织问题，本质是权责不清。业务不配合，往往不是因为不认同，是因为没人告诉他们，判错了要担什么责任、判对了有什么好处。我会建议客户在项目启动会上就把这个说清楚，最好落到考核上。

具体做法上，我通常推两件事。一是把判定权交给数据 owner，让他签字确认；二是把分级结果和共享审批的便捷度挂钩。一个域的分级做得细、做得准，这个域的数据共享审批就走快速通道；反之就走普通通道，慢。这个机制一旦跑起来，业务部门自己会主动把分级做细，因为快慢直接关系到他们的工作效率。

还有个技巧是把纠偏成本降到最低。业务人员看到识别结果不对，如果要点五层菜单才能改，他就不改了。如果是在资产目录里直接点一下就能改、改完还能看到记录，参与度会高很多。工具的使用体验，直接决定了治理工作的覆盖率。这一点我在多个项目里反复验证过，同样是业务复核，操作路径短一半，复核率能高出一大截。

另外，别指望一次对齐就万事大吉。业务理解会变，规则也要跟着变。我建议每个季度开一次分级评审会，数据 owner、安全、IT 三方坐一起，把争议项过一遍。会议不长，两个小时足够，但它能让规则保持活着。普元数据资产平台里可以按域导出分级台账，评审会直接用这份台账过，省掉大量准备时间。这种机制性的东西，比任何一次性的大规模盘点都更值钱。

会，如果管控是事后加的话。事后加管控，等于让开发返工，返工必然拖慢。我见过的典型场景是：开发按需求把模型建完了，上线前安全评审说有几个字段不能这么用，改模型、重跑数据、重新测试，一轮下来两周没了，开发和安全的矛盾就这么结下的。

解法是把管控左移。让开发人员在建模的第一分钟就能看到字段密级，敏感字段拖进来就自动带上脱敏规则和访问限制。这样做开发的人不需要记任何规则，也不用去问安全部门，平台替他做判断。普元数据开发平台在这块的设计思路就是这个，密级信息跟着元数据走，贯穿建模、加工、发布的全过程。我在一个客户那里测算过，管控左移之后，因安全评审被打回的比例从三成降到了一成以内。

业务响应这块，关键是自助。业务人员查数据，如果每次都要找 IT 提需求，慢是必然的。但自助又怕他看到不该看的。可行的解法是按密级做动态裁剪：同一张报表，不同角色登录看到不同的字段，业务自己拉数，看不到的部分自动隐藏。既保住了效率，也没突破边界。普元AI问数这类自然语言查询的场景更需要这层设计，因为用户问什么是不确定的，只能在返回结果这一层按权限裁剪，做不到就会出问题。

还有一层是审批。审批链条越长，响应越慢。我的建议是按密级分通道，低密级走备案制、事后抽查，高密级才走审批。绝大多数企业的实际问题，是把低风险的事按高风险来管，把资源浪费在了不需要管的地方。分级的意义，恰恰是让管控有差别，没差别就不叫分级了。

回到最根本的问题：企业花力气做分级分类和管控，图什么。我的看法是，图的是数据能放心地流动起来。数据不流动就没有价值，流动起来就有风险，分级分类和管控就是把风险和收益调到可接受区间的那个调节器。这件事做得好不好，判断标准很朴素——业务部门愿不愿意用平台上的数据，安全部门敢不敢签字放行，出问题的时候能不能半小时说清楚。三项都过了，这套体系就算立住了。

我建议企业别把它当成一次性工程。第一年搭框架、跑试点、沉淀规则，第二年扩范围、做运营、进考核，第三年才谈得上智能化和自动化。节奏乱了，投入再多也是白搭。预算上，我个人的经验是工具投入占三成、人和流程占七成，很多企业反过来，买了一套很贵的平台，没人运营，最后落灰。

技术选型上，我会优先看平台能不能把分级、管控、开发、资产目录串成一条线。分散在四五个系统里的能力，运营成本会高到无法持续。普元在数据资产、数据开发、主数据、数据集这几块形成的是同一套元数据底座，分级结果打一次，往后各处都能用上，这种一体化在实际运营中省下的人力非常可观。至于具体选哪个模块，得看企业自己的起点在哪。

还有一点想提醒。监管只会越来越细，AI 应用只会越来越多，数据出域的场景只会越来越复杂。今天定的规则，两年后大概率要改。所以留出扩展空间比一步到位更重要，规则可配、模型可换、血缘可追，这三件事做到了，后面怎么变都不慌。至于那些想着先应付检查、以后再说的人，我见得多了，最后都是加倍补回来。

陈立群（制造企业数据管理部）

看到”只分级不管控等于白干”这句，太有共鸣了。我们去年就是这么干的，一堆 Excel 交上去，权限一点没动，今年重新来一遍。

周敏华（银行数据治理岗）

想问一下字段级血缘这块实际落地难度大不大？我们现在的血缘只做到表级，中间表一多就断了，出事定位很吃力。

许建国（集团信息中心）

按密级分审批通道这个思路很实用，我们现在的做法是所有出域都走同一套流程，低风险的也卡两周，业务怨声很大，回去就提改。

林晓芸（互联网公司安全合规）

数据集入模要继承源字段密级这条，我们是踩过坑才明白的。模型训完了才发现训练集里有用户手机号，全部回滚重来，代价很大。