在穿透式监管体系建设的整体版图中，穿透式监管系统平台是技术层面的载体。

它承载着规则模型的运行，汇聚全级次的业务数据，向各级管理者呈现风险的态势。

但这个平台“怎么建”？是独立开发一套全新的软件系统，还是在原有各业务系统之上增加和集成监管功能？这是最让企业感到纠结和困惑的地方。

这个纠结和困惑的背后，还有一层更深的关系需要理清。

国资委2026年1号文提出建设“全域数字化资源管理平台”（DRP）的目标，紧接的2号文和15号文则要求建设智能化穿透式监管系统（智能监管平台）。

这两套平台是什么关系？各自承担什么功能？在建设时如何衔接？这就成了每一家央企启动穿透式监管体系建设无法回避的系列问题。

本文试图回答这些问题。从我们提出的  “三域知识隔离”底层方法论出发，在总结一些央企实践案例的基础上，提炼出一套具有自身底层逻辑的穿透式监管系统平台建设框架。

这个框架的核心是先深刻理解穿透式监管平台的特殊性——它既不是传统ERP式的业务执行系统，也不是传统BI式的数据分析工具，而是一种以“发现异常、验证风险、驱动处置”为闭环的监管操作系统。

一、穿透式监管系统平台的建设模式

本文提出，穿透式监管系统平台的建设模式，是决定该平台能否成功的第一个关键决策。

在没有充分思考的情况下，部分尝试推动穿透式监管系统平台打造的企业容易陷入以下两者极端：一种是“另起炉灶”——认为穿透式监管是全新要求，必须在现有系统之外独立建一套全新的监管平台；另一种是“修修补补”——认为在现有OA或ERP上加几个审批节点、做几张报表就算完成。

但实际上，也有不少央企，已趟出了一些更为务实之路。例如，某航空央企集团围绕穿透监管需求，采取“统建模型”策略，系统性盘点数据资源、理清数据来源、明确数据分布，形成“穿透监管数据一本账”，在此基础上按主题域多维分组，形成统一数据资产目录，为监管模型分析提供数据分布概览与数据脉络指引。

中国电信翼支付打造的“星辰御风”智能化穿透式监管平台，其落地应用的关键是构建一个“从数据中来，到监管中去”的闭环能力体系，将海量多源数据转化为精准的监管洞察与主动防控能力。 某科技公司在与中国商飞的合作中，围绕最新监管政策要求打造穿透监管模型，利用AI底座能力实现从集团到上下游合作主体的全链条穿透，实现从“人防”到“技防”的转变。

这些案例揭示了一个共同逻辑：穿透式监管平台的建设，本质是在现有信息化成果之上做智能化增量，对现有系统进行深度集成，而非推倒重建。 为什么这是更为合理的路径？

1. 从信息化投资的逻辑看，央企经过多年建设，普遍已拥有ERP系统、司库系统、采购平台、合同管理系统、国资监管报送系统等业务系统，部分企业还建成了数据中台或数据仓库。 这些系统存储着穿透式监管所需的核心数据，完全另起炉灶意味着在各业务系统之外再建一套平行的数据采集和处理体系，不仅投资巨大，还存在数据二次搬运的质量风险。

2. 从系统架构的逻辑看，穿透式监管平台需要解决的核心问题不是“业务怎么做”，而是“风险怎么识别”——这是现有业务系统不具备的能力。 但风险识别需要的数据已经存在于各业务系统中，因此最优策略是新平台专注于智能分析层的构建，数据层优先复用企业已有的数据中台或数据仓库。

当然，“新建”与“升级”的边界，在实践中并非泾渭分明。 通过检索可以发现，被冠以“新建”之名的项目，其核心交付物往往是“模型能力”与“数据中台”的建设，而非推倒现有业务系统。 例如某央企穿透式监管系统平台建设项目的招标核心是外部数据建设，致力于“动态采集集团统建系统中的全级次全量业财数据及税务、工商等第三方数据”，并“基于统一数据标准及校验规则，实现数据统一治理与共享”。

这与升级改造模式在底层逻辑上是一致的——都是增量建构，而非推倒重来。

因此，我们将穿透式监管平台的建设模式（或路径）概括为“增量建构、深度集成”。 本模式或路径包含以下四个维度，可谓“两项集成、两项构建”。

数据层的集成，指穿透式监管平台通过对接企业已有的数据中台、数据仓库或业务系统数据库，实现数据的汇聚和标准化处理，而不是自建一套独立的数据采集体系。

模型层的建构，指规则模型、风险模型、图计算模型等智能分析组件是平台真正的增量价值所在。

应用层的建构，指监管驾驶舱、预警工作台、派单督办系统、全息画像等应用功能是平台需要新建的核心模块。

流程层的集成，指预警工单的流转可以通过与企业已有OA系统、流程引擎的接口集成实现。   

二、穿透式监管系统平台的架构

穿透式监管平台之所以不能等同于传统的BI系统（Business Intelligence，商业智能系统）或ERP系统，在于其核心功能逻辑存在本质差异。

BI系统的核心逻辑是“呈现”——将已有数据以图表形式展示，回答“发生了什么”。

ERP系统的核心逻辑是“执行”——按预设流程完成业务操作，回答“怎么操作”。

穿透式监管平台的核心逻辑则是“发现—验证—处置”——从数据中发现异常信号、通过规则模型验证风险、驱动人工核查和整改闭环，回答“有没有问题、问题怎么解决”。

基于这一认识，我们将穿透式监管平台设计为如下的“三层双通道”架构。

三个层次设计   

本文提出，穿透式监管系统平台架构，按照一个从数据到智能再到应用的递进逻辑，分为以下三个层次。

 第一层：数据汇聚与治理层。

这一层是穿透式监管系统平台的基座，负责将分散在各业务系统中的数据汇聚起来，经过清洗和标准化处理后形成可供规则模型直接使用的监管数据集。

这一层的建设应当优先复用企业已有的数据中台能力，但需要补齐穿透式监管特有的数据需求，包括：全级次财务数据的完整性校验、产权树与股权关系图谱的结构化表达、外部数据（工商、司法、舆情）与内部数据的关联映射。 某央企在数据盘点基础上形成“数据资产目录”的做法值得借鉴。

第二层：规则模型与智能分析层。

这是平台最核心的差异化能力所在，也是“增量建构”的主战场。

这一层负责承载规则模型的后台运行，提供规则配置、模型训练、图计算、AI推理等计算能力。 某智能化穿透式监管平台在这一层提出了“三库四引擎”架构，是一个具有参考价值的实践样本。

规范库将法律法规、监管政策和内部规章进行结构化拆解，转化为原子化的管控条款，确保每条预警信号都有据可依。要素库对多源异构数据进行标签化和特征提取，将离散数据点编织成标准化风险画像要素。风险库汇聚历史风险事件、审计问题、巡视反馈和行业典型案例，形成可复用的风险模式库，使经验转化为数字资产。

策略引擎依托风险场景和管控规则，自动匹配、编排和调度监管模型。模型引擎支持从规则建立、模型训练到部署上线的全流程开发管理。图计算引擎基于实体间的多维关系构建关联图谱，自动穿透复杂股权关系、人员关联和资金链路。AI引擎集成大语言模型能力，实现监管政策的智能问答、非结构化文本的语义解读和风险初判报告的自动生成。

第三层：监管应用与交互层。

这一层是平台与用户的接触面，按照“五自动”闭环进行功能组织。

数据自动采集接入各业务系统实现增量数据的实时汇聚。模型自动分析在后台持续运行规则模型对全量数据进行扫描。风险自动预警将异常信号按红黄蓝三级分级推送到驾驶舱和预警工作台。核查自动派单根据预警信号的风险等级和规则类型自动生成核查工单并推送到责任岗位。整改自动跟踪对工单处理进度进行全程跟踪，超期自动催办，整改完成后验证销号。 这五个环节不是简单的功能菜单排列，而是一个具有严格时序依赖的闭环——采集支撑分析，分析触发预警，预警驱动派单，派单牵引整改，整改反馈分析。

双通道设计  

除了三层递进的纵向架构，穿透式监管平台还需要一条独特的设计理念，我称之为“双通道”设计。

理解双通道的逻辑起点，是看清楚这个平台其实承载了两类信息流。

一类是“业务信息流”——ERP、司库、采购、合同等业务系统正常运行产生的数据，其流向是自下而上的汇聚与呈现。

另一类是“监管信息流”——规则模型触发预警后产生的核查指令、整改任务、验收反馈，其流向是自上而下的派发与追溯。

传统BI系统只处理第一类信息流，传统OA系统只处理第二类信息流，但穿透式监管平台必须同时承载两类信息流，并将它们在规则模型这一枢纽上打通。

当规则模型在业务信息流中识别到异常信号时，自动触发监管信息流中的核查工单派发。当核查人员在监管信息流中反馈核查结论时，这个结论又成为优化规则模型判断逻辑的输入。

这种“业务信息流与监管信息流的实时转换”，是穿透式监管平台区别于其他企业级应用的核心特征。

双通道设计在平台功能层面的具体体现是：自上而下通道承载监管驾驶舱的整体态势呈现、预警信号的分级展示与溯源下钻、核查工单的精准推送与超期催办、问题整改的全流程跟踪与闭环验收。自下而上通道承载业务数据的自动汇聚与质量校验、规则模型的持续运行与结果反馈、处置结果的自动回传与状态更新。 两条通道在规则模型层交汇——自上而下的监管策略定义了“监控什么”，自下而上的业务数据支撑了“怎么监控”，两者的闭环互动构成了平台的智能核心。

架构的判断标准   

智能化穿透式监管系统平台架构是否合理，不是看技术多么先进或功能多么齐全，而是看它是否解决了穿透式监管的核心问题。

据此，本文提出三条评判标准。

一是数据是否真正贯通？不是看接入了多少系统，而是看能否在三分钟内从集团总部查询到末级子企业的实时数据。

二是规则是否能够精准预警？不是看部署了多少条规则，而是看预警准确率是否稳定在百分之八十五以上，误报率是否控制在可接受范围。

三是处置是否形成闭环？不是看生成了多少张工单，而是看从预警到整改销号的平均周期是否能满足监管时效要求。

这三条标准贯穿穿透式监管系统平台建设的全过程，是检验架构设计是否务实的关键尺度。 

三、穿透式监管系统平台与DRP的关系

如前述，在平台建设的技术路线选择中，需要同时澄清的是穿透式监管系统平台与DRP系统的关系。

DRP的定位   

DRP系统是国资委1号文提出的“全域数字化资源管理平台”。其定位是“未来央国企全域数据的中枢”，以财务数智化为起点，覆盖投资、采购、生产、销售等企业经营管理全域，通过业财融合实现物流、资金流、信息流、价值流“四流合一”。

1号文明确了DRP平台建设的四阶段目标：2026年完成财务核心能力数字化重构，2027年实现业财深化融合，2028年部分企业率先建成DRP，2030年所有央企基本建成DRP。

DRP与穿透式监管平台的关系   

对于这两个技术平台的关系，我们认为可以概括为“DRP是全域数据底座和核心能力引擎，穿透式监管系统平台是上层重点应用”。

从功能分工看，DRP负责数据的汇聚、治理和标准化，打通各业务系统之间的数据壁垒，形成企业级统一数据视图。1号文的表述是“用DRP支撑价值创造与穿透监管”，即明确DRP既要支撑全面预算、成本管控、资源配置等价值创造功能，也要为穿透式监管提供数据底座和技术能力。 穿透式监管系统平台则基于DRP提供的高质量数据，运行规则模型，实现风险识别、预警推送、派单督办、整改跟踪和风险画像等监管闭环功能。

故，DRP是未来各类数字化应用的统一底座，穿透式监管系统平台是这一底座上率先落地的“上层应用”。

两者的建设应当统筹规划、协同推进，避免形成新的数据孤岛。具体协同方式，可参考如下两种策略。

对于已启动DRP建设的企业，穿透式监管平台应当作为DRP的核心应用模块之一同步规划，直接复用DRP的数据底座能力。 对于尚未启动DRP建设的企业，穿透式监管平台可先行建设监管数据集市——聚焦十大重点领域所需的数据范围，构建轻量级数据底座。待DRP全面启动后，将这部分数据底座迁移至DRP统一架构。 但无论采用哪种策略，核心原则是“数据底座统一、监管应用独立”。

DRP负责数据的统一采集、治理和存储，穿透式监管平台则负责监管逻辑的运行和闭环管理。两者有清晰的接口边界，在数据层面深度耦合。

四、穿透式监管系统平台与数据、规则、体系的关系

我们一直认为，穿透式监管平台不是一个孤立的软件项目，而是在数据治理、规则模型和治理体系的共同作用下才能有效运行的技术载体。

正确理解平台与数据、规则及体系之间的有机关系，是把握平台定位和建设节奏的关键。

平台与数据   

平台与数据的关系，不是“先做一遍完整的数据治理再开发平台”，而是“规则模型需要什么数据就优先治理什么数据，平台运行中发现什么数据质量问题就定向治理什么问题”。

规则模型的每一个判断条件都需要源头数据的支撑。数据来源映射表中定位的系统、表名、字段，必须在数据治理完成后真正可获取、可计算。源头数据不准，规则模型再精密也是空中建楼阁。数据贯通的范围决定了平台监控的覆盖面，只有产权、资金、投资、采购等核心数据链路全部贯通，平台才能真正实现全级次覆盖。

因此，数据治理不是平台建设的可选项，而是与平台开发同步推进、相互牵引的核心工程。

穿透测试阶段，便需要摸底数据质量现状。数据治理任务书阶段，则要明确整改要求。平台开发阶段完成系统对接和数据清洗，运行阶段需要持续监控数据质量。

这四个阶段与平台建设的四个阶段——需求分析、开发测试、试运行、持续运营是完全对应的，形成“以规则需求驱动数据治理、以数据治理支撑平台运行”的双向循环。

平台与规则   

平台与规则的关系，是穿透式监管体系建设中最容易被低估的一对关系。

平台本身只是一套技术框架——提供数据接入、界面展示、流程流转等通用能力。

规则模型才是填充这套框架的算法灵魂。没有精准的规则模型，平台就是一个空转的数据展示工具，无法实现真正的自动预警和有效处置。

从功能需求的角度看，平台需要开发什么功能，完全由规则模型决定。需要监控围标串标，就需要开发IP地址比对和投标文件相似度分析功能。需要监控价格异常，就需要开发市场价格对比和偏离度计算功能。需要监控关联交易，就需要开发股权关联图谱和利益冲突识别功能。

平台的功能模块是对规则模型的工程化实现，而非反过来。

从建设时序的角度看，规则模型设计应当先行于平台功能开发。 如果规则模型尚未完成，平台开发需求就是无源之水。

正确的时序是：在六要素清单编制阶段完成规则模型设计，在业务技术映射确认阶段将规则模型转化为技术需求，在平台开发阶段按规则清单逐项实现功能，在试运行阶段验证每条规则的技术实现效果。

平台与体系   

穿透式监管平台能否真正发挥作用，不取决于技术架构是否先进，而取决于治理条件是否具备。 平台建设是技术工程，体系建设是治理工程，两者必须同步推进，不可偏废。

四项治理条件是平台有效运行的前提。

董事会是否已将穿透式监管纳入议事日程，决定了平台生成的运行评价报告能否产生管理压力。制度体系是否已配套修订，决定了平台发现的问题在制度上是否有对应的处置依据。穿透式监管执行责任清单是否已明确到岗位，决定了预警工单推送后是否有人接单、有人核查、有人整改。监督追责机制是否已与平台对接，决定了平台发现的重大违规线索能否顺畅进入追责程序。

从建设时序的衔接逻辑看，平台建设应当放在体系建设的中后期进行，而不是一开始就上平台。 在体制机制和制度修订基本完成之后，启动平台的技术开发，这样平台的需求才能准确反映治理体系的要求。在规则模型设计完成之后，确定平台的功能范围，如此开发目标才能清晰。在数据治理取得实质性进展之后，进入平台的全面测试，测试数据才能真实反映运行环境。在平台试运行的同时发布配套制度，这些制度与技术才能同步生效。

小结一下：穿透式监管系统平台的建设，不是一次普通的软件采购，而是一次治理能力的技术化落地。平台不是穿透式监管体系的全部，但体系的有效性最终要通过平台来承载和验证。从更深层次看，平台建设的本质是弥合治理与风险管理、数字化架构和管理信息系统开发三个知识领域之间的鸿沟。