「金融科技深水区」系列 · 第 3 篇
云平台升级：金融机构的「平台化」到底平了什么
摘要三行
1 云化的第一波红利（资源省钱）已经见顶，第二波红利（能力复用）才是分水岭。 判断标准只有一条：一个业务需求从提出到上线，要穿过几道人工关卡。
2 两个硬对比 ：2025 年 13 家有可比口径的上市银行金融科技投入合计仍超 1800 亿元、六大行超 1300 亿元，同期商业银行净息差降至 1.40% 的历史低位；而一家以 AI 原生模式经营的民营银行公开口径的户均 IT 运维成本是 1.9 元/年 ，传统银行普遍在数十元到上百元------一到两个数量级的差距，不在机房里，在关卡里。
3 你能拿走 ：平台化四件套的落地清单、一张五级成熟度自测表、一张"自建 / 复用 / 采购"决策门表、一条 90/180/365 天路线，以及五个高频返工点。
一、1800 亿投下去了，平的到底是什么
先把账摆清楚。
据证券时报对上市银行年报的梳理：2024 年 13 家主要上市银行金融科技投入合计约 1829.62 亿元，占营业收入平均约 4.07%；2025 年 13 家有可比口径的投入合计仍超过 1800 亿元 ，其中国有六大行合计超过 1300 亿元，四家大行单年投入突破 250 亿元。
同一时期，商业银行的净息差在 2026 年一季度降到了 1.40% 左右，处于历史低位。
一边是每年上千亿的技术开支，一边是每 100 元收入只剩 1 块 4 的利差。这两件事放在一起，问的其实是同一个问题：这些钱买到的是资产，还是费用？
再看一个反差极大的样本。
一家以 AI 原生模式经营的民营银行，公开披露的口径是：科技人员占全行员工比例长期保持在 50% 以上，历年 IT 投入占营业收入比例超过 9%，但户均 IT 运维成本控制在 1.9 元/年 。传统银行动辄数十元、甚至上百元。
投入强度是传统银行的三倍多，单户成本却低一到两个数量级。
这个反差说明：平台化平的从来不是"服务器钱"，而是"每笔业务里嵌着多少人工协调"。 图 1 把这件事画清楚了。
图 1｜红利从"资源省钱"迁移到"能力复用"：左边省的是固定资产，右边省的是每笔业务的人工关卡与协调成本
所以本文给一个可以直接拿去自测的度量：
平台化程度 = 一个业务需求从提出到生产可用，需要穿过多少道人工关卡、等待多少个不可控的工作日。
数一数你们这几道关卡：申请资源要几层审批？环境不一致要几个人日排查？安全评审排到几周后？上线窗口是不是只能等"停业测试"？日志出问题时能不能一个人定位到跨系统的调用链？
关卡数不降，云化只是把物理机换成了虚拟机，把机房搬到了云上。
二、监管那句话，翻译过来是一个问句
【原文】
《国家金融监督管理总局关于银行业保险业人工智能安全开发应用的指导意见》（金发〔2026〕8 号，2026 年 6 月 18 日发布）第十三条：
金融机构要加强智能算力资源的云化管理，加强对人工智能应用的运行监测，实现对应用、模型、算力、网络的一体化管理，保障人工智能应用安全可靠运行。
再配上更早的一句。《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》（银保监办发〔2022〕2 号，2022 年 1 月 10 日印发）第十九条：
推进传统架构向分布式架构转型，主要业务系统实现平台化、模块化、服务化......加快推动企业级业务平台建设，加强企业架构设计，实现共性业务功能的标准化、模块化。
【翻译】
这两句话合起来，把"要不要上云"这个技术问题，换成了一个管理问句：你能不能在一块屏上，同时管住应用、模型、算力、网络这四层？
管得住，才叫平台化；管不住，你拥有的只是"多套分散的系统 + 一份云厂商合同"。
【定性】
平台化不再是技术选型题，而是一项可以被现场检查的管理能力。四件套少一件，前面三件花的钱就白花。
还有一个更容易被忽略的落点：第三十条明确"将数字化转型情况纳入银行保险机构信息科技监管评级评分"。这句话的真实含义是------你的平台化程度，最终会体现在监管评级分数上。
三、平台化四件套：少一件，前面三件的钱就白花
"平台化"这三个字在方案书里通常是一团雾。我把它拆成四件可交付、可验收的东西。
图 2｜四件套不是四个产品，是四层能力：门户解决"自助"，编排解决"一致"，可观测解决"定位"，安全策略解决"敢用"
- 统一门户：把"申请"变成"自助"
交付物是服务目录 + 配额 + 策略即代码 ，不是一个带登录页的工单系统。
判断标准很硬：一个业务部门要一套符合安全基线的生产环境，是提交工单等三天，还是在目录里勾选、十分钟内拿到？ 如果答案是后者，门户才算成立。
- 统一编排：把"环境一致"变成默认值
分布式架构最大的隐性成本是环境漂移 ------开发、测试、预发、生产四套环境各有历史包袱，每次上线都是一次考古。
落点是三件事：基础设施即代码、镜像与配置不可变、跨云用同一套编排描述。银保监办发〔2022〕2 号第二十条要求的"适应'敏态'与'稳态'的全周期线上交付管理流程"，说的就是这个。
- 统一可观测：把"四层"打通成一条链
金发〔2026〕8 号第十三条那句"对应用、模型、算力、网络的一体化管理"，工程上就是要求一条调用链能贯穿四层 。
传统可观测只有应用层（APM）和基础设施层（监控）。AI 时代多了两层，而且它们最容易被漏：
· 模型层 ：版本、输入输出、评测分数、漂移指标、Token 消耗；
· 算力层 ：GPU 利用率、显存、排队时长、单位推理成本。
还有一条硬指标必须现在就做进去。金发〔2026〕8 号第二十一条要求：日志保存期限应不低于业务存续期。
这句话的分量很多科技负责人没读出来------日志留存从"运维习惯"变成了"合规义务"，而且期限锚定在业务存续期，不是 180 天。 一个 30 年期房贷的模型决策日志，理论上要留 30 年。存储架构不提前设计，三年后一定返工。
- 统一安全策略：把"卡点"做进流水线
安全不该是上线前的一道人工审批，而该是流水线里的自动闸门。这一层放到第七节展开。
平台化成熟度自测表
这张表建议直接打印，逐行打勾。
|--------|--------|--------------------------|---------------------------|
| 等级 | 名称 | 典型特征 | 可验证判据（做到才算） |
| L0 | 手工运维 | 资源靠工单，环境靠人搭 | 申请一套标准环境 > 2 个工作日 |
| L1 | 资源池化 | 有私有云 / 已买公有云，机器变快了 | 资源交付 < 1 天，但配置仍靠人填 |
| L2 | 自助与编排 | 服务目录 + IaC，环境可重复生成 | 同一份编排文件在测试与生产产出一致结果 |
| L3 | 可观测贯通 | 一条调用链穿透应用---模型---算力---网络 | 任一线上故障可在 30 分钟内定位到四层中的哪一层 |
| L4 | 策略内建 | 安全、成本、数据分级作为策略自动执行 | 违规资源在创建时即被拒绝，且自动生成可审计证据 |
多数机构自报在 L2---L3，实测在 L1---L2。 差别就在最后两列：自报看"我们有没有这个平台"，实测看"这件事是不是自动发生的"。
四、多云与混合云的真实成本：组织成本大于许可成本
架构图上的多云，画的是四个漂亮的方框。真实成本是一座冰山。
图 3｜看得见的只有水面上的许可与专线；水面下的集成、重复建设与组织协调，才是多云账单的大头
· 显性成本 ：许可、资源、专线、驻场。这部分最好谈，也最容易被压价。
· 集成成本 ：同一能力在每个云上都要重新适配一遍。账号体系、日志格式、网络模型、监控口径------四个云就是四套"方言"。
· 重复建设成本 ：因为跨云复用困难，每个云项目旁边都长出一个"小平台"。这些小组件各自为政，最后没人能说出全行到底有几套可观测、几套 CI/CD。
· 组织成本 ：多供应商协调、责任真空、口径不一致。这是最难量化、也最容易在事故当晚爆出来的那一项。
一个必须说清的反直觉：多云不等于分散风险
很多机构的立项理由是"避免单一供应商锁定"。方向没错，但结论常被用反。
金发〔2026〕8 号第十八条要求在使用外部技术时"在外包策略、数据安全、集中度管理 等方面建立管理机制"，并"对外包合作机构实行名单制管理 "；第十九条进一步明确"防范对个别技术服务过度依赖引发的集中度风险"。
而更早的银保监办发〔2022〕2 号第二十五条划了底线："坚持管理责任、核心能力不外包原则" ，并要求**"保障关键外部合作方的可替代性"** 。
把这几句连起来读，会得到一个不太舒服的判断：
签第四家云厂商，不会自动降低集中度------它常常只是把集中度从"一家云"转移成了"一家集成商"。真正的可替代性来自你自己的平台层：能力沉淀在编排文件、策略代码和统一可观测里，而不是沉淀在某个厂商的工单系统里。
所以本系列的反直觉结论是这一句：上云越深，机构越需要一个内部云运营组织，而不是更多云厂商。
这个组织不必大，但必须拥有三样东西：服务目录的定义权、编排与策略代码的主干、以及四层可观测数据。没有这三样，它就是又一个协调会，而不是一个平台。
自建 / 复用 / 采购：三道决策门
|---------------------|----------------------------|----------------|----------------------|
| 判断维度 | 自建 | 复用集团或行业平台 | 采购商业产品 |
| 是否属于"关键平台、关键组件" | 是------2 号文第二十一条要求形成自主研发能力 | 视归属 | 否 |
| 是否涉及客户数据与模型决策 | 优先自建或私有化 | 需数据隔离与责任条款 | 须满足外包与名单制管理 |
| 能力是否已被同业验证 | 谨慎自建 | 优先复用 | 优先采购 |
| 三年总成本（含组织成本） | 常高于报价 2---3 倍 | 最低，但议价权弱 | 中等，锁定风险高 |
| 出问题谁负责 | 自己 | 平台方 + 你（责任要写清） | 厂商 SLA + 你（主体责任不可外包） |
| 典型适用 | 核心账务、风控决策、统一编排 | 算力池、测试环境、行业数据集 | 通用中间件、监控组件、商业模型 |
这张表最关键的一行是最后一行的反面：无论选哪一列，"谁使用谁负责"这条原则都不变。 金发〔2026〕8 号把它写在了总体要求的第一句。
五、网络：从"带宽"到"确定性"
报告第二章把"网络应用创新"与"云平台升级"并列放在第一节，这个编排本身就是一个判断：分布式架构走到深水区，网络不再是配套工程，而是延迟与确定性的第一变量。
架构师在这里要处理的是一个两难：
· 多中心、多活（2 号文第十八条明确要求"构建多中心、多活架构"）会让东西向流量激增 ，专线成本随站点数近似平方增长；
· 但业务侧对"确定性"的要求也在提高------一次风控决策、一笔支付、一次模型推理，超时就是失败，不是"慢一点"。
破法不是先升级网络，而是先把"确定性"翻译成业务语言。 三个动作：
1 给每类业务写时延预算 ：核心交易、批量清算、在线推理、内部办公各一档，写进架构决策记录，而不是留在运维同学的经验里。
2 把 RPO/RTO 与业务影响连起来 ：多活不是技术荣誉，是为了让某类业务在站点失效时少停多少分钟。连不上业务指标的容灾，都是预算浪费。
3 中小机构优先考虑共建共享 ：金发〔2026〕8 号第十二条明确"鼓励有条件的大型金融机构向中小金融机构输出算力服务，支持同业探索基础设施共建共享"，并支持"使用国家算力节点或行业基础设施降低研发应用成本"。对多数中小机构，接入比自建更符合"务实高效"这条原则。
六、绿色数据中心：PUE 不是终点，"单位业务量的算力成本"才是
报告把"绿色数据中心"单列一节，很多人把它读成基建部门的事。它其实是架构指标。
先看政策的硬约束。《数据中心绿色低碳发展专项行动计划》（国家发展改革委等部门 2024 年 7 月印发）提出：
到 2025 年底，全国数据中心布局更加合理，整体上架率不低于 60%，平均电能利用效率降至 1.5 以下 ，可再生能源利用率年均增长 10%。
同时，新建及改扩建大型和超大型数据中心 PUE 降至 1.25 以内，国家枢纽节点数据中心项目 PUE 不得高于 1.2，枢纽节点新建数据中心绿电占比超过 80%。
请注意目标里最容易被忽略的那一项：上架率不低于 60%。
图 4｜PUE 管的是"每度电有多少进了 IT 设备"，上架率管的是"每分投资有多少在跑业务"------两个指标合起来才是真实的绿色与成本
这两个指标的差别很关键：
· PUE 是电的效率 ：1.5 意味着每 1.5 度电里只有 1 度真正用于计算。
· 上架率是资本的效率 ：建了不用，PUE 再漂亮，每一台空转的服务器都在同时浪费电、浪费折旧、浪费机房指标。
一个推演（待验证，各机构应用自身数据复核） ：为把 PUE 从 1.4 压到 1.2 而做的液冷改造，如果导致上架率从 70% 掉到 50%，那么"单位有效算力的能耗与折旧"很可能不降反升------因为建设期的隐含碳与空转成本被摊到了更少的业务量上。
所以架构师该做的换算，是把两个指标合成一个业务能听懂的数：
单位业务量算力成本 = （电力成本 + 折旧 + 运维）/（笔数 + 推理次数 + 账户·年）
只有换算到这个粒度，科技预算才第一次能和业务部门对话。否则"我们 PUE 降了 0.1"这句话，在经营会上等于没说。
七、安全底座：把"人盯人"换成"策略内建"
报告第二章第二节把"安全技术底座"与云平台并列，这一节的工程含义最容易被低估：监管要的不是更多安全人员，而是把安全变成平台能力。
先看两条已经生效的硬要求。
模型与算法侧 ，银保监办发〔2022〕2 号第二十六条：对模型开发、验证、部署、评价、退出进行全流程管理，"确保模型的可解释性和可审计性"，"模型管理核心环节要自主掌控"。
AI 应用侧 ，金发〔2026〕8 号把颗粒度推得更细：
· 第十五条：按业务场景重要性、应用规模、对客影响度、模型依赖度、模型复杂度实施风险分类分级 ，制定应用清单；
· 第十六条：涉及资金交易、资产评估、信贷审批、承保理赔、风险管理等，以及与客户利益直接相关、直接影响金融合约达成的场景为高风险应用，须经本机构风险管理委员会批准后方可实施 ；
· 第十七条：高风险应用关键环节建立人工监督和干预机制 ，明确紧急停用及模型退出条件，建立备用系统或人工替代流程；
· 第二十二条：可解释性不足的技术在高风险场景仅能作为辅助工具 ；应用于涉及客户权益或有实质性财务影响的关键决策时，须设置人工复核节点，完整保留原始数据、推理路径及阈值触发记录，确保责任可追溯 。
这四条连起来，其实是一份架构说明书。
图 5｜把分级准入、人工复核、停用回退做进流水线：合规证据是系统运行的副产品，不是审计前两周的项目交付物
三个落地动作：
1 应用清单是主数据，不是台账。 每个 AI 应用要有唯一 ID、风险等级、责任人、准入批准记录，并与 CMDB、发布流水线、权限系统联动。清单靠 Excel 维护，等于没有清单。
2 人工复核节点做成流程卡点，不做成口头约定。 "谁复核、复核什么、复核记录存在哪"必须是系统字段，否则第二十二条那句"责任可追溯"无法举证。
3 证据链自动生成。 原始输入、模型版本、推理路径、阈值触发、人工干预动作，在运行时落库，按业务存续期归档。审计取数应该是平台的一个查询，而不是审计前两周的一次专项工程。
这里有一条我判断未来两年会出事的红线：多数机构的 AI 应用清单，现在还散落在各部门自己维护的表格里。
八、落地路线：90 / 180 / 365 天
不要一上来就"建企业级云平台"。那是三年项目，通常死在第二年，死因是看不到产出。
图 6｜先打通一条链，再复制能力；先做可见的自助，再做不可见的策略------顺序反了，平台会变成新的审批环节
0---90 天：打通一条链，别扩面。
· 选 1 条业务线 （建议选有明确上线频次压力的渠道类或运营类系统）；
· 交付三件看得见的东西：一个能自助申请到合规环境的服务目录、一条贯穿应用与算力的调用链、一份自动生成的上线证据包 ；
· 同步把 AI 应用清单建起来（哪怕只有 20 个应用），字段一次定全：风险等级、责任人、准入批准、模型版本、日志留存期。
90---180 天：复制能力，收敛重复。
· 把第一条链的编排模板、基线镜像、安全策略沉淀为可复用资产 ，第二条业务线接入时只做配置不做开发；
· 做一次全行"平台盘点"：数清楚有几套 CI/CD、几套监控、几套日志。目标不是合并，是明确每套的唯一负责人与退出计划 ；
· 上线成本与上架率两个指标的换算看板，把"单位业务量算力成本"进经营例会。
180---365 天：把策略做进底座，把责任写进代码。
· 安全策略、数据分级、成本配额从"审批意见"变成"创建时自动执行"，走到 L4 的判据；
· 完成一次真实演练：关闭一个云厂商的服务，验证你的编排与可观测能不能在约定时间内把关键业务切走 ------这是"可替代性"唯一可信的证明；
· 把平台化度量（关卡数、交付时长、故障定位时长、单位业务量成本）纳入科技条线的常态考核。
这条路线里最反直觉的一条：第一个 90 天不要碰"统一"两个字。 先做出一个让人羡慕的自助体验，再让人主动来接入；先做统一，你得到的是一套新的强制流程。
九、五个高频返工点
1 先建门户，后建编排。 门户变成高级工单系统，审批从线下搬到线上，关卡一道没少。门户必须长在编排之上。
2 可观测只做到应用层。 模型和算力两层缺失，AI 应用出问题时无人能定位，最后回到"人肉排查 + 厂商驻场"。四层贯通是金发〔2026〕8 号第十三条的原话，不是加分项。
3 日志按运维默认策略留存。 等到监管要求"不低于业务存续期"时才发现存储架构不支持，只能补建归档系统，成本翻几倍。
4 把多云当风险分散，把平台层让给集成商。 三年后想换厂商，发现能力全在别人手里，切换成本高于新建。可替代性必须自己举证，演练一次才算数。
5 AI 应用清单靠各部门自报。 清单永远比实际少，而且少的那几个往往风险最高。清单必须是主数据，与发布流水线联动，未经登记的应用无法上线。
十、三类人行动清单
如果你是机构科技条线负责人
1 数一遍你们的关卡 ：抽 20 个已上线需求，统计从提出到生产可用的审批节点数与等待工作日数。这个数字就是你的平台化真实水位，比任何成熟度模型都准。
2 给平台层设一个内部运营组织 ，并把服务目录定义权、编排主干、可观测数据三样东西的归属写进职责说明书。
3 把"换掉一家云厂商"做成一次年度演练 ，演练报告作为供应商续谈的前置材料。
如果你是业务条线负责人
4 提出需求时同时要求"环境交付时长承诺" ，把它当成 SLA 来谈，而不是当成技术的内部事务。
5 在你自己的场景里定义确定性 ：哪类业务超时即失败、哪类可以降级、哪类允许批量延后。这三档写不清楚，网络与容灾预算一定花错。
6 主动认领 AI 应用清单里的业务责任人角色 ------按第二十二条，涉及客户权益的决策要有人复核，复核人必须是业务侧的。
如果你是架构师 / 平台负责人
7 把"四层一体可观测"写进架构决策记录 ，并给出一个真实故障的定位时长作为验收证据。
8 把策略做成代码，而不是做成流程 ：配额、基线、数据分级、成本上限在资源创建时执行，违规即拒绝并留证。
9 在方案书里同时写 PUE、上架率与单位业务量算力成本 。只写 PUE 的方案，在经营会上撑不过五分钟。
收束
回到标题那个问题：平台化到底平了什么。
它平的不是机房的电，是业务的等待；不是服务器的数量，是人工关卡的数量；不是供应商的名单，是责任的归属。
监管说的是"一体化管理"，机构做的是"四套分散系统"------这中间的落差，就是未来三年科技预算最大的浪费点。
架构师手记（三句话）
1 平台化的收益不会出现在基础设施账单上，它出现在"某个需求少等了三周"这件事上------所以度量方式决定它能不能被看见。
2 所有"多云分散风险"的方案，最后都要回答同一个问题：如果明天必须换掉一家，你能在几天内切完？答不上来，就是没有平台层。
3 云化越深，越需要一个不写业务代码、但为所有业务代码负责的内部组织。这件事在预算表上不好看，所以大多数机构不做。
下期预告 ：第 4 篇《技术底座与安全底座：金融架构的"看不见的一半"》------当平台化走完，智能研发平台与智能运维会同时改变成本曲线和安全左移的位置。我会把研发生命周期、安全卡点和智能化三张图叠成一张。
一个在金融科技行业做了十六年架构的人。这里聊三件事：金融合规政策怎么读、数字基础设施怎么建、系统架构怎么改。如果你也在金融与技术的交叉口上，欢迎关注。