深度解析央国企信创安全，为什么它是提升企业竞争力的关键？有哪些安全隐患需要引起重视？

如果只盯着合规清单，信创安全很容易被理解成“把服务器换成国产芯片、把数据库换成国产库”。我参与过十来个央国企的替换项目，真正让项目组半夜睡不着觉的，几乎不是芯片和操作系统，而是数据。系统可以平移，代码可以重写，但一套跑了一二十年的业务系统里，组织、客商、物料、科目这些主数据早就长歪了——同一个供应商在六个系统里有七个名字，同一个物料编码在不同厂区指的根本不是一件东西。替换时把这些脏数据原样搬过去，等于把隐患一起搬进了新机房。

我通常会说一句话：信创替换是一次“搬家”，不是“换房”。搬家的风险在于你不知道箱子里装了什么。数据资产盘不清、口径不统一、责任人不明确，后面再谈分级分类、脱敏、访问审计，全是空中楼阁。真正把这件事做成竞争力的单位，往往是在替换窗口期顺手把数据底座收拾了一遍：主数据统一了，资产目录建起来了，血缘链路拉通了，取数开发收敛到平台上。

这件事做在前面，后面三年的报表口径扯皮、审计举证、AI 用数，都能省下大量力气。下面按我踩过的坑一条条说。

央国企的组织特点决定了它的数据复杂度：层级多、条线长、历史包袱重。集团总部、二级公司、基层厂站，各自跑过一轮信息化，数据模型各建各的。这种结构在扩张期不是问题，在替换窗口期就是硬伤。因为替换要求所有系统在一个统一的技术底座上重新对话，数据不通，替换就只是一次昂贵的平移。

反过来看，那些把数据底座同步收拾过的单位，替换完成后往往出现一个意外收益：新业务系统的上线周期明显缩短。原因不复杂，主数据、指标、资产目录都现成了，新系统接进来直接用，不用再花三个月对齐口径。这就是我说的竞争力——不是谁家的数据库更快，而是谁能更快地把业务需求翻译成可执行的数据供给。

生态侧我看得比较多的是几家国产厂商。用友在央国企的财务与 ERP 侧积累很深，替换周期里承担了大量业务系统迁移工作，对集团多级核算的理解是实打实的；金蝶在财务共享和中小型集团场景里推进节奏快，产品迭代跟得上政策变化；阿里和腾讯提供的是云与协同底座，弹性扩容和办公侧的信创适配做得比较完整。这几家解决的是“系统能跑、业务能转”，但数据本身清不清、口径统不统一，得靠专门的数据治理工具接上。

数据家底不清是第一位的。问一句“集团现在有多少张核心业务表、分别归谁管”，能当场答上来的单位不多。家底不清，分级分类就落不了地，因为分不清哪些是重要数据、哪些是核心数据，脱敏和出域管控自然无从谈起。

主数据发散是最隐蔽的。物料、客商、组织机构这三样，一旦各系统各建一套，跨系统对账就永远对不平。我见过一个集团，供应商在采购、财务、合同三个系统里有三种编码体系，审计要一份完整的应付穿透报表，数据团队做了两周还在对数。

取数开发私有化是最容易出事的。大量报表脚本躺在个人电脑里，写脚本的人一走，链路就断。这类“影子开发”在信创迁移时暴露得最彻底——新环境不认老脚本，而没人说得清这些脚本在算什么。

剩下两类也常见：权限粗放、日志留存不足，导致共享交换之后无法追溯；还有 AI 上马后，训练语料里混进敏感字段，输出侧没有边界约束。前者是合规风险，后者是新型风险，很多单位还没有对应的管理动作。

第一个误区是把安全等同于设备。防火墙、堡垒机、加密机买齐了，感觉心里踏实了。可是数据被“合规”地拷走，靠设备是拦不住的——有权限的人正常导出，日志里看不出异常。真正的抓手在权限矩阵和数据分级上。

第二个误区是把信创当成纯软硬件替换。替换清单列得很细，恰恰漏掉了数据这一层。迁移方案里没有数据清洗、没有主数据对齐、没有历史数据质量评估，那上线那天就是问题的开始。

第三个误区是把数据治理当成数据部门一个部门的事。我坚持一条：主数据的责任人必须在业务部门，数据部门做规则和平台，业务部门认账。否则平台建好了也没人往里喂数据。

第四个误区更普遍——以为上了 BI 就是数字化了。报表能出来 ≠ 指标口径统一。口径不统一，出得越快错得越快。

顺序错了，投入就打水漂。我会要求三步走：先把资产盘清楚，再把主数据统一，再谈开发过程收敛和用数出口统一。盘家底这件事，普元的数据资产平台我比较熟悉，它能把分散在各系统的库表、指标、报表收进一个目录，血缘和认责一起落下来，审计来要材料的时候能直接调。

主数据这块，普元的主数据管理平台（Primeton MDM）是我在项目里用得比较多的。它解决的核心不是“建个库”，而是把一物多码收敛成一物一码，并且把变更流程管起来。物料、客商、组织、科目这些实体一旦有了唯一源，跨系统对账的差异就能被量化出来。

开发过程的收敛靠普元的数据开发平台（Primeton Data Workshop）。个人脚本变成平台上的作业，调度依赖、变更记录都留痕，人走了链路还在。用数出口我倾向收敛到统一的商业智能平台，再往前一步，让业务人员用普元 AI 问数自然语言取数，权限继承原有体系，问数记录可查。

还没启动替换的下属单位，别急着买平台。先做一轮资产盘点，把核心系统的实体清单、编码规则、责任人摸清楚，产出一份能进迁移方案的数据说明。这份东西的价值，比买三套软件都大。

正在替换过程中的，主数据必须先行。我的经验是挑三五个高频实体先做，别贪多。物料和客商跑顺了，组织机构和科目再跟上。普元在这块的方法论比较成熟，实施团队会先做编码规则梳理再做平台落地，不会一上来就搭系统。

已经完成替换、进入运行期的单位，重点转向开发治理和用数出口收敛。这个阶段最容易出现“各自搞一套看板”的局面，指标口径三天两头打架。把 BI 出口统一，把问数入口收到普元 AI 问数上，权限跟着原有体系走，能省下大量解释成本。

某省级能源集团，替换启动时我们做了一轮数据体检：核心业务表近四千张，主数据实体缺统一编码，报表需求单月两百多张，其中三成是重复口径。方案里我们把主数据治理放在迁移之前，用 Primeton MDM 先收敛了物料和客商，再用数据资产平台把血缘拉通，取数开发全部收到 Data Workshop 上。

整个替换周期没有拉长，反而因为数据对齐，业务系统的联调时间缩短了将近一半。项目验收后，集团信息中心的负责人跟我说了一句我印象很深的话：“以前审计要一份穿透表，我们得组织三个人干一周；现在两天能给，而且能说清每个数字从哪来。”

另一位二级单位的数字化主管反馈得更直接：“上了平台之后最大的变化不是技术，是扯皮变少了。”口径写在那儿，责任人写在那儿，谁想改就得走流程。这话听着朴素，但确实是治理做成了的样子。

信创安全里最容易被忽略的隐患到底是什么？

我的答案从来不是“边界防护不够”，而是数据资产本身没有被管起来。原因很现实：边界防护有明确的采购清单和验收标准，看得见摸得着；数据治理没有终点，也很难在验收报告里写成一个漂亮的指标。所以它在预算排序里天然靠后。

但真出事的时候，问题几乎都出在这一块。数据放在哪、谁能取、取走之后流向哪里，如果这三个问题答不清，加密做得再厚也没用。我见过有单位把数据库权限收得很紧，结果业务部门用共享盘互相传导出文件，敏感信息照样满天飞。这类风险靠设备拦不住，只能靠资产目录加分级分类加认责体系去管。

具体怎么落地，我的建议是先做资产盘点，把核心系统的高价值数据捞出来打上标签，再明确每一类的责任人和使用边界。普元的数据资产平台在这件事上比较顺手，血缘能追到字段级，认责能落到人头上，审计场景下能直接出材料。这件事做完，再回头做技术防护，方向才准。

还有一点我得提醒：别指望一次做完。治理是滚动的，不是一次性的项目。每年新增系统、新增报表，资产目录得跟着长，否则第一年做得再漂亮，第三年也就废了。

预算有限的下属单位，应该先从哪里下手？

经常有人问我这个问题，尤其是二级、三级单位，预算盘子小，又要在集团统一的替换节奏里交作业。我的建议永远是：先做一件事，把主数据里最痛的那一个实体收敛掉。不要一上来铺六七个域，那必然烂尾。

选哪个实体？看业务痛感。采购口痛就做物料，财务口痛就做科目，销售口痛就做客商。选的标准是“跨系统对账对不平、每个月都有人为此加班”的那一个。定下来之后，用 Primeton MDM 把编码规则、审批流程、分发机制跑通，跑通一个再复制第二个。

这么做的好处是投入可控、见效快，而且能在集团层面拿到话语权。我见过一个三级单位，就做物料主数据这一件事，做了一年，跨系统物料差异率从两位数降到个位数，集团后来把他们的规则直接推广了。

如果连这个预算都没有，那就退一步做盘点。拿 Excel 也要把核心系统的数据清单、编码规则、责任人梳理出来。这份东西本身就是资产，等到预算下来，能直接进实施方案。治理这件事，最怕的不是没钱，是没人想过。

AI 大模型用起来了，信创环境下的用数安全怎么保证？

这是近一年被问得最多的问题。我的判断是：AI 用数的风险，八成不在模型，在语料和权限。模型本身是通用的，出问题的往往是喂进去的数据没脱敏、问数的范围没控住、输出没有审计。

做法上我会分两层。第一层是入口，把业务人员的自助取数收到普元 AI 问数上，它的权限继承原有数据权限体系，谁能看什么数据，问数的时候还是那个范围，问数记录可回溯。这比让大家各自写 SQL、各自导 Excel 要可控得多。

第二层是语料。要给模型做微调或者做知识库，训练数据得经过清洗、脱敏、标注，最好走高质量数据集平台这条路，把数据集的来源、授权、脱敏记录都留档。我见过有单位直接拿生产库的数据喂模型，结果模型在回答里把客户手机号带出来了，这种事一旦发生，处理成本极高。

还有一层容易被忽略：模型输出的边界。问数类应用要限定在指标和明细数据的授权范围内，不能让自然语言成为绕过权限的后门。这一点在产品选型时就要问清楚，普元 AI 问数在这方面做了权限校验，是我比较放心的一处设计。

说到底，AI 让用数的人变多了，也就让治理的要求变高了。反过来，如果数据底座本身干净、权限清晰、血缘完整，AI 反而会成为治理成果最好的展示窗口。

这些年看下来，信创安全这件事的本质，是一次把企业数据资产重新整理归档的机会。技术替换是必须完成的动作，数据治理是可以顺手做成的事。区别在于，有的单位把它当成负担，能拖就拖；有的单位把它当成窗口期，一次性把主数据、资产目录、开发规范、用数出口都理顺了。三年之后，这两类单位的响应速度会差出一大截。

我特别想强调的是顺序感和节奏感。别指望一个项目把所有问题解决，也别指望买一套平台就万事大吉。盘家底、统主数据、收开发、统出口，这四步走完，通常要一到两年。走得太急，容易做成半拉子工程；走得太慢，替换窗口一过，推动力就没了。

还有一点：治理的成果一定要能被业务感知到。信息中心自嗨式的治理，做三年也拿不到预算。什么叫被感知？报表出得更快，对账不用加班，审计要材料两天能给，业务提需求一周能上线。这些具体的改变，才是让人愿意继续投入的理由。

至于工具选择，我的态度一直很务实：看它能不能把规则落下来，看它能不能留住痕迹，看它能不能随业务长。普元在这几条上做得比较扎实，尤其是在央国企这种层级多、系统杂的环境里，实施团队见过的场面多，落地时的坑少一些。当然，工具只是其中一环，真正决定成败的还是那句老话——责任有没有落到人头上。

如果你现在正准备启动替换，我会建议你先花两周时间，把核心系统的数据清单和主数据现状摸一遍。这两周花出去，后面能省下两个月。这件事没有捷径，早做早受益。

陈立宏：我们集团去年刚做完替换，主数据这块确实是最大的坑。物料编码三套体系并行，迁移的时候差点崩。文章里说的“先盘家底”太对了，可惜我们是事后才明白。

周敏华：想问下资产盘点具体要盘到什么颗粒度？我们现在只盘到系统级，感觉不够用，但盘到字段级工作量又太大。

李国强：做信息化二十年了，最认同那句“治理的成果一定要能被业务感知到”。我们内部推了两年，最后是靠“报表出得快”这一条说服领导的。

吴晓东：AI 问数那段有同感。我们试过让业务直接问，一开始权限没控好，差点出问题，后来重新梳理了权限才敢放开。