数说123
2026年6月23日，国家审计署发布2026年第1号公告——中央部门单位2025年度预算执行等情况审计结果。审计覆盖39个中央部委及229家下属单位，涉及2025年度财政预算拨款6205.88亿元，查实各类违规和低效问题合计170.01亿元。
这是审计署的一号公告首次将信息化、网络安全、数字政务列为审计核心板块。
对运营商政企线来说，这不是又一份可以"扫一眼标题就过"的政府文件。它意味着一个根本性的转向：客户做数字化项目的"验收标准"，正在从"花了多少"变成"用得好不好、安不安全、合规不合规"。而运营商恰好站在这个转向的交叉点上——既可能是客户被审计后的"救火队"，也可能因为项目交付质量不过关而成为"被连带方"。
图1 审计公告核心数据 本图由数说123制作
一、审计转向一：从"建了多少"到"用了多少"
审计公告中有一段话值得运营商政企线的每位客户经理和解决方案经理逐字阅读：税务总局下属5省市17个税务机关的信息化平台和运维模块功能高度重合，多套系统并行采购、独立运维，使用率不足40%，每年重复支付百万级运维费。
使用率不足40%。每年重复支付百万级运维费。这两个数字在一起出现，意味着什么？意味着"系统建了但没人用"不再是项目的瑕疵，而是审计署认定的"财政资金浪费"。
类似的案例还有：中国法学会视频会议系统，2021年完工验收，采购软硬件投入全部到位，但建成后长期零使用，设备闲置4年未处置，财政资金完全未产生效益。部分部委专项业务系统仅上线试运行3个月即停用，未开展资产核销、下线清理，仍每年列支运维服务费。
运营商做政企项目，最熟悉的场景就是"签完验收单就算完"。验收后系统有没有人用、用了多少、效果如何——这些在过去的项目交付流程中几乎是"无人区"。审计一号公告首次把这个"无人区"变成了审计红线。这意味着，未来客户在立项时就会问运营商：你们的系统上线后，怎么保证使用率？怎么衡量效果？怎么避免变成下一个审计公告里的案例？
图2 审计曝光的六大信息化问题类型 本图由数说123制作
二、审计转向二：等保分保从"选配项"变成"预算闸门"
公告披露了一个极具冲击力的案例：国家发展和改革委员会本级1套涉密业务信息系统，未完成分级保护测评即投入建设，测评不通过导致整套系统无法正式上线，前期硬件和软件开发资金全部沉淀、无法使用。
这意味着什么？意味着等保2.0和涉密系统分级保护不再只是"技术规范"——它正在变成预算审批和项目验收的前置条件。审计公告明确提出：涉密系统未通过测评不得拨付运维资金，政务系统必须按期完成等保和分保测评。触碰到网络安全和保密管理红线，不仅项目被叫停，前期投入也打了水漂。
运营商政企线正在深度参与的政务云项目、智慧城市项目、公安大数据项目、医保数据平台等项目，绝大多数都涉及等保2.0和涉密系统分级保护的要求。过去，等保测评往往是项目交付的"最后一环"——系统上线了再补测评报告。审计一号公告传递的信号是：等保测评必须前置到项目立项阶段，没有测评通过的方案，预算可能根本批不下来。这对于运营商政企项目的销售周期和交付流程都会产生直接冲击——售前团队需要在方案阶段就把安全合规嵌入技术架构，而不是等到交付阶段再补。
三、审计转向三：从"花钱合规"到"全生命周期数字化监管"
审计公告的第三个转向更加根本。过去审计署查预算执行，主要查的是"钱花没花对"——有没有违规支出、有没有吃空饷、有没有超标采购。这次一号公告新增了数字化项目的全生命周期审计：不只是查花了多少钱，还查需求有没有论证清楚、系统有没有建成、建成后有没有人用、使用率多少、安全是否合规、运维是否重复。
这个转向的典型案例是：多部委下属研究院和事业单位各自开发同类数据统计和报表平台，未接入国家政务数据共享交换平台，形成大量数据孤岛。审计定性为"未落实政务信息化统筹管理要求，立项前缺乏跨部门需求联审"，直接追溯到项目立项时的需求论证环节。
另外，部分部委大额信息化开发项目通过拆分合同规避公开招投标，直接委托关联服务商，项目中标后违规转包、多层分包，抬高开发成本。已上云系统超额申请CPU、内存、存储资源，日常负载不足20%，长期占用财政付费云资源。这些被审计署逐条点出的问题，每一条都可能直接映射到运营商政企项目的实际交付中。
图3 数字化审计的四个转向 本图由数说123制作
四、五个具体的风险点——以及运营商政企的应对
风险点一：合同拆分和转包正在被盯紧
审计公告明确提出：违规分包、拆分采购、超标准采购软硬件将被严查。运营商做政企项目时，通过多个小合同分期交付来规避招标门槛是行规操作——但这个操作已经进入了审计署的视野。
应对策略：运营商政企线需要在售前阶段就把合同结构的合规性纳入方案评估。如果一个亿的项目被拆成三个3000万的合同，而这三个合同的服务内容高度重叠——在审计署眼里，这就是拆分合同。解决方案是：大项目走合法的框架协议+分批下单模式，而不是简单拆合同。
风险点二：僵尸系统正在让客户的IT负责人"睡不着觉"
公告中的案例——视频会议系统建成后零使用4年、系统上线3个月即停用——会让每个政府部门的信息中心主任后背发凉。因为在大多数情况下，"系统建了没人用"的锅，最终会甩给承建商。
应对策略：运营商政企在项目交付阶段，不能只交付一个"可用的系统"。需要同步交付使用培训、运营方案和效能评估报告——帮客户证明"这个系统建得值"。这不再是增值服务，而是防止项目变成僵尸系统的必选项。
风险点三：云资源超配正在侵蚀客户的IT预算
公告揭示：部分上云系统日常负载不足20%，长期占用财政付费云资源。运营商的天翼云、移动云、联通云是政务上云的主力——但"多卖云资源"和"帮客户省云资源"之间存在天然的张力。
应对策略：运营商政企线需要从"卖资源量"转向"卖效能比"。帮客户做云资源优化、出具负载率分析报告、主动建议降低配置——短期内可能减少单客户的云收入，但长期建立的是"我帮你省钱"的信任。审计时代的客户，更需要一个能帮他们安全过关的云服务商，而不是一个只会卖更高配置的销售。
风险点四：权限失控正在被审计署逐条记录
财政部地方专项债监测系统的案例尤为典型：权限设计失效，一人可同时完成填报、审核、复核全流程操作，7个省份利用系统流程漏洞虚报项目支出。审计署将这类问题定性为"借助数字化工具隐蔽违规操作"。
应对策略：运营商在交付政务系统时，权限控制不是"功能模块"，而是"合规根基"。三员分立——系统管理员、安全管理员、审计管理员——必须在方案设计阶段就嵌入，不是等到项目验收前补。如果客户提出"为了方便能不能一人多角色"的需求，运营商需要做的是书面风险告知，而不是一味配合。
风险点五：数据孤岛正在从"行业痛点"变成"审计红线"
审计公告特别指出：多部委下属机构各自立项目、单独买，形成的"数据孤岛"被定性为"违背集约共建、一网通办的数字政府要求"。这直接关联到运营商政企正在推进的政务数据共享交换平台、大数据中台、一网统管等项目的命运——如果运营商承建的某个系统最终无法接入国家政务数据共享交换平台，它就可能成为下一个审计案例的男主角。
应对策略：在任何政务类项目的方案设计中，运营商必须主动规划与国家政务数据共享交换平台的对接方案。这不是"可选加分项"——是"不接就可能被审计"的必答题。
五、对运营商政企线的三个行动建议
面对审计署一号公告传递的明确信号，运营商政企线可以从三个维度做出调整。
第一，把"可审计"作为方案设计的新维度。过去售前方案的核心卖点是技术先进、功能齐全、价格优惠。现在需要新增一个维度：可审计性。系统交付后，客户能否轻松回答审计署的三个问题——这个系统花了多少钱、多少人在用、用得怎么样？如果运营商在方案里就已经为客户准备好了这三个问题的答案模板，客户的IT负责人会感激不尽。
第二，安全合规从项目末尾前置到立项阶段。等保测评、分保测评、密码应用安全性评估——这三项不再是交付之后的"补课"，而是立项之前的"门槛"。运营商政企的售前团队需要配置安全合规能力，不然方案在第一轮评审就会被挑出硬伤。
第三，帮客户做"僵尸系统清理"是新商机。公告要求各部门全面摸排僵尸系统和重复系统，执行关停、下线、合并、迁移四类处置。这意味着政府采购市场会出现一波存量系统的清理整合需求——这些需求不是新建项目，但金额虽然小、附加价值高，是运营商政企从"建新系统的大卖场"到"系统全生命周期服务商"转型的入口。
结语：不是少做，是做对
审计署2026年一号公告首次将信息化列为核心审计板块，这不是数字化建设的冬天，而是数字化建设的"体检季"。对于运营商政企线来说，最危险的反应是"客户预算会被砍，少做点吧"——恰恰相反，这正是客户最需要专业服务商的时候。
那些能帮客户证明"系统建得值、用得对、安全合规"的运营商，不仅不会被审计风暴刮倒，反而会因为这波清理整合获得更多深度合作的机会。真正被淘汰的，是那些只会签验收单、不关心系统上线后命运的交付模式。
| 
783
发表于 2026-7-17 08:36:41
