模 模界数智
AiDClass 观察 · 第 6 篇

分类分级怎么跟上监管变化:规则、模型、知识库三种工程范式对比

模界数智 官网首发
规则、模型和动态行业知识库共同驱动持续更新的分类判断

让分类分级跟上变化

动态行业知识库的工程方法

前五期我们从不同侧面讨论了分类分级——从范式演进到伪 AI 拆解,从准确率潜规则到金融体系,从跨行业地图到医疗深耕。读完这五期,一位有经验的从业者会问出一个非常有质量的问题:

分类分级标准不是一次定好就不再变。监管文件每年都在更新,业务每年都在变,合规边界每年都在调整。一个能在 2026 年跑出 95% 准确率的工具,到 2028 年还能保持吗?这件事的工程难点到底在哪里?

这是一个比「准确率指标」更有重量的问题。它把分类分级从「一次性能力」推到了「长期工程」——而长期工程的核心,从来不是单点技术先进,而是工程范式是否适合处理「持续变化」。

这一期我们专门讨论这件事。不讨论某家厂商的产品有多强,而是讨论一个更基础的问题:面对分类分级这种「持续变化」的领域,什么样的工程方法才能真正跟上节奏?

一、分类分级是一个「持续变化」的问题

讨论应对方法之前,先讲清楚「变化」本身。分类分级所要应对的变化,不是一个维度,而是四个维度同时在发生。

变化一:监管在变

过去四年,中国数据分类分级相关的国家级和行业级监管文件每年都有更新。仅 2024 - 2026 这三年,与金融、医疗相关的就有:

  1. 2024 年金规 24 号文落地;

  2. 2024 年 GB/T 43697 国家标准正式发布;

  3. 2025 年金办发 93 号文出台,启动专项行动;

  4. 2025 年人行令 3 号发布,确立人行口径管理办法;

  5. 2025 年医疗、教育、汽车等多个行业的细则陆续落地;

  6. 2026 年金融监管总局推动「四个一批」执法。

可以预期的是——未来五年,这种节奏不会减弱。数据安全法第 21 条只是起点,各行业的实施细则会持续出台和迭代。

变化二:业务在变

机构内部的业务变化与监管变化同步发生,且节奏更快。

  1. **新业务的引入:**银行的养老金融、保险的健康管理服务、券商的财富管理 3.0、医院的互联网医院——这些过去三年才进入主流的业务,各自带来一整套新字段、新数据流、新分类节点;

  2. **新数据源的接入:**传感器、移动端、第三方平台、生态合作方——数据来源在持续扩展,每接入一个新源,都意味着新一批字段需要分类;

  3. **新场景的出现:**AI 训练数据、向量库、对外开放 API、数据交易——这些场景在过去三年从「不存在」变成了「核心场景」,每一个都带来分类分级的新需求。

变化三:行业认知在变

第三个变化是最微妙的——同一份数据,在不同年份的合规解读可能完全不同。

举个例子:车辆 GPS 数据在 2019 年的主流解读是「设备数据」,2021 年随着《汽车数据安全管理若干规定》出台,变成了「重要数据」,2023 年在跨境流动规则下又演化出新的分类边界。

同一个字段,五年内的合规身份发生了三次变化——这种变化不会有任何监管文件「指名道姓」告诉你,需要专业人员持续理解和判断。

变化四:跨行业扩展时,变化是指数级的

以上三个维度的变化,只是在单个行业内的情形。一旦机构需要跨行业服务(比如金融集团进入医疗健康业务、互联网平台涉足金融业务、综合医疗集团介入消费医疗),变化的复杂度立即从「加法」变成「乘法」。

从金融到医疗,不是「再学一套规则」——是整个分级体系、敏感性判定逻辑、监管对齐关系全部要重做。在这种场景下,「应对变化的工程能力」直接决定了机构能不能成功跨界。

分类分级不是一次工程,而是一个长期演进的能力。能不能跟上变化,决定了一个工具五年后是否还有用。

二、三种应对变化的工程范式

面对持续变化,业内目前存在三种主流的工程范式。它们各有合理性,也各有边界。这一节我们做一个公允的对比——每一种范式都先说它适合什么,再说它在哪个边界会失效。

范式一:规则方式

规则方式是分类分级最早、最基础的工程范式。变化发生时,工程师在规则库里增删改条目——新增一类业务,加一组新规则;新发布的监管文件,把它的条款转化为可执行的规则。

  1. **它适合什么:**标准稳定、规则可枚举的简单场景。比如银行卡号识别、身份证号识别、纯结构化的常规字段——这些场景下,规则方式既高效又可控。

  2. **它在哪里失效:**变化频繁、跨领域复杂的场景下,规则维护成本指数级上升。当规则库膨胀到上千条,规则之间的冲突、覆盖、漏洞难以人工跟踪——更糟糕的是,新增一条规则可能影响已有规则的判断,系统的可预测性下降。

规则方式不是错的——它是基础工具,任何分类分级系统都需要包含规则能力。但仅靠规则方式应对「持续变化」,工程负担会越来越重。

范式二:模型方式

模型方式是过去几年随着 AI 技术成熟而兴起的——把字段的语义识别问题转化为分类任务,用监督学习训练一个分类模型。变化发生时,补充新样本,微调或重训模型。

  1. **它适合什么:**样本充足、类别相对稳定的常规识别。比如对常见 PII 字段(姓名、电话、地址、邮箱等)的识别,模型方式可以达到非常好的准确率,而且对字段命名变化有一定的鲁棒性。

  2. **它在哪里失效:**类别频繁变化的场景下,「重新训练」的成本与延迟都难以接受。每一次变化都需要数据科学家、标注团队、训练算力、上线流程整体配合,从识别到生效的周期通常以月计。同时,模型的「黑盒性」让合规追溯困难——监管问「为什么把这字段判成 L4」,模型只能说「置信度 0.92」,这在执法语境下不够。

模型方式有它真实的价值——在稳态识别上,它确实比规则方式更具泛化能力。但它的工程节奏与「持续变化」的分类分级需求,存在结构性错位。

范式三:知识库方式

第三种范式相对较新,把分类分级看作「业务知识 + 监管知识 + 数据上下文」的推理问题。变化发生时,在知识库中增加或调整一条业务知识——比如「新型养老金融业务的客户健康告知字段,根据 24 号文应判为重要数据」,这条知识进入知识库,引擎在下一次推理时就会引用它。

  1. **它适合什么:**持续变化、跨行业、跨标准的复杂场景。知识库的更新单位是「一条业务知识」,而不是「一组规则」或「一批样本」——更新者是业务专家或合规专家,而不是开发工程师或数据科学家;更新周期是「小时到天」,而不是「月到季度」。

  2. **它在哪里失效:**知识库本身的设计成本高——需要把行业知识、监管框架、业务概念体系结构化,这件事不是几个月能完成的。一个浅层的知识库,与一个深思熟虑的规则库相比并没有优势。

知识库方式的真正价值,要等到知识库本身达到一定深度之后才显现——这也正是为什么这种范式难以「短期堆出来」。

三种范式的速查表

维度规则方式模型方式知识库方式
变化的处理单位一条规则一批训练样本一条业务知识
更新角色规则工程师 / 开发数据科学家 + 标注团队业务专家 / 合规专家
更新周期周到月月到季度小时到天
可解释性强(规则即依据)弱(标签 + 置信度)强(业务推理链)
适应新行业重写规则库重新收集样本 + 重训扩展行业层知识
典型适用场景标准稳定、规则可枚举的简单场景样本充足、类别稳定的常规识别持续变化、跨行业、跨标准的复杂场景

一句话总结这张表:

规则方式的更新单位是「一条规则」,模型方式的更新单位是「一批样本」,知识库方式的更新单位是「一条业务知识」。在分类分级这种持续变化的领域,更新单位的「颗粒度与节奏」决定了能否真正跟上变化。

三、动态行业知识库的工程特征

讲完三种范式的对比,这一节专门展开「动态行业知识库」这个概念——它不是一本静态的「数据字典」,而是一套有特定工程结构的活体系统。

一个真正可用的动态行业知识库,至少有以下五个工程特征。

特征一:业务概念是核心单位,不是字段也不是规则

传统数据字典的核心单位是「字段」——一个字段一行记录。规则系统的核心单位是「规则」——一条规则覆盖某一类场景。

动态行业知识库的核心单位是「业务概念」——客户、账户、保单、诊疗记录、医保结算……每个业务概念有一组属性、一组典型字段、一组判定逻辑、一组关联概念。

为什么这个选择重要?因为业务概念比字段更稳定、比规则更灵活。一家保险公司从「车险」扩展到「健康险」,字段会换、规则会变,但「保单」「被保险人」「保险责任」这些业务概念是延续的。围绕业务概念组织的知识库,有天然的演进能力。

特征二:监管条款与业务概念之间是多对多映射

一个业务概念可能受多份监管文件约束(比如「客户健康告知」既受 24 号文管,也受医疗数据规章管),一份监管文件覆盖多个业务概念(JR/T 0197 覆盖全部金融业务概念)。

传统的「字段 → 规则 → 标签」单线映射,根本承载不了这种复杂关系。动态知识库必须把「业务概念」「监管条款」「分级标签」三者之间做成多对多关系网,任何一个节点的变化,都能通过关系网传导到其他节点。

特征三:版本化,而不是覆盖式更新

当一份监管文件发布新版本时,旧版不能简单删除——已经按旧版做的分类分级判定还在系统里,需要可追溯。

动态知识库必须支持版本化:每一份监管、每一个业务概念、每一条判定逻辑都有版本号;每一次更新都是「新增版本」而不是「覆盖旧版」;系统中的每一个分类结果都能溯源到「依据是哪一版的哪一条知识」。

这种版本化能力,是分类分级在执法语境下「可解释、可追溯」的工程基础。

特征四:分层结构,而不是扁平化知识

一个跨行业、跨机构的知识库,如果做成「一锅炖」的扁平结构,新增任何一行都可能影响所有客户。动态知识库必须有明确的分层:

  1. **通用层:**数据安全法第 21 条等顶层法律语义,所有行业、所有机构共享;

  2. **行业层:**金融、医疗、电信等每个行业的业务概念体系和监管框架,行业内共享;

  3. **机构层:**每家机构的命名习惯、业务自定义节点、内部分级标准,机构独有。

这种分层让「新增一家客户」只需要扩展机构层、「进入一个新行业」只需要扩展行业层、「适应新发布的法律」更新通用层——三层之间相互独立,变化不会

  1. 彼此污染,系统的可演进性大幅提升。

特征五:更新粒度细到「一条业务知识」

传统软件系统的更新粒度是「一个版本」——每次发版包含多个变化,变化之间相互耦合,回滚成本高。

动态知识库的更新粒度细化到「一条业务知识」——业务专家在管理后台修改一条概念定义、添加一条监管映射、调整一个判定逻辑,变化立即生效,不需要软件发版。

这种细粒度更新带来的工程价值是巨大的——业务专家可以在不依赖技术团队的情况下持续维护知识库,合规变化可以在数小时内被系统响应,机构的运营节奏不再被「下次发版」拖累。

四、动态知识库与「业务推理」的耦合

讨论完知识库的工程特征,需要回答一个关联问题:知识库本身不是终点,它需要被某种「推理能力」消费才能产生价值。两者的关系是什么?

一个不太严谨但传神的比喻

如果把分类分级系统比作一辆车:

  1. 动态行业知识库 = 燃料,提供分类分级所需的业务知识、监管知识、判定依据;

  2. 业务推理引擎 = 发动机,把燃料(知识)转化为动力(分类判定)。

两者必须匹配。没有发动机的燃料,只是一桶汽油——不会自己变成动力。没有燃料的发动机,只是一台机器——再精密也无法运转。

常见的两种「不匹配」

不匹配一:没有引擎的知识库

一些早期工具实质上是「带管理后台的数据字典」——可以录入很多业务知识、监管映射,但没有真正的推理能力。系统要么靠规则匹配字段命名,要么靠简单文本检索调取知识——前者退化成规则方式,后者退化成查字典。

这种工具的典型表现:知识库里有大量内容,但实际识别效果与「不用知识库」差别不大。

不匹配二:没有知识库的引擎

另一种走向是「拿大模型直接做分类分级」——把字段名、字段类型、样本数据直接喂给通用大模型,让模型输出分类结果。这种方式在通用场景下可能跑出像样的结果,但在专业领域立刻露馅:

  1. 不知道某家保险公司的「投保人健康告知」与「被保险人体检结果」的合规边界差异;

  2. 不知道证券业 JR/T 0158 与金融业 JR/T 0197 的分级口径区别;

  3. 不知道医疗机构的科研用数据与临床用数据在去标识化强度上的差异;

  4. 不知道国办发 93 号文具体要求的「能运营的能力」与「合规清单」的区别。

这些知识不在大模型的训练数据里——它们藏在监管文件的细节、行业实践的惯例、合规专家的判断中。通用大模型再强,也只是一个聪明但无知的实习生。

两者耦合才是有意义的工程

一个真正可用的分类分级系统,必须把动态行业知识库与业务推理引擎深度耦合:

  1. 推理引擎接受字段输入时,主动从知识库中检索相关的业务概念、监管条款、判定逻辑;

  2. 推理过程中遇到不确定情况时,回到知识库中查找类似先例、典型样本、专家批注;

  3. 推理结果输出时,把知识库中的依据条款附在结果之后,形成可解释的推理链;

  4. 推理结果被人工复核时,复核结果回写到知识库,形成知识库的持续优化。

这种耦合让知识库不再是「静态资料」,而是「与推理过程共同演进的活体系」。这也是「业务推理范式」与「训练式范式」最根本的区别——前者的知识是显式的、可读的、可演进的;后者的知识被压缩在模型参数里,改不动、看不清、解释不了。

五、跨行业扩展时的真正考验

讨论到这里,我们能回答一个之前几期反复提到的问题:为什么跨行业扩展是分类分级工具的天花板?

跨行业不是「换一套规则」,是「换整个知识体系」

从金融到医疗的扩展,不是在金融规则库后面加一组医疗规则——是要建立一个完全不同的业务概念体系、对接一个完全不同的监管框架、维护一个完全不同的命名习惯库。

如果用规则方式扩展——意味着工程师从零开始写一整套医疗规则库,工作量等同于「再做一遍金融的工程」。

如果用模型方式扩展——意味着从零开始收集医疗字段样本、做标注、训练模型、上线部署。每个新行业的边际成本与第一个行业相同,没有规模效应。

只有用知识库方式扩展,且知识库本身设计为「分层结构」——通用层不变、行业层从零开始构建一份医疗知识、机构层在医疗客户落地时再扩展——才能让跨行业的工程量逐步收敛,真正具备规模化复制的能力。

分层知识库的三个具体作用

作用一:通用层让跨行业有共同基础

数据安全法第 21 条、GB/T 43697 国家标准、个人信息保护法——这些是所有行业的共同基础。把它们沉淀在通用层,任何行业的知识库都共享这层基础,不需要重复理解和实现。

作用二:行业层让跨行业有差异化能力

金融行业的「客户身份证号 + 银行卡号」组合敏感度,与医疗行业的「患者姓名 + 罕见病诊断」组合敏感度,判定逻辑完全不同。行业层把每个行业的特殊性结构化沉淀下来,新增一个行业 = 增加一个行业层模块。

作用三:机构层让同一行业有定制能力

同样是保险行业,平安、太保、人保的字段命名、业务流程、内部合规节点完全不同。机构层让每家客户有自己的定制空间,而不会污染行业层的通用知识——这也是分类分级工具能做到「一客户一标准」的根本工程基础。

这种分层不是一个产品概念,是一种工程方法论。它让「跨行业扩展」从「重做一遍」变成「叠加一层」,真正具备规模化的可能。

写在最后

回到本文开头那个问题:分类分级的工具,五年后还能保持有用吗?

答案取决于这个工具的「工程范式」——

  1. 如果它的核心是规则,五年内规则库会膨胀到难以维护;

  2. 如果它的核心是模型,五年内会经历多次重训,每一次都伴随能力震荡;

  3. 如果它的核心是知识库,五年内会随业务、监管、行业的演进而不断丰厚,工具的能力会持续增强而不是衰减。

决定分类分级工具长期价值的,不是某一年的准确率指标,而是工程范式是否适合处理「持续变化」。

这不是一个产品话题,而是一个工程方法论话题。这个话题的重要性,在分类分级走向「跨行业基础设施」的路上,只会越来越突出。

行业正在到达一个共识——单靠规则不够,单靠模型也不够,需要把行业知识结构化、动态化、可演进化地组织起来。AiDClass 是这条道路上的一种实现,但我们更希望整个行业都开始重视「行业知识库工程」这件事——它会成为未来五年中国数据安全领域最重要的基础设施之一。

下一期我们会进入辑三的第一篇——为什么 80% 的分类分级项目最终止步于「加密、脱敏、访控」?分类分级的真正价值还有更广阔的空间,我们一起来打开。

—— AiDClass 团队 · 模界数智

正在规划企业 AI 相关项目?

建议从真实业务场景切入,优先完成项目诊断:评估业务价值、核查数据基础、识别安全与权限风险,审慎评估之后,再决定是否启动 PoC 原型建设,避免无效投入。

预约 30 分钟交流