AI 扩展计划 / Playbooks
AI Wardley Mapping Product Strategy Playbook
这些来源用于校准术语、地图方法和治理语言。本文不是法律、合规、采购、投资或监管意见；正式项目必须由 legal、compliance、risk、security、privacy、procurement、data owner、model risk、architecture board 和 business owner 审查。
1,032 行AI_WARDLEY_MAPPING_PRODUCT_STRATEGY_PLAYBOOK.md
Wardley Mapping for AI Product / Platform Strategy Playbook
适用对象：高级 AI PM、AI Platform PM、Product Architect、AI Architect、Enterprise Architect、金融零售 AI 转型负责人。 核心问题：如何用 Wardley Mapping 把 AI 产品机会、平台边界、build / buy / partner、竞争地形和架构投资路线放到同一张战略地图里，而不是用孤立 PRD、供应商清单或技术架构图做决策。 学习目标：训练战略态势感知能力。重点不是基础产品管理，而是从 user need、value chain、evolution axis、doctrine、climatic patterns 和 strategic gameplay 出发，设计 AI 平台与产品组合路线。 作品集定位：本文可直接转化为 AI strategy portfolio evidence，包括 AI Wardley Map、value chain template、evolution heatmap、build-buy-partner memo、platform boundary ADR、competitive landscape map、architecture investment thesis 和金融零售案例包。
Source Anchors
这些来源用于校准术语、地图方法和治理语言。本文不是法律、合规、采购、投资或监管意见；正式项目必须由 legal、compliance、risk、security、privacy、procurement、data owner、model risk、architecture board 和 business owner 审查。
| Anchor | Official / primary source | 在本 playbook 中的用法 |
|---|---|---|
| Simon Wardley - Writings / Books | https://www.swardleymaps.com/writings-books | 作为 Wardley Mapping 原始材料入口，用于 user need、value chain、evolution、doctrine、climatic pattern 和 gameplay 的方法锚点 |
| Wardley Mapping book by Simon Wardley | https://learnwardleymapping.com/book/ | 作为 Wardley Mapping 书籍章节入口，用于训练从地图看战略、组织、机会、浪费和竞争态势 |
| Wardley Maps community resources | https://list.wardleymaps.com/ | 用于工具、社区资料、案例和地图实践参考 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern、Map、Measure、Manage 组织 AI risk、eval、monitoring、control、portfolio governance 和 evidence |
| Team Topologies | https://teamtopologies.com/ | 用 stream-aligned team、platform team、enabling team、complicated subsystem team 和 interaction modes 设计 AI 平台组织边界 |
| Team Topologies - Key Concepts | https://teamtopologies.com/key-concepts | 用 four team topologies 和 collaboration / X-as-a-Service / facilitation 解释平台能力如何进入业务流 |
| Team Topologies - Platform Manifesto | https://teamtopologies.com/platform-manifesto | 用 internal customer、self-service pattern、adoption、engagement 和 platform as product 约束 AI 平台建设 |
Source anchors 到作品集证据的映射：
| Source lens | 可以产出的 evidence | 面试表达 |
|---|---|---|
| Wardley Mapping | AI Wardley Map、evolution heatmap、strategic playbook、investment thesis | “我不是按 vendor hype 排路线，而是先把 user need、value chain 和组件演进位置画出来，再决定哪里 build、哪里 buy、哪里平台化。” |
| NIST AI RMF | AI risk tier、control pack、eval gate、monitoring plan、evidence binder | “地图告诉我哪里投资，AI RMF 告诉我哪些风险必须被治理、评估和持续管理。” |
| Team Topologies | platform boundary、team interaction model、cognitive load assessment、X-as-a-Service contract | “平台不是共享代码库，而是让 stream-aligned teams 更快、更安全交付 AI 产品的内部产品。” |
One-Sentence Positioning
Wardley Mapping for AI Strategy = 用 user need 锚定价值链，用 evolution axis 判断组件成熟度，用 doctrine 建立基本作战纪律，用 climatic patterns 识别不可逆趋势，用 strategic gameplay 决定 AI 产品、平台、供应商和架构投资的取舍。
1. 为什么 AI PM / 架构师需要战略地图
AI 产品和平台最容易出现的失败不是“模型不够强”，而是团队没有态势感知：
- 把所有 AI 机会都当成同一种 chatbot。
- 把供应商能力表当成战略。
- 把 foundation model 选择当成护城河。
- 把第一个成功 pilot 扩成平台。
- 把所有平台能力都集中建设，导致业务团队等待和绕行。
- 把高风险 decisioning 和低风险 knowledge retrieval 放进同一套上线门禁。
- 把 eval 当测试活动，而不是产品契约和治理控制面。
Wardley Map 的价值在于把讨论从“我们喜欢什么方案”拉回“用户需要什么、价值链依赖什么、每个组件处于什么演进阶段、哪些变化由市场驱动、哪些投资能形成真实优势”。
1.1 AI 战略地图回答的高级问题
| 决策问题 | 没有地图时的典型错误 | 用 Wardley Map 后的判断方式 |
|---|---|---|
| 哪些 AI use case 值得做 | 看高层偏好、供应商 demo 或团队热情 | 从 user need 和 value chain 识别高可见、高痛点、高杠杆节点 |
| 哪里 build | 看到关键能力就自研 | 只在差异化、控制权、规模经济或监管责任明确的组件 build |
| 哪里 buy | 看到成熟 SaaS 就采购 | 对 commodity / product 化组件优先 buy，同时保留出口、审计和数据边界 |
| 哪里 partner | 复杂就外包 | 在 domain know-how、实施加速、监管解释或组织能力迁移上 partner，避免核心判断外包 |
| 何时平台化 | 第一个场景就建平台 | 当多个 use case 共享低可见但高复用组件，并且 Team Topologies 的 platform-as-product 条件成立时平台化 |
| 如何投资架构 | 按技术潮流投资 | 围绕 value chain bottleneck、risk control point、evolution movement 和 competitive gap 投资 |
| 如何看竞争 | 列 competitor feature | 比较竞争者在哪些 value chain 节点拥有速度、数据、分发、合规、生态或成本优势 |
1.2 地图与传统 artifacts 的关系
| Artifact | 适合回答 | 不适合回答 | 与 Wardley Map 的关系 |
|---|---|---|---|
| PRD | 用户流程、范围、验收 | 为什么这个产品路线比另一个更值得投资 | 地图先定义战略位置，PRD 再定义可交付产品 |
| C4 架构图 | 系统边界、组件、部署 | 哪些组件应该商品化、外购或形成护城河 | 地图决定架构投资方向，C4 展示实现结构 |
| Capability map | 企业能力覆盖 | 能力组件的市场演进和竞争动作 | capability map 可作为 value chain 的上层输入 |
| Vendor scorecard | 供应商能力比较 | 供应商能力是否战略上重要 | 地图先定义需要买什么，scorecard 再比较谁更合适 |
| Risk register | 风险和控制 | 哪些风险来自演进趋势和平台边界 | 地图把风险放回价值链和组织边界 |
| Roadmap | 时间安排 | 为什么这个顺序正确 | 地图用 evolution、dependency 和 gameplay 解释 roadmap 顺序 |
2. Wardley Mapping 核心语言转成 AI 战略语言
| Wardley concept | 原始含义 | AI 产品 / 平台转译 | 产出 |
|---|---|---|---|
| User need | 地图锚点，用户真正要完成的事 | 客户、员工、风控、合规、开发者或监管审查者的高价值需求 | User need statement |
| Value chain | 满足用户需求所需的组件和依赖 | 体验、流程、决策、知识、数据、模型、工具、评估、治理、基础设施 | AI value chain |
| Visibility | 对用户价值的可见程度 | 越靠上越接近业务体验和决策影响，越靠下越接近平台和基础设施 | Map y-axis |
| Evolution axis | Genesis -> Custom -> Product -> Commodity | 从新颖实验到定制建设、产品化服务、标准化基础设施 | Map x-axis |
| Doctrine | 普遍适用的基本原则 | 先有 user need、owner、数据边界、风险分层、eval、可逆性和反馈机制 | AI doctrine checklist |
| Climatic patterns | 外部不可逆趋势 | 模型能力商品化、agent 风险上升、eval 标准化、监管增强、成本下降但用量上升 | Trend assumptions |
| Strategic gameplay | 基于地图的行动 | build、buy、partner、平台化、开源、生态、标准、差异化、快速跟随、退出 | Strategy moves |
3. AI Value Chain 模板
AI value chain 不从“模型”开始，而从 user need 开始。模型通常在价值链中段或底层；真正决定成败的是业务流程、数据治理、控制点和用户信任。
3.1 通用模板
User / actor
-> user need
-> experience / workflow surface
-> decision or task boundary
-> domain policy / business rule
-> AI interaction pattern
-> orchestration / workflow engine
-> tool access / system integration
-> knowledge / retrieval / memory
-> data products / metadata / lineage
-> model access / model gateway
-> eval / monitoring / incident loop
-> identity / entitlement / audit
-> infrastructure / cloud / runtime
3.2 AI value chain 表格模板
| Value chain node | User-visible? | Strategic question | Typical AI components | Evidence required |
|---|---|---|---|---|
| User need | Very high | 谁的哪个高价值问题被解决 | Persona、workflow pain、outcome metric | 用户证据、业务基线、风险影响 |
| Experience / workflow | High | AI 在流程哪里出现，改变什么行为 | Copilot UI、case workbench、advisor desktop、agent console | TO-BE workflow、adoption signal、human role |
| Decision boundary | High | AI 是 inform、draft、recommend、approve 还是 act | HITL、approval queue、policy engine | Decision rights、risk tier、exception path |
| Domain policy | Medium-high | 哪些政策和业务规则约束输出 | Policy RAG、rule engine、reason codes | Policy owner、effective date、exception rule |
| AI pattern | Medium | RAG、agent、classification、extraction、forecasting、decisioning 如何组合 | RAG、tool agent、classifier、scoring model | Pattern ADR、failure taxonomy |
| Orchestration | Medium | 多步骤流程如何稳定、可回滚、可审计 | Workflow engine、state machine、event bus | State model、retry、compensation、SLA |
| Tool / integration | Medium-low | AI 可读写哪些系统，权限如何控制 | Tool gateway、API adapter、CRM/core/case system connector | AuthZ、idempotency、tool audit |
| Knowledge / retrieval | Medium-low | 知识从哪里来，如何证明有效 | Ingestion、chunking、metadata、reranker、citation | Source owner、lineage、freshness、retrieval eval |
| Data product | Low-medium | 特征、标签、历史案例是否可复用 | Feature store、golden dataset、entity graph | Data contract、quality SLA、PII control |
| Model access | Low | 如何选择、路由、替换和降级模型 | Model gateway、routing、fallback、quota | Provider policy、latency、cost、version |
| EvalOps | Low but critical | 如何证明质量、风险和回归 | Dataset registry、eval runner、judge、release gate | Eval report、critical failure、slice analysis |
| Security / audit | Low but mandatory | 如何防泄露、越权、滥用和审计失败 | IAM、policy-as-code、audit log、SIEM export | Control pack、evidence binder |
| Infrastructure | Low | 运行成本、性能、可靠性如何管理 | Cloud、container、queue、vector DB、observability | SLO、DR、cost model、capacity plan |
3.3 AI value chain 使用规则
| Rule | 说明 |
|---|---|
| 从上往下拆 | 先写 user need，再写 AI pattern 和技术组件 |
| 每个节点必须有 owner | 没有 owner 的知识、数据、eval、prompt、工具权限会变成生产风险 |
| 越靠上越关注差异化 | 用户体验、决策边界、领域政策和工作流往往是差异化来源 |
| 越靠下越关注复用和标准化 | model gateway、EvalOps、audit、observability 更适合平台化 |
| 高风险节点不能只靠供应商承诺 | AML、信贷、财富建议、客户可见输出必须有内部控制和证据 |
| 地图要反映依赖 | 如果 value chain 中某个低层组件不成熟，上层产品路线必须降速或改变路径 |
4. Evolution Mapping：把 AI 组件放到演进轴
演进轴不是技术成熟度评分，而是市场与组织对某个组件的共同认知：它是否稀缺、不可预测、需要定制，还是已经产品化、标准化、可替换。
4.1 演进阶段定义
| Stage | 特征 | AI 场景信号 | 管理方式 |
|---|---|---|---|
| Genesis | 新颖、不确定、少数团队探索 | 新 agent pattern、新交互范式、新监管解释、新数据产品假设 | 小实验、强学习、少承诺、快速关闭 |
| Custom-built | 价值明确但高度定制 | 领域 workflow、专有 policy、复杂 entitlement、业务特有 eval | 内部设计、架构 ADR、领域团队深度参与 |
| Product / Rental | 多家供应商可提供，配置仍重要 | RAG 平台、LLM app framework、eval SaaS、workflow automation、AI客服套件 | buy / partner / hybrid，重视集成和控制 |
| Commodity / Utility | 标准化、低差异、高可替换 | 云算力、基础模型 API、日志管道、身份认证、对象存储、基础向量检索 | 优先消费成熟服务，控制成本、SLO 和 exit path |
4.2 AI 组件演进热力图
| Component | Current evolution | 可能变化 | 战略含义 |
|---|---|---|---|
| Foundation model API | Product -> Commodity | 主流模型能力继续趋同，价格和上下文窗口竞争加剧 | 不把单一模型当护城河，投资 model gateway 和评估能力 |
| Domain-specific small model | Custom -> Product | 金融、客服、合规、文档理解模型逐渐产品化 | 对高价值领域可 hybrid，保留训练数据和验证能力 |
| Prompt engineering practice | Custom -> Product | 模板、registry、policy、testing 工具成熟 | 不靠个人 prompt 技巧，转向 prompt/config lifecycle |
| RAG ingestion pipeline | Custom -> Product | 连接器、解析、chunking、rerank 产品化 | buy 基础能力，build 权限、元数据、source governance |
| Knowledge governance | Genesis -> Custom | 企业内部知识 owner、有效期、权限、引用标准仍不成熟 | 这是高杠杆架构投资，不是简单工具采购 |
| EvalOps | Genesis -> Product | eval platform、judge、dataset registry 正在标准化 | 早建内部 eval contract 和 golden set，工具可买 |
| AI observability | Product | tracing、token、latency、feedback 工具成熟 | 平台统一 telemetry，接入 risk 和 incident loop |
| Tool gateway for agents | Genesis -> Custom | 权限、审批、idempotency、audit 模式还在形成 | 对金融动作必须内部控制，不能完全托管给 agent vendor |
| Policy-as-code for AI | Genesis -> Custom | 合规规则、输出约束、审批策略逐渐工程化 | 建立 policy owner 和 machine-enforceable controls |
| AI gateway | Custom -> Product | 多模型路由、审计、成本、guardrail 产品化 | 关键控制面可 hybrid：买底层，保留内部 policy abstraction |
| Customer-facing AI safety | Custom -> Product | guardrails、red-team、content safety 逐渐成熟 | 金融零售仍需本地化合规话术、适当性和升级机制 |
| Wealth suitability logic | Custom | 监管、产品、客户画像和建议责任高度本地化 | 不外包最终 suitability boundary，AI 只做受控辅助 |
| Credit decisioning policy | Custom | 部分自动化平台成熟，但风险偏好和解释责任本地化 | build / hybrid policy layer，供应商可提供模型或平台组件 |
4.3 演进位置到动作的转换
| Map position | 推荐动作 | 例子 | 风险 |
|---|---|---|---|
| 高可见 + Genesis | 探索、学习、差异化试验 | AI-native advisor experience、agentic AML investigation | 过早规模化，合规边界不清 |
| 高可见 + Custom | 核心产品投资 | 信贷审批工作台、财富顾问 copilot、case narrative workbench | 低估组织 adoption 和流程改造 |
| 高可见 + Product | 选择性购买并深度配置 | 客服 AI 套件、contact center AI | 被 vendor UI 限制体验和数据 |
| 低可见 + Genesis | 小团队研究，不进入主路线 | 新 agent memory、自治工具策略 | 技术驱动，缺业务证据 |
| 低可见 + Custom | 可能是平台投资窗口 | EvalOps contract、tool gateway、knowledge governance | 平台团队孤岛化 |
| 低可见 + Product | buy / hybrid | model gateway、RAG platform、observability | 锁定、成本、审计缺口 |
| 低可见 + Commodity | 直接消费，避免自研 | 云基础设施、基础日志、对象存储 | 忽略成本治理和可用性 |
5. AI Doctrine：地图之前先建立作战纪律
Doctrine 是不依赖具体场景、相对普遍适用的基本原则。AI 领域的 doctrine 不是口号，而是每张地图都要默认检查的前置纪律。
5.1 AI strategy doctrine
| Doctrine | 操作化解释 | 证据 |
|---|---|---|
| Know your users | 明确 customer、frontline、risk reviewer、developer、data owner、auditor 的不同需求 | Persona / actor map、workflow observation、adoption evidence |
| Focus on user need | 不以模型能力或供应商 demo 定义路线 | User need statement、business baseline |
| Understand the value chain | 把体验、流程、数据、模型、eval、治理和组织依赖画出来 | AI value chain map |
| Use appropriate methods | Genesis 用探索，custom 用工程和治理，commodity 用采购和自动化 | Evolution heatmap、sourcing memo |
| Challenge assumptions | 地图节点、位置、依赖和趋势必须能被不同角色挑战 | Assumption log、map review notes |
| Design for reversibility | 模型、供应商、prompt、index、policy、workflow 都要有 rollback / exit | Reversal trigger、exit plan、fallback design |
| Make risk measurable | 关键风险必须转成 eval、monitoring、control 和 release gate | NIST AI RMF aligned control pack |
| Keep platforms as products | 平台必须服务 internal customer adoption，不是架构团队的标准化欲望 | Platform PRD、team interaction contract、adoption metrics |
| Reduce cognitive load | 业务团队不应理解每个模型和 eval 细节才能安全交付 | Golden path、self-service API、enablement material |
| Preserve decision rights | 高风险金融决策必须明确人、规则、模型和系统的责任边界 | Decision boundary map、RACI、audit trail |
5.2 AI doctrine review questions
| Question | Good answer signal | Weak answer signal |
|---|---|---|
| User need 是否足够具体 | 能说出角色、任务、风险、频率、价值和失败成本 | “提升效率”“用 AI 降本” |
| Value chain 是否完整 | 包含知识、数据、权限、eval、audit、incident | 只有 UI 和模型 |
| Evolution 位置是否可辩护 | 每个关键组件都有市场证据、内部能力证据、供应商证据 | 凭团队直觉打点 |
| Build / buy 是否由地图推导 | 决策与组件可见性、演进位置、风险和差异化一致 | 先有偏好再补理由 |
| 平台边界是否清楚 | 平台提供 X-as-a-Service，业务保留 domain workflow | 所有能力都塞进平台 |
| 风险是否进入路线 | 高风险节点有 eval gate、HITL、monitoring、kill switch | 风险放到上线前一次性评审 |
6. Climatic Patterns：AI 领域的不可逆趋势
Climatic patterns 是不受单个企业意愿控制、但会改变战略地形的外部力量。AI PM / 架构师要把这些趋势写进地图假设，而不是等趋势发生后被动重排 roadmap。
6.1 AI climatic patterns
| Pattern | AI 领域表现 | 战略影响 |
|---|---|---|
| Everything evolves | 模型、RAG、agent、eval、gateway 都会从新颖走向产品化和商品化 | 不把今天的定制实现当长期架构，路线要预留替换 |
| Commoditization accelerates adoption | 模型 API、托管向量检索、AI observability 降低门槛 | 竞争差异转向 workflow、data、trust、distribution、governance |
| Higher-order systems emerge | 当模型和工具调用商品化，会出现更复杂 agentic workflow 和 AI operating model | 提前投资 tool gateway、state management、eval replay 和 incident response |
| Inertia is predictable | 老系统、数据 owner、合规流程、采购合同会抵抗变化 | 地图中要标出 inertia nodes，安排 migration 和 change strategy |
| Co-evolution of practice | 技术成熟会推动组织、流程和监管实践演进 | EvalOps、AI risk review、model registry 会从“创新团队做法”变成标准生产纪律 |
| Efficiency creates more demand | 模型价格下降不等于总成本下降，使用量会增加 | 必须投资 cost governance、quota、routing、caching 和 value attribution |
| Data gravity remains | 模型可换，但受控数据、标签、知识、事件和反馈难迁移 | 数据产品、knowledge governance 和 eval dataset 是长期资产 |
| Regulation follows harm | 客户可见、信贷、财富、AML、支付等高影响场景监管压力更高 | 低风险 copilot 与高风险 decisioning 不能共享同一控制强度 |
| Ecosystems beat isolated tools | 单点 AI 工具容易被平台、工作流系统或 hyperscaler 吸收 | 需要生态策略、API strategy、exit path 和 partner model |
6.2 趋势到投资主题
| Climatic pattern | Architecture investment | Product strategy |
|---|---|---|
| Foundation models commoditize | Model gateway、model evaluation、routing、fallback | 多模型策略，不卖“某模型能力”，卖业务 outcome |
| RAG tooling productizes | Knowledge governance、metadata、authorization-before-retrieval | 用可信知识体验做差异化 |
| Agentic workflows rise | Tool gateway、workflow state、approval queue、idempotency、kill switch | 从 read-only copilot 逐步走向 bounded action |
| Eval becomes standard | Dataset registry、release gate、production sampling、evidence binder | 把 eval 报告作为产品发布凭证 |
| AI cost becomes board-level | FinOps、quota、cost per successful task、budget guardrails | 用 unit economics 管 portfolio，不按 token 消耗讲价值 |
| Regulatory scrutiny grows | Risk tiering、audit trail、control pack、human oversight | 高风险路线先设计控制，再扩展功能 |
7. Strategic Gameplay：从地图到行动
Strategic gameplay 不是抽象战略词汇，而是对地图上具体节点采取行动。AI 领域尤其需要避免“全都做”“全都买”“全都平台化”的懒惰决策。
7.1 常用 AI strategic plays
| Play | 何时使用 | AI 示例 | 成功条件 |
|---|---|---|---|
| Exploit commodity | 组件已商品化，差异化低 | 使用云模型 API、托管日志、对象存储 | 严控成本、SLO、数据边界和 exit |
| Build where differentiated | 高可见、强领域差异、强控制需求 | 财富顾问 suitability workflow、信贷 exception reason engine | 有 domain owner、数据资产、eval 和长期维护能力 |
| Buy mature components | Product / commodity 组件成熟 | Contact center AI、OCR、managed vector DB、eval dashboard | 合同可审计、集成可控、数据可导出 |
| Partner for capability transfer | 需要领域实施或监管解释，但不能外包核心能力 | AML taxonomy setup、credit policy mapping、knowledge migration | 明确 knowledge transfer、internal owner 和退出条件 |
| Platform the invisible repeated capabilities | 多业务重复且低可见组件 | model gateway、EvalOps、tool gateway、audit、cost dashboard | 平台团队以 internal customers 和 adoption 为指标 |
| Differentiate through workflow | 底层模型相似，流程体验可形成优势 | AML investigator workbench、advisor desktop、客服坐席 copilot | 深入真实流程，减少切换成本和认知负荷 |
| Use ecosystem leverage | 市场产品化快，自己无法覆盖 | 与 hyperscaler、SI、domain SaaS、data vendor 形成组合 | 保留架构控制面和数据资产 |
| Attack inertia | 竞争者被遗留系统或采购锁定 | 用 thin layer、API facade、shadow mode、parallel run 快速落地 | 避免制造新一代不可替换 legacy |
| Open standards / portability | 供应商锁定风险高 | 日志 schema、eval dataset、policy config、prompt registry 可导出 | 把 portability 写进架构和合同 |
| Fast follower | 技术演进快但差异化不高 | 不自研通用 agent framework，等待成熟产品 | 保留实验窗口和替换能力 |
7.2 AI 竞争地形地图
竞争不是“谁的模型分数高”，而是谁控制了 value chain 中最有杠杆的节点。
| Competitor type | 控制的节点 | 优势 | 弱点 | 我方打法 |
|---|---|---|---|---|
| Hyperscaler / cloud AI platform | Model access、infra、security、data platform、observability | 集成深、规模大、采购便利 | 领域工作流浅，容易锁定 | 利用基础能力，保留 domain workflow、eval contract 和 policy layer |
| Foundation model provider | Model quality、API、tool ecosystem | 能力迭代快，开发者心智强 | 企业治理、workflow、行业责任有限 | 多模型路由，避免单模型依赖 |
| Enterprise SaaS vendor | CRM、contact center、case management、workflow | 已在业务流程内，有分发 | 跨系统平台能力弱，定制受限 | 让其服务特定流程，不让其吞掉全局 AI 控制面 |
| Domain AI vendor | AML、KYC、credit、wealth 等行业流程 | 领域模板和实施经验 | 数据适配、审计、模型透明度不一 | 做 vendor diligence，内部掌握 policy、eval、audit 和 exit |
| SI / consulting partner | 交付能力、流程梳理、变更管理 | 能快速铺项目 | 容易制造定制债和知识外流 | partner for acceleration，不外包核心架构判断 |
| Open-source ecosystem | Framework、模型、eval、observability 工具 | 灵活、透明、成本可控 | 运维和安全责任在内部 | 用于可控组件和防锁定，生产前补治理 |
| Internal platform team | 组织上下文、权限、审计、风险责任 | 可对齐企业控制和复用 | 可能脱离业务、过度抽象 | 用 Team Topologies 的 platform-as-product 约束 |
7.3 Strategic gameplay selection matrix
| Map observation | Recommended gameplay | 例子 |
|---|---|---|
| 高价值节点在 Genesis，竞争者也不成熟 | 探索 + 小规模差异化 | AI-native relationship manager assistant |
| 高价值节点在 Custom，我方有领域数据 | Build / hybrid | 信贷 policy exception reasoning、AML entity graph |
| 低可见节点在 Product，多个团队重复建设 | Platform + buy / hybrid | EvalOps、model gateway、RAG ingestion |
| 低可见节点在 Commodity | Consume + govern | Cloud runtime、basic logging、storage |
| Vendor 控制高风险决策边界 | Rebalance boundary | 把决策、政策和审计层拉回内部 |
| 业务团队绕过平台 | Improve platform UX | 增加 golden path、SDK、self-service、support model |
| 地图显示多个 use case 共享同一知识治理瓶颈 | Invest in architecture runway | Knowledge source registry、metadata、permission model |
| 成本节点快速右移但用量上升 | FinOps gameplay | quota、routing、cache、unit economics |
8. Build / Buy / Partner Decision
Build / buy / partner 不是采购问题，而是地形问题。先看组件在地图上的位置，再看差异化、风险、控制权、组织能力和经济性。
8.1 决策原则
| Option | Best when | Avoid when | Evidence |
|---|---|---|---|
| Build | 组件靠近用户价值、高差异、强监管责任、需要内部控制、长期规模经济成立 | 市场已有成熟产品且差异化低；内部没有运行能力 | Capability thesis、TCO、architecture ADR、operating model |
| Buy | 组件成熟、标准化、非差异化、time-to-value 关键、供应商有审计证据 | 高风险决策边界被供应商黑箱控制；数据和日志不可导出 | Vendor scorecard、security review、exit plan、contract terms |
| Partner | 需要领域知识、迁移能力、实施速度或 change management；内部必须学习接管 | Partner 变成永久外包核心能力 | Knowledge transfer plan、RACI、handover criteria |
| Hybrid | 底层或工具成熟，但 policy、eval、audit、domain workflow 必须内部控制 | 边界复杂到团队无法运营 | Boundary ADR、integration contract、support model |
8.2 AI build-buy-partner matrix
| Component | Default stance | Why | Boundary guardrail |
|---|---|---|---|
| Foundation model | Buy / multi-provider | 快速商品化，单模型不是长期护城河 | 通过 model gateway 管理版本、日志、成本和 fallback |
| Model gateway | Hybrid | 可买底层能力，但企业 policy、routing、audit、cost attribution 是控制面 | 内部保留 policy abstraction 和 logs export |
| RAG platform | Hybrid | parsing、index、retrieval 工具成熟；知识治理差异化 | 内部掌握 source registry、permission、freshness、eval |
| Domain ontology | Build / partner | AML、信贷、财富和客服术语高度本地化 | Partner 可加速，但 owner 必须在内部 |
| EvalOps tooling | Buy / hybrid | 工具产品化，但 eval contract 和 golden set 是核心资产 | 数据集、rubric、release thresholds 内部控制 |
| Tool gateway | Build / hybrid | 金融动作权限、审批、幂等和审计责任高 | 不允许 vendor agent 直接绕过企业授权 |
| Customer service copilot UI | Buy / configure | contact center AI 已产品化，价值在 adoption 和知识治理 | 客户可见回答规则、升级路径、日志内部可审计 |
| AML investigation workbench | Hybrid | 领域流程、证据链、SAR 边界强差异 | 可买 extraction / summarization，内部控制 case narrative 和 approval |
| Credit decisioning | Build / hybrid | 风险偏好、政策例外、解释和模型风险责任本地化 | AI 不应黑箱替代审批责任 |
| Wealth advisor assistant | Hybrid | suitability、建议边界、客户信任高风险 | 供应商可供内容和工具，内部保留建议策略和合规审核 |
8.3 Decision memo 模板
# AI Build / Buy / Partner Decision Memo
## 1. Decision
- Use case: AML investigation copilot
- Component: Evidence retrieval and SAR narrative drafting
- Recommendation: Hybrid
- Decision owner: Head of Financial Crime Product
- Review date: 2026-09-30
## 2. Map Context
- User need: Investigator needs faster evidence gathering and regulator-ready narrative draft without losing human accountability.
- Value chain position: High-visible workflow and narrative layer depend on lower-visible retrieval, entity graph, LLM summarization, EvalOps and audit.
- Evolution stage: Narrative boundary and red flags are custom; LLM summarization is product / commodity; retrieval tooling is product; AML eval dataset is custom.
- Dependencies: Case management, transaction history, entity graph, sanctions / watchlist data, policy documents, model gateway, evidence binder.
- Competitor / vendor landscape: Domain AML vendors offer workflow accelerators; hyperscalers offer model and search infrastructure; internal risk team controls policy and SAR accountability.
## 3. Strategic Rationale
- Differentiation: Case evidence quality, investigator workflow and SAR narrative evidence chain.
- Control requirement: SAR decision, red flag taxonomy, audit schema and release thresholds remain internally controlled.
- Risk tier: High, because wrong recommendations can affect regulatory reporting and investigation quality.
- Time-to-value: Buy mature extraction / summarization components to shorten pilot, build internal evaluation and approval boundary.
- Scale economics: Shared retrieval, model gateway and EvalOps can support KYC, fraud and compliance operations.
- Reversibility: Model and retrieval provider can be replaced if eval regression, audit gaps or cost thresholds are breached.
## 4. Options Considered
| Option | Benefits | Costs | Risks | Reversal trigger |
|---|---|---|---|---|
| Build | Maximum control over workflow, policy and evidence chain | Slower delivery and higher operating burden | Reinventing mature LLM / search capabilities | If delivery misses pilot gate by two review cycles |
| Buy | Faster pilot and vendor domain accelerators | Contract, integration and data governance effort | Vendor controls too much of SAR boundary | If audit logs, eval export or policy control are insufficient |
| Partner | Speeds taxonomy, workflow migration and change management | Requires strong knowledge transfer management | Long-term dependency on external experts | If internal owners cannot operate without partner after agreed handover |
| Hybrid | Uses mature components while retaining decision boundary and evidence control | Boundary design and integration complexity | Ownership confusion between vendor, platform and AML team | If support model or control ownership remains unclear after pilot |
## 5. Required Controls
- Data boundary: PII and investigation data only through approved gateway, no provider training use, retention aligned to compliance policy.
- Eval gate: Critical failures for fabricated evidence, stale policy citation, missing adverse signal and unauthorized disclosure must be zero.
- Audit evidence: Store input metadata, retrieved sources, model version, prompt version, narrative draft, reviewer approval and final action.
- Human oversight: Investigator remains accountable for SAR narrative and escalation decision.
- Incident response: Wrong evidence, leakage, unsafe recommendation, tool failure and cost runaway enter AI incident taxonomy.
- Exit path: Export prompts, eval datasets, logs, retrieval index metadata and case evidence schema.
## 6. Decision
- Selected option: Hybrid.
- Why now: LLM summarization and retrieval tooling are mature enough, while AML evidence and audit controls remain strategic.
- What would make this decision wrong: Vendor cannot expose required logs, internal team cannot maintain eval dataset, or investigator adoption remains below agreed threshold.
- Next governance checkpoint: Pilot gate review after 200 sampled cases and model risk signoff.
9. Platform vs Product Boundary
AI 平台边界的核心不是“共享能力越多越好”，而是让 stream-aligned product teams 更快、更安全、更低认知负荷地交付 AI 产品。
9.1 平台应该承担的能力
| Platform capability | 为什么平台化 | Internal customer |
|---|---|---|
| AI use case intake + risk tiering | 统一进入 portfolio，避免暗箱 pilot | AI PM、business owner、risk reviewer |
| Model gateway | 模型路由、日志、成本、fallback、allowlist 一致 | AI app team、security、FinOps |
| Prompt / config registry | 版本、审批、回滚、环境隔离 | Product team、risk、ops |
| Knowledge ingestion baseline | 连接器、metadata、权限、freshness 基线 | Knowledge owner、domain team |
| Retrieval evaluation starter kit | 统一衡量 citation、grounding、stale source | RAG product team |
| Tool gateway | 工具权限、审批、审计、幂等、kill switch | Agent product team、security |
| EvalOps platform | dataset、runner、judge、release gate、evidence | Product, architecture, model risk |
| AI observability | trace、latency、cost、quality、feedback、incident | SRE、ops、risk |
| Policy guardrail service | 统一底线：PII、越权、禁止建议、升级规则 | Legal、compliance、product |
| Cost governance | quota、budget、cost per successful task | Sponsor、FinOps、platform PM |
9.2 产品团队应该保留的能力
| Product / domain capability | 为什么不应平台吞掉 |
|---|---|
| User need and workflow ownership | 业务流程、采用方式和价值指标必须由 stream-aligned team 负责 |
| Domain policy interpretation | AML、信贷、财富、客服政策不能由平台团队代替业务责任人解释 |
| Product experience | 不同角色需要不同 UX、信任信号、升级路径和反馈机制 |
| Domain eval cases | golden set、failure taxonomy、rubric 需要领域专家维护 |
| Business outcome accountability | 平台负责加速和控制，产品负责业务结果 |
| Adoption and change management | 用户行为改变必须在业务团队里发生 |
9.3 Team Topologies 边界设计
| Team type | AI strategy role | Interaction mode |
|---|---|---|
| Stream-aligned team | 负责 AML、客服、信贷、财富等具体 AI 产品价值流 | 主要消费平台 X-as-a-Service，也与平台短期 collaboration |
| Platform team | 提供 model gateway、EvalOps、tool gateway、knowledge baseline、observability | X-as-a-Service；用 platform roadmap 管 internal customer |
| Enabling team | 帮助业务团队掌握 eval、RAG、risk controls、AI-native workflow design | Facilitation；短期嵌入，降低认知负荷 |
| Complicated subsystem team | 深度模型、优化、实体图谱、特征工程、高风险 decisioning engine | Collaboration + internal service；处理专业复杂度 |
9.4 Boundary ADR 模板
# AI Platform Boundary ADR
## Context
- Product / use case: Customer service knowledge platform.
- User need: Agents need current, authorized and cited answers across products and customer states.
- Shared platform capabilities consumed: Model gateway, knowledge ingestion baseline, retrieval evaluation, prompt registry, guardrail service, AI observability.
- Domain capabilities retained locally: Product answer policy, customer eligibility rules, escalation path, tone policy, training and adoption metrics.
## Decision
- Platform owns: Gateway, metadata standard, retrieval baseline, eval runner, trace schema, cost attribution and guardrail primitives.
- Product team owns: Customer journey, answer policy, source owner workflow, launch sequencing, agent coaching and outcome metrics.
- Shared governance owner: CX product lead, compliance reviewer, platform PM and enterprise architect.
- Interaction mode: X-as-a-Service / Collaboration / Facilitation
## Rationale
- Reuse evidence: AML, KYC and service use cases all need retrieval, citation, prompt versioning and trace review.
- Cognitive load reduction: Product teams consume approved ingestion and eval patterns instead of building search and model controls.
- Risk control: Platform enforces permission-before-retrieval and release gates; CX owns answer accuracy and escalation rules.
- Differentiation: Customer trust and agent workflow remain product-specific.
- Cost / speed impact: Shared gateway and retrieval reduce duplicate engineering while allowing domain teams to move independently.
## Consequences
- Benefits: Faster pilots, consistent audit evidence, clearer source ownership and lower duplicate platform spend.
- Trade-offs: More upfront boundary design and shared prioritization.
- Operational responsibilities: Platform SLO for shared services; CX owns knowledge freshness and adoption.
- Metrics: Time-to-safe-pilot, retrieval groundedness, agent adoption, answer correction rate, cost per resolved contact.
- Revisit trigger: Two product teams require unsupported retrieval pattern or platform adoption falls below agreed target.
10. 架构投资路线：从地图到 Architecture Runway
AI 架构投资必须绑定地图上的 bottleneck、control point 和 evolution movement。不要因为某项技术热门就进入 runway。
10.1 投资主题
| Investment theme | Map signal | Architecture deliverable | Business payoff |
|---|---|---|---|
| AI gateway | 多团队接模型、成本不可见、供应商依赖上升 | Model gateway、routing policy、quota、fallback、logs | 降低接入成本，提升可替换性和治理 |
| EvalOps | 多 use case 上线靠主观体验，缺 release evidence | Dataset registry、eval runner、release gate、production sampling | 让质量和风险可决策 |
| Knowledge governance | 多个 RAG 共享低质量知识源 | Source registry、metadata standard、permission filter、freshness SLA | 提高引用可信度和复用 |
| Tool gateway | agent 需要调用内部系统 | Tool catalog、authZ、approval、idempotency、kill switch | 支持 bounded action，控制越权和误操作 |
| Domain evidence graph | AML、欺诈、信贷需要实体和关系证据 | Entity graph、case link、evidence lineage | 提高调查质量和解释力 |
| Policy-as-code | 合规规则散落在文档和 prompt | Machine-enforceable policies、approval workflow | 减少违规输出和变更不可追溯 |
| AI observability | 生产问题难定位 | End-to-end trace、quality signal、incident taxonomy | 提高可运营性和审计能力 |
| Cost / FinOps | 使用增长快，账单不可解释 | Cost attribution、budget caps、cache、unit economics | 防止规模化后 ROI 失真 |
| Developer golden path | 业务团队重复造轮子 | SDK、reference app、templates、docs、support model | 降低认知负荷，加快安全交付 |
10.2 投资优先级评分
| Dimension | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| Value chain leverage | 只影响单点小任务 | 改善一个流程节点 | 支撑多个高价值 AI value streams |
| Reuse potential | 单一团队 | 两个 use case | 多业务、多产品、多模型复用 |
| Risk reduction | 风险影响不清 | 降低部分上线风险 | 形成正式 release gate 或 control plane |
| Competitive impact | 内部效率 | 改善 time-to-market | 形成领域体验、数据、合规或成本优势 |
| Evolution timing | 市场不成熟且需求弱 | 可试点 | 组件正在产品化，适合 hybrid 抢占窗口 |
| Operating readiness | owner 不清 | 有候选 owner | 平台、业务、风险、SRE owner 明确 |
分数解释：
- 24-30：进入 architecture runway，并配 funding gate。
- 18-23：进入 pilot runway，限定范围和复盘点。
- 12-17：先做 discovery、供应商验证或组织能力补强。
- 低于 12：不进入路线，保留观察。
11. 金融零售案例
以下案例用同一套地图语言：user need、value chain、evolution、platform boundary、sourcing、architecture investment、strategic gameplay。
11.1 AML Copilot
User need
AML investigator 需要在有限时间内识别高风险可疑活动，快速聚合证据，生成可审查的 narrative draft，同时保留人工判断、监管证据链和 SAR 决策责任。
Value chain
| Node | Evolution | Strategic note |
|---|---|---|
| Investigator case outcome | Custom | 高可见、高责任，必须按机构 AML 操作模型设计 |
| Case triage workbench | Custom | 体验和流程差异化明显 |
| SAR narrative draft | Custom | AI 可 draft，但 SAR 决策必须保留给授权人员 |
| Red flags taxonomy | Custom | 机构政策、地区监管和风险偏好本地化 |
| Entity / transaction graph | Custom -> Product | 图谱工具可买，但实体解析、风险解释和 lineage 是核心资产 |
| Evidence retrieval | Product -> Custom | 检索工具成熟，证据来源、权限、引用要内部治理 |
| LLM summarization | Product -> Commodity | 不形成长期差异 |
| Eval cases | Custom | 历史 case、false positive、missed risk、regulator feedback 是核心资产 |
| Audit / evidence binder | Custom -> Product | 工具可买，证据 schema 和监管响应由内部控制 |
Build / buy / partner
| Component | Decision | Rationale |
|---|---|---|
| Foundation model | Buy via gateway | 摘要和文本生成不是差异化 |
| AML workbench UX | Build / hybrid | 工作流、证据展示、升级路径与机构流程强相关 |
| Transaction / entity graph | Hybrid | 图数据库和 entity resolution 可买，风险语义和数据 lineage 内部掌握 |
| Red flags taxonomy | Build + partner | 可让专家顾问加速，但 owner 必须在 financial crime team |
| Eval dataset | Build | 历史 case 和质量门槛是核心控制资产 |
| SAR decision boundary | Build governance | 不允许供应商或 AI 黑箱做最终监管判断 |
Strategic gameplay
- 用 commodity LLM 加速文本处理。
- 在 case evidence graph、workflow UX、eval set 和 audit binder 上 build。
- 通过 partner 加速 taxonomy 和流程迁移，但在 2-3 个季度内完成内部接管。
- 将 evidence retrieval、model gateway、EvalOps 纳入平台，AML-specific red flags 留在产品域。
11.2 客服知识平台
User need
客服坐席和数字渠道需要基于最新、授权、可引用的产品政策回答客户问题，降低平均处理时长、升级率和错误承诺风险。
Value chain
| Node | Evolution | Strategic note |
|---|---|---|
| Customer trust and answer quality | Custom | 品牌、合规话术、客户状态决定体验 |
| Agent assist / customer-facing UI | Product -> Custom | contact center AI 可买，但语气、升级、限制条件要本地化 |
| Product policy knowledge | Custom | source owner、effective date、eligibility 和 jurisdiction 是核心 |
| Retrieval / citation | Product | 可买工具，但 eval 和权限过滤要统一 |
| Knowledge ingestion | Product -> Custom | 连接器可买，metadata 和 governance 是架构投资 |
| Conversation analytics | Product | SaaS 成熟 |
| Guardrails | Product -> Custom | 通用安全可买，金融承诺、费用、豁免、适当性规则需本地化 |
Platform boundary
| Platform owns | Product / CX owns |
|---|---|
| Knowledge ingestion baseline、metadata schema、retrieval eval、model gateway、conversation trace、guardrail service | Answer policy、customer journey、handoff rules、tone、training、adoption、business metrics |
Strategic gameplay
- Buy contact center AI capabilities where mature。
- Build knowledge governance and answer policy。
- Platformize retrieval、EvalOps、guardrails、observability。
- 用 A/B 或 shadow mode 比较 AI-assisted answer quality，但高风险话术先走坐席 copilot，不直接 customer-facing。
11.3 信贷 Decisioning
User need
信贷团队需要更快、更一致、更可解释地完成申请评估、政策例外判断、材料缺口识别和审批 memo，但不能把受监管的最终授信责任交给不可解释的 AI。
Value chain
| Node | Evolution | Strategic note |
|---|---|---|
| Credit decision accountability | Custom | 风险偏好、监管、模型风险和审批责任高度本地化 |
| Underwriter workflow | Custom | 体验和例外处理可差异化 |
| Policy eligibility check | Custom -> Product | 规则引擎成熟，但政策语义和 exception reason 本地化 |
| Document extraction | Product | OCR / extraction 可买 |
| Scorecard / ML risk model | Custom -> Product | 传统模型成熟，GenAI 不替代核心评分责任 |
| Explainability / adverse action reasons | Custom | 高监管敏感，必须内部控制 |
| Eval / backtesting | Custom | 历史申请、拒绝理由、违约结果、fair lending slices 是核心资产 |
Decision boundary
| AI level | Allowed | Not allowed |
|---|---|---|
| Inform | 政策引用、材料缺口、历史相似案例 | 生成未经验证的政策解释 |
| Draft | 贷审 memo 草稿、question list、exception summary | 自动给客户发送拒绝或批准理由 |
| Recommend | 低风险补件建议、人工复核优先级 | 黑箱替代审批人 |
| Act | 创建内部任务、预填字段并等待审批 | 自动批准、自动拒绝、自动调额 |
Strategic gameplay
- Build policy and decision boundary。
- Buy document extraction and workflow acceleration。
- Hybrid scorecard / ML platform，但 model risk、fairness slices、reason code 和 approval responsibility 内部控制。
- Invest in backtesting, adverse action evidence, policy-as-code and audit trail。
11.4 财富顾问
User need
财富顾问需要在客户目标、风险承受能力、持仓、产品适当性和市场信息之间形成更高质量的建议准备材料，同时保持 suitability、披露、审批和客户沟通责任清晰。
Value chain
| Node | Evolution | Strategic note |
|---|---|---|
| Client trust / suitability | Custom | 高可见、高风险，是差异化和监管责任中心 |
| Advisor desktop | Custom / Product | CRM 和财富平台可买，顾问工作流需定制 |
| Portfolio analysis | Product | 分析工具成熟 |
| Product universe and restrictions | Custom | 机构产品、限制名单、客户资格本地化 |
| Meeting prep summary | Product -> Custom | LLM 摘要可买，合规边界需内部设计 |
| Recommendation drafting | Custom | 必须受 suitability、审批和 disclosure 控制 |
| Market commentary | Product | 可买内容，但引用和许可要清楚 |
| Audit and supervision | Custom -> Product | 监管和机构政策强约束 |
Platform boundary
| Shared platform | Wealth product domain |
|---|---|
| Model gateway、retrieval、content licensing metadata、prompt registry、EvalOps、audit logging | Suitability policy、advisor workflow、recommended action boundary、disclosure language、supervision rules |
Strategic gameplay
- 不把“客户面对面的自动投资建议”作为第一阶段目标。
- 先做 advisor copilot：prepare、summarize、compare、draft with approval。
- Build suitability boundary and disclosure controls。
- Partner with content / market data providers，但保留建议策略和客户沟通责任。
11.5 AI Gateway / EvalOps 平台
User need
业务 AI 团队需要快速、安全、可评估、可审计地构建 AI 应用；风险、合规、架构和平台团队需要统一控制模型接入、成本、质量、变更和证据。
Value chain
| Node | Evolution | Strategic note |
|---|---|---|
| AI product teams shipping safely | Custom | internal customer need，要用 platform-as-product 管 |
| Golden paths / SDK | Custom -> Product | 组织上下文强，先内部建 |
| Model gateway | Product | 可 buy / hybrid |
| Prompt / config registry | Product -> Custom | 工具可买，审批和 policy 适配内部 |
| EvalOps | Genesis -> Product | 工具成熟中，eval contract 和 dataset 内部建 |
| AI observability | Product | buy / integrate |
| Cost attribution | Product | buy / integrate，和 internal chargeback 适配 |
| Evidence binder | Custom -> Product | 审计证据 schema 要结合金融治理 |
Platform strategy
| Capability | MVP stance | Scale stance |
|---|---|---|
| Model gateway | Hybrid: approved models, logs, cost attribution | Multi-provider routing, fallback, risk-based policy |
| EvalOps | Build eval contract + buy runner if useful | Dataset registry, release gates, production sampling |
| Knowledge governance | Start with 2 source systems and metadata standard | Enterprise source registry and permission-before-retrieval |
| Tool gateway | Start read-only and approval-only actions | Risk-tiered tool catalog, idempotency, kill switch |
| Developer experience | Reference apps and templates | Self-service platform with SLO and support model |
Strategic gameplay
- 平台从 2-3 个高价值 use case 的重复痛点中抽象，不从空白架构蓝图开始。
- 低可见、重复、控制强的能力平台化。
- 高可见、领域差异的工作流保留给 stream-aligned teams。
- 平台指标用 time-to-safe-pilot、eval coverage、reused components、cost per successful task 和 incident rate，不只看 API calls。
12. 模板
12.1 AI Wardley Map Canvas
# AI Wardley Map Canvas
## User Need
- Primary actor: AML investigator.
- Need: Prepare evidence-backed case narrative faster while preserving human accountability.
- Frequency: Daily case review and escalation workflow.
- Business value: Lower investigation cycle time, better consistency and stronger regulatory evidence.
- Risk / harm if wrong: Missed suspicious activity, fabricated evidence, privacy breach or poor regulator response.
## Value Chain
| Node | Dependency | User visibility | Owner | Evidence |
|---|---|---:|---|---|
| Case narrative | Evidence retrieval, red flags, model gateway | High | AML product owner | Reviewer quality score and SAR audit sample |
| Evidence retrieval | Source registry, permissions, entity graph | Medium | Knowledge / data owner | Citation accuracy and stale-source eval |
| EvalOps | Golden set, failure taxonomy, release gate | Low | EvalOps lead | Critical failure report and approval record |
## Evolution Placement
| Node | Genesis | Custom | Product | Commodity | Rationale |
|---|---:|---:|---:|---:|---|
| SAR narrative boundary | Low | High | Low | Low | Institution policy and accountability are local |
| LLM summarization | Low | Low | High | Medium | Multiple providers can perform generic summarization |
| Audit logging | Low | Medium | High | Low | Tools mature, but evidence schema is institution-specific |
## Climatic Patterns
| Pattern | Impact on this map | Timing | Confidence |
|---|---|---|---|
| Model commoditization | Model choice becomes less differentiating than evidence and eval | 6-12 months | High |
| Regulatory scrutiny | SAR-related AI output needs stronger audit and human oversight | Continuous | High |
## Strategic Gameplay
| Node | Play | Build / buy / partner | Architecture investment | Reversal trigger |
|---|---|---|---|---|
| Evidence retrieval | Hybrid platform capability | Buy search components, build source governance | Knowledge registry and retrieval eval | Citation accuracy below release threshold |
| SAR narrative boundary | Build domain control | Internal policy and approval design | Workflow audit and human review queue | Reviewer override rate remains excessive |
12.2 Evolution Heatmap
| Component | Current stage | Evidence | Movement expected | Action | Owner |
|---|---|---|---|---|---|
| Foundation model access | Product -> Commodity | Multiple providers, falling prices, API parity | More commodity | Buy through gateway | Platform |
| Domain policy | Custom | Institution policy, jurisdiction, risk appetite | Slow movement | Build / govern | Domain |
| Eval dataset | Custom | Internal historical cases and expert labels | Becomes strategic asset | Build | EvalOps + domain |
12.3 Strategic Gameplay Register
| Play ID | Map node | Move | Why now | Expected advantage | Risk | Control | Review date |
|---|---|---|---|---|---|---|---|
| PLAY-001 | Model gateway | Hybrid platform | Multiple teams integrating models separately | Cost, audit, routing, replacement | Platform friction | Golden path + support | 2026-09-30 |
12.4 Competitive Landscape Canvas
| Competitor / vendor | Value chain nodes controlled | Evolution stage | Strength | Weakness | Our response |
|---|---|---|---|---|---|
| Domain AML vendor | Case workbench, typology templates, investigation accelerators | Product / custom | Fast pilot and domain workflow patterns | May not expose full eval, audit and policy control | Use for acceleration, keep SAR boundary and evidence schema internal |
| Hyperscaler AI platform | Model access, search, observability, security primitives | Product / commodity | Scale and enterprise integration | Limited domain workflow | Consume infrastructure, build domain controls and eval assets |
12.5 Architecture Investment Thesis
# Architecture Investment Thesis
## Investment
- Name: Enterprise AI Gateway and EvalOps control plane.
- Value chain bottleneck: Multiple AI product teams need safe model access, release evidence, traceability and cost control.
- Components affected: Model gateway, prompt registry, eval runner, dataset registry, audit log, cost attribution.
- Risk tier: Medium to high, because the platform supports both employee copilot and regulated workflow use cases.
## Strategic Reason
- User need improved: Stream-aligned teams can launch AI pilots faster without rebuilding model, eval and audit controls.
- Competitive gap closed: Reduces time-to-safe-pilot while competitors remain blocked by fragmented PoCs or vendor lock-in.
- Platform reuse: AML, KYC, service, credit and wealth use cases share gateway, eval and observability.
- Control / compliance benefit: Creates consistent release gate, model log, prompt version, dataset lineage and evidence binder.
## Evidence
- Current pain: Teams connect models directly, release quality is reviewed inconsistently and cost attribution is unclear.
- Pilot signal: Two or more use cases require the same model logging, eval runner and retrieval trace capabilities.
- Cost of delay: Duplicate integrations, delayed risk signoff, weak audit reconstruction and rising token spend.
- Alternatives considered: Allow local implementations, buy a full AI suite, or build a lightweight internal control plane.
## Delivery Shape
- Build / buy / partner: Hybrid, using mature gateway / observability components while building internal policies, eval contracts and evidence schema.
- Platform boundary: Platform owns shared controls; product teams own domain workflow and outcome metrics.
- Teams involved: Platform, security, model risk, EvalOps, enterprise architecture and two pilot product teams.
- Release gates: Gateway onboarding, eval threshold approval, production sampling and quarterly map review.
## Success Metrics
- Adoption: Percent of new AI use cases using gateway and EvalOps before pilot.
- Quality: Percent of releases with passing eval report and zero critical failures.
- Risk: Audit reconstruction completeness and incident closure time.
- Cost: Cost per successful task and model spend by use case.
- Business outcome: Time-to-safe-pilot and reuse across business teams.
## Stop / Revisit Rule
- Stop if: Product teams bypass the platform because golden paths are slower than local implementation.
- Revisit if: Vendor gateway becomes insufficient for internal policy, audit or data boundary requirements.
- Scale if: Three high-value use cases pass release gates and show measurable reduction in integration and review time.
13. 评审清单
13.1 Map quality checklist
| Check | Pass signal |
|---|---|
| User need 清晰 | 能说清 actor、task、outcome、risk、frequency |
| Value chain 完整 | 包含 workflow、decision boundary、domain policy、data、model、eval、audit、infra |
| Evolution placement 可挑战 | 每个关键节点有供应商、市场、内部能力或案例证据 |
| 依赖关系真实 | 上层体验依赖的底层知识、权限、eval 和控制被画出 |
| 趋势假设明确 | 包含 commoditization、regulation、cost、ecosystem、inertia |
| Gameplay 可执行 | 每个动作有 owner、投资、边界和复盘条件 |
13.2 Build / buy / partner checklist
| Check | Pass signal |
|---|---|
| 不是先有结论 | 决策由 map position、risk、differentiation、control 和 economics 推导 |
| Vendor risk 可管理 | 数据、日志、模型版本、subprocessor、SLA、exit path 清楚 |
| 内部能力不空心化 | 核心 policy、eval、decision boundary 和 audit owner 留在内部 |
| Partner 有退出机制 | 明确 knowledge transfer、handover 和内部 owner |
| Build 有运行能力 | 团队、SRE、security、risk、support 和 funding 可持续 |
13.3 Platform boundary checklist
| Check | Pass signal |
|---|---|
| Internal customer 明确 | 平台服务哪些 stream-aligned teams 和哪些任务 |
| Cognitive load 降低 | 平台提供 golden path、SDK、reference app、support model |
| 复用证据充分 | 至少 2 个高价值 use case 共享能力或控制点 |
| 不吞掉 domain ownership | 业务 team 保留 workflow、domain eval、adoption、business outcome |
| Interaction mode 清楚 | Collaboration、X-as-a-Service、Facilitation 被明确选择 |
| Metrics 不虚 | 使用 safe pilot speed、reuse、eval coverage、cost、incident，而不是只看调用量 |
13.4 Financial retail AI risk checklist
| Area | Pass signal |
|---|---|
| Customer impact | 明确客户权益、资金、信用、隐私和投诉影响 |
| Human oversight | 高风险 decisioning 有人工责任、审批和 override |
| Explainability | 信贷、财富、AML 输出有 reason、evidence、citation 或 policy reference |
| Fairness / bias | 信贷、营销、服务优先级有 slice analysis 和监控 |
| Audit | 能重建 input、context、model、prompt、tool、output、approval、final action |
| Incident | 有 unsafe output、data leakage、wrong advice、cost runaway、tool misuse 的处理流程 |
| Reversibility | 可以 rollback、disable、switch model、re-index、replay eval、通知 owner |
14. 反模式
| Anti-pattern | 表现 | 后果 | 纠正动作 |
|---|---|---|---|
| Chatbot-as-strategy | 所有需求都变成聊天入口 | 高风险流程被浅层 UI 掩盖 | 回到 user need 和 workflow insertion point |
| Vendor-first strategy | 先选供应商再定义问题 | 锁定、范围膨胀、价值不清 | 先画 map，再做 vendor scorecard |
| Model-as-moat | 把某个 foundation model 当长期优势 | 快速被商品化 | 投资 workflow、data、eval、trust、distribution |
| RAG as data governance | 把文档丢进向量库就算知识平台 | 过期、越权、错误引用 | 建 source registry、metadata、permission、freshness |
| Eval theatre | 上线前跑几个 happy path | 生产风险不可见 | 建 failure taxonomy、golden set、critical gates |
| Platform maximalism | 平台团队试图统一所有业务流程 | 业务绕行，平台 adoption 低 | 平台只做低可见、重复、控制强能力 |
| Product team local optimum | 每个团队自建模型、RAG、日志、eval | 成本高、治理不一致 | 共享 model gateway、EvalOps、audit 和 guardrails |
| Partner dependency trap | SI / vendor 永久掌握核心知识 | 内部能力空心化 | 设定 knowledge transfer 和 internal owner |
| Automation before decision rights | 先让 agent 执行动作，再补审批 | 越权、事故、审计失败 | 先画 decision boundary 和 tool permission |
| All-build ideology | 认为自研才安全 | 慢、贵、重复造轮子 | 商品化组件 buy，控制面和差异化 build |
| All-buy ideology | 认为 vendor handles everything | 核心责任外包、审计薄弱 | 内部保留 policy、eval、audit、decision boundary |
| Static map | 地图画完不更新 | 路线和市场脱节 | 每季度复盘 evolution movement 和 gameplay |
15. 30 天训练计划
目标：30 天内形成一套可展示的 AI Wardley Mapping portfolio，不训练基础 PM 技能，只训练战略地图、平台边界、build / buy / partner、竞争地形和架构投资判断。
| Day | Focus | Output | Review question |
|---|---|---|---|
| 1 | 阅读 Wardley Mapping book 目录和核心概念 | 1 页方法摘要 | user need、value chain、evolution 如何互相约束 |
| 2 | 拆解 NIST AI RMF | AI risk 到 map 节点映射表 | 哪些地图节点必须进入 Govern / Measure / Manage |
| 3 | 拆解 Team Topologies | AI 平台团队边界草图 | 平台 team 服务谁，降低什么认知负荷 |
| 4 | 选择 5 个金融零售 AI 场景 | Scenario shortlist | 每个场景的 actor 和 risk 是否不同 |
| 5 | AML Copilot user need | AML user need + value chain v1 | 哪些节点高可见、哪些节点低可见 |
| 6 | AML evolution mapping | AML evolution heatmap | 哪些 build，哪些 buy，哪些 partner |
| 7 | AML strategic gameplay | AML build-buy-partner memo | SAR 决策边界是否清楚 |
| 8 | 客服知识平台 value chain | Service knowledge map v1 | 知识治理瓶颈在哪里 |
| 9 | 客服平台边界 | Platform vs CX boundary ADR | 平台和 CX 团队 owner 是否分清 |
| 10 | 客服竞争地形 | Vendor / SaaS landscape table | 哪些 vendor 控制流程入口 |
| 11 | 信贷 decisioning map | Credit decisioning map v1 | AI 允许影响哪些决策，禁止哪些动作 |
| 12 | 信贷 eval / fairness | Credit eval slice plan | 哪些 failure 是 release blocker |
| 13 | 信贷 sourcing memo | Credit hybrid decision memo | 哪些政策和 reason code 必须内部掌握 |
| 14 | 财富顾问 map | Wealth advisor copilot map | suitability 和 disclosure 边界是否显式 |
| 15 | 财富顾问 gameplay | Advisor copilot phased strategy | 为什么先 advisor copilot 而不是客户自动建议 |
| 16 | AI gateway map | AI gateway value chain | gateway 是产品、平台还是控制面 |
| 17 | EvalOps map | EvalOps platform map | eval contract 和工具边界是否清楚 |
| 18 | Knowledge governance map | Enterprise knowledge map | source owner、freshness、permission 是否可执行 |
| 19 | Tool gateway map | Agent tool gateway control map | read、draft、act 的权限是否分层 |
| 20 | Competitive landscape | 6 类竞争者地形图 | 我方在哪些节点能赢 |
| 21 | Climatic pattern synthesis | AI climatic pattern memo | 哪些趋势会改变 12 个月路线 |
| 22 | Architecture investment scoring | 10 个投资主题评分 | 哪些进入 runway，哪些等待 |
| 23 | Portfolio roadmap | 4 季度 AI strategy roadmap | 顺序是否由依赖和演进推导 |
| 24 | Platform operating model | Team Topologies interaction model | collaboration 何时转 X-as-a-Service |
| 25 | Executive memo | 2 页高管决策备忘录 | 是否能解释 trade-off 而非堆术语 |
| 26 | ARB review pack | 架构评审包 | 是否包含 map、ADR、risk、eval、exit |
| 27 | Interview answers | 10 道高级面试答案 | 是否能用地图回答 build / buy / platform |
| 28 | Portfolio packaging | 作品集目录和 artifact links | 每个 artifact 是否证明一种能力 |
| 29 | Mock review | 自我挑战假设清单 | 哪些 map node 证据不足 |
| 30 | Final synthesis | AI Wardley Mapping case portfolio | 能否 15 分钟讲清战略、架构和投资路线 |
16. 面试答案
Q1：为什么 AI PM / 架构师要用 Wardley Map，而不是只做 roadmap？
30 秒回答： Roadmap 告诉团队什么时候做什么，但不解释为什么这个顺序是对的。Wardley Map 先把 user need、value chain、组件演进位置和外部趋势画出来，再推导 build / buy / partner、平台边界和架构投资。对 AI 来说，这能避免被模型 hype、供应商 demo 或孤立 PoC 牵着走。
2 分钟回答： AI 产品不是单一功能，它依赖 workflow、data、knowledge、model、eval、security、audit 和组织责任。传统 roadmap 很容易把这些依赖压扁成日期和功能列表。Wardley Map 的优势是展示地形：上层哪些体验和决策直接影响用户价值，下层哪些组件已经商品化，哪些仍是定制瓶颈，哪些趋势会不可逆地改变市场。比如 foundation model API 正在商品化，所以我不会把单一模型当战略护城河；但 AML evidence graph、credit reason code、wealth suitability boundary 和 eval dataset 更接近差异化和控制点，应该 build 或 hybrid。地图让路线、平台投资和供应商决策可辩护。
Q2：如何用地图做 AI build / buy / partner 决策？
30 秒回答： 我先看组件在 value chain 的可见性和 evolution stage，再看差异化、风险、控制权、规模经济和内部运行能力。高可见、高差异、高责任的组件倾向 build / hybrid；低可见、成熟、非差异的组件倾向 buy；需要领域迁移或实施加速时 partner，但核心 policy、eval、audit 和 decision boundary 不外包。
2 分钟回答： 以客服知识平台为例，contact center AI、语音转写、基础检索都比较产品化，可以 buy；但金融产品政策、费用豁免边界、客户资格、过期文档处理、引用规则和升级路径是本地化控制，需要内部 owner。以 AML 为例，LLM summarization 可以通过 gateway 消费，但 red flag taxonomy、case narrative boundary、SAR approval 和历史 case eval set 是核心资产。Partner 可以帮助 taxonomy 迁移和流程落地，但必须有 knowledge transfer 和内部接管条件。这个决策不是采购偏好，而是地图上的位置推导。
Q3：AI 平台和业务 AI 产品的边界怎么划？
30 秒回答： 平台做低可见、重复、控制强、可服务多个 use case 的能力，例如 model gateway、EvalOps、tool gateway、knowledge ingestion baseline、audit、cost governance。业务产品保留 user need、workflow、domain policy、domain eval、adoption 和业务结果。
2 分钟回答： 我会用 Team Topologies 的视角看：platform team 应该提供 compelling internal product，降低 stream-aligned teams 的认知负荷，而不是接管业务流程。比如平台提供 model gateway、prompt registry、retrieval eval、tool gateway 和 observability；AML 团队负责 red flags、case workflow、SAR boundary；信贷团队负责 policy exception、reason codes、fairness slices；财富团队负责 suitability 和 disclosure。interaction mode 也要设计：早期通过 collaboration 共同探索，稳定后变成 X-as-a-Service，能力缺口通过 enabling team facilitation 补齐。
Q4：AI 竞争优势来自哪里？
30 秒回答： 长期优势通常不来自单个 foundation model，而来自高价值 workflow、受控数据和知识、领域 eval、用户信任、分发入口、合规控制和组织执行速度。地图可以显示哪些节点会商品化，哪些节点值得投资。
2 分钟回答： 在 AI 领域，很多底层能力会快速产品化或商品化：模型 API、基础 RAG、observability、OCR、语音识别。真正难复制的是企业自己的交易历史、case labels、知识治理、审批流程、监管解释、客户关系和 adoption 机制。例如 AML Copilot 的优势不是“会总结文本”，而是能把交易、实体、历史案例、red flags 和 SAR narrative 证据链串起来；财富顾问的优势不是“能聊天”，而是能在 suitability、disclosure 和 advisor workflow 中形成可信建议准备材料。地图帮助我把资源投到不会马上被市场商品化的节点。
Q5：如何避免 AI 平台过早平台化？
30 秒回答： 我要求至少有多个高价值 use case 证明同一能力重复出现，并且平台能显著降低认知负荷、风险和交付时间。第一个 PoC 不建大平台，先抽象最小 golden path。
2 分钟回答： 过早平台化的典型表现是先建统一 agent platform、统一 UI builder、统一 ontology，但业务场景还没有验证。我的做法是从 2-3 个真实场景中提取重复组件，比如 AML、客服和信贷都需要 model gateway、eval、audit、knowledge ingestion 和成本归因，那么这些适合平台化。相反，AML red flags、信贷 exception policy、财富 suitability 不应由平台统一。平台 MVP 应该包括 gateway、prompt/config registry、EvalOps、knowledge baseline、observability 和 cost dashboard，而不是承诺无代码生成所有 AI 应用。
Q6：AI gateway / EvalOps 为什么是架构投资，不只是工具采购？
30 秒回答： AI gateway 是模型接入、路由、成本、日志和政策控制面；EvalOps 是质量、风险和发布门禁控制面。工具可以买，但 control policy、eval contract、golden set、risk thresholds 和 evidence binder 必须由企业掌握。
2 分钟回答： 当企业有多个 AI use case，模型调用、prompt 变更、RAG index、tool call 和输出质量都会持续变化。没有 gateway，团队会分散接模型，成本和审计不可控；没有 EvalOps，上线只能靠主观体验。工具采购只能解决部分执行问题，真正的架构投资是建立统一的控制面：请求日志、模型版本、fallback、quota、dataset registry、failure taxonomy、release gate、production sampling、incident loop。这些能力让 AI 从 PoC 进入可运行、可审计、可复盘的生产系统。
Q7：金融零售高风险 AI decisioning 怎么设计边界？
30 秒回答： 先明确 AI 是 inform、draft、recommend、act with approval 还是 autonomous act。信贷、财富、AML 等高风险场景一般不让 AI 直接做最终决定，而是让 AI 生成证据、摘要、建议和草稿，由授权人员或规则系统承担决策责任。
2 分钟回答： 以信贷为例，AI 可以提取材料、引用政策、发现缺失信息、草拟贷审 memo、提示例外原因，但自动批准、自动拒绝、自动生成客户 adverse action reason 都需要严格控制。以财富顾问为例，AI 可以做 meeting prep、产品比较、风险提示草稿，但 suitability 判断和客户沟通必须经过顾问和监督流程。地图上这些 decision boundary 是高可见、高风险、高差异节点，因此不能交给黑箱供应商。必须配套 human oversight、audit trail、fairness slice eval、policy-as-code 和 rollback。
Q8：如何把 Wardley Map 转成 12 个月 AI roadmap？
30 秒回答： 先识别 value chain bottleneck 和可复用低层能力，再按 evolution 和依赖安排顺序：先补 doctrine 和控制面，再做高价值场景 pilot，最后把重复能力平台化并规模化。
2 分钟回答： 我会把 roadmap 分成三条线。第一条是场景线：AML、客服、信贷、财富按价值和风险推进 pilot。第二条是平台线：model gateway、EvalOps、knowledge governance、tool gateway、observability 按重复痛点建设。第三条是治理线：risk tiering、release gate、evidence binder、incident process。顺序不是任意的：如果没有 knowledge governance，RAG 场景会失败；如果没有 EvalOps，高风险场景不能 scale；如果没有 gateway，供应商和成本会失控。地图让 roadmap 顺序由依赖和演进推导，而不是由组织政治推导。
17. 作品集交付物
一个高级 AI PM / 架构师作品集不应只展示 PRD，而要展示战略判断和架构决策证据。
| Deliverable | 内容 | 证明的能力 |
|---|---|---|
| AI Wardley Map Pack | AML、客服、信贷、财富、AI gateway / EvalOps 五张地图 | 能从 user need 到 value chain 和 evolution 做战略分析 |
| Evolution Heatmap | 20 个 AI 组件的 Genesis / Custom / Product / Commodity 判断 | 能识别商品化趋势和投资窗口 |
| Build-Buy-Partner Memo | 每个案例的 sourcing decision 和边界 | 能做 vendor / build / partner 取舍 |
| Platform Boundary ADR | 平台团队与业务团队的 owner、interaction mode、metrics | 能设计 AI 平台边界和组织协作 |
| Competitive Landscape Map | hyperscaler、foundation model provider、SaaS、domain vendor、SI、open source、internal platform 对比 | 能看竞争地形，不停留在 feature list |
| Architecture Investment Thesis | gateway、EvalOps、knowledge governance、tool gateway 等投资论证 | 能把架构投资转成业务、风险和速度语言 |
| Financial Retail Case Portfolio | AML Copilot、客服知识平台、信贷 decisioning、财富顾问、AI gateway / EvalOps | 能把金融零售业务背景转成高级 AI 策略 |
| ARB Review Pack | map、ADR、risk tier、eval gate、control pack、exit plan | 能进入架构评审和高管决策场景 |
| Interview Answer Bank | 10 道 build / buy / platform / governance / AI strategy 答案 | 能在面试中讲清高级战略判断 |
| 30-Day Training Evidence | 每日输出、复盘问题、最终 synthesis | 能证明学习方法和可持续迭代能力 |
17.1 Portfolio narrative
我用 Wardley Mapping 处理 AI 产品战略，不从模型或供应商开始，而从 user need 和 value chain 开始。
对每个金融零售场景，我先识别用户价值、决策边界、风险和依赖，再把组件放到 evolution axis。
成熟和非差异组件通过 buy / hybrid 加速，核心 workflow、policy、eval dataset、audit 和 decision boundary 保留内部控制。
当多个场景共享低可见但高复用能力时，我把它们沉淀为 AI platform capabilities，并用 Team Topologies 定义平台团队与业务团队的交互方式。
最终输出不是一张静态图，而是一套可评审、可投资、可上线、可复盘的 AI strategy operating system。
18. Executive Summary 模板
# Executive Summary: AI Wardley Mapping Strategy
## Strategic Position
本阶段不把 AI 战略定义为“采购某个模型”或“上线若干 chatbot”，而是围绕金融零售高价值工作流建立 AI 产品与平台组合。
## Key Map Insights
- Foundation model access 正在商品化，单模型不是长期差异化。
- Knowledge governance、domain eval dataset、decision boundary 和 audit evidence 是金融零售 AI 的关键控制资产。
- 多个 use case 共享 model gateway、EvalOps、tool gateway、observability 和 cost governance，适合平台化。
- AML、信贷、财富等高风险场景必须保留人工责任、政策解释和监管证据链。
## Recommended Plays
- Buy / hybrid 成熟底层能力：model access、basic RAG tooling、observability、OCR、contact center AI。
- Build 差异化和控制节点：domain workflow、policy boundary、eval dataset、audit evidence、decision rights。
- Partner 加速 taxonomy、implementation 和 change management，但用明确 handover 防止能力外包。
- Platformize 低可见、重复、控制强能力，保持业务团队对 user need 和 outcome 负责。
## Architecture Investments
- AI gateway
- EvalOps
- Knowledge governance
- Tool gateway
- Policy-as-code
- AI observability and incident loop
- Cost governance
## Governance
所有高风险 AI use case 必须通过 risk tiering、eval gate、human oversight、audit trail、incident runbook 和 quarterly map review。
19. 最终判断框架
当一个 AI 产品或平台决策进入评审时，用下面五句话结束讨论：
- 这个 user need 是否足够重要，且不是技术驱动的伪需求。
- 这条 value chain 中哪些节点真正决定差异化、控制权和风险。
- 每个关键组件在 evolution axis 上的位置是否支持当前 build / buy / partner 决策。
- 平台边界是否降低业务团队认知负荷，而不是夺走业务责任。
- 架构投资是否服务于地图上的 bottleneck、climatic pattern 和 strategic gameplay，而不是服务于技术偏好。
能回答这五个问题，AI PM / 架构师就能把 AI 战略从“功能路线”升级为“态势感知 + 架构投资 + 组织执行”的组合能力。