数据分类分级的三代范式：规则引擎、训练式模型、业务推理引擎

从模型训练到业务推理，金融数据治理的第三种解法

2024 年金规 24 号文落地，2025 年 93 号文启动专项行动，2026 年成为金融数据安全名副其实的「执法年」。在这个时间节点上，全国 4600 余家金融机构面临同一道必答题：如何把分类分级从一份制度文档，变成一套能动态运营的能力。

围绕这道题，过去几年，出现了三种不同的解决思路。我们把它们称为数据分类分级的「三次范式」——它们之间不是简单的产品之争，而是技术路线层面的代际差异。

理解这三次范式的演进，对金融机构选择技术路线、对数据安全从业者建立完整认知，都会起到重要的借鉴作用。

一、第一代：规则引擎与正则匹配

最早金融机构引进的数据分类分级技术工具，本质上是一套「规则引擎」。

它的工作机制简单直接：通过预定义的正则表达式（18 位身份证号、19 位银行卡号、11 位手机号），叠加关键词库（字段名中包含「姓名」「客户」「手机」等关键字），再配合命名规则匹配，对数据库字段做出判断。后续部分技术提供商尝试以向量匹配替代关键词匹配，但实践显示，该方式仅会扩大命中范围、降低识别准确率，整体价值有限，本质仍属于规则匹配范畴。这一代技术的代表，是数据库审计厂商衍生出的合规扫描模块。

它解决了什么

在 JR/T 0197 标准刚发布的早期，金融机构需要快速建立”我有多少敏感字段“的初步认知。规则引擎能在数小时内扫完一个核心系统，给出第一份字段清单。这在合规起步期是很有价值的。

它的能力局限在哪里

可识别「长得像」敏感数据的字段，识别不出「业务上是」敏感数据的字段；

上下文理解的差异——同样命名为 AMT 的字段，在交易系统里是金额，在风控系统里可能是评分；

命名一旦不规范（拼音缩写、业务术语、历史遗留命名），识别率下跌；

仅识别结构化数据

到 2022 年前后，金融机构意识到：规则引擎不足以支撑 24 号文要求的「动态维护的数据资产目录」。市场开始呼唤更智能的方案。

二、第二代：训练式模型与字段语义分类器

第二代的核心思路，是把分类分级问题转化为机器学习问题：用大量已标注的字段样本去训练一个分类器，再用这个分类器去识别未知字段。

这条路线有三种代表性的实现形态：

金融机构****内部自研模型：头部机构基于自有数据，训练一个垂直领域的字段语义分类器；

共建训练模型：多家机构共同标注、共同训练，输出一个面向行业的通用模型；

安全厂商的 AI 增强产品：在传统规则引擎上叠加小模型，形成「规则 + 训练」的双引擎架构。

第二代相比第一代，是一次真正的进步。它能识别字段名以外的语义信息，能基于上下文做更复杂的判断，能在一定程度上摆脱对命名规范的依赖。

但所有训练式方案都共享一组方法论层面的固有特性。这些特性不是某一款具体产品的实现缺陷，而是「训练式 AI 范式」本身的边界条件——无论由谁来训练、用多少数据训练、训练多少个模型，这些约束都会出现。

特性一：训练前的「前置标注」工作量极大

任何监督学习模型的准确率，都取决于训练数据的质量与覆盖度。对数据分类分级而言，这意味着——模型上线前，机构需要先准备好大量已标注的字段样本：每个字段的中英文名、字段类型、长度、业务说明、所属业务域、对应的分类分级标签，缺一不可。

但现实中，绝大多数金融机构的核心系统建于二十年前的产品周期里，字段命名是拼音缩写或英文缩写，业务说明长期缺失，或者散落在不同的需求文档、接口规范、ER 图、研发口口相传里。

要给训练式模型「喂饭」，机构必须先组织业务人员、研发人员、数据治理团队，把数万到数十万字段的业务含义重新梳理、标注、补全。这本身就是一项以「人·月」为单位的工程。

更现实的问题是：这种「给字段加注解」的活，难以直接转化为业务价值，不贡献功能迭代，同时需要消耗大量人力，推进意愿普遍偏低。一线机构反馈，仅这一项前置工作，就能让分类分级项目延期 3-6 个月。

特性二：模型上线后准确率有天然上限

训练式模型的准确率，受制于三个因素——训练数据的覆盖度（见过多少种字段）、标注一致性（不同标注者对同一类字段判断是否一致）、分布一致性（新机构、新业务的字段是否落在训练分布之内）。

在金融行业这种「业务多样、命名不规范、行业语义复杂」的领域里，即便采用多种工程化技巧，整体准确率通常仍基本上低于 80%。

这个区间意味着什么？在一个 5 万字段量级的核心系统里，每识别 100 个字段，就有 20-30 个需要人工复核——也就是 1 万到 1.5 万次人工判断。而且这种「人工复核」不能交给初级人员，或者外包人员完成，必须由金融企业内部懂业务、懂监管的合规专家来做。在大多数机构里，这样的人力本就极度稀缺。

特性三：对非结构化数据覆盖能力的缺失

训练式字段语义分类器，本质上是为「结构化数据库字段」这一具体场景设计的。它的输入是「字段名 + 类型 + 样本 + 业务说明」的组合，它的输出是「这个字段属于哪个分类分级标签」。

但金融机构的敏感数据，恰恰大量分布在非结构化场景中：

投保单、贷款合同、对公协议、客户经理签报等业务文档（PDF / Word / 图片扫描件）；

客户服务录音、催收录音、销售质检语料（音频）；

客户经理与客户的微信、邮件沟通记录（半结构化文本）；

内网知识库、文件服务器、共享盘里散落的临时文档（文件系统）。

按行业普遍估算，金融机构 60%-80% 的敏感数据其实存在于非结构化场景中。一个只能处理结构化字段的工具，覆盖的只是「看得见的冰山一角」——而 24 号文与 93 号文要求的，是「全量数据资产目录」。

特性四：类别体系一经训练即被固化

训练式模型的另一个固有约束：类别体系是模型架构的一部分，类别一变，模型就要重新训练。具体表现为：

新增一个分类节点（比如行内新启动的「养老金融」业务）：需要收集新样本、重新标注、重新训练、重新测试、重新部署，周期 1-3 个月；

调整分级标准（比如把某类数据从「重要」升到「核心」）：模型需要重新校准；

客户化定制（比如某家保险公司希望按「承保 / 核保 / 理赔 / 精算」细分到四个子域）：必须为该客户单独训练子模型；

适配新监管（每年若干份新发布的金规、人行、证监文件）：训练数据需要扩充再训练。

这种「训练-部署-固化」的循环，与金融业务「持续迭代、监管持续更新」的行业节奏，存在结构性错位。

特性五：决策过程缺乏可解释性

第二代模型输出的是「分类标签 + 置信度」，但很难告诉合规官「为什么把这个字段判定为重要数据」。监管现场检查中，单纯的模型判定结果缺乏说服力，合规检查需明确对应监管条款及判定依据。

小结：第二代向前迈进了一大步，但是不够

以上五个特性，不是某一款产品的实现缺陷，而是「用模型训练解决分类分级」这条技术路线本身的边界。这条路线没有错——它在合适的场景下依然有不可替代的价值。但要让分类分级真正成为「能运营的能力」，需要的不是「更好训练的模型」，而是「完全不同的工作机制」。

三、第三代：业务推理引擎

第三代的核心理念，可以用一句话概括：

不训练分类器，而是让 AI 像一位有金融行业经验的合规专家那样去推理。

这是范式层面的转变。第三代不再把分类分级问题当作「分类模型的输出问题」，而是当作「业务理解 + 监管对齐 + 推理决策」的复合问题。

具体而言，第三代引擎的工作流是这样的：

1. 业务上下文构建：输入字段（或文档片段）的同时，引擎自动调取该字段所在的业务系统、所属业务域、字段命名的可能含义、相关字段构成的语义集合。

2. 监管标准对齐：引擎内置完整的监管知识库——JR/T 0197、JR/T 0158、JR/T 0250、金规 24 号、人行令 3 号、93 号文等的细则与示例，实时检索可能适用的分类分级规则。

3. 多步业务推理：基于业务上下文与监管规则，引擎进行多步推理——比如「这个字段在投保业务中代表客户的健康告知，根据 JR/T 0197 第 6.2 条以及保险业专属要求，应判定为 L3 敏感数据」。

4. 可解释输出：引擎输出的不是一个标签，而是一段推理链——分类标签 + 适用的监管条款 + 推理依据 + 置信度。

这种工作机制带来的差异，体现在五个能力维度上。下面我们逐一展开。

能力一：结构化与非结构化的统一处理

由于第三代引擎的核心不是「字段语义分类器」，而是「业务推理」，输入形式被解耦了。无论输入是数据库字段、文档段落、图片中识别出的文字、还是录音转写的文本，引擎的工作机制是相同的——理解输入的业务含义，对齐监管规则，输出推理结论。

具体落地形态：

**结构化数据：**通过元数据接口对接数据库，逐字段推理；

**文档类：**调用文档解析能力（含 OCR），把 PDF / Word / 图片拆解为业务含义后再进行推理；

**音视频：**先做语音转写，再进行业务推理；

**半结构化：**API 报文、日志、JSON 字段、协议正文等，按业务字段语义逐项推理。

一个工具覆盖结构化与非结构化两类资产——这是金融机构落地 24 号文「全量数据资产目录」要求的关键基础设施。

能力二：业务推理取代模型训练

第三代不需要为某个客户、某个行业、某份新监管去「重新训练」模型。它的能力扩展是知识层的，而不是参数层的：

**新增一个业务类别：**在知识库中描述这个类别的业务含义、判定规则、引擎立即可用；

**适配新发布的监管文件：**把文件解析进知识库，引擎在下一次推理时就会引用新规则；

**服务一个新行业（证券、信托、消金、融资租赁）：**把该行业的业务知识与监管映射加入知识库，无需重新训练模型。

能力扩展的单位从「人·月」变成了「人·天」，从「工程级改造」变成了「知识库扩展」。

能力三：准确率的跃升

第三代的准确率优势，不来自「模型更大」或「数据更多」，而来自工作机制本身。具体体现在三个层面：

**业务上下文的注入：**相比孤立判断「这个字段是什么」，加入「它在哪个业务流程中、属于哪个业务对象」会让判断准确度显著提升；

**监管规则的精确对齐：**相比「模型学到的模糊语义」，「逐条对齐监管条款」的判断更准确也更可控；

**推理链的自我验证：**引擎在输出推理过程时会进行一致性检查，逻辑不自洽的判断会被自动标记为低置信度待复核项。

在多家头部金融机构的内部对照测试中，第三代引擎在覆盖完整业务类别的前提下，准确率可以稳定在 90% 以上，对标准业务字段类型可以接近 97%。而大多数置信度较低的场景，都发生在知识库的边界，或者未覆盖的位置。

能力四：人工介入的大幅减少

前置标注工作的消失，是第三代最显著的工程优势之一。

由于引擎本身具备业务推理能力，它不需要「训练前的字段注解准备」。即使面对一份字段命名混乱、说明缺失的老旧核心系统数据库，引擎也能：

通过字段名、样本数据、表名、字段间关系，自主推断业务含义；

调取行业知识库中类似命名模式的语义，做出合理假设；

标记「需要业务确认」的不确定项，但不阻塞整体流程的推进。

这意味着：原本需要数十「人·月」的「研发团队补注解」工作，可以被压缩到一名数据治理人员花几周时间做「复核与确认」。人力投入大幅下降，同时项目周期从原本的 3-6 个月压缩到 4-8 周。

能力五：一客户一标准的灵活配置

这是第三代区别于前两代的能力差异，也是容易被忽视、但落地之后影响大的一项。

由于第三代引擎的「类别体系」是描述在知识库中的，而不是固化在模型参数里的——每一家客户都可以根据自己的业务特点，配置一套专属的分类分级标准：

银行可以按「对公 / 零售 / 信用卡 / 金融市场 / 同业 / 国际业务」分主线，每条主线下设专属子类；

保险公司可以按「承保 / 核保 / 理赔 / 精算 / 再保险 / 投资」分主线，覆盖产寿险差异；

券商可以按「经纪 / 投行 / 资管 / 自营 / 研究 / 财富管理」分主线；

金控集团可以叠加多个子公司的标准体系，在集团层做统一视图。

类别可以新增、可以合并、可以拆分、可以重命名、可以重新映射监管条款——所有这些操作都不需要重新训练任何模型，只需要在配置界面上修改类别定义。

更进一步，针对新增的业务（银行的养老金融、保险的健康管理服务、券商的财富管理 3.0）、新出台的监管要求（每年新增数份金规文件），客户可以自行扩展自己的分类树，工具立即生效。

这才是「动态维护的数据资产目录」的真实形态——不是定期重新跑一遍模型扫描，而是分类标准本身能跟着业务和监管持续呼吸。

四、三代范式：一图看清差异

把上面所有讨论整理成一张对照表，可以一眼看清三代范式的能力分野：

五、三代范式的并存与选择

需要再次强调：三代范式不是「对错关系」，而是「代际关系」——它们各有最适合的场景。

第一代规则引擎，在标准化、字段命名规范、合规要求基础的场景下，依然是最低成本的选择。它适合作为「兜底扫描」的快速工具。

第二代训练式模型，在业务相对标准化、字段注解齐全、分类体系稳定的场景下，能稳定地提供 70%-80% 的自动化结果。它适合作为「行业基准」的参考。

第三代业务推理引擎，则更适合：

业务复杂、字段命名不规范、注解缺失的存量系统；

需要按 JR/T 0197 与人行《业务领域数据安全管理办法》的要求，将文档、影像、音视频、报文等非结构化数据纳入分类分级覆盖范围的机构；

业务持续迭代、监管持续更新、需要快速适配新要求的机构；

集团化经营、子公司业务差异大、需要「一企一策」分类标准的机构。

对绝大多数中型以上的金融机构而言，前两类场景与后四类场景同时存在。这意味着——完整的数据治理工具链，往往需要三代能力的组合。但其中，第三代引擎是唯一能解决「动态、跨形态、可定制」问题的核心组件。

写在最后：分类分级，最终是一场认知升级

数据分类分级表面上是一项合规工作，本质上是金融机构在 AI 时代重建「数据自我认知」的过程。

未来五年，监管会持续加码，数据资产会持续膨胀，业务变化会持续加速。一个「训练-冻结-上线」的工具，注定跟不上这个节奏。

行业需要的，不是一个「更好的模型」，而是一个能像合规专家那样持续学习、持续推理、持续解释的工作伙伴。

这不是产品的升级，而是工作方式的转变。

第三代业务推理引擎，正在让这件事从愿景变成现实。

—— 模界数智 · AiDClass 团队