AI Maturity Model / Roadmap / Capability Assessment Playbook
这些来源作为学习锚点, 不构成认证、审计、法律、合规或监管意见。正式组织评估必须由 business owner、enterprise architecture、risk、compliance、privacy、security、model risk、data owner、technology owner、internal audit 和 management review 机制共同确认。
AI Maturity Model / Roadmap / Capability Assessment Playbook
配对阅读：本手册的原理/架构解读版是
docs/ai-foundations/papers/81-ai-maturity-model-roadmap-capability-assessment.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。
定位: 面向 AI 产品架构、企业架构、转型治理、金融零售运营和风险管理负责人, 把 AI maturity model、capability assessment、roadmap sequencing、investment dependency、operating cadence 和组织能力证据连接成一套可评估、可治理、可复盘的成熟度体系。 目标: 不再用模型数量、POC 数量或工具采购数量证明 AI 进展, 而是用可审计的能力证据说明组织是否能持续交付被采用、可治理、可复用、可扩展的 AI 业务能力。 核心观点: AI 成熟度不是“会不会用 AI”, 而是组织能否把战略、数据、模型、评估、风险、集成、产品采用、人才和运营节奏变成稳定的 transformation operating system。 适用范围: 银行、消费金融、财富管理、保险、支付、零售金融运营、客服、AML / KYC、信贷、反欺诈、分行与数字渠道、企业 AI 平台和 AI 组织能力建设。
1. Source Anchors
这些来源作为学习锚点, 不构成认证、审计、法律、合规或监管意见。正式组织评估必须由 business owner、enterprise architecture、risk、compliance、privacy、security、model risk、data owner、technology owner、internal audit 和 management review 机制共同确认。
| Anchor | Official Source | 本 playbook 的使用方式 |
|---|---|---|
| CMMI official | https://cmmiinstitute.com/ | 借鉴 capability maturity、process institutionalization、continuous improvement 的语言, 但不把 AI 成熟度简化为流程合规打分 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 风险、证据、控制和持续监控 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 用 AI management system 思维连接 policy、objectives、operation、performance evaluation、improvement 和 management review |
| TOGAF ADM official | https://www.opengroup.org/togaf | 用 architecture development、roadmap、migration planning、implementation governance 连接能力蓝图和转型路线图 |
2. System Positioning
AI Maturity Model 是一套把 AI 战略意图转成能力域、成熟度证据、路线图依赖、投资决策、运营节奏和组织学习闭环的管理框架。
管理原则:
AI 成熟度不能用“做了多少 AI POC”衡量, 而要看组织是否能稳定地产生可采用、可评估、可治理、可复用、可扩展的 AI 能力, 并能用证据决定继续投、暂停、扩展、平台化或停止。
3. 为什么 AI Maturity 不是模型数量或 POC 数量
AI 转型最常见的错觉是把活动量当成成熟度:
更多模型
-> 更多 POC
-> 更多 demo
-> 更多供应商
-> 更多仪表盘
-> 看起来更成熟
真正的成熟路径应当是:
战略焦点
-> 能力域定义
-> 证据标准
-> 分阶段路线图
-> 平台复用
-> 风险和收益闭环
-> 组织学习和持续改进
3.1 错误成熟度信号
| 错误信号 | 为什么误导 | 成熟组织会看什么 |
|---|---|---|
| 已接入多个 foundation model | 模型接入不等于业务能力, 还可能增加供应商、成本和版本风险 | model gateway、routing policy、eval gate、cost SLO、fallback、vendor exit plan |
| POC 数量很多 | POC 只证明可演示, 不证明可上线、可采用、可控风险 | pilot evidence、release gate、adoption proof、benefit realization、scale / stop decision |
| 每个部门都有 AI 工具 | 分散工具会制造数据边界、审计、权限和支持碎片 | AI inventory、risk tier、approved pattern、shared platform capability、support model |
| Prompt library 很丰富 | prompt 不是组织能力, 除非有版本、评估、权限和反馈闭环 | prompt / context versioning、golden set、regression eval、usage telemetry、owner |
| 高管看到 demo 很满意 | demo 多发生在低风险、低异常、低集成场景 | real workflow trial、exception handling、human oversight、audit trail、rollback plan |
| 模型指标很好 | accuracy、BLEU、win rate 或 judge score 不能自动证明业务价值 | baseline、task completion、quality review、customer harm signal、finance sign-off |
| 上线了 chatbot | chatbot 可能只是新入口, 不代表流程被改造 | workflow redesign、knowledge governance、handoff, escalation, adoption and support evidence |
3.2 成熟度的证据定义
AI 成熟度的最小证据链:
Business outcome
-> capability domain
-> maturity gap
-> roadmap increment
-> delivery artifact
-> eval / risk / adoption evidence
-> operating cadence
-> management decision
如果一个组织只能展示 demo, 但无法展示谁拥有能力、谁承担风险、如何评估、如何监控、如何采用、如何停止和如何复用, 它仍处在低成熟度阶段。
3.3 需求、流程和治理能力之后的升级重点
当组织已经具备成熟度模型、需求分析或 stakeholder analysis 的基础能力后, 下一阶段要证明的是:
| 原有强项 | AI 成熟度升级 |
|---|---|
| 会定义业务需求 | 能把需求转成 eval contract、risk control、adoption metric 和 roadmap increment |
| 会分析流程 | 能识别 AI 进入流程后的责任、证据、异常、人工监督和运营节奏变化 |
| 会做 stakeholder engagement | 能组织 business、risk、data、architecture、platform、finance 和 operations 的证据门禁 |
| 会做 solution evaluation | 能比较 no-AI、workflow-only、AI-assisted、agentic、vendor 和 platform reuse 方案 |
| 会写 business case | 能把收益承诺连接到 baseline、benefits register、adoption-adjusted ROI 和 stop rule |
4. Capability Domains
AI capability assessment 不应只评估技术栈, 而要评估组织能否把 AI 放入真实业务系统。以下八个能力域可以用于组织评估、能力证据映射和季度路线图复盘。
4.1 Capability Domain 总览
| Domain | 成熟组织要证明什么 | 关键证据 |
|---|---|---|
| Strategy / Investment Mix | AI 投资是否服务明确战略, 并通过组合治理决定 fund / scale / stop | AI investment thesis、investment kanban、funding gate、benefits register、capacity allocation |
| Data / Knowledge | 数据和知识是否可被 AI 安全、稳定、可追溯地使用 | data product、knowledge ownership、lineage、access control、data quality SLO、golden set |
| Model / Platform | 模型、RAG、agent、tool 和基础设施是否可复用、可观测、可控制成本 | model gateway、RAG platform、tool registry、versioning、CI/CD、observability、FinOps |
| EvalOps | 需求是否被转成可验证的质量、风险和上线门禁 | eval contract、golden dataset、rubric、LLM-as-judge calibration、regression gate、release report |
| RiskOps | AI 风险是否被分层、控制、接受、监控和复盘 | risk tiering、policy-as-code、human oversight、incident runbook、control evidence、risk acceptance |
| Integration | AI 是否进入真实流程、系统、权限、审计和运营支持 | API / event integration、workflow state、SSO / role-based access control、system-of-record writeback、audit trail、rollback |
| Product / Adoption | 用户是否真的改变行为, 收益是否被采用证据支撑 | journey map、role redesign、AI literacy、champion network、support model、adoption dashboard |
| Talent / Operating Model | 组织是否有角色、论坛、RACI、培训和管理节奏支撑持续改进 | role competency matrix、RACI、governance forums、training record、quarterly maturity review |
4.2 Domain 评分问题
每个 domain 都用 0-4 分评估, 但评分不是自我感觉, 只看证据。
| 分数 | 判断方式 | 证据要求 |
|---|---|---|
| 0 | 没有被正式定义 | 没有 owner、artifact、流程或运行记录 |
| 1 | 有零散实践 | 有个人经验、单个模板或一次性案例 |
| 2 | 可重复 | 至少两个 use case 使用同一套方法, 有轻量门禁 |
| 3 | 被管理 | 有 owner、KPI / KRI、review cadence、风险接受和改进 backlog |
| 4 | 可规模化优化 | 跨产品线复用, 有自动化证据、平台能力、收益闭环和持续改进记录 |
4.3 Domain 之间的依赖
成熟度评估必须看依赖, 不能单看单项高分。
| 如果缺失 | 会拖累什么 | 典型后果 |
|---|---|---|
| Strategy / Investment Mix | Platform、RiskOps、Talent | 大量团队各自做 AI, 没有优先级和停项机制 |
| Data / Knowledge | EvalOps、Product、RiskOps | 回答不可追溯、质量不可控、权限边界模糊 |
| EvalOps | Release、RiskOps、Adoption | 只能靠主观验收, 无法证明质量是否退化 |
| RiskOps | Integration、Scale、Customer-facing AI | 上线前评审混乱, 生产后事故处理被动 |
| Integration | Product / Adoption、Benefits | 用户仍在多个系统复制粘贴, 价值无法兑现 |
| Product / Adoption | Benefits、Talent | 上线后使用率低, 一线抵触, 收益无法被 finance 接受 |
| Talent / Operating Model | 所有能力域 | 能力依赖少数专家, 换人后体系失效 |
5. Maturity Levels
这里使用五级成熟度作为组织语言: ad hoc、repeatable、managed、scaled、optimized。重点不是名称, 而是每级必须能拿出什么证据。
5.1 五级成熟度总表
| Level | 名称 | 组织表现 | 证据要求 |
|---|---|---|---|
| 1 | Ad hoc | AI 由个人兴趣、部门试验或供应商 demo 推动 | 有 use case 说明和实验记录, 但缺少统一 owner、gate、risk tier、eval 和 adoption 证据 |
| 2 | Repeatable | 部分团队能重复做 discovery / pilot, 开始复用模板 | 有 intake、problem statement、basic data check、pilot criteria、轻量风险评估和复盘记录 |
| 3 | Managed | AI investment governance、release gate、risk control、platform pattern 和 adoption 指标进入管理节奏 | 有 investment review、funding gate、eval report、risk acceptance、runbook、benefits register 和 owner RACI |
| 4 | Scaled | 多条业务线复用平台、EvalOps、RiskOps、知识治理和 adoption playbook | 有 shared platform usage、cross-line reuse、automated monitoring、unit economics、training coverage 和 scale decision |
| 5 | Optimized | 组织能持续学习、重配投资、优化成本、改进控制、淘汰低价值能力 | 有 quarterly maturity trend、control effectiveness、incident learning、model / data drift response、retirement record 和 strategic reallocation |
5.2 每级不能跳过的证据
| Level | 最低证据门槛 | 不能宣称成熟的情况 |
|---|---|---|
| 1 | 至少能说明业务问题、试验范围、用户、数据来源和风险假设 | 只有 demo 视频、供应商介绍或“大家觉得有用” |
| 2 | 至少两个试点使用同一套 intake、baseline、eval criteria 和复盘格式 | 每个团队都重新发明 prompt、评估表和审批路径 |
| 3 | 有正式 gate: discovery、pilot、release、scale / stop, 且有决策记录 | 项目上线靠 sponsor 推动, 风险、数据、架构和运营只在最后补签 |
| 4 | 有平台复用率、共享能力 backlog、跨业务线 adoption 数据和统一监控 | 每个业务线都买不同工具、建不同知识库、用不同评估标准 |
| 5 | 有持续改进机制: 事故复盘、控制有效性、组合重配、能力退休和人才升级 | 从不停止低价值能力, 也无法解释哪些能力因学习而改变 |
5.3 成熟度不是线性升级
金融零售组织常见状态是局部成熟、整体不成熟:
| 状态 | 例子 | 评估结论 |
|---|---|---|
| 平台成熟, adoption 低 | 已有 model gateway 和 RAG 平台, 但一线经理没有采用指标 | 不能评为 scaled, 因为价值没有进入流程 |
| RiskOps 强, EvalOps 弱 | 风险审批严格, 但 eval set 和质量门禁不稳定 | 生产风险可能被流程掩盖, 不是被证据管理 |
| POC 强, investment governance 弱 | 很多团队能做 pilot, 但缺少 scale / stop 机制 | Repeatable 到 Managed 的断点 |
| 单点产品强, 复用弱 | 某个客服助手效果好, 但知识、评估、监控无法复用 | 局部 Level 3, 组织 Level 2 |
| 高管支持强, operating model 弱 | 有 AI 战略和预算, 但 owner、RACI、forum、cadence 不清 | 战略清晰不等于执行成熟 |
6. Roadmap Sequencing
AI maturity roadmap 应按证据和依赖排序, 不是按技术潮流排序。推荐顺序:
Foundation
-> Pilot Evidence
-> Platformization
-> Governance Scaling
-> Product-line Reuse
6.1 Roadmap 阶段
| Phase | 目标 | 核心动作 | 出口证据 |
|---|---|---|---|
| Foundation | 建立共同语言、inventory、risk tier、use case intake 和能力域基线 | 建 AI inventory、定义 domain scorecard、确认 owner、建立 intake 和 risk triage | AI use case inventory、capability heatmap、RACI、initial risk tier、90-day roadmap |
| Pilot Evidence | 证明少数高价值用例值得继续投资 | 做 baseline、workflow trial、golden set、eval、architecture spike、adoption trial | pilot report、eval result、SME review、cost / latency view、risk control design、scale / stop memo |
| Platformization | 把重复能力沉淀为可复用平台和标准模式 | 建 model gateway、RAG pattern、eval harness、prompt / context registry、observability、FinOps | platform capability backlog、reuse map、reference architecture、release gate template、cost SLO |
| Governance Scaling | 将治理从人工审批扩展为标准流程、自动证据和管理节奏 | 接入 AI management system、control library、policy-as-code、monitoring、incident response、management review | control evidence binder、risk acceptance record、monitoring dashboard、incident drill、quarterly review |
| Product-line Reuse | 在多产品线复用能力, 形成持续优化和退休机制 | 跨业务线 rollout、role-based adoption、shared support、benefits realization、retirement governance | reuse rate、adoption cohort、benefits sign-off、unit economics trend、retirement / improvement decisions |
6.2 路线图排序原则
| 原则 | 解释 | 决策用法 |
|---|---|---|
| Evidence before scale | 没有 pilot evidence 不扩大 | 高管想快速铺开时, 用 eval、adoption、risk、cost 证据判断是否可扩展 |
| Platform after repetition | 看到重复模式后再平台化 | 三个以上用例重复需要 gateway、RAG、eval、logging 或 approval 时, 转入 platform runway |
| Governance by risk tier | 低风险不被重流程拖慢, 高风险必须前置控制 | 内部 copilot、客户交互、信贷决策、AML case support 使用不同门禁 |
| Adoption in roadmap | 采用不是上线后的培训任务 | 每个 release 都必须有 user cohort、manager cadence、support model 和 benefit measurement |
| Dependencies visible | 数据、权限、集成、SME、风险和平台容量要在同一张图上 | investment review 中用 dependency map 决定顺序和 WIP limit |
6.3 Investment Dependency Map 的思路
AI roadmap 常被卡住, 不是因为模型, 而是因为依赖没有显性化。
| Dependency | 影响的用例 | 决策信号 | 推荐处理 |
|---|---|---|---|
| Knowledge ownership | 客服助手、RM copilot、政策问答 | 多个用例都需要同一批产品政策和流程知识 | 先建 knowledge governance, 再扩大 RAG 场景 |
| Case management integration | AML、投诉、催收、理赔 | 用户需要把 AI 输出写回系统并留痕 | 优先投资 workflow integration 和 audit trail |
| Eval golden set | 客服、信贷解释、KYC review | 缺少高质量样本, 无法做 release gate | 建 SME 标注节奏和 eval repository |
| Risk acceptance authority | 客户交互、信贷、反欺诈 | 不清楚谁能接受 residual risk | 建 risk tier 和审批授权矩阵 |
| Platform capacity | 多业务线同时接入 | 平台团队成为瓶颈 | 设置 platform runway 和 intake WIP limit |
| Change manager capacity | 分行、运营中心、客服中心 | 一线 adoption 需要培训、经理节奏和支持 | 把 adoption capacity 纳入 investment allocation |
6.4 Operating Cadence
成熟度不是年度评估报告, 而是固定节奏下的证据更新。
| Cadence | 参与者 | 输入 | 输出 |
|---|---|---|---|
| Weekly intake triage | product strategy、process architecture、solution architecture、risk liaison、platform | new use cases、duplicate map、risk signal | accept、merge、park、reject、request discovery |
| Bi-weekly delivery review | product、engineering、data、SME、ops | pilot progress、eval result、integration blocker、user feedback | unblock decision、scope adjustment、evidence update |
| Monthly investment review | business sponsors、finance、risk、architecture、platform | scorecard、benefits register、capacity view、cost trend | fund、continue、scale、pause、stop、platformize |
| Quarterly maturity review | executive sponsor、AI governance、enterprise architecture、audit liaison | maturity scorecard、capability heatmap、incident learning、roadmap dependency | target maturity update、investment shift、control improvement、talent plan |
7. Capability Practice Map
个人能力和组织成熟度要用同一套证据语言连接。目标不是证明“懂 AI”, 而是能让组织从低成熟度走向可管理、可扩展和可持续改进。
7.1 Problem and Workflow Architecture
| 成长阶段 | 能力证据 | 组织成熟度作用 |
|---|---|---|
| Level 1 -> 2 | problem memo、AS-IS / TO-BE、baseline table、pilot criteria | 把模糊 AI 想法转成业务问题、流程、用户、baseline 和试点标准 |
| Level 2 -> 3 | requirements-to-eval matrix、risk control checklist、acceptance criteria、UAT + SME review pack | 把需求转成 eval、risk、adoption 和 release evidence |
| Level 3 -> 4 | capability heatmap、process pattern library、data readiness register、adoption blocker taxonomy | 跨多个用例抽象重复模式和能力缺口 |
| Level 4 -> 5 | maturity review memo、lessons learned、control improvement backlog、retirement recommendation | 把事故、反馈和收益学习回灌需求体系 |
这类能力的核心不是写需求文档, 而是把业务问题转成可评估、可治理、可采用的证据链: baseline、workflow、eval、risk、adoption、owner 和 stop rule 都要清楚。
7.2 Product Strategy and Value Management
| 成长阶段 | 能力证据 | 组织成熟度作用 |
|---|---|---|
| Level 1 -> 2 | AI product brief、opportunity canvas、MVP scope、success metric | 定义 MVP、目标用户、use case scope 和成功指标 |
| Level 2 -> 3 | pilot report、release gate memo、benefits register、adoption dashboard | 管理 pilot 到 release 的价值、风险、成本和采用 |
| Level 3 -> 4 | investment kanban、platform reuse map、funding memo、scale / stop decision | 把多个用例连接到平台能力和投资治理 |
| Level 4 -> 5 | quarterly investment review、unit economics trend、retirement record、product-line reuse roadmap | 持续优化投资组合, 淘汰低价值能力, 推动产品线复用 |
AI 产品能力要被当作 evidence-driven investment。每个阶段都要回答是否值得继续投、是否可控、是否被采用、是否能复用平台能力, 而不是默认从 POC 推到上线。
7.3 Enterprise Architecture and Platform Reuse
| 成长阶段 | 能力证据 | 组织成熟度作用 |
|---|---|---|
| Level 1 -> 2 | C4 diagram、sequence diagram、data flow、threat / risk notes | 画出单个 AI solution 的组件、数据流、权限和风险边界 |
| Level 2 -> 3 | ADR、reference pattern、monitoring design、rollback plan、architecture review pack | 建立 reference architecture、release gate 和 observability 设计 |
| Level 3 -> 4 | platform capability map、reuse metrics、control architecture、cost / latency SLO | 推动 model gateway、RAG、EvalOps、RiskOps 和 integration pattern 的平台化 |
| Level 4 -> 5 | architecture roadmap、technical debt register、resilience review、strategic reallocation memo | 把架构演进纳入企业路线图和管理评审 |
AI 架构成熟度要从单点系统设计提升到企业能力设计: 哪些能力应该产品化、哪些控制必须平台化、哪些风险要前置、哪些依赖会决定路线图顺序。
7.4 Capability Evidence and Organization Maturity
| 组织成熟度问题 | 能力证据 | 说明 |
|---|---|---|
| 没有统一 intake | AI use case intake + scoring example | 把想法流量变成可治理入口 |
| POC 无法 scale | pilot evidence pack | 从 demo 推进到证据门禁 |
| 数据和知识混乱 | knowledge governance + data readiness assessment | 识别 AI 失败的上游原因 |
| 上线后没人用 | adoption plan + dashboard | 设计行为改变和收益兑现 |
| 风险审批被动 | risk tier + control evidence binder | 把治理前置到生命周期 |
| 平台投资难解释 | reuse map + platform runway memo | 把平台成本讲成组合杠杆 |
| 成熟度无法复盘 | quarterly maturity review pack | 把成长转成管理节奏 |
8. Financial Retail Case: 银行 / 零售金融 AI Maturity Assessment
8.1 背景设定
一家区域银行正在推进四类 AI 场景:
| 场景 | 目标 | 当前状态 |
|---|---|---|
| AML investigator copilot | 帮助分析员检索交易、KYC、历史 case 和 typology, 起草 narrative | POC 演示成功, 尚未进入生产队列 |
| Customer service knowledge assistant | 帮助客服回答产品、费用、流程和投诉处理问题 | 内部 pilot 中, 使用率波动 |
| Credit memo assistant | 帮 RM 和信贷分析师整理财务资料、行业风险和授信 memo 初稿 | 数据权限和模型风险争议较大 |
| Branch advisor copilot | 帮分行员工查询产品适配、流程材料和合规提醒 | 知识库分散, 培训未统一 |
8.2 成熟度评估摘要
| Domain | 当前等级 | 证据观察 | 主要缺口 | 90 天动作 |
|---|---|---|---|---|
| Strategy / Investment Mix | 2 | 有 AI steering committee 和场景清单, 但 funding gate 不稳定 | 没有统一 scale / stop 标准 | 建 investment kanban、risk-adjusted scoring、monthly value review |
| Data / Knowledge | 1 | 知识散落在政策 PDF、SharePoint、核心系统和专家经验 | 没有 owner、lineage、权限和更新 SLA | 建知识域 owner、RAG source register、data quality SLO |
| Model / Platform | 2 | IT 已接入两个模型供应商, 有初步日志 | 缺少统一 gateway、cost SLO、version pinning 和 fallback | 建 model gateway MVP、routing policy、cost dashboard |
| EvalOps | 1 | Demo 主要靠 SME 主观试用 | 缺少 golden set、rubric、regression eval | 先为 AML 和客服建立 200 条高质量评估样本 |
| RiskOps | 2 | 风险团队参与评审, 但控制证据不标准 | risk tier、residual risk、human oversight 口径不统一 | 建 risk tier matrix、control library、risk acceptance memo |
| Integration | 1 | 多数场景仍是独立界面或复制粘贴 | 没有 case management / CRM 写回和审计留痕 | 优先做客服和 AML 的 workflow integration spike |
| Product / Adoption | 2 | 有培训和试点用户, 但没有经理节奏和收益口径 | 使用率、任务完成、返工和信任信号未闭环 | 建 adoption dashboard、champion network、support taxonomy |
| Talent / Operating Model | 2 | 有 AI lead 和少数专家, 角色能力未成体系 | product strategy、process architecture、solution architecture、Risk、Ops 的 RACI 不清 | 建 role competency map、quarterly maturity review、training path |
总体判断:
组织处于 Repeatable 初期。
单个团队具备 POC 能力, 但还没有形成 managed AI operating model。
最关键断点不是模型能力, 而是知识治理、EvalOps、workflow integration、risk evidence 和 adoption cadence。
8.3 推荐路线图
| 时间 | 目标 | 关键交付 | 决策 |
|---|---|---|---|
| 0-30 天 | 建立 maturity baseline 和 investment discipline | use case inventory、capability scorecard、risk tier、owner RACI | 哪些场景进入 discovery / pilot, 哪些合并或暂停 |
| 31-60 天 | 建立 AML 和客服两个 pilot evidence pack | baseline、golden set、eval report、workflow trial、human oversight design | 哪个场景进入 limited release, 哪个需要补证据 |
| 61-90 天 | 启动平台化和治理扩展 | model gateway MVP、RAG source register、release gate、adoption dashboard | 投资 platform runway, 批准 limited production |
| Quarter 2 | 扩展到信贷 memo 和分行 copilot | cross-use-case reuse map、risk control evidence、role-based training | 按风险等级 scale, 或限制高风险功能 |
| Quarter 3 | 建立产品线复用和持续改进 | quarterly maturity review、benefits sign-off、incident learning、retirement record | 重新分配预算, 淘汰低采用或高风险能力 |
8.4 关键依赖图
| Roadmap Item | Depends On | Blocks | Owner |
|---|---|---|---|
| AML limited release | Golden set、case management audit trail、human review queue、risk acceptance | AML scale、model monitoring | Financial Crime Ops + product strategy + solution architecture |
| Customer service scale | Knowledge owner、source freshness SLA、answer groundedness eval、support model | Contact center rollout | Customer Ops + Knowledge Owner |
| Credit memo pilot | Data permission、model risk review、explainability boundary、RM workflow design | Relationship manager adoption | Credit Risk + Wealth / Commercial Product |
| Branch advisor rollout | Product knowledge taxonomy、role-based AI literacy、branch manager cadence | Branch adoption and benefit proof | Retail Banking Ops |
| Platform runway | Reuse evidence from AML and客服、cost baseline、logging standard | Multi-line scale | Platform Lead + Enterprise Architect |
8.5 Assessment Narrative 示例
当前银行的 AI 成熟度不是“缺模型”, 而是缺一套从 use case intake 到 release gate、adoption proof、risk acceptance 和 platform reuse 的证据系统。建议把未来 90 天聚焦在两个高价值、可控范围的 pilot evidence pack: AML investigator copilot 和客服知识助手。只有当它们证明了 eval quality、人工监督、工作流集成、用户采用和风险控制后, 才进入 limited release。与此同时, 将重复出现的能力沉淀为 model gateway、RAG source register、eval harness 和 control library, 为下一季度的信贷和分行场景复用。
9. Artifact Templates
以下模板用于组织评估、季度复盘和能力证据管理。它们的目标不是制造表格, 而是让每个成熟度判断都有证据、owner、决策和后续动作。
9.1 Maturity Scorecard
| Field | 示例写法 |
|---|---|
| Assessment scope | Retail banking AI use case mix: AML copilot、客服知识助手、信贷 memo assistant、分行 advisor copilot |
| Assessment date | 2026-Q3 maturity review |
| Business outcome focus | 降低 AML backlog、提高客服一次解决率、缩短信贷 memo 周期、提升分行合规查询质量 |
| Overall maturity | Level 2 Repeatable, with Platform and RiskOps moving toward Level 3 |
| Highest maturity domain | Strategy / Investment Mix: 已有 steering committee、场景清单和初步优先级 |
| Lowest maturity domain | EvalOps: 缺少统一 golden set、rubric、regression 和 release gate |
| Top three gaps | knowledge ownership、workflow integration、adoption measurement |
| Top three investments | model gateway MVP、AML /客服 eval repository、adoption dashboard |
| Decision requested | 批准 90 天 managed maturity uplift, 限制新增 POC, 聚焦两个 evidence pack |
Score table:
| Domain | Score 0-4 | Evidence | Gap | Next maturity increment | Owner |
|---|---|---|---|---|---|
| Strategy / Investment Mix | 2 | AI 场景清单、steering committee | 缺少 scale / stop 标准 | 建 funding gate 和 monthly value review | AI Transformation Lead |
| Data / Knowledge | 1 | 部分知识库和政策文档 | owner、lineage、freshness SLA 不清 | 建 RAG source register | Data / Knowledge Owner |
| Model / Platform | 2 | 两个模型供应商接入、基础日志 | gateway、fallback、cost SLO 不统一 | 建 model gateway MVP | Platform Lead |
| EvalOps | 1 | SME 试用反馈 | golden set 和 regression 缺失 | 建 AML /客服 eval pack | EvalOps Lead |
| RiskOps | 2 | 风险团队参与 pilot review | control evidence 格式不统一 | 建 risk tier 和 control library | Model Risk / Compliance |
| Integration | 1 | 独立工具试用 | 写回、审计、权限、rollback 缺失 | 做 workflow integration spike | Architect |
| Product / Adoption | 2 | 试点培训和用户反馈 | 经理节奏和收益证明不足 | 建 adoption dashboard | Product Ops + Operations |
| Talent / Operating Model | 2 | 少数核心专家推动 | RACI 和 role training 不完整 | 建 competency map 和季度复盘 | HR / AI Lead |
9.2 Capability Heatmap
| Capability | Business value | Risk exposure | Current maturity | Target maturity | Heat | Rationale |
|---|---|---|---|---|---|---|
| AI use case investment governance | High | Medium | 2 | 3 | Amber | 影响资源分配和停项决策 |
| Knowledge governance for RAG | High | High | 1 | 3 | Red | 多个场景依赖同一知识源, 且客户影响大 |
| EvalOps release gate | High | High | 1 | 3 | Red | 没有质量证据就不能规模化 |
| Model gateway and observability | Medium | High | 2 | 3 | Amber | 供应商和版本变化需要统一控制 |
| Workflow integration | High | Medium | 1 | 2 | Red | 复制粘贴阻碍采用和审计 |
| Role-based AI literacy | Medium | Medium | 2 | 3 | Amber | 一线使用边界不清会制造误用和抵触 |
| Benefits realization | High | Medium | 1 | 3 | Red | 没有 finance sign-off, 收益无法可信 |
Heat 解释:
| Heat | 含义 | 管理动作 |
|---|---|---|
| Red | 高价值或高风险, 当前成熟度明显不足 | 进入季度重点投资和管理层 review |
| Amber | 有进展但会限制 scale | 纳入 90 天改进计划 |
| Green | 当前能力足以支撑本阶段目标 | 监控趋势, 避免过度建设 |
9.3 Roadmap Dependency Map
| Roadmap Increment | Business Outcome | Depends On | Evidence Gate | Decision Owner | Risk if Delayed |
|---|---|---|---|---|---|
| AML copilot limited release | 降低 time-to-first-summary 和 QA rework | AML golden set、case audit trail、human review、risk acceptance | Eval pass、SME review、incident runbook、limited user cohort | Financial Crime Ops Head | Backlog 不降, POC 价值停留在 demo |
| Customer service assistant scale | 提高 first contact resolution 和知识一致性 | Knowledge owner、freshness SLA、groundedness eval、support model | Adoption > target、quality review pass、complaint signal stable | Customer Ops Head | 使用率波动, 一线不信任 |
| Model gateway MVP | 控制模型成本、权限、日志和 fallback | Vendor policy、architecture pattern、observability | Cost SLO、routing rule、version record、rollback test | Platform Lead | 多团队重复接入供应商 |
| Quarterly maturity review | 让 AI 成熟度进入管理节奏 | Scorecard、heatmap、benefits register、incident learning | Review pack complete、decision log signed | AI Steering Committee | 成熟度停留在一次性评估 |
9.4 Quarterly Maturity Review
Review 目标:
用同一套证据回答:
哪些能力成熟了?
哪些能力阻碍 scale?
哪些投资应继续、扩大、暂停或停止?
哪些控制需要改进?
哪些个人和团队能力需要升级?
建议议程:
| Time | Topic | Decision |
|---|---|---|
| 10 min | Investment maturity trend | 确认 overall level 和 domain movement |
| 15 min | Capability heatmap | 确认 Red / Amber capability 的投资顺序 |
| 20 min | Evidence review | 审核 eval、risk、adoption、benefits、incident 和 cost |
| 15 min | Roadmap dependency | 决定解 blocker、调整 WIP、合并重复项目 |
| 15 min | Scale / stop decisions | 批准 scale、限制范围、停止或转平台化 |
| 10 min | Talent and operating model | 确认 role gaps、training、RACI 和 forum 改进 |
| 5 min | Decision log | 记录 owner、deadline、下一次 review 输入 |
Decision log:
| Decision | Evidence Used | Owner | Effective Date | Follow-up Metric |
|---|---|---|---|---|
| AML copilot 进入 limited release | Eval pass、SME review、audit trail、risk acceptance | Financial Crime Ops | 2026-Q3 Sprint 4 | AHT、QA defect、escalation quality、incident count |
| 暂缓 credit memo customer-facing explanation | Data permission 和 model risk evidence 不足 | Credit Risk | 2026-Q3 | 完成 data permission map 和 eval set |
| 投资 model gateway MVP | 三个用例重复模型接入和日志需求 | Platform Lead | 2026-Q3 | Reuse count、cost per task、fallback success |
| 停止两个低采用 POC | 使用率低、无 business owner、无收益基线 | AI Investment Lead | 2026-Q3 | Freed capacity、reallocated budget |
10. 系统学习笔记：成熟度模型如何成为运营系统
10.1 成熟度评估必须服务管理决策
AI 成熟度不能看模型数量或 POC 数量, 而要看组织是否能稳定交付可采用、可评估、可治理、可复用的 AI 能力。评估要覆盖 strategy / investment mix、data / knowledge、model / platform、EvalOps、RiskOps、integration、product adoption 和 talent operating model。每个维度都必须有证据, 例如 eval gate、risk acceptance、adoption dashboard、benefits register 和 platform reuse map。成熟度最终要服务决策: 继续投、规模化、平台化、暂停或停止。
10.2 Evidence-based operating model
AI maturity model 应被设计成 evidence-based operating model, 而不是咨询式打分表。第一步是明确业务战略和 AI investment thesis, 然后建立 use case inventory 和 capability domains。第二步是按八个能力域评估成熟度: investment mix、data / knowledge、platform、EvalOps、RiskOps、integration、adoption 和 talent。第三步是用五级证据判断当前状态: ad hoc、repeatable、managed、scaled、optimized。
关键是每一级都要有证据门槛。Repeatable 说明至少有多个用例复用同一套 intake、baseline 和 pilot criteria; managed 说明有 investment review、release gate、risk acceptance、runbook 和 benefits register; scaled 说明平台能力、评估能力、风险控制和 adoption playbook 已经跨业务线复用。
在金融零售场景中, 成熟度要特别关注 AML、客服、信贷、反欺诈和分行运营。很多组织的问题不是没有模型, 而是知识治理、评估样本、风险授权、系统集成和 adoption cadence 不成熟。所以 roadmap 不能从“买更多工具”开始, 而要按 foundation、pilot evidence、platformization、governance scaling 和 product-line reuse 排序。这样成熟度评估会直接变成投资决策和组织能力建设。
10.3 Transformation governance and value realization
Maturity assessment 要连接到 investment governance 和 value realization。重点不是证明团队很忙, 而是让管理层看到哪些 AI 投资真正产生业务结果, 哪些能力阻碍规模化, 哪些风险需要控制, 哪些 POC 应该停止。
季度 maturity review 可以用 scorecard 看八个能力域, 用 heatmap 看高价值高风险能力缺口, 用 dependency map 看数据、平台、风险、集成和 change capacity 的瓶颈, 用 benefits register 看收益是否被 finance 和业务 owner 接受。最后输出 scale / stop / platformize / reallocate 决策。
这种方法的价值是把 AI 转型从“创新活动”变成“可治理的企业能力建设”。它能保护高价值创新, 也能及时停止低证据、低采用或高风险的项目。
10.4 Enterprise architecture and capability-based planning
AI maturity model 要接到 capability-based planning 和 architecture roadmap。核心问题不是单个 AI 系统能不能跑, 而是企业是否具备可复用的 model gateway、RAG pattern、EvalOps、RiskOps、observability、workflow integration、identity、audit trail 和 resilience capability。
TOGAF ADM 的思路可以把业务目标、能力差距、目标架构、迁移路线图和 implementation governance 串起来。成熟度评估会明确哪些能力应先建立 foundation, 哪些用例需要 pilot evidence, 哪些重复模式应进入 platform runway, 哪些 governance control 必须在 scale 前完成。
在金融零售中, 这尤其重要。AML copilot、客服助手、信贷 memo 和分行 advisor 看起来是四个产品, 但背后共享知识治理、评估、权限、审计、模型接入、人工监督和监控能力。成熟架构要把这些重复能力产品化, 同时用风险分层和证据门禁保证速度与控制并存。
10.5 防止成熟度评估形式主义
成熟度评估不能只做年度问卷或主观打分。每个成熟度结论都必须连接四件事: 证据、owner、决策和下一步投资。比如 EvalOps 不能只说“level 2”, 必须说明有哪些 golden set、哪些 release gate、哪些用例复用、哪些质量问题导致不能 scale。季度 review 结束时必须产生明确决策: fund、scale、pause、stop、platformize 或 improve control。没有决策的成熟度评估只是报告, 不是管理系统。
10.6 个人能力如何转化为组织转型能力
个人能力要连接组织成熟度, 不能停留在“学过很多 AI 概念”。Problem framing、workflow architecture、requirements-to-eval、risk control、investment governance、pilot evidence、adoption、benefits realization、reference architecture、platform reuse、release gate 和 roadmap dependency 都是可复盘的组织能力证据。真正的目标是把组织从 ad hoc 推到 repeatable、managed, 甚至 scaled。