AI 扩展计划 / Playbooks
AI Transformation Value Office Playbook
本手册补齐的是 portfolio governance 层。已有文档分别解决高管沟通、平台产品、能力评估和董事会治理, 本文件把它们连接成一个企业级 AI 投资组合运营系统。
843 行AI_TRANSFORMATION_VALUE_OFFICE_PLAYBOOK.md
AI Transformation Value Office / Portfolio Governance Playbook
目标: 训练从 AI PM / BA / Architect 升级到能管理企业 AI 投资组合、价值实现、采用、成本、风险和停项决策的能力。 适用对象: AI PM Lead、AI Transformation Consultant、Enterprise Architect、AI Portfolio Lead、AI Governance PM。 核心原则: 企业 AI 转型不是不断启动 POC, 而是用可审计的 portfolio operating model 把资金投向能被采用、能复用、能控制风险、能证明收益的 AI 能力。
1. 定位与相邻资产连接
本手册补齐的是 portfolio governance 层。已有文档分别解决高管沟通、平台产品、能力评估和董事会治理, 本文件把它们连接成一个企业级 AI 投资组合运营系统。
| 连接文档 | 已解决的问题 | 本手册如何承接 |
|---|---|---|
docs/AI_EXECUTIVE_COMMUNICATION_MEMO_PACK.md | 单个 use case 如何向高管讲清 decision、ROI、risk、stop rule | 把多个 memo 汇总为 monthly exec dashboard、funding gate、scale/stop decision |
docs/AI_PLATFORM_PM_PLAYBOOK.md | 如何把 model gateway、RAG、eval、cost、audit 等做成共享平台能力 | 判断哪些项目应复用平台、哪些能力值得平台化、平台成本如何分摊到 portfolio |
docs/AI_CAPABILITY_ASSESSMENT_RUBRIC.md | 如何证明 AI BA / PM / Architect 能力 | 增加 portfolio-level artifact: backlog、benefits register、dependency map、decision log |
docs/AI_BOARD_AUDIT_COMMITTEE_GOVERNANCE_PACK.md | 董事会/审计委员会如何监督 material AI systems | 把 board oversight 落到日常 intake、risk gate、benefits proof、kill/scale governance |
一句话定位:
AI Value Office = Enterprise AI use case portfolio + funding gates + benefit realization + risk gates + platform reuse + change adoption + kill/scale decisions.
它不是传统 PMO 的 AI 版本。PMO 常问“项目是否按计划交付”, AI Value Office 必须问:
这个 AI use case 是否还值得投?
真实业务基线是什么?
收益是否被 finance 认可?
风险是否被 risk owner 接受?
用户是否真的采用?
能否复用平台能力?
单位成本是否随规模下降?
什么时候停止、继续 pilot、规模化或平台化?
2. AI Value Office 概念
2.1 从 PMO 到 Value Office
| 维度 | Traditional PMO | AI Transformation Value Office |
|---|---|---|
| 管理对象 | 项目计划、资源、里程碑 | AI use case portfolio、平台能力、风险暴露、收益证据 |
| 资金逻辑 | 年度预算分配 | 分阶段 funding gate: discovery、pilot、release、scale |
| 成功定义 | on time / on budget | adopted、valuable、safe、auditable、reusable、economically scalable |
| 风险管理 | 项目风险登记册 | AI risk tier、model/data/control evidence、regulatory sensitivity、stop rules |
| 平台关系 | 项目各自交付 | 重复能力沉淀到 model gateway、RAG、eval、observability、cost、audit |
| 价值证明 | business case 估算 | baseline、target、leading/lagging indicators、finance sign-off |
| 采用管理 | 培训与上线通知 | workflow redesign、manager cadence、usage proof、quality proof、behavior change |
| 停项机制 | 项目延期或预算耗尽后再讨论 | gate 前置: POC 不达证据即停止, 达到复用阈值即平台化 |
2.2 Value Office 的七个职责
| 职责 | 关键问题 | 典型产物 |
|---|---|---|
| Use case portfolio | 哪些 AI 机会进入组合, 哪些只是想法 | AI Portfolio Kanban、intake form、portfolio backlog |
| Funding gate | 每个阶段批准多少钱、多久、谁负责 | Funding memo、stage gate decision |
| Benefits realization | 收益如何定义、测量、归因、签字 | Benefits register、baseline model、finance sign-off |
| Risk gate | 哪些 use case 需要更强控制或委员会批准 | Risk tier、control evidence、release gate |
| Platform reuse | 哪些能力复用, 哪些经验沉淀为平台 | Reuse map、platform capability backlog |
| Change adoption | 业务流程是否真的改变 | Adoption dashboard、training and manager cadence |
| Kill / scale decision | 停止、继续、规模化、平台化的证据是什么 | Scale/Stop memo、decision log |
2.3 Value Office 不做什么
| 不做 | 原因 | 正确边界 |
|---|---|---|
| 不替业务 owner 承诺收益 | 收益必须由业务流程 owner 承担 | Value Office 提供 measurement discipline 和 challenge |
| 不替 risk owner 接受风险 | 风险接受必须在治理授权内完成 | Value Office 确保 evidence、gate、residual risk 清楚 |
| 不把所有 POC 都推进成产品 | AI POC 天然高不确定 | Value Office 要有停止权和资源再分配机制 |
| 不把平台当成万能解法 | 平台化需要复用证据 | 先看 reuse potential、cost-to-serve、control leverage |
| 不用模型指标替代业务指标 | accuracy 不能自动变成收益 | 必须连接 workflow、adoption、quality、unit economics |
3. Operating Model
3.1 生命周期
| Stage | 目标 | 入口条件 | 核心动作 | 出口证据 | 典型决策 |
|---|---|---|---|---|---|
| Intake | 收集 AI 机会并去重 | 有业务 owner、流程、问题陈述 | 记录 pain point、scope、data source、risk signal | 完整 intake card | reject、merge、enter prioritization |
| Prioritization | 排出 portfolio 优先级 | intake card 完成 | scoring、capacity check、strategic fit review | ranked backlog | fund discovery、park、reject |
| Discovery | 证明问题值得做 | business sponsor 承诺参与 | AS-IS/TO-BE、baseline、data readiness、risk tier、no-AI option | discovery memo | fund pilot、stop、return to business process redesign |
| Pilot | 证明可行且可控 | pilot funding + gate criteria | eval set、architecture spike、workflow trial、control design、adoption trial | pilot report | continue pilot、release candidate、stop |
| Release | 生产上线并受控运行 | quality/risk/adoption/cost gate 通过 | runbook、monitoring、incident path、training、release gate | release pack | approve limited release、delay、stop |
| Scale | 扩展到更多用户、流程、区域 | limited release 证明收益和风险可控 | scale economics、change management、support model、platform reuse | scale memo | scale、platformize、cap expansion |
| Retire | 停止低价值或高风险能力 | 触发 stop rule 或收益衰减 | migration、data retention、vendor exit、lessons learned | retirement record | retire、replace、merge |
3.2 Stage Gate Cadence
| Gate | 会议节奏 | 参与者 | 决策材料 | 决策输出 |
|---|---|---|---|---|
| Weekly intake triage | 每周 30-45 分钟 | AI PM lead、BA lead、platform、risk liaison | Intake cards、duplicate map | reject / merge / score |
| Portfolio prioritization | 双周 | Business sponsors、finance、risk、architecture、platform | Scoring matrix、capacity view | funded discovery list |
| Pilot gate | 每 4-6 周 | Business owner、AI PM、BA、architect、data owner、risk、finance | Discovery memo、baseline、risk tier、pilot budget | pilot approve / stop |
| Release gate | 每次生产发布前 | AI governance、ops、platform、risk、business owner | Eval report、control evidence、runbook、rollback | release / delay / reject |
| Monthly value review | 每月 | CFO delegate、COO delegate、CIO/CTO delegate、AI Value Office | Exec dashboard、benefits register、cost report | scale / stop / reallocate |
| Quarterly portfolio review | 每季度 | Executive sponsors、risk committee liaison、platform lead | Portfolio health、material risk、investment options | strategic rebalancing |
3.3 RACI
R = Responsible, A = Accountable, C = Consulted, I = Informed.
| Activity | Business owner | AI PM | BA | Architect | Data owner | Risk | Finance | Platform | Ops |
|---|---|---|---|---|---|---|---|---|---|
| Intake problem statement | A | R | R | C | C | I | I | I | C |
| Portfolio scoring | A | R | R | C | C | C | C | C | I |
| Baseline and value hypothesis | A | R | R | I | C | I | C | I | C |
| Data readiness assessment | C | C | R | C | A | C | I | C | I |
| Architecture option and reuse map | C | C | I | A/R | C | C | I | C | C |
| Risk tier and controls | C | C | R | C | C | A/R | I | C | C |
| Funding memo | A | R | C | C | C | C | A/R | C | C |
| Pilot delivery | A | R | R | R | R | C | I | R | C |
| Eval and release evidence | A | R | R | R | C | C | I | R | C |
| Adoption plan | A | R | R | I | I | I | I | I | R |
| Benefits sign-off | A | R | C | I | I | I | A/R | I | C |
| Scale/stop decision | A | R | C | C | C | C | A/R | C | C |
| Retirement and lessons learned | A | R | R | C | C | C | C | C | R |
3.4 Operating Forums
| Forum | 问题焦点 | 好输出 | 坏信号 |
|---|---|---|---|
| Intake clinic | 这是业务问题还是技术愿望 | intake card 被合并、拒绝或进入 scoring | “先做 demo 看看”但无人承诺流程和数据 |
| Data and workflow clinic | baseline、数据、流程是否能支撑 pilot | AS-IS/TO-BE、data readiness、exception list | 只说有文档、有数据, 没 owner 和质量证据 |
| Architecture/risk gate | 能否可控上线 | risk tier、control map、C4、runbook | POC 代码直接推生产, 无审计和回滚 |
| Value review | 收益是否真实、可归因、可扩张 | benefits register 更新, finance challenge closed | 只报节省小时数, 无 adoption 和质量证明 |
| Platform reuse council | 哪些能力值得平台化 | reuse backlog、chargeback model、reference architecture | 每个项目都重做 RAG、eval、logging |
4. Portfolio Scoring
4.1 Scoring Principles
评分不是为了伪精确, 而是让 portfolio 决策透明。每个 use case 都要把价值、可行性、风险、复用和采用压力放在同一张表里比较。
推荐 1-5 分制:
| 分数 | 含义 |
|---|---|
| 1 | 弱或不清楚, 证据不足 |
| 2 | 有方向, 但依赖强假设 |
| 3 | 中等, 有部分证据 |
| 4 | 强, 有可验证证据 |
| 5 | 非常强, 已有可靠数据或历史证明 |
风险类维度采用反向解释: risk tier、regulatory sensitivity、adoption burden、cost-to-serve 分数越高代表负担越高。最终 scoring 要同时看 value score 和 constraint score, 不要把高风险高价值项目伪装成低风险。
4.2 Dimension Definitions
| Dimension | 问什么 | 评分证据 | 常见误判 |
|---|---|---|---|
| Strategic fit | 是否支持企业战略、监管承诺、核心能力 | strategy map、OKR、board priority | 把“热门技术”当战略 |
| Value size | 经济价值或风险价值有多大 | volume、cost、loss、revenue、risk exposure | 只算人工节省, 不算审核和运营成本 |
| Feasibility | 技术和流程是否可交付 | architecture spike、workflow complexity、integration map | demo 可跑就算可行 |
| Data readiness | 数据是否可用、可信、授权、可更新 | source owner、quality score、freshness、access | 有数据仓库就算 ready |
| Risk tier | 对客户、资金、合规、隐私影响多大 | autonomy level、materiality、reversibility | “human review” 被当成万能降风险 |
| Reuse potential | 是否能复用或沉淀平台能力 | shared pattern、common data、tool/API reuse | 过早抽象成平台 |
| Time-to-value | 多快能证明价值 | baseline availability、pilot scope、user access | 把上线时间当价值时间 |
| Cost-to-serve | 规模化单位成本和支持成本 | token/license、infra、support、review、QA | 只看模型调用成本 |
| Adoption burden | 需要多大行为改变 | process change、training、manager incentives | 完成培训就算 adoption |
| Regulatory sensitivity | 是否触及监管、审计、模型风险要求 | jurisdiction、policy mapping、customer impact | 内部工具就认为无监管风险 |
4.3 Recommended Weighting
| Dimension | Weight | Direction | 解释 |
|---|---|---|---|
| Strategic fit | 12% | higher is better | 不服务战略的 AI 项目很难获得持续 adoption |
| Value size | 18% | higher is better | portfolio 必须把资金投向大问题 |
| Feasibility | 12% | higher is better | 可交付性决定是否进入 pilot |
| Data readiness | 10% | higher is better | 数据不 ready 会拖垮 eval、risk 和 value proof |
| Reuse potential | 8% | higher is better | 可复用项目优先获得平台支持 |
| Time-to-value | 8% | higher is better | 快速证明价值能提高资金周转 |
| Risk tier | 10% | lower is better | 高风险不等于不做, 但必须有更强 gate |
| Cost-to-serve | 8% | lower is better | 单位经济不成立时不要规模化 |
| Adoption burden | 8% | lower is better | 高 adoption burden 需要 change investment |
| Regulatory sensitivity | 6% | lower is better | 敏感场景需要更强 oversight |
Portfolio view 建议把 use case 放入四象限:
| Quadrant | 特征 | 投资策略 |
|---|---|---|
| Scale now | 高价值、高可行、证据强、风险可控 | 优先资金、扩大用户、沉淀 reusable pattern |
| Controlled bet | 高价值, 但风险/数据/采用约束强 | 小额分阶段 funding, 强 gate, 明确 stop rule |
| Platform candidate | 单个收益中等, 复用潜力高 | 与平台 backlog 绑定, 用 2-3 个 use case 验证 |
| Stop or park | 价值弱、证据弱、约束强 | 停止、合并、回到流程优化或等待数据成熟 |
4.4 金融零售组合示例
| Use case | Strategic fit | Value size | Feasibility | Data readiness | Risk tier | Reuse potential | Time-to-value | Cost-to-serve | Adoption burden | Regulatory sensitivity | Portfolio view |
|---|---|---|---|---|---|---|---|---|---|---|---|
| AML/KYC investigator copilot | 5 | 5 | 3 | 3 | 5 | 4 | 3 | 3 | 3 | 5 | Controlled bet |
| Customer service policy RAG | 4 | 4 | 4 | 4 | 3 | 5 | 4 | 2 | 3 | 3 | Scale now / platform pattern |
| Credit policy assistant | 5 | 4 | 3 | 3 | 5 | 4 | 3 | 3 | 4 | 5 | Controlled bet |
| Payment dispute triage | 4 | 4 | 4 | 4 | 4 | 3 | 4 | 2 | 3 | 4 | Scale after control proof |
| Fraud alert prioritization | 5 | 5 | 3 | 4 | 5 | 3 | 3 | 3 | 4 | 5 | Controlled bet |
| Merchant risk review copilot | 4 | 4 | 3 | 3 | 4 | 4 | 3 | 3 | 3 | 4 | Pilot candidate |
| Wealth advisor compliance guardrail | 5 | 4 | 3 | 3 | 5 | 3 | 2 | 3 | 4 | 5 | Controlled bet |
| Retail inventory demand insight | 3 | 4 | 4 | 4 | 2 | 3 | 4 | 2 | 3 | 2 | Scale now |
| Regulatory reporting assistant | 5 | 3 | 3 | 3 | 5 | 4 | 2 | 3 | 3 | 5 | Controlled bet |
| AI platform capabilities | 5 | 4 | 4 | 4 | 4 | 5 | 3 | 3 | 2 | 4 | Platform candidate |
5. Benefits Realization
5.1 Value Chain
AI 收益必须经过一条完整证据链:
Baseline -> Target -> Pilot evidence -> Adoption proof -> Quality proof -> Risk proof -> Unit economics -> Finance sign-off -> Scale decision
如果缺少 adoption proof, 模型质量不会变成收益。如果缺少 quality proof, 效率提升可能只是把风险推给客户或监管。如果缺少 finance sign-off, portfolio review 会变成自说自话。
5.2 Baseline
Baseline 是 benefits realization 的起点, 不是事后补表。每个 use case 至少记录:
| Baseline type | 指标示例 | 数据来源 | Owner |
|---|---|---|---|
| Volume | 每月 case、alert、call、claim、transaction 数 | workflow system、CRM、case management | Business owner |
| Cycle time | AHT、time-to-summary、time-to-decision、queue age | ops dashboard、process mining | Ops |
| Cost | labor cost、vendor cost、rework cost、infra cost | finance model、capacity plan | Finance |
| Quality | error rate、QA fail、complaint、reopen、appeal overturn | QA system、complaint system | Business / Risk |
| Risk | false negative、policy breach、audit finding、control gap | risk system、audit finding | Risk |
| Experience | CSAT、NPS、employee effort、merchant/client friction | survey、VOC、EX survey | Business owner |
弱 baseline:
客服很忙, AI 可以节省时间。
强 baseline:
过去 3 个月每月平均 42,000 个政策咨询 case, 平均处理时间 13.8 分钟, QA fail 率 7.2%, 其中 38% 失败来自政策引用错误或遗漏。目标 first pilot 只覆盖 8 个高频政策主题, 不处理投诉赔付承诺。
5.3 Target
Target 必须同时包含 value、quality、risk、adoption、cost:
| Target class | 示例 |
|---|---|
| Value target | 可辅助 case 的平均处理时间从 13.8 分钟降到 10.5 分钟 |
| Quality target | unsupported claim rate 低于 3%, source citation completeness 高于 98% |
| Risk target | high-risk topic 必须 100% supervisor approval, stale policy hit 低于 1% |
| Adoption target | 目标用户中 70% 每周使用 3 次以上, manager review cadence 每周执行 |
| Cost target | all-in cost per assisted case 低于 0.45 美元, p95 latency 低于 6 秒 |
5.4 Leading and Lagging Indicators
| Indicator type | 用途 | 金融零售例子 |
|---|---|---|
| Leading indicator | 提前判断是否会产生收益 | weekly active users、suggestion acceptance、citation click、override reason quality |
| Lagging indicator | 证明最终业务结果 | cost per case、loss reduction、QA fail reduction、complaint reduction、revenue lift |
| Guardrail indicator | 防止收益以风险为代价 | false negative sample、policy breach、bias metric、audit completeness、incident count |
| Learning indicator | 判断系统是否持续改进 | feedback closure time、eval regression、prompt/model version performance |
5.5 Unit Economics
AI portfolio 不能只报总收益, 必须看单位经济:
Net value per unit =
gross benefit per unit
- model/token cost
- platform cost allocation
- license cost
- human review cost
- QA/control cost
- support and change cost
- incident/risk reserve where material
| Use case | Unit | Gross benefit | Cost-to-serve | Net value signal | |---|---|---|---| | Customer service RAG | assisted case | 节省处理时间、降低 QA rework | token、RAG、license、supervisor review | 只有当 suggestion acceptance 和 quality gate 同时达标才成立 | | AML copilot | alert review | 缩短 evidence gathering、降低 rework | retrieval、case integration、senior review、audit sampling | 不能用减少 SAR/STR 数量作为直接收益 | | Fraud prioritization | alert / transaction | 提升 fraud capture、降低 false positive handling | real-time latency、model monitoring、appeal support | 必须同时看 fraud loss 和客户误拦截 | | Inventory insight | SKU-store-week | 降低缺货和库存积压 | demand model、planner review、integration | 更适合快速规模化, 但要防止推荐无人采用 |
5.6 Adoption Proof
Adoption proof 不是登录次数。它要证明用户行为和管理节奏改变了。
| 证据 | 好例子 | 不充分例子 |
|---|---|---|
| Usage depth | 70% 目标用户每周处理 10 个以上真实 case | 200 人参加培训 |
| Workflow integration | AI 建议进入 case record, override reason 结构化记录 | 打开一个独立聊天窗口 |
| Manager cadence | 主管每周 review 低信任、override、异常案例 | 上线邮件告知 |
| SOP change | 新 SOP 明确哪些建议可用、哪些必须升级 | 用户自行判断 |
| Behavior delta | 查找知识时间下降, QA rework 下降 | 用户反馈“感觉有帮助” |
5.7 Quality Proof
| 质量维度 | 证明方式 | Gate 示例 |
|---|---|---|
| Task success | golden set + production sample | task success >= 85% |
| Groundedness | source citation and claim check | unsupported claim rate < 3% |
| Red-flag recall | 专家标注高风险场景 | red-flag recall >= 95% |
| Human override | override reason 分析 | high-risk override reviewed weekly |
| Regression | 每次 prompt/model 变更回归测试 | no critical regression before release |
5.8 Risk Reduction Proof
不是所有 AI use case 都是“效率提升”。很多金融零售场景的价值来自风险降低。
| 风险收益 | 证明方式 | 例子 |
|---|---|---|
| 漏报降低 | 专家抽样、false negative review | AML red flag 被更早提示 |
| 错误承诺降低 | unsupported claim、stale source hit | 客服不再引用过期费用政策 |
| 审计证据增强 | audit log completeness | regulatory reporting assistant 保留 source、version、reviewer |
| 控制一致性提升 | exception rate、policy adherence | wealth advisor guardrail 阻断不适配建议 |
| 操作韧性提升 | incident response time、rollback time | model degradation 后 15 分钟切换 fallback |
5.9 Finance Sign-off
Finance sign-off 不是让财务背书技术方案, 而是确认收益计算口径可以进入企业投资组合决策。
| Sign-off item | Finance 要确认什么 |
|---|---|
| Baseline validity | volume、cost、capacity 是否来自可信系统 |
| Benefit type | 是 hard saving、cost avoidance、risk reduction、revenue uplift 还是 productivity capacity |
| Attribution | 收益是否能合理归因到 AI + process change |
| Cost completeness | 是否包含 license、infra、review、support、change、risk/control 成本 |
| Realization timing | 收益何时进入 P&L、预算、capacity plan 或 risk report |
| Confidence level | conservative/base/upside 三档假设是否清楚 |
6. 金融零售 AI Portfolio Map
6.1 Use Case Grouping
| Domain | Use case | Value hypothesis | Primary risk | Platform reuse |
|---|---|---|---|---|
| AML/KYC | Investigator copilot、KYC refresh assistant、EDD evidence retrieval | 降低 evidence gathering 时间, 提高 narrative consistency | 漏报、错误引用、监管证据不足 | RAG、case summarization、audit log、red-flag eval |
| Customer service | Policy RAG、complaint triage、agent assist | 降低 AHT、QA rework、投诉升级 | 错误承诺、隐私泄露、stale policy | knowledge ingestion、citation、supervisor approval |
| Credit | Credit policy assistant、document completeness review、underwriter copilot | 提升资料审查效率和政策一致性 | fair lending、解释不足、模型风险 | policy retrieval、decision support guardrails |
| Payment disputes | Chargeback triage、evidence pack draft、merchant response assistant | 缩短争议处理周期, 提高证据完整性 | 错误拒赔、客户体验、卡组织规则误用 | workflow summarization、document extraction |
| Fraud | Alert prioritization、case summary、appeal analysis | 提升 fraud capture, 降低 false positive handling | 漏放欺诈、误拦客户、实时延迟 | feature store、monitoring、human approval |
| Merchant risk | Onboarding review、ongoing monitoring、risk narrative | 缩短商户审核, 提升异常识别 | 不当准入、歧视、公平性、合规 | KYC/RAG、risk scoring support、audit evidence |
| Wealth | Advisor compliance guardrail、suitability check、portfolio explanation assistant | 降低合规返工, 提升顾问质量 | 不当建议、suitability breach、客户损失 | policy guardrails、approved product universe |
| Retail inventory | Demand insight、promotion forecast、store replenishment assistant | 降低缺货和库存积压 | 预测错误、门店不采用 | forecasting integration、planner workflow |
| Compliance reporting | Regulatory change monitor、report drafting assistant、evidence binder | 提升报送一致性和审计可追溯 | 错报、漏报、版本错误 | source control、approval workflow、audit trail |
| AI platform capability | Model gateway、RAG service、eval harness、cost dashboard、prompt registry | 降低重复建设, 统一治理和成本 | 平台故障、权限、shadow AI、成本失控 | 作为其他 use case 的 enabling capability |
6.2 Portfolio Balance
强 portfolio 不能全是客服 chatbot, 也不能全是高风险信贷和 AML。建议保持四类资产平衡:
| Portfolio bucket | 比例建议 | 目标 |
|---|---|---|
| Quick value | 25-35% | 低到中风险, 3 个月内证明 adoption 和收益 |
| Strategic risk/value | 25-35% | AML、fraud、credit、wealth 等高价值高治理场景 |
| Platform enablers | 20-30% | model gateway、RAG、eval、observability、cost、audit |
| Options and learning | 10-15% | 新型 agent、multimodal、advanced analytics, 小额受控探索 |
6.3 Dependency Map
| Use case | Upstream dependency | Downstream dependency | Hidden constraint |
|---|---|---|---|
| AML copilot | KYC data、transaction history、case notes、typology library | SAR/STR review, QA sampling | 数据权限和监管证据格式 |
| Service RAG | policy source of truth、knowledge owner、CRM integration | supervisor review, complaint escalation | 政策更新频率和内容 ownership |
| Fraud prioritization | feature pipeline、rules engine、case system | appeals, customer notification | 实时延迟和 false positive 处理能力 |
| Wealth guardrail | product catalog、client suitability data、advisor desktop | compliance review, disclosure | 投资建议边界和 jurisdiction 差异 |
| Platform eval harness | golden set owners、rubric、model registry | release gate, monitoring | 业务专家时间和 judge calibration |
7. Stop / Scale Rules
7.1 什么时候停止 POC
POC 停止不是失败, 是 portfolio discipline。以下任一条件满足就应停止或回到 discovery:
| Stop trigger | 判断标准 | 处理方式 |
|---|---|---|
| No business owner | 没有人愿意承担流程、收益、采用责任 | 停止, 不允许变成技术团队自娱自乐 |
| Baseline unavailable | 4 周内无法拿到可信 baseline | 停止或改成 data readiness initiative |
| Data not usable | 数据无法授权、质量不足、更新不可控 | 停止 POC, 先做 data product |
| No workflow change | TO-BE 流程无法被业务接受 | 停止 AI, 回到流程优化 |
| Quality floor not met | red-flag recall、groundedness、task success 达不到最低门槛 | 停止或缩小范围 |
| Risk unacceptable | 风险 owner 不接受 residual risk, controls 无法落地 | 停止或改成人工辅助低风险范围 |
| Unit economics impossible | all-in cost 高于可承受收益且无规模下降路径 | 停止 |
| Adoption failed | 目标用户持续不用, manager cadence 缺失 | 停止或重做 change plan |
7.2 什么时候继续 Pilot
| Continue pilot condition | 证据要求 |
|---|---|
| 问题真实但范围需缩小 | baseline 清楚, 但 first pilot 只保留高频低风险任务 |
| 质量接近门槛且错误可解释 | error taxonomy 指向可修复的数据、prompt、workflow 问题 |
| 用户采用有早期信号 | 目标用户主动使用, 但 SOP 和 manager cadence 还未稳定 |
| 风险可控但 evidence 不足 | controls 已设计, 需要更多 production-like sample |
| 成本可控但规模模型待验证 | cost per unit 在 pilot 可接受, scale 假设需要验证 |
7.3 什么时候规模化
规模化必须同时满足四类证据:
| Evidence | Scale gate |
|---|---|
| Value proof | baseline-to-target 改善被业务和 finance 接受 |
| Quality proof | release gate 达标, production sample 没有 critical regression |
| Risk proof | residual risk owner 签字, controls 可运行, incident path tested |
| Adoption proof | 用户使用、主管复盘、SOP 更新、支持模型稳定 |
规模化前必须回答:
扩到 10 倍用户时, 成本、延迟、支持、QA、incident、training 是否仍可承受?
哪些指标会在 scale 时恶化?
如果恶化, 谁有权暂停?
7.4 什么时候平台化
平台化不是“这个功能很酷”, 而是已有复用证据。
| Platformize trigger | 证据 |
|---|---|
| 3 个以上 use case 重复构建同一能力 | 多个团队重复做 RAG、eval、prompt registry、audit log |
| 控制要求必须统一 | 高风险 use case 都需要同一 release gate、logging、RBAC |
| 成本可通过共享下降 | model gateway、cache、routing、observability 能降低 cost-to-serve |
| 风险因分散实现而上升 | shadow AI、prompt drift、不可审计调用 |
| 平台 owner 能承诺服务 | 有 roadmap、SLO、support、chargeback 或 showback |
7.5 什么时候 Retire
| Retirement trigger | 例子 |
|---|---|
| 收益衰减 | 业务流程变化后 AI 辅助不再节省时间 |
| 风险上升 | 新监管解释要求更高控制, 现方案不适配 |
| 平台替代 | 单点工具被共享平台能力取代 |
| 供应商退出 | vendor SLA、合规、成本不再可接受 |
| 低采用持续 | 连续 2 个 review cycle 达不到 adoption floor |
8. PM / BA / Architect 输出
8.1 Portfolio Backlog
| 字段 | 内容 |
|---|---|
| Use case name | 清楚命名业务流程, 避免“AI assistant”泛化 |
| Domain | AML/KYC、service、credit、fraud、wealth、retail、platform |
| Business owner | 对收益和采用负责的人 |
| Problem baseline | volume、cycle time、cost、quality、risk |
| Stage | intake、prioritization、discovery、pilot、release、scale、retire |
| Score | 10 个 dimension 的评分 |
| Gate date | 下一次决策日期 |
| Decision needed | fund discovery、fund pilot、release、scale、stop |
8.2 Funding Memo
Funding memo 要让 CFO、business owner、risk、CIO/CTO 同时能判断是否值得投。
| Section | 内容 |
|---|---|
| Decision requested | 请求批准的阶段、金额、周期、范围 |
| Business baseline | 当前损耗和数据来源 |
| Recommendation | AI-assisted、agentic、workflow-only、vendor/custom/hybrid 的选择 |
| Expected benefit | conservative/base/upside 三档 |
| Cost | one-time、run-rate、platform allocation、support、control cost |
| Risk and controls | top risks、risk owner、gate threshold |
| Platform reuse | 使用哪些共享能力, 是否产生新平台需求 |
| Stop rule | 何时停止且如何释放资源 |
8.3 Benefits Register
| 字段 | 内容 |
|---|---|
| Benefit ID | 与 use case 和 stage 关联 |
| Benefit type | hard saving、cost avoidance、risk reduction、revenue uplift、capacity |
| Baseline | 当前数值、时间窗口、数据源 |
| Target | pilot target、scale target |
| Leading indicator | adoption、quality、workflow usage |
| Lagging indicator | cost、loss、error、complaint、revenue |
| Owner | business owner + finance reviewer |
| Confidence | low、medium、high |
| Sign-off status | proposed、validated、realized、rejected |
8.4 Reuse Map
| Reusable capability | 当前 use case | 潜在 use case | 平台 owner | 决策 |
|---|---|---|---|---|
| RAG with citations | service RAG、regulatory reporting | AML、wealth、merchant risk | AI platform | productize ingestion + source freshness |
| Eval harness | service RAG、AML copilot | all high-risk use cases | EvalOps/platform | standard golden set workflow |
| Model gateway | all pilots | all production AI | platform | mandatory production route |
| Audit log | AML、wealth、credit | all material AI systems | platform/security | central audit schema |
| Cost dashboard | service、platform | all AI apps | platform/finance | showback by use case |
8.5 Dependency Map
| Dependency | Type | Affected use cases | Owner | Risk if late | Mitigation |
|---|---|---|---|---|---|
| Policy source cleanup | Data/content | service RAG、wealth guardrail | Knowledge owner | stale or conflicting answer | freeze scope to top 8 policies |
| Case management API | Integration | AML、dispute、fraud | IT owner | no workflow integration | start with read-only summary, plan API phase |
| Eval expert labeling | SME capacity | AML、credit、wealth | Business owner | weak release evidence | reserve reviewer time in pilot funding |
| Model gateway logging | Platform | all production AI | Platform lead | audit gap | release gate requires gateway route |
8.6 Monthly Executive Dashboard
Dashboard 只回答 portfolio 决策, 不堆项目流水账。
| Section | 指标 |
|---|---|
| Portfolio shape | count by stage、domain、risk tier、investment bucket |
| Value | forecast benefit、validated benefit、realized benefit、confidence |
| Adoption | active users、workflow penetration、manager cadence、SOP completion |
| Quality | release gate pass rate、unsupported claim、red-flag recall、regression |
| Risk | high-risk systems、open control gaps、incidents、risk acceptance due |
| Cost | monthly run-rate、cost per unit、platform allocation、budget variance |
| Decisions | scale、stop、funding、risk acceptance、platformization requests |
8.7 Decision Log
| 字段 | 内容 |
|---|---|
| Date | 决策发生日期 |
| Forum | intake triage、pilot gate、release gate、value review、board/risk committee |
| Decision | fund、continue、release、scale、stop、retire、platformize |
| Evidence considered | scoring、baseline、eval、risk、cost、adoption |
| Decision owner | 最终 accountable person |
| Conditions | 附带限制或下一 gate |
| Revisit date | 何时复盘 |
| Lessons | 对 portfolio rule 或平台能力的影响 |
9. 30 天 Lab: Build an AI Portfolio Operating Pack
目标: 30 天后形成一个可展示的 AI portfolio operating pack, 覆盖 portfolio backlog、scoring、benefits、reuse、dependency、dashboard、decision memo。
| Day | 任务 | Artifact |
|---|---|---|
| 1 | 选定企业背景: 金融集团、区域银行、支付公司或零售金融平台 | Portfolio context one-pager |
| 2 | 定义 AI Value Office charter: 决策权、范围、不做范围 | Value Office charter |
| 3 | 设计 intake form 字段和 gate 规则 | AI use case intake form |
| 4 | 收集 20 个金融零售 AI use case, 覆盖业务和平台能力 | Raw use case inventory |
| 5 | 合并重复 use case, 去除无 owner、无流程、无数据的想法 | Clean portfolio backlog v1 |
| 6 | 为每个 use case 写 problem statement 和业务 owner | Problem statement pack |
| 7 | 建立 10 维 scoring matrix 和权重 | Use Case Scoring Matrix v1 |
| 8 | 给 20 个 use case 打分, 标注证据和假设 | Scored portfolio backlog |
| 9 | 画四象限: Scale now、Controlled bet、Platform candidate、Stop or park | Portfolio quadrant map |
| 10 | 选择 6 个进入 discovery 的 use case | Discovery shortlist memo |
| 11 | 为 6 个 use case 建 baseline: volume、cycle time、quality、cost、risk | Baseline workbook |
| 12 | 为 6 个 use case 定 target: value、quality、risk、adoption、cost | Target and gate sheet |
| 13 | 做 data readiness assessment | Data readiness heatmap |
| 14 | 做 risk tier 和 regulatory sensitivity classification | AI risk tier register |
| 15 | 为 3 个最高优先级 use case 写 funding memo | 3 funding memos |
| 16 | 为 3 个 use case 设计 pilot gate 和 stop rule | Pilot gate pack |
| 17 | 为 3 个 use case 设计 benefits register | Benefits Realization Register v1 |
| 18 | 为 3 个 use case 设计 quality proof: golden set、rubric、release threshold | Quality proof plan |
| 19 | 为 3 个 use case 设计 adoption proof: workflow、SOP、manager cadence | Adoption proof plan |
| 20 | 计算 unit economics, 包含平台、review、support、control 成本 | Unit economics model |
| 21 | 识别复用能力: RAG、eval、gateway、audit、cost、prompt registry | Reuse map |
| 22 | 画 dependency map, 标注 owner、风险和缓解 | Dependency map |
| 23 | 设计 monthly executive dashboard 指标和红黄绿规则 | Executive dashboard v1 |
| 24 | 模拟一次 monthly value review, 做 scale/stop/fund 决策 | Decision log sample |
| 25 | 写一个 Stop Decision Memo, 选择一个该停的 POC | Stop memo |
| 26 | 写一个 Scale Decision Memo, 选择一个可规模化 use case | Scale memo |
| 27 | 写一个 Platformization Memo, 说明哪些能力进入平台 backlog | Platformization memo |
| 28 | 把 portfolio pack 映射到 NIST AI RMF、GenAI Profile、ISO/IEC 42001、OMB M-24-10 | Governance mapping sheet |
| 29 | 准备 30 秒、2 分钟、CFO/COO/CIO 深挖表达 | Interview answer pack |
| 30 | 汇总成作品集: executive summary、dashboard、appendix、decision log | AI Portfolio Operating Pack |
30 天最终包结构
AI Portfolio Operating Pack
1. Executive summary
2. Value Office charter
3. Portfolio backlog and scoring
4. Financial retail use case map
5. Benefits realization register
6. Risk and governance mapping
7. Reuse and dependency map
8. Monthly executive dashboard
9. Scale/Stop decision memos
10. Interview storytelling appendix
10. Templates
10.1 AI Portfolio Kanban
| Stage | Entry rule | Exit evidence | Example card |
|---|---|---|---|
| Intake | Business owner, workflow, pain, rough data source identified | Intake card complete | Customer service policy RAG |
| Prioritization | 10-dimension scoring completed | Ranked and capacity checked | Fraud alert prioritization |
| Discovery | Discovery funding and owner confirmed | Baseline, target, data readiness, risk tier | AML investigator copilot |
| Pilot | Pilot gate and stop rule approved | Pilot evidence: quality, adoption, cost, risk | Payment dispute triage |
| Release | Release gate passed | Limited production release and monitoring | Service RAG for 8 policy topics |
| Scale | Benefits signed off and support model ready | Expanded users/process/regions | Inventory demand insight |
| Retire | Stop trigger or replacement approved | Retirement record and lessons learned | Legacy standalone chatbot |
Kanban card fields:
| Field | Example |
|---|---|
| Use case | Customer service policy RAG |
| Business owner | Head of Contact Center Operations |
| Stage | Pilot |
| Decision needed | Limited release approval |
| Next gate date | 2026-08-15 |
| Value hypothesis | Reduce AHT and QA rework for 8 high-volume policy topics |
| Risk tier | Medium-high |
| Platform reuse | RAG ingestion, citation, model gateway, audit log |
| Stop rule | Stop if unsupported claim rate remains above 3% after remediation cycle |
10.2 Use Case Scoring Matrix
| Dimension | Weight | Score | Evidence example | Interpretation |
|---|---|---|---|---|
| Strategic fit | 12% | 4 | Contact center efficiency is FY priority | Strong business alignment |
| Value size | 18% | 4 | 42,000 monthly policy cases, 13.8 min AHT | Material operating value |
| Feasibility | 12% | 4 | CRM and knowledge base API available | Pilot feasible |
| Data readiness | 10% | 3 | 80% policy docs owned, 20% needs cleanup | Discovery risk remains |
| Reuse potential | 8% | 5 | Same RAG pattern for compliance reporting | Platform candidate |
| Time-to-value | 8% | 4 | 8 policy topics can pilot in 6 weeks | Fast evidence |
| Risk tier | 10% | 3 | Customer-facing draft, human approval | Medium constraint |
| Cost-to-serve | 8% | 2 | Cost per assisted case projected at 0.32 USD | Manageable |
| Adoption burden | 8% | 3 | Agents need workflow change and supervisor cadence | Needs change plan |
| Regulatory sensitivity | 6% | 3 | Policy advice can affect complaints | Moderate sensitivity |
Decision interpretation:
Fund pilot if value + feasibility + reuse are strong, but require quality gate, source freshness control, supervisor approval for high-risk topics, and adoption proof before release.
10.3 Benefits Realization Register
| Field | Example |
|---|---|
| Benefit ID | BR-CSR-RAG-001 |
| Use case | Customer service policy RAG |
| Benefit type | Productivity capacity + quality improvement |
| Baseline | 42,000 monthly policy cases, 13.8 min AHT, 7.2% QA fail |
| Target | 30% assisted cases reduce AHT to 10.5 min, QA fail below 5% |
| Leading indicators | weekly active agents, suggestion acceptance, citation click, override reason |
| Lagging indicators | AHT, QA fail, complaint escalation, rework hours |
| Guardrails | unsupported claim < 3%, stale source hit < 1%, high-risk topics supervisor-approved |
| Cost model | token + RAG + platform allocation + supervisor review + support |
| Finance view | productivity capacity counted after staffing plan or backlog reduction is confirmed |
| Confidence | Medium until 4-week production sample |
| Sign-off | Business owner and finance reviewer sign at monthly value review |
10.4 Scale / Stop Decision Memo
# Scale / Stop Decision Memo
## Decision Requested
Approve limited scale of customer service policy RAG from 30 agents to 180 agents across two contact center teams, with weekly monitoring and a stop trigger tied to unsupported claim rate, adoption, and cost per assisted case.
## Current Stage
Pilot completed for 8 high-volume policy topics over 6 weeks.
## Evidence Summary
- Baseline: 42,000 monthly policy cases, 13.8 min AHT, 7.2% QA fail.
- Pilot result: assisted cases reached 10.9 min AHT, QA fail 4.9%, unsupported claim 2.4%.
- Adoption: 76% target agents used the tool weekly, median 14 assisted cases per agent per week.
- Cost: all-in cost per assisted case 0.38 USD, within 0.45 USD gate.
- Risk: high-risk topics required supervisor approval; no severe incident during pilot.
## Recommendation
Scale to two teams, not enterprise-wide. Keep topic scope fixed for 30 days while monitoring production quality and support load.
## Conditions
- Keep all production calls through model gateway.
- Weekly manager review of override reasons and low-confidence answers.
- Source freshness control reviewed every Friday.
- Finance validates realized benefit after 4 production weeks.
## Stop / Rollback Trigger
Pause expansion if unsupported claim rate exceeds 3% for two consecutive weekly samples, stale source hit exceeds 1%, cost per assisted case exceeds 0.45 USD, or weekly active usage falls below 60% of target users.
## Next Review
Monthly value review after 4 production weeks.
10.5 Executive Portfolio Dashboard
| Section | Metric | Green | Yellow | Red |
|---|---|---|---|---|
| Portfolio flow | % use cases with named business owner | >= 95% | 80-94% | < 80% |
| Value | validated benefits / forecast benefits | >= 70% | 40-69% | < 40% |
| Adoption | pilots meeting adoption gate | >= 70% | 50-69% | < 50% |
| Quality | releases with eval report and regression pass | 100% | 90-99% | < 90% |
| Risk | high-risk systems with current risk owner sign-off | 100% | 95-99% | < 95% |
| Cost | use cases with cost per unit reported | >= 90% | 70-89% | < 70% |
| Reuse | new pilots using platform gateway/eval/logging | >= 80% | 60-79% | < 60% |
| Decision discipline | POCs stopped or scaled based on gate evidence | documented for all gate decisions | partial documentation | decisions made without evidence |
Monthly narrative:
This month the portfolio moved from 42 to 38 active use cases after stopping 5 low-evidence POCs and adding 1 platform capability. Validated benefits increased from 41% to 55% of forecast as customer service RAG and inventory demand insight passed adoption gates. Two controlled bets remain constrained by data readiness: AML copilot and wealth guardrail. The decision request is to fund platform eval harness expansion because 7 high-risk pilots now depend on consistent release evidence.
11. 面试表达
11.1 30 秒版本
我会把 AI 转型从“做很多 POC”升级成 AI Value Office。它不只是 PMO, 而是管理 use case portfolio、funding gate、benefits realization、risk gate、platform reuse、change adoption 和 kill/scale decision。每个 AI use case 先通过 intake 和 scoring, 再用 baseline、target、quality proof、adoption proof、unit economics 和 risk evidence 决定是否继续投。这样 CFO 能看到收益口径, COO 能看到流程采用, CIO/CTO 能看到平台复用和成本, risk 能看到控制证据。
11.2 2 分钟版本
企业 AI 最大的问题不是缺少 idea, 而是缺少 portfolio discipline。我的做法是建立 AI Transformation Value Office。
第一层是 intake 和 prioritization。每个 use case 必须有 business owner、流程、baseline、数据来源和风险信号, 然后按 strategic fit、value size、feasibility、data readiness、risk tier、reuse potential、time-to-value、cost-to-serve、adoption burden、regulatory sensitivity 打分。
第二层是 stage gate。Discovery 证明问题和数据, pilot 证明质量、采用、成本和风险, release 证明控制和运维, scale 证明单位经济和 adoption 可扩张。每一阶段都有 stop rule。
第三层是 benefits realization。我不会只说节省小时数, 而是建立 baseline、target、leading/lagging indicators、unit economics、adoption proof、quality proof、risk reduction proof, 最后让 finance sign off 收益口径。
第四层是 platform reuse。凡是多个 use case 重复需要 model gateway、RAG、eval、audit log、cost dashboard, 就进入平台 backlog, 降低重复建设和治理风险。
最终输出包括 portfolio backlog、funding memo、benefits register、reuse map、dependency map、monthly exec dashboard 和 decision log。这样 AI 转型就从试点集合变成可投资、可治理、可停止、可规模化的企业能力。
11.3 CFO 深挖
CFO 问: 你怎么证明 AI 真的带来财务价值, 而不是部门自己说节省时间?
强回答:
我会先区分 benefit type: hard saving、cost avoidance、risk reduction、revenue uplift 和 productivity capacity。不是所有效率提升都能进 P&L。每个 use case 必须有 baseline、target、数据来源和 finance reviewer。比如客服 RAG, 我不会直接把节省分钟数乘以工资当收益, 而是看是否减少 backlog、减少加班、降低 QA rework, 或释放 capacity 到可量化任务。成本也要包括 token、license、platform allocation、human review、QA、support 和 change cost。最后用 conservative/base/upside 三档, 在 monthly value review 做 finance sign-off。
继续追问时强调:
| CFO concern | 回答重点 |
|---|---|
| 成本失控 | cost per unit、budget cap、showback/chargeback、model routing |
| 机会成本 | portfolio scoring + stop rule, 停掉低证据 POC |
| 收益归因 | AI + process change + adoption proof, 不把模型效果直接当财务收益 |
| 扩张经济性 | scale 前验证 cost-to-serve 是否随规模下降 |
11.4 COO 深挖
COO 问: 很多 AI 工具上线后没人用, 你怎么保证 adoption?
强回答:
我会把 adoption 当成 release 和 scale gate, 不是培训任务。Discovery 阶段先画 AS-IS/TO-BE workflow, 明确 AI 改变哪一步, 谁审批, 异常怎么处理。Pilot 阶段要求 adoption proof: 目标用户每周真实使用、建议进入系统记录、override reason 结构化、主管每周复盘低信任案例、SOP 更新。Scale 前还要确认 support model、manager cadence 和运营指标。如果用户只参加培训但不在真实 case 中使用, 不能规模化。
继续追问时强调:
| COO concern | 回答重点 |
|---|---|
| 运营中断 | limited release、rollback、runbook、support path |
| 员工抵触 | workflow fit、manager cadence、incentive alignment |
| SLA 影响 | latency、fallback、manual path、capacity plan |
| 质量波动 | QA sampling、feedback loop、incident threshold |
11.5 CIO / CTO 深挖
CIO/CTO 问: 你如何避免每个团队重复做 AI, 最后形成一堆不可维护的工具?
强回答:
我会把 platform reuse 放进 portfolio gate。每个 use case 在 discovery 就要标注是否复用 model gateway、RAG ingestion、eval harness、prompt registry、audit log、cost dashboard 和 observability。三个以上 use case 重复构建同一能力, 或高风险控制必须统一时, 就提出 platformization memo。生产 AI 必须走 model gateway, release gate 必须有 eval report、logging、rollback 和 ownership。这样平台不是先做大而全, 而是由 portfolio 复用证据驱动。
继续追问时强调:
| CIO/CTO concern | 回答重点 |
|---|---|
| Shadow AI | mandatory gateway、app registry、DLP、audit log |
| 技术债 | reusable patterns、reference architecture、platform backlog |
| 成本和性能 | routing、cache、quota、p95 latency、cost per use case |
| 运维责任 | SLO、runbook、incident owner、version rollback |
| 安全和权限 | RBAC、tool gateway、least privilege、data boundary |
12. Source Anchors
本手册不是法规解读, 但 portfolio governance 可以用以下公开框架作为治理锚点:
| Source | 可借鉴点 | 在本手册中的映射 |
|---|---|---|
| NIST AI Risk Management Framework | AI risk management 的 Govern、Map、Measure、Manage 思路 | risk gate、control evidence、portfolio dashboard、decision log |
| NIST AI RMF Generative AI Profile | 面向 GenAI 的风险画像和治理实践 | GenAI use case risk tier、eval、red-team、content/data/control guardrails |
| ISO/IEC 42001:2023 | AI management system 的组织化、持续改进、治理要求 | Value Office charter、RACI、stage gate、continual improvement |
| OMB M-24-10 official briefing | AI governance、innovation、risk management 的公共部门政策表达 | AI inventory、risk management minimum practices、senior accountability |
| OMB M-24-10 memorandum PDF | 更适合引用的正式备忘录文本 | material AI system register、rights/safety impact、agency-level governance analogy |
使用这些 anchors 时要注意:
- 不要机械套框架。 面试和作品集重点是把框架转译成企业 portfolio operating model。
- Governance 与 value 要放在同一张桌上。 只谈风险会变成审批部门, 只谈 ROI 会忽略 AI 特有风险。
- 所有框架最终都要落到 artifact。 intake、scoring、benefits register、risk gate、dashboard、decision log 才是可证明能力。
13. 自测清单
完成本手册学习后, 应能独立回答并产出:
| 能力 | 自测问题 | 作品集证据 |
|---|---|---|
| Portfolio framing | 如何把 30 个 AI idea 变成可治理 portfolio | AI Portfolio Kanban + scoring matrix |
| Funding governance | 为什么这个 use case 现在只给 discovery, 不给 scale budget | Funding memo + stage gate |
| Benefits realization | 如何证明收益真实且被 finance 接受 | Benefits register + unit economics |
| Risk governance | 高风险 AI use case 如何进入 pilot 和 release | Risk tier + release gate evidence |
| Platform thinking | 哪些能力应该平台化, 哪些不该过早平台化 | Reuse map + platformization memo |
| Adoption leadership | 如何证明用户真的改变工作方式 | Adoption proof dashboard |
| Stop/scale discipline | 什么时候停, 什么时候继续, 什么时候规模化 | Scale/Stop decision memo + decision log |
| Executive communication | 如何同时回答 CFO、COO、CIO/CTO 和 risk 的追问 | Monthly executive dashboard |
最终判断标准:
你不只是能设计一个 AI use case, 而是能管理一组 AI 投资, 让企业知道该投什么、停什么、复用什么、控制什么、如何证明价值。