AI Maturity Model：能力评估与路线图
AI 成熟度不是“上线了多少模型”或“有多少个实验项目”，而是组织能否稳定地把 AI 假设转化为可控业务结果。成熟度模型的价值在于把能力、证据、风险、投资节奏和组织行为放进同一个评估系统：哪些能力已经可复用，哪些能力仍依赖个人英雄主义，哪些能力一旦扩大规模就会引入不可接受的合规、运营或声誉风险。
AI Maturity Model / Roadmap / Capability Assessment 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_MATURITY_MODEL_ROADMAP_CAPABILITY_ASSESSMENT_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| CMMI Institute | https://cmmiinstitute.com/ | 参考 capability maturity、过程能力和持续改进语言 |
| 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、运营、绩效评价和持续改进 |
| TOGAF | https://www.opengroup.org/togaf | 参考架构开发、能力规划、路线图和治理思想 |
核心导读
AI 成熟度不是“上线了多少模型”或“有多少个实验项目”，而是组织能否稳定地把 AI 假设转化为可控业务结果。成熟度模型的价值在于把能力、证据、风险、投资节奏和组织行为放进同一个评估系统：哪些能力已经可复用，哪些能力仍依赖个人英雄主义，哪些能力一旦扩大规模就会引入不可接受的合规、运营或声誉风险。
对金融零售企业，成熟度评估必须回答一个更硬的问题：当 AI 触达客户、员工决策、信贷、营销、运营、客服和风控时，组织是否有足够的架构、治理、数据、评测和运营能力支撑“规模化而非偶发成功”。
问题定义
AI 转型常见失败不是技术不可用，而是成熟度错配：
- 业务想用 AI 改造核心流程，但数据 lineage、知识边界、权限、监控和追责机制仍停留在报表时代。
- 团队能做 demo，但不能证明回答正确率、业务收益、风险暴露、人工接管和模型变更影响。
- 平台提供模型 API，但没有形成可复用的评测、控制、证据、成本和安全能力。
- 治理团队要求审批，交付团队要求速度，双方没有一套共同的 capability map 和 maturity evidence。
因此成熟度模型要评估的不是“是否使用 AI”，而是组织在 AI 生命周期中的能力质量：
| 评估对象 | 成熟问题 |
|---|---|
| 战略与组合 | AI 投资是否绑定价值流、能力缺口和风险 appetite |
| 产品发现 | use case 是否有可测量假设、任务边界和 adoption 机制 |
| 数据与知识 | 数据、文档、语义和权限是否可被 AI 安全消费 |
| 平台工程 | 复用能力是否以服务目录、golden path 和 SLO 形式提供 |
| 评测与监控 | 是否有离线 eval、在线 telemetry、drift、incident 和改进闭环 |
| 控制与证据 | 控制是否嵌入交付流水线和运行时，而不是发布前补材料 |
| 组织与运营 | 责任、流程、技能和预算是否支持长期运营 |
核心原理与方法
成熟度模型要同时具备三种属性。
第一，能力分层。不要把“会提示词”“有向量库”“有模型网关”当作同一层能力。可使用 capability domain 拆解：
| Domain | 关键能力 |
|---|---|
| Value & Investment Governance | AI 机会筛选、收益假设、价值流指标、stop/scale 规则 |
| Product & Workflow | 任务分解、human-AI handoff、异常路径、业务采纳 |
| Data & Knowledge | 数据质量、知识治理、语义契约、provenance、retention |
| Platform & Engineering | 模型访问、RAG、工具调用、评测流水线、可观测性、成本控制 |
| Risk & Control | 风险分级、控制库、证据图、审计查询、事件响应 |
| Operating Model | 决策权、服务 ownership、技能体系、管理评审、持续改进 |
第二，等级不是口号，而是证据门槛。
| Level | 状态 | 证据标准 |
|---|---|---|
| L1 Fragmented | 零散实验 | 成功依赖个人经验，缺少统一日志、评测和控制 |
| L2 Repeatable | 可重复交付 | 有模板化交付路径，但跨团队复用和风险分级仍弱 |
| L3 Managed | 可管理 | 有服务目录、控制门、eval baseline、SLO 和运营责任 |
| L4 Measured | 可量化优化 | 投资、质量、风险、成本、采用率和业务结果可追踪 |
| L5 Adaptive | 自适应演进 | 架构、治理和产品组合能根据证据持续调整 |
第三，成熟度要支持路线图决策，而不是生成评分报告。评估结果必须转化为 sequencing：先补哪些平台能力，哪些 use case 可以放大，哪些必须暂停，哪些控制要前置。
系统与架构模型
AI 成熟度评估可以建成一个 enterprise capability assessment system：
Business Strategy / Risk Appetite
-> AI Capability Map
-> Maturity Evidence Model
-> Gap Analysis
-> Roadmap Sequencing
-> Funding / Governance Gates
-> Operating Metrics / Management Review
-> Capability Improvement Backlog
关键不是打分表，而是打分背后的架构对象：
| 架构对象 | 说明 |
|---|---|
| AI use case inventory | 每个 use case 的业务能力、风险等级、数据源、模型、工具、owner |
| Capability map | 从业务能力到 AI 平台能力、控制能力、运营能力的映射 |
| Evidence object | eval report、control test、incident record、model card、data lineage、approval record |
| Transition architecture | 从当前分散状态到目标平台化状态的阶段架构 |
| Roadmap dependency graph | use case 与数据、平台、控制、技能、供应商能力的依赖 |
成熟度路线图应分成三类 work package：
| Work package | 例子 | 决策意义 |
|---|---|---|
| Foundation | 模型网关、日志标准、知识库权限、eval harness | 不解决就无法规模化 |
| Product Scale | 客服 copilots、信贷解释、运营助手、营销内容审查 | 能直接验证业务收益 |
| Control Uplift | 模型风险验证、证据图、供应商退出、数据保留策略 | 降低规模化后的尾部风险 |
关键机制与取舍
成熟度模型最难的部分是处理真实取舍。
| 取舍 | 需要明确的判断 |
|---|---|
| 速度 vs 控制 | 低风险内部助手可走轻量门控，高风险客户决策必须有强 evidence gate |
| 中央平台 vs 业务自治 | 平台提供强约束能力，业务保留 workflow 和 adoption 设计权 |
| 统一标准 vs 场景差异 | 日志、证据、风险分级统一；eval case、业务指标、人工接管阈值按场景定制 |
| 技术成熟 vs 组织成熟 | 技术组件上线不代表组织具备 incident、ownership、cost 和 change management |
| ROI vs 风险减少 | 部分基础能力不直接产生收入，但决定是否能在监管和运营压力下持续运行 |
成熟度路线图不能只按价值排序，还要按依赖和风险排序：
- 先建立 AI inventory、风险分级和最低日志证据标准。
- 再建设可复用的 RAG、tool calling、评测、监控和模型访问能力。
- 选择 2-3 个高价值但风险可控的价值流验证 adoption 与收益。
- 对高风险场景补足独立验证、监管证据、人工监督和退出方案。
- 用季度 management review 更新成熟度评分和投资组合。
证据与控制
成熟度评估要避免主观评分，必须定义 evidence rubric。
| 能力 | 低质量证据 | 高质量证据 |
|---|---|---|
| 价值管理 | “业务反馈不错” | baseline、目标、收益归因、采用率、成本和 stop/scale 规则 |
| 评测 | 一次性测试截图 | 固定 eval suite、版本记录、失败分类、阈值和回归趋势 |
| 数据治理 | 文档上传列表 | provenance、权限继承、质量规则、retention 和删除证明 |
| 风险控制 | 审批邮件 | control objective、control activity、test result、owner、exception |
| 运营 | 项目上线公告 | SLO、incident、人工接管、drift、成本、用户反馈闭环 |
可以用以下评估矩阵把成熟度与控制连接：
| Domain | Capability | Maturity Level | Required Evidence | Gap | Roadmap Action |
|---|---|---|---|---|---|
| Platform | Prompt/tool trace | L2 | trace schema、log retention、PII masking test | 缺统一 trace id | 建模型网关日志标准 |
| Risk | High-risk validation | L1 | independent validation plan、challenge findings | 无独立挑战 | 建 validation gate |
| Data | Knowledge provenance | L2 | source id、owner、freshness、access rule | 删除链路不完整 | 建 provenance graph |
| Value | Adoption measurement | L2 | active users、task completion、override reason | 缺收益归因 | 建 value stream dashboard |
成熟度报告的输出不应是“整体 3.2 分”，而应是“哪些能力已经允许规模化，哪些能力只能支持实验，哪些能力正在阻塞高风险场景上线”。
AI 产品与金融零售场景
以金融零售银行建设客户服务 AI、信贷解释 AI 和运营知识助手为例，成熟度评估可以形成三阶段路线图。
| 阶段 | 业务重点 | 架构重点 | 治理重点 |
|---|---|---|---|
| Phase 1 | 内部知识助手和客服坐席辅助 | 模型网关、RAG 基线、日志、知识库权限 | use case inventory、低风险门控、人工反馈 |
| Phase 2 | 客户服务回答、投诉摘要、营销合规初审 | eval suite、在线监控、人工接管、内容策略 | 控制库、证据图、incident playbook |
| Phase 3 | 信贷解释、个性化建议、跨渠道智能服务 | 语义层、决策服务隔离、独立验证、模型切换 | 高风险评审、监管问询包、持续管理评审 |
真正的成熟路线不是“所有场景一起推进”，而是根据能力缺口分流：
- 内部效率场景用于验证平台复用、知识治理和成本模型。
- 客户交互场景用于验证内容安全、人工接管、投诉处理和品牌风险。
- 决策影响场景用于验证模型风险、解释证据、审计追踪和合规义务。
反模式
- 把成熟度等同于 AI 项目数量，导致组合膨胀但平台和治理能力没有复利。
- 只评估技术栈，不评估数据、流程、人工责任、控制和运营能力。
- 用平均分掩盖关键能力短板，例如没有独立验证却推进高风险场景。
- 路线图只列 use case，不列 foundation 和 control uplift。
- 成熟度评估只做年度报告，没有连接 funding、architecture review 和 management review。
- 把成熟度模型设计得过细，最后无法被业务和技术团队实际使用。
最终心智模型
AI 成熟度模型是一套投资和治理系统：用 capability map 描述组织能做什么，用 evidence rubric 证明能力是否真实存在，用 maturity gap 决定路线图顺序，用 management review 推动持续改进。成熟组织不是“AI 项目更多”，而是能在价值、速度、风险、成本和控制之间做可解释、可复盘、可审计的组合决策。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。