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
定位: 面向 AI BA、AI PM、AI Architect、AI Transformation Lead、Enterprise Architect 和金融零售 AI 转型负责人, 把 AI maturity model、capability assessment、roadmap sequencing、portfolio 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. One-Sentence Positioning
AI Maturity Model 是一套把 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 CBAP 之后的升级重点
你已经是 CBAP, 不需要再证明成熟度模型、需求分析或 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 / Portfolio | AI 投资是否服务明确战略, 并通过组合治理决定 fund / scale / stop | AI investment thesis、portfolio 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 / RBAC、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 / Portfolio | 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 portfolio、release gate、risk control、platform pattern 和 adoption 指标进入管理节奏 | 有 portfolio 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 强, portfolio 弱 | 很多团队能做 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、风险和平台容量要在同一张图上 | portfolio review 中用 dependency map 决定顺序和 WIP limit |
6.3 Portfolio 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 纳入 portfolio allocation |
6.4 Operating Cadence
成熟度不是年度评估报告, 而是固定节奏下的证据更新。
| Cadence | 参与者 | 输入 | 输出 |
|---|---|---|---|
| Weekly intake triage | AI PM、BA lead、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 portfolio 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. Individual Capability Map
个人成长和组织成熟度要用同一套证据语言连接。目标不是说自己“懂 AI”, 而是证明自己能让组织从低成熟度走向可管理、可扩展和可持续改进。
7.1 AI BA 能力升级
| 成长阶段 | 你要证明什么 | 作品集证据 |
|---|---|---|
| Level 1 -> 2 | 能把模糊 AI 想法转成业务问题、流程、用户、baseline 和试点标准 | problem memo、AS-IS / TO-BE、baseline table、pilot criteria |
| Level 2 -> 3 | 能把需求转成 eval、risk、adoption 和 release evidence | requirements-to-eval matrix、risk control checklist、acceptance criteria、UAT + SME review pack |
| 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 |
AI BA 面试信号:
我不是只把 AI 需求写成 user story, 而是把业务问题转成可评估、可治理、可采用的证据链: baseline、workflow、eval、risk、adoption、owner 和 stop rule 都要清楚。
7.2 AI PM 能力升级
| 成长阶段 | 你要证明什么 | 作品集证据 |
|---|---|---|
| Level 1 -> 2 | 能定义 MVP、目标用户、use case scope 和成功指标 | AI PRD、opportunity canvas、MVP scope、success metric |
| Level 2 -> 3 | 能管理 pilot 到 release 的价值、风险、成本和采用 | pilot report、release gate memo、benefits register、adoption dashboard |
| Level 3 -> 4 | 能把多个产品用例连接到平台能力和 portfolio funding | portfolio kanban、platform reuse map、funding memo、scale / stop decision |
| Level 4 -> 5 | 能持续优化投资组合, 淘汰低价值能力, 推动产品线复用 | quarterly portfolio review、unit economics trend、retirement record、product-line reuse roadmap |
AI PM 面试信号:
我会把 AI 产品当作一个 evidence-driven investment。每个阶段都要回答是否值得继续投、是否可控、是否被采用、是否能复用平台能力, 而不是默认从 POC 推到上线。
7.3 AI Architect 能力升级
| 成长阶段 | 你要证明什么 | 作品集证据 |
|---|---|---|
| Level 1 -> 2 | 能画出单个 AI solution 的组件、数据流、权限和风险边界 | C4 diagram、sequence diagram、data flow、threat / risk notes |
| Level 2 -> 3 | 能建立 reference architecture、release gate 和 observability 设计 | ADR、reference pattern、monitoring design、rollback plan、architecture review pack |
| Level 3 -> 4 | 能推动 model gateway、RAG、EvalOps、RiskOps 和 integration pattern 的平台化 | platform capability map、reuse metrics、control architecture、cost / latency SLO |
| Level 4 -> 5 | 能把架构演进纳入企业路线图和管理评审 | architecture roadmap、technical debt register、resilience review、strategic reallocation memo |
AI Architect 面试信号:
我会把 AI 架构从单点系统设计提升到企业能力设计: 哪些能力应该产品化、哪些控制必须平台化、哪些风险要前置、哪些依赖会决定路线图顺序。
7.4 个人作品集如何连接组织成熟度
| 组织成熟度问题 | 个人可展示资产 | 说明 |
|---|---|---|
| 没有统一 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 / Portfolio | 2 | 有 AI steering committee 和场景清单, 但 funding gate 不稳定 | 没有统一 scale / stop 标准 | 建 portfolio 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 和少数专家, 角色能力未成体系 | BA、PM、Architect、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 和 portfolio 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 + AI PM + Architect |
| 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 PM |
| 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 portfolio: 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 / Portfolio: 已有 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 / Portfolio | 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 | AI PM + Ops |
| 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 portfolio 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 | Portfolio 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 Portfolio Lead | 2026-Q3 | Freed capacity、reallocated budget |
10. Interview Answers
10.1 30 秒版本
我衡量 AI 成熟度不会看模型数量或 POC 数量, 而会看组织是否能稳定交付可采用、可评估、可治理、可复用的 AI 能力。我的评估会覆盖 strategy / portfolio、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 2 分钟版本
我会把 AI maturity model 设计成 evidence-based operating model, 而不是咨询式打分表。第一步是明确业务战略和 AI investment thesis, 然后建立 use case inventory 和 capability domains。第二步是按八个能力域评估成熟度: portfolio、data / knowledge、platform、EvalOps、RiskOps、integration、adoption 和 talent。第三步是用五级证据判断当前状态: ad hoc、repeatable、managed、scaled、optimized。
关键是每一级都要有证据门槛。比如 repeatable 说明至少有多个用例复用同一套 intake、baseline 和 pilot criteria; managed 说明有 portfolio 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 Lead 版本
作为 Transformation Lead, 我会把 maturity assessment 连接到 portfolio 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 Architect 版本
作为 Enterprise Architect, 我会把 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 不能只说“2 分”, 必须说明有哪些 golden set、哪些 release gate、哪些用例复用、哪些质量问题导致不能 scale。季度 review 结束时必须产生明确决策: fund、scale、pause、stop、platformize 或 improve control。没有决策的成熟度评估只是报告, 不是管理系统。
10.6 追问: 如何把个人成长讲成组织转型能力?
我会用作品集证据连接个人能力和组织成熟度。AI BA 展示 problem framing、workflow、requirements-to-eval 和 risk control; AI PM 展示 portfolio、pilot evidence、adoption 和 benefits realization; AI Architect 展示 reference architecture、platform reuse、release gate 和 roadmap dependency。这样面试官看到的不是“我学过很多 AI 概念”, 而是我能把组织从 ad hoc 推到 repeatable、managed, 甚至 scaled 的具体证据。