数据分类分级的自动化实现方案：基于大模型的敏感数据识别与打标实战

Mon, 07 Sep 2026 10:00:00 +0800

数据分类分级是所有数据安全工作的起点。加密、脱敏、访问控制、审计、DLP，这些手段哪一个不需要先知道"这条数据到底有多敏感"？但一个尴尬的现实是：大多数企业连"家底"都摸不清——几万张表、上百万个字段，靠人工一个一个标注级别，既标不完，也标不准，更标不起。

有句话说得好：凡是重复性、规则性强的脑力劳动，最终都会被自动化吃掉。数据分类分级这件事，恰恰站在这个临界点上。本文拆解一套"规则引擎 + 大模型"的自动化打标方案，重点讲大模型怎么把语义级的敏感数据识别这件事真正做起来。

一、为什么分类分级必须走向自动化

传统上，数据分类分级有三种做法，各有各的死穴：

做法	死穴
人工盘点	字段海量、成本极高，且不同人标准不一、容易漏
正则规则引擎	只能识别"长什么样"（手机号、身份证号），对语义敏感的字段无能为力
数据字典白名单	依赖字段名规范，字段名一不规范（“备注"“扩展字段”）就漏判

先看规则引擎的边界。用正则匹配手机号、身份证号、银行卡号这类 PII（个人可识别信息），准确率可以做到接近 100%，速度也快。但问题在于：大量敏感信息不是靠"格式"识别，而是靠"语义"识别。

比如一个字段叫 patient_description，里面写的是"患者于 2024 年确诊恶性肿瘤，目前接受化疗”。这个字段既没有标准格式，也没有明显的 PII 模式，但它毫无疑问是敏感数据——个人健康信息。规则引擎面对它只能抓瞎。

再比如一个 contract_remark 字段，写的是"该供应商为某军工单位二级配套"。没有身份证号、没有手机号，但它是供应链敏感信息。

规则引擎解决的是"已知的敏感长什么样"，大模型解决的是"没见过的敏感长什么样"。这两者必须配合，缺了谁都不完整。

二、先把标准钉死：分类分级框架是自动化的前提

在谈大模型之前，必须先说清楚一件事：自动化打标，打的是什么标？标准从哪来？

如果连"分几类、分几级、什么数据算敏感"都没定，大模型只能凭"感觉"打标，结果必然是各行其是。所以第一步是把分类分级框架定死，大模型只是这个框架的"执行者"。

这里参考一份真实的行业规范（某大型汽车集团的数据分类分级标准，已脱敏），它的框架可以直接抄：

三大数据类：企业数据、个人信息、车联网数据（车企特有，其他行业换成自己的业务域即可）。

六级分级，由低到高：

级别	名称	定义要点
1级	公开数据	可对外公开发布、转发传播
2级	内部共享数据	泄露对个人/组织权益造成一般危害，内部及关联方可共享
3级	授权共享数据	泄露造成严重危害，内部授权后访问，外发需审批脱敏
4级	限制分发数据	泄露造成特别严重危害，建立授权控制列表严格管控
5级	重要数据	泄露直接危害国家安全（一般危害），按法律法规认定
6级	核心数据	泄露危害国家安全（严重/特别严重危害），按法律法规认定

5级、6级对应国家层面"重要数据、核心数据"，由监管认定，企业基本不碰；内部主要精力花在 1-4 级的一般数据上。

这份规范里有一条原则，对自动化打标至关重要——就高从严原则：当多个因素可能影响分级时，按可能造成的最高影响程度确定级别。

翻译成工程语言就是：大模型打标宁高勿低，模棱两可时取高级别。这直接决定了后面 Prompt 和判定逻辑怎么设计。

还有一组概念是判定的"打分表"——分级要素：

影响对象	影响程度
国家安全 / 经济运行 / 社会秩序 / 公共利益 / 组织个人权益	特别严重 / 严重 / 一般 / 无危害

这个二维矩阵，就是大模型做判定时脑子里要装的东西。

三、方案设计：规则引擎 + 大模型的两层架构

单靠大模型不经济——每条都调模型，慢且贵；单靠规则引擎不全面——语义敏感抓不到。所以落地的架构是两层：

数据字段 → 第一层：规则引擎（正则 PII 识别）
                ├─ 命中 → 直接定级，不走模型
                └─ 未命中 → 第二层：大模型语义识别
                              └─ 输出 级别 + 依据 + 置信度

第一层：规则引擎兜底

用正则 + 数据字典覆盖"格式可识别"的敏感数据：

类型	识别方式	定级
手机号 / 身份证 / 银行卡 / 邮箱	正则匹配	4级（敏感个人信息）
姓名、证件号、家庭住址	数据字典 + 正则	3-4级
内部字段名白名单（薪资、绩效、密钥）	字段名匹配	4级

第一层命中的，直接定级，不进大模型，省钱又省时间。这一层能覆盖的，往往是"大头"——在一个真实盘点里，PII 类字段常常占敏感字段的六七成。

第二层：大模型语义识别

第一层漏掉的——那些靠语义判断的敏感字段——交给大模型。这是本文的重点，下面展开。

四、大模型打标的关键实现

4.1 识别粒度：字段级为主

实践证明，字段级是最优粒度——给模型一个"字段名 + 字段注释 + 采样值"，让它判断这个字段的级别。表级太粗（一张表可能混着各种级别的字段），记录级太细（成本高、且逐条判断不稳定）。

字段级识别的输入构造：

字段名：patient_description
字段注释：患者病情描述
采样值：["患者于2024年确诊恶性肿瘤，接受化疗中", ...]
→ 大模型判断：个人健康信息，敏感个人信息，4级

4.2 Prompt 设计：把标准喂进去

大模型不会凭空知道你的分级标准，必须把框架喂进去。Prompt 三要素：

角色设定：你是一名数据安全分级专家
标准注入：把六级定义、就高从严原则、分级要素矩阵贴进去
few-shot 示例：给 3-5 个标注好的例子，让模型学会判断口径

few-shot 的设计有个关键：示例要覆盖"容易误判"的边界 case，比如：

“备注"字段（名不副实，可能藏着敏感信息）
“年龄"字段（看似敏感，其实一般是 2-3 级的一般个人信息）
衍生字段（聚合后的统计值，级别可能降）

这几个例子能让模型在判断时"拿捏"住尺度，而不是见什么敏感词就往 4 级上靠。

4.3 结构化输出 + 置信度

让模型输出结构化 JSON，而不是自由文本：

{
  "level": 4,
  "reason": "字段含个人健康信息，属敏感个人信息，按就高从严定为4级",
  "confidence": 0.92
}

confidence 是人工审核的开关：置信度低于阈值（如 0.85）的，转人工复核。这既保证了效率，又兜住了大模型"幻觉"的风险。

4.4 就高从严的工程化

模型有时会给出"3级或4级"这种模糊判断。工程上直接把"就高从严"编码进判定逻辑：只要模型提及可能达到更高危害，就取高级别。

这个取舍背后是一笔账：与其漏标一个敏感字段（酿成泄露事故），不如多标一个、让业务方复核后降级。安全领域的"错杀"成本远低于"漏放"成本。

五、落地流程：从资产盘点到持续运营

自动化打标不是跑一次就完事，要嵌入持续运营：

资产盘点：从数据目录（Data Catalog）拉出全量字段清单
批量打标：规则引擎 + 大模型逐字段判定
人工校准：低置信度字段 + 抽检，人工复核修正
结果落库：分级结果写回数据目录，供下游安全组件读取
动态更新：业务变化、新表上线时增量打标

这里要强调一点：第一版准确率到 70-80% 就够了，先跑起来再校准。很多项目死在"追求一次性 100% 准确"上，迟迟不敢上线，最后什么都没落地。数据分类分级是"越用越准"的事，不是"一步到位"的事。

六、实测效果与几个坑

效果（一个中型企业的体量，几万个字段）：

指标	数值
PII 类（规则引擎覆盖）准确率	接近 100%
语义敏感类（大模型覆盖）准确率	85-90%，人工复核后 95%+
成本	字段级调用，远低于人工盘点

踩过的坑：

坑	现象	解法
字段名误导	“备注"“扩展字段"名不副实，藏着敏感信息	采样值必须喂给模型，不能只看字段名
过度定级	模型把"年龄"“性别"也定成 4 级，数据可用性受损	few-shot 里加降级示例，明确"一般个人信息 2 级”
幻觉定级	模型编造"这是国家级重要数据”	限定只在 1-4 级内判断 + 置信度阈值 + 人工复核
衍生数据漏判	聚合后的统计数据被当普通数据	单独处理衍生字段，参考原始数据级别

回到开头那个问题

数据分类分级这件事，为什么过去十年做了又废、废了又做？根子在于它一直被当成一个"一次性的咨询项目”——请人盘点一次，出了份《分级规范》文档，三个月后字段一变化，又回到原点。

大模型的价值，不在于它比人"聪明"多少，而在于它把"分类分级"从一次性的专家动作，变成了一个可以随业务持续运行的自动化能力。

标准钉死、规则兜底、大模型补语义、人工校置信度——这套组合跑通之后，分类分级才真正从"写在纸上的规范”，变成"活在系统里的能力”。而这，恰恰是它该有的样子。

敏感数据识别 on 文艺技术笔记