当前，很多中央企业和地方国企在推动穿透式监管时，普遍采取分领域推进的策略。这种做法的好处是显而易见的：每个领域由对应的业务部门牵头，业务熟悉、推进起来有资源有抓手。

但实际执行中，一个普遍性的问题逐渐暴露。

各领域的牵头部门，大多不知道如何推进自己领域的穿透式监管建设。

投资部门知道要“穿透投资项目”，但不清楚穿透到什么程度、用什么方法穿；采购部门知道要“穿透采购过程”，但不明白哪些环节需要穿、哪些数据需要看；财务部门知道要“穿透财务数据”，但搞不清如何从海量数据中识别出真正的风险。

各领域都在等一个明确的指导。到底应该按照什么样的步骤、采用什么样的方法，把一个领域的穿透式监管从“政策要求”变成“具体行动”。

与此同时，集团层面的牵头部门，通常是内控合规部门或信息化部门，也没法给出一个统一的、可操作的指导方法。

有的发了文件，但文件停留在原则性要求层面，各领域看了仍然不知道怎么做。有的组织了培训，但培训讲的是“穿透式监管是什么”，没有讲“具体怎么干”。有的引进了咨询公司，但咨询公司给出的方案是通用模板，套到任何一个领域都说得通，套到任何一个领域都不够用。

这就形成了一个尴尬的局面：政策要求很明确，方向很清楚，但各领域在具体操作层面缺乏统一的实施方法论。

每个领域都在摸索，但每个领域的摸索方式各不相同，经验无法复用，教训无法共享。

本文就试图回应这个问题，提出一个适用于十大重点领域穿透式监管实施的统一方法论。

01 实施方法论：五层法

本文（陶光辉律师）提出，穿透式监管在各领域的实施，遵循一个共同的逻辑：从业务出发，以风险为导向，通过管控设计、模型转化和数据支撑，最终实现系统化的自动监管。

这个逻辑链条，可分为五个层层递进的实施层次（五层法）。

第一层：业务场景层

把一个领域的管理活动，按照时间线和业务逻辑，拆解为若干阶段、若干流程、若干场景，直到每一个场景都是一个可被观察、可被描述、可被管控的最小单元。

这一层回答的问题是：这个领域到底在做什么？有哪些环节？每个环节谁在做、做什么、输入什么、输出什么？

第二层：风险点识别与梳理层

对每一个业务场景，识别可能出现的风险事项，评估其发生的可能性和影响程度，按照风险类型和风险等级进行分类分级。

这一层回答的问题是：每个环节可能出什么问题？哪些问题是高频的？哪些问题是严重的？

第三层：管控措施与管理标准设计层

针对每一个风险点，设计对应的管控措施，并将这些措施转化为可执行、可检验、可量化的管理标准。管控措施回答“做什么”，管理标准回答“做到什么程度算做到了”。

这一层回答的问题是：针对每个风险，应该采取什么措施？怎么判断措施是否执行到位？

第四层：模型化设计层

将管理标准中那些可以被量化、被计算的部分，转化为计算机可执行的判定逻辑，形成规则模型。模型一般由风险场景、规则逻辑、数据来源、预警阈值、处置动作、迭代规则等要素构成。

这一层回答的问题是：哪些管控措施可以交给系统自动执行？系统怎么判断异常？发现异常后怎么办？

第五层：数据层支撑与系统部署层

明确每个规则模型所需的数据来源、数据表和字段，完成数据治理和系统集成，让模型在真实的业务环境中运行起来。

这一层回答的问题是：模型需要什么数据？数据从哪里来？数据质量如何保证？系统怎么部署？

这五个层次构成了一条从“业务事实”到“系统运行”的转化链条。

业务场景层提供了分析的对象，风险识别层提供了分析的目标，管控设计层提供了解决方案，模型化层提供了技术转化，数据层提供了运行支撑。

五层环环相扣，上一层输出是下一层输入，任何一层的缺失都会导致整个链条断裂。

这五个层次的另一个特征是可复制性。无论面对的是投资领域、采购领域、合同领域还是境外领域，都可以按照这五个层次逐层展开。

变化的不是方法论，而是每一层的具体内容。不同领域的业务场景不同，风险点不同，管控措施不同，模型逻辑不同，数据来源不同。但“怎么走到那里”的路径是一致的。

02 各层的具体内涵与操作要点

（一）业务场景层：把领域“切分”到可管理的颗粒度

业务场景层是整个方法论的基础。如果一个领域的业务全貌都不清晰，那么，后续的所有工作就失去了锚点。这也是领域的穿透式监管，要对领域熟悉的原因。

业务场景拆解的方法是“从大到小、逐层细化”。

先确定这个领域包含哪些大的业务阶段，再确定每个阶段包含哪些流程，再确定每个流程包含哪些场景，最后确定每个场景的操作步骤和关键要素。

以投资领域为例。投资的全生命周期可以拆解为投资决策、投资实施、投后管理、投资退出四个阶段。投资决策阶段又包含项目立项、可行性研究、尽职调查、决策审批等流程。可行性研究流程又包含技术可行性分析、市场可行性分析、财务可行性分析、风险评估等场景。

每一个场景都可以进一步描述其发生背景、执行主体、输入文件、输出文件、与上下游场景的衔接关系。

拆解的颗粒度要足够细，细到能够看清每一个操作步骤、每一个决策节点、每一份关键文件。

但也不是越细越好，过度拆解会使后续工作变得庞杂而难以推进。一个实用的原则是：拆解到“能够独立描述其风险特征”的颗粒度为止。

当一个场景可以被清晰地描述为“某人在某个环节基于某份材料做出某个决定”时，这个颗粒度就足够了。

业务场景层的输出是一张完整的业务地图。这张地图的价值在于，它让管理者第一次完整地看到了一个领域“到底有多大的覆盖面”，也让后续每一个环节的参与者都能在自己的工作范围内找到精确的坐标。

（二）风险点识别与梳理层：把风险“标定”到每个场景

有了业务地图，下一步是回答每一个场景可能出现什么问题。

风险识别的方法是“基于场景逐项分析”。

对每一个场景，可提出三个问题：这个场景可能出什么问题？这个问题发生的可能性有多大？这个问题一旦发生，影响有多大？

这三个问题的答案，综合起来，就形成了一个风险点的完整描述。这与我们之前的风险评估，很像。

在识别过程中，可参考已有的内控手册、审计报告、巡视反馈、纪委案件、行业案例等，但最终要落到业务流程上。

国资委明确的十一类突出问题——过度负债、无关多元、多层架构、薪酬乱象、财务金融风险、控股不控权、虚假贸易、“捞偏门”“靠企吃企”、资产闲置、境外风险等——为各领域的风险识别提供了重要的方向指引，但不能替代各领域自身的场景化风险分析。

每一个领域的风险识别都必须从自己的业务场景出发，而不是从一张通用的问题清单出发。

风险识别完成后，需要对风险点进行分类分级。

分类是按照风险的类型进行归集，比如结构性风险（源于制度设计缺陷）、行为性风险（源于人的违规操作）、关联性风险（源于不同主体和数据之间的勾连关系）。

分级是按照发生概率和影响程度划分为高风险、中风险、低风险。

分类分级的目的是为后续管控措施的设计提供依据。高风险需要重点防控，中风险需要常规管控，低风险需要保持关注。

风险识别层的输出是一张风险地图。每一个风险点都落在业务地图的某一个具体场景上，形成了“场景到风险”的精确映射。

这张地图可指导后续管控措施的设计。每一个风险点都必须被回答：针对这个风险，应该做什么？

（三）管控措施与管理标准设计层：把“要做什么”写清楚

识别了风险，接下来要回答两个问题：针对这个风险应该做什么？做到什么程度算做到了？这就是管控措施和管理标准的设计。

管控措施设计要遵循一个基本原则，能用系统解决的不用人，能用标准解决的不用经验。

有些管控措施天然适合由系统执行，比如金额校验、日期比对、版本一致性检查。有些管控措施必须由人来执行，比如审核意见的实质性判断、谈判策略的制定、纠纷协商中的让步决策。

还有一些管控措施介于两者之间，比如资质审查——系统可以自动核验证照是否过期，但无法判断资质是否“真实有效”，需要系统提供信息、人来做最终判断。

管控措施的来源，一般有两个。一是现有内控措施的梳理和升级，把现有内控体系中已经存在的控制点找出来，对照穿透式监管的要求进行升级。把人工控制升级为自动控制，把抽样检查升级为全量扫描。

二是基于风险点的增量设计，对那些现有内控措施覆盖不到的风险点，设计新的管控措施来补上缺口。

管控措施设计完成后，必须转化为管理标准。

管理标准是连接“人防”和“技防”的桥梁。一个合格的管理标准具备三个特征。

可陈述，标准可以用一句清晰的话表达出来，比如“申请金额不得超过预算可用余额”，而不是“预算应得到合理控制”。

可检验，标准的达成情况可以被客观验证，存在明确的是或否判断，不存在“基本做到”的模糊地带。

可量化，标准可以被转化为数值或状态，比如“合同签署日期不得早于审批完成日期”“定金比例不得超过合同金额的百分之二十”。

管理标准的可量化程度，直接决定了后续模型化的难度。越是接近“数值比对”的标准，模型化就越容易。越是依赖“主观判断”的标准，模型化就越困难。但这并不意味着依赖主观判断的标准不重要。

恰恰相反，那些最难被模型化的风险点，往往需要最严格的人工管控流程来弥补。

管控措施与管理标准设计层的输出，是一套完整的“风险到管控”的映射表。每一个风险点都对应着一条或多条管控措施，每一条管控措施都对应着一条或多条管理标准。

（四）模型化设计层：把“标准”变成“代码”

管理标准是给人看的，规则模型是给机器执行的。这是最需要注意区分的。

模型化设计的任务，就是把管理标准中那些可以被量化、被计算的部分，转化为计算机可执行的判定逻辑。

在穿透式监管的语境下，一个完整的规则模型，至少由以下要素构成。

1. 风险场景描述了这个模型在什么业务背景下工作，明确模型的适用范围和边界。场景描述不是为了写一段漂亮的文字，而是为了确保模型的适用范围清晰可辨。场景描述越精确，误报的可能性就越低。

2. 规则逻辑将管理标准转化为“如果A则B”的计算表达式，必须具体到技术人员可以直接编码的程度。规则逻辑的设计决定了模型的准确性，过于宽泛会产生大量误报，过于狭窄则可能漏报真实风险。

3. 数据来源明确了模型判断需要哪些数据、从哪里来。每一条规则都必须明确数据来源，如果所需数据不可得，模型就无法运行，需要先完成数据治理。

4. 预警阈值设定了触发预警的临界值及风险等级。同一个规则逻辑可以对应多个风险等级，取决于阈值的设定。阈值的设定应当结合管理实际，初期可适当宽松以避免过多干扰业务，后续根据运行数据逐步收紧。

5. 处置动作明确了预警触发后的处理流程和责任岗位。不同等级的预警对应不同的处置层级、时限要求和审批权限。

红色高风险预警应在规定时限内启动核查并由高层级部门处置，黄色中风险预警由业务部门自行处置，蓝色低风险预警作为管理提示而非强制整改事项。

模型化设计还需要区分三类规则的配置权限。

刚性规则对应红线事项，全集团统一执行，子企业无权调整。适配规则是参数可调的规则，子企业在集团给定的参数范围内自行设定阈值。柔性规则是子企业自查规则，在集团框架内自行配置。这三类规则的区分在系统层面的实现，就是模型配置权限的分层管理。

模型化设计层的输出，是一套完整的规则模型设计文档。每一个模型都对应着一条或多条管理标准，每一条管理标准都对应着一个或多个风险点。

（五）数据层支撑与系统部署层：让模型“跑”起来

规则模型再精巧，没有数据就是空中楼阁。

数据层要解决三个问题：数据从哪里来、数据质量如何保证、数据如何支撑模型的持续运行。

1. 数据溯源是第一步。每一个规则模型都需要明确其所需数据的具体来源——哪个系统、哪张数据表、哪个字段。没有精确的数据溯源，模型开发就无从下手。

2. 数据治理是第二步。各领域的数据往往存在三个共性问题。标准不统一，同一类数据在不同系统中编码不同，跨系统数据无法自动关联。接口不通畅，各系统由不同部门在不同时期建设，数据无法自动流转。质量不可控，部分历史数据缺失关键字段，部分数据依赖人工填报，准确性无法保证。

数据治理需要沿着三条主线推进。统一主数据标准，制定核心主数据的编码规则和属性定义，让各系统使用同一种“语言”。打通核心系统接口，按照业务优先级分批次实现各系统与数据中台的自动对接。建立数据质量监控机制，对缺失、异常、滞后的数据自动报警，按照“谁产生、谁负责”原则将质量责任明确到具体岗位。

正确的数据治理策略是“模型驱动数据治理”。先根据业务风险的高低和模型化的可行性，确定哪些规则模型需要优先上线，再倒推这些模型需要哪些数据，按照模型的优先级排序数据治理的优先级。对于核心模型所需的关键数据，优先打通接口、优先清洗历史数据、优先建立质量监控。对于辅助模型所需的数据，可以在核心模型运行稳定后再逐步完善。

3. 系统部署是第三步。部署节奏应当遵循“试点先行、逐步扩展”的原则。先选取业务场景成熟、数据基础较好的子领域或业务单元作为试点，验证模型的准确率和系统的稳定性。积累经验后逐步扩展到全领域。最后实现全级次覆盖和常态化运行。

03 方法论应用中的几个关键问题

1. 模型管控与人工管控的边界。可以说，每个领域都存在两类风险：一类可以被清晰量化和规则化，另一类只能依赖于人的主观判断。

前者的判定依据是客观事实，不存在判断模糊的空间，系统可以独立完成从识别到预警的全过程。这是模型管控。

后者的判定依赖于对行为动机和场景语境的综合判断，目前的技术手段难以可靠实现，关键之处只能依赖人来判断。

当然，这个边界应当动态调整而非一成不变。对于类似于“中等可模型化”的风险，正确的做法不是让系统自动通过或拦截，而是让系统完成初步筛选和打标，将有疑点的案例精准推送给专业人员复核。

2. 规则模型与AI大语言模型的关系。两者的关系是互补而非替代。规则模型擅长精确匹配和逻辑判定，对于确定性逻辑具有高可靠性、低成本和可解释性强的优势。大语言模型擅长语义理解和内容生成，对于文本中的模糊条款识别、核查报告的辅助撰写等场景可以发挥作用。

穿透式监管系统的建设不是在两者之间做单选题，而应让两者各展所长、协同工作。

3. 各领域的差异化实施。十大重点领域的业务逻辑不同，风险特征不同，因此在五层方法论的具体应用中，每一层的内容都会有所不同。但五层方法论的结构是通用的。无论哪个领域，都要从业务场景拆解开始，经过风险识别、管控设计、模型转化，最后到数据支撑和系统部署。

小结一下：十大重点领域穿透式监管的实施，需要一个统一的、可操作的方法论。五层递进法提供了一个从业务出发、以风险为导向、通过技术手段实现自动监管的路径。

作者介绍：陶光辉，律师、高级经济师、法学院客座教授，中国管理科学学会理事、中国人工智能学会会员等。擅长领域：穿透式监管、风险管控数智化升级，治理风险与合规（GRC）、法治央企建设等。