AI 扩展计划 / Playbooks
AI Team Topologies / Conway Platform Operating Model Playbook
以下来源是本文的外部锚点。本文把它们转成企业 AI 平台、金融零售 AI 产品、模型风险和运营模型语言。访问日期按 2026-06-29 记录。
906 行AI_TEAM_TOPOLOGIES_CONWAY_PLATFORM_OPERATING_MODEL_PLAYBOOK.md
AI Team Topologies / Conway / Platform Operating Model Playbook
定位：面向高级 AI PM / AI BA / Product Architect / Enterprise Architect / AI Platform Lead / Model Risk / Compliance，把 Conway's Law、Team Topologies、cognitive load 和 platform operating model 迁移到企业 AI 平台和金融零售 AI 产品组织。
适用边界：本文假设读者已经具备 CBAP 级业务分析能力，不讲基础组织设计、岗位职责入门或传统流程梳理。重点是：如何设计 AI 平台团队拓扑、团队交互、认知负载边界、平台团队 API、EvalOps / AI gateway / model risk operating model，以及如何用金融零售案例形成作品集。
核心观点：AI 平台失败经常不是模型失败，而是组织通信结构、平台边界、风险责任、评估能力和业务流团队之间的结构性错配。
Source Anchors
以下来源是本文的外部锚点。本文把它们转成企业 AI 平台、金融零售 AI 产品、模型风险和运营模型语言。访问日期按 2026-06-29 记录。
| Anchor | Official / primary source | 本文使用方式 |
|---|---|---|
| Melvin E. Conway, How Do Committees Invent? | https://www.melconway.com/Home/Committees_Paper.html | 用 Conway's Law 理解系统设计会映射组织通信结构，并用 inverse Conway 设计 AI 平台团队边界。 |
| Conway's Law summary by Mel Conway | https://melconway.com/Home/Conways_Law.html | 用原作者对 thesis 的总结校准“系统结构复制组织通信结构”这一核心判断。 |
| Team Topologies official | https://teamtopologies.com/ | 用 Team Topologies 作为企业 AI 团队拓扑、交互模式、平台团队和 cognitive load 的主框架。 |
| Team Topologies key concepts | https://teamtopologies.com/key-concepts | 用 four team types、three interaction modes、Team Cognitive Load、Thinnest Viable Platform 设计 AI 平台 operating model。 |
| Team Topologies resources and Team API | https://teamtopologies.com/resources | 用 Team API、team interaction modeling、TVP 模板思想设计 AI platform team API 和跨团队契约。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI risk lifecycle、模型风险、EvalOps、持续监控和管理层证据。 |
| NIST AI RMF Playbook | https://airc.nist.gov/airmf-resources/playbook/ | 把风险治理转为可执行 owner、gate、dashboard、evidence 和 operating cadence。 |
| AI Platform PM Playbook | docs/AI_PLATFORM_PM_PLAYBOOK.md | 连接 AI gateway、RAG、EvalOps、cost、audit、adoption 等平台产品能力。 |
| AI Operating Model / RACI / Runbook | docs/AI_OPERATING_MODEL_RACI_RUNBOOK.md | 复用 owner、RACI、governance cadence、incident、change management 的运行结构。 |
| AI EvalOps Platform Architecture Playbook | docs/AI_EVALOPS_PLATFORM_ARCHITECTURE_PLAYBOOK.md | 把 eval harness、release gate、evidence binder 和 production monitoring 放进团队拓扑。 |
| AI Model Risk Management Playbook | docs/AI_MODEL_RISK_MANAGEMENT_PLAYBOOK.md | 把 model risk、validation、effective challenge、ongoing monitoring 纳入 operating model。 |
1. One-Sentence Positioning / 一句话定位
AI Team Topologies =
用 Conway's Law 反向设计组织通信结构，
用 Team Topologies 管理团队类型、交互模式和 cognitive load，
让 stream-aligned AI 产品团队能在平台团队、complicated-subsystem 团队、
enabling 团队和风险治理能力的支持下，
持续交付可评估、可审计、可运行、可扩展的企业 AI 产品。
高级表达不是：
我们成立一个 AI CoE，统一推动 AI 转型。
而是：
我们把 AI 组织设计成 team-of-teams operating model：
业务流团队对 AML、客服、信贷等 outcome 负责；
AI platform team 提供 gateway、EvalOps、RAG、tool gateway、observability 和 cost control；
complicated-subsystem team 管理模型、检索、特征、风险方法和高复杂算法；
enabling team 通过短周期协作提升业务团队的 AI delivery 能力；
model risk、security、privacy 和 compliance 通过明确 gate、evidence 和 effective challenge 嵌入 flow，而不是成为上线末端的排队审批。
本文的核心训练目标：
| 能力 | 高级表现 | 作品集证据 |
|---|---|---|
| Conway mirroring | 能解释 AI 平台架构为什么会复制组织通信结构 | Conway map、inverse Conway target map |
| Team taxonomy | 能把 AI 产品和平台组织映射到四类团队 | AI team topology diagram |
| Cognitive load design | 能识别 stream team 被模型、RAG、eval、risk、tooling 压垮的具体位置 | cognitive load heatmap |
| Team API | 能定义平台团队、模型风险团队、EvalOps 团队的可消费接口 | team API cards |
| Interaction modes | 能区分 collaboration、X-as-a-Service、facilitation，并设置退出条件 | interaction contract |
| Platform operating model | 能把 AI gateway、EvalOps、model risk、business ownership 串成运行机制 | AI platform operating model |
| Financial retail translation | 能用 AML、客服、信贷、AI gateway、EvalOps、model risk 案例讲清楚 | portfolio case pack |
2. 为什么 AI 平台组织不能只靠“AI 中台”
企业 AI 平台常见误区是把平台理解成统一工具或统一部门。真实问题更复杂：
| 表面问题 | 深层组织问题 | 平台后果 |
|---|---|---|
| 每个业务团队重复接模型 | AI gateway 没有被产品化，业务团队只能自救 | 日志、权限、成本、fallback 和审计不一致 |
| 每个 use case 都要平台团队深度参与 | 平台能力没有清晰 Team API | 平台团队变成人肉集成队列 |
| EvalOps 跑不起来 | 评估责任分散在 PM、数据、QA、模型风险之间 | release gate 形式化，线上失败不能回流 |
| 模型风险介入太晚 | 风险团队和产品团队的交互模式只有末端审批 | 返工、争议、上线延迟、证据缺口 |
| 业务团队不采用平台 | 平台按技术组件设计，没有对齐业务流 | 平台 API 可用但不可用好 |
| AI CoE 变成专家池 | enabling 和 delivery 混在一起 | 专家过载，业务团队能力没有提升 |
| 架构越来越碎 | 团队边界、系统边界和数据责任不一致 | RAG、prompt、tool、policy、eval 互相绕线 |
Conway's Law 给出的提醒是：如果组织通信结构混乱，AI 平台架构会复制这种混乱。Team Topologies 给出的操作语言是：用少数清晰团队类型、明确交互模式和认知负载管理，设计一个可以演进的 team-of-teams。
3. AI 团队拓扑 Taxonomy
3.1 四类团队迁移到 AI 平台
| Team Topologies 类型 | 企业 AI 迁移 | 主要 owner | 不该承担的事 | 成功信号 |
|---|---|---|---|---|
| Stream-aligned team | 面向业务流或客户旅程的 AI 产品团队，如 AML investigation copilot、客服 AI、信贷 underwriting copilot、门店员工 assistant | Business Product Owner + AI PM + Solution Architect + domain SMEs + engineers | 不自建通用 gateway、通用 eval 平台、通用模型治理 | 端到端 outcome 改善，能独立发布低中风险变更 |
| Platform team | 提供可消费的 AI 平台能力，如 model gateway、prompt registry、RAG ingestion、tool gateway、EvalOps、AI observability、cost ledger、policy guardrails | AI Platform PM + Platform Architect + SRE / Security / Data Platform | 不替每个业务团队定制所有流程，不接管业务 outcome | 平台成为 path of least resistance，减少重复建设和认知负载 |
| Complicated-subsystem team | 管理高复杂度子系统，如信用评分模型、AML graph typology、retrieval/reranking science、LLM judge calibration、fairness methodology、privacy-preserving AI | Applied Scientist / Risk Model Lead / ML Architect / Quant / Security specialist | 不成为所有 use case 的交付主力，不把专业复杂性推给 stream team | 复杂能力以服务、库、模型卡、评估方法或专家 review 被稳定消费 |
| Enabling team | 短期帮助其他团队建立能力，如 EvalOps coaching、AI product discovery clinic、risk-by-design facilitation、RAG design enablement、frontline adoption enablement | AI Enablement Lead + senior practitioner | 不长期代替 stream team 交付，不变成永久审批层 | 团队能力提升后退出，留下 playbook、示例、training 和可运行实践 |
关键判断：
Stream-aligned team owns business outcome.
Platform team owns reusable capability and developer / builder experience.
Complicated-subsystem team owns hard expertise that should not be duplicated.
Enabling team owns capability uplift and temporary acceleration.
3.2 AI stream-aligned team 示例
| Stream | Outcome | AI capability | 必须拥有的能力 | 主要消费的平台服务 |
|---|---|---|---|---|
| AML investigation | 降低低价值告警处理时间，提高 SAR narrative 质量，降低漏报风险 | case summarization、entity linking、typology hint、narrative draft、evidence citation | AML domain expertise、case workflow、human review、quality sampling | AI gateway、case tool connector、EvalOps、audit log、RAG policy store |
| Customer service | 降低 handle time、提升 first contact resolution、控制错误话术和升级不足 | agent assist、customer summary、next-best-action、policy answer、warm handoff | conversation design、exception taxonomy、knowledge ownership、handoff operations | RAG ingestion、policy guardrails、telemetry、feedback loop |
| Credit underwriting | 提高申请材料审查效率和解释一致性，控制公平借贷和模型风险 | document extraction、risk factor summary、policy checklist、decision support | credit policy、underwriter workflow、model risk controls、human override | feature store、EvalOps、model registry、decision log、explanation service |
| Branch / store operations | 支持员工查询 SOP、处理例外、推荐下一步操作 | employee copilot、process assistant、task checklist | frontline work-as-done、training、operational escalation | knowledge platform、identity、tool gateway、observability |
| Wealth advisor | 合规地生成客户会前摘要、投资产品信息检索、follow-up draft | advisor copilot、portfolio explanation、document generation | suitability rules、disclosure、advisor workflow、supervision | approved knowledge RAG、policy guardrail、prompt registry、audit evidence |
3.3 AI platform team 示例
| Platform capability | Team API should expose | 消费者 | 平台不应暴露的复杂性 |
|---|---|---|---|
| AI gateway | approved models、routing、fallback、quota、logging、cost attribution、PII handling | 所有 AI app teams | vendor API 差异、密钥管理、低层 retry、模型版本漂移 |
| EvalOps platform | dataset registry、evaluator registry、batch runner、release gate report、production sample mining | AI PM、engineer、model risk、QA | judge calibration internals、eval infra、结果存储细节 |
| RAG / knowledge platform | ingestion pipelines、metadata、permission filter、retriever API、citation、freshness dashboard | 客服、AML、员工 copilot、wealth | chunking/rerank 细节、权限传播、index rebuild complexity |
| Tool gateway | approved tool catalog、risk tier、RBAC、HITL、idempotency、audit | agent / workflow teams | 系统鉴权差异、工具错误恢复、审计日志格式 |
| AI observability and cost | traces、quality signals、latency、fallback、token/cost ledger、SLO dashboard | platform owner、stream teams、finance、risk | telemetry schema 分裂、provider billing 差异 |
| Policy / guardrail service | policy rules、blocked actions、sensitive content controls、escalation triggers | customer-facing AI、employee AI、agent systems | 合规规则散落在 prompt 中 |
3.4 Complicated-subsystem team 示例
| Subsystem | 为什么复杂 | 输出形态 | 与 stream team 的正确关系 |
|---|---|---|---|
| AML graph typology model | 图谱、实体解析、异常模式、监管解释和低频高损风险高度耦合 | service API、typology library、model card、validation report | 先 collaboration 探索，再 X-as-a-Service 消费，定期 effective challenge |
| Credit risk / affordability model | 统计建模、公平性、可解释性、模型验证和政策一致性要求高 | model service、score explanation、monitoring pack | stream team 不复制模型方法，只消费经验证的服务和解释 |
| LLM judge calibration | 评价标准、专家一致性、judge drift、slice bias 难以由单个业务团队管理 | evaluator cards、calibration report、judge registry | EvalOps platform 暴露为可选 evaluator，风险高场景保留人审 |
| Retrieval science | chunking、embedding、rerank、hybrid search、权限过滤、freshness trade-off | retrieval patterns、reference implementation、tuning guide | RAG platform 产品化，业务团队只配置 domain sources 和 acceptance criteria |
| Privacy / confidential AI control | 数据分类、脱敏、保留、跨境、供应商、日志可见性复杂 | policy-as-code、privacy pattern、review rubric | security/privacy 提供模式和 gates，不参与每个 prompt 的日常审批 |
| Real-time decision optimization | 排队、容量、约束、优化目标、多目标权衡复杂 | optimization service、simulation notebook、decision policy | stream team 提供业务约束和 outcome，复杂算法团队提供可验证引擎 |
3.5 Enabling team 示例
| Enabling mission | 进入条件 | 介入方式 | 退出证据 |
|---|---|---|---|
| EvalOps enablement | stream team 无法把需求转成 eval contract | 2 到 4 周 facilitation，建立 golden set、rubric、release gate | 团队能独立新增 eval case，release report 质量达标 |
| AI risk-by-design clinic | use case risk tier 高，团队不熟悉 model risk / compliance expectation | workshop + review pairing + evidence checklist | use case card、risk control map、evidence binder 可复用 |
| RAG design enablement | 知识源复杂、权限多、答案质量不稳定 | 架构 pairing、retrieval eval、knowledge owner coaching | retrieval quality dashboard 和 source owner cadence 已运行 |
| Frontline adoption enablement | 员工低信任或过度依赖 AI | shadowing、training、feedback taxonomy、supervisor loop | adoption dashboard 显示正确使用、纠错和升级行为 |
| Agent safety enablement | tool use、自动执行、权限和回滚风险高 | threat modeling、HITL design、tool risk tiering | tool contract、approval rules、rollback runbook 已被 stream team 接管 |
4. Conway Mirroring for AI Platform
4.1 Conway 不是一句口号，而是架构诊断工具
Conway mirroring 要问：
当前 AI 系统结构是否正在复制我们的组织通信结构？
如果是，它复制的是清晰边界，还是复制了排队、模糊责任、重复建设和审批瓶颈？
在企业 AI 中，系统结构通常会映射这些组织关系：
| 组织通信结构 | 系统会长成什么样 | 典型症状 |
|---|---|---|
| 风险、平台、业务、数据各自排队审批 | 多个独立 gate 串联，证据重复提交 | 上线慢，责任不清，团队绕过平台 |
| 每个业务线自建 AI 能力 | 多套 gateway、prompt store、eval、RAG、日志 | 成本不可控，审计不可比，模型风险不可聚合 |
| 平台团队只面向技术组件 | 平台 API 技术可用但业务难用 | 业务继续找专家手工接入 |
| Model risk 只在上线前审查 | 风险控制是文档层，不进入 daily delivery | 末端返工，线上监控弱 |
| CoE 按专家池运作 | 专家成瓶颈，业务团队不成长 | 每个项目都依赖同一批专家 |
| 知识 owner 和 AI team 分离 | RAG 答案质量没有长期责任人 | 知识过期，纠错无人认领 |
4.2 Inverse Conway: 从目标 AI 架构反推团队结构
如果目标 AI 平台架构是：
Business AI apps
-> AI gateway
-> RAG / tool / policy services
-> EvalOps release gate
-> observability / cost / audit
-> model risk and governance evidence
那么目标团队结构应当支持：
| 目标架构性质 | 反推团队设计 |
|---|---|
| AI app teams 能快速试点 | stream-aligned teams 直接拥有业务流和 release scope |
| 通用 AI 控制集中一致 | platform team 拥有 gateway、EvalOps、observability、cost、audit |
| 高复杂算法不被重复实现 | complicated-subsystem teams 以服务、模型、方法库输出 |
| 新能力能被组织吸收 | enabling teams 用短周期 facilitation 建能力 |
| 风险不是末端阻塞 | model risk、security、compliance 提供 risk patterns、gate criteria、evidence API |
| 平台可演进但不过度膨胀 | thinnest viable platform，按真实 stream needs 增加能力 |
4.3 Conway Mirror Map 模板
| 当前组织通信路径 | 当前系统映射 | 风险 | 目标通信路径 | 目标系统映射 |
|---|---|---|---|---|
| 客服 AI team 直接找模型供应商 | app 内嵌 provider SDK | 日志、成本、数据边界不一致 | 客服 AI team 通过 AI gateway 消费 approved models | 统一 routing、logging、cost、fallback |
| AML team 找数据团队临时导数 | case feature pipeline 手工维护 | 数据血缘和复现困难 | AML stream team 消费 governed feature / entity service | 可追溯 feature、entity、case context |
| Model risk 在上线前审文件 | 风险证据离线保存 | 返工和证据断裂 | Model risk 定义 gate criteria，EvalOps 生成证据 | release report、monitoring、exception log 自动归档 |
| RAG 错误发群里修 | 知识库更新无 owner | 同错重复出现 | Knowledge owner + RAG platform 有 freshness 和 correction SLA | source registry、feedback-to-index loop |
| CoE 专家写 prompt | prompt 变成专家个人资产 | 不可维护，不可审计 | Enabling team 教 stream team 写 eval-backed prompt | prompt registry、rubric、regression report |
4.4 诊断句式
面试或作品集中可以这样表达：
我先做 Conway mirroring：把 AI 系统组件和组织通信路径画在同一张图上。
如果系统里出现重复 gateway、重复 eval、知识无人负责、model risk 末端返工，
我不会先要求大家“加强沟通”，而是会用 inverse Conway 重新定义团队边界、
Team API 和 interaction modes，让目标平台架构有对应的组织通信结构。
5. Cognitive Load: AI 团队最容易被什么压垮
5.1 三类认知负载迁移到 AI
| Cognitive load 类型 | AI 语境 | 例子 | 处理方式 |
|---|---|---|---|
| Intrinsic load | 业务问题本身不可避免的复杂度 | AML typology、credit policy、客户投诉升级、监管解释 | stream team 保留核心领域理解，必要时 complicated-subsystem 支持 |
| Extraneous load | 组织和平台设计不佳造成的额外复杂度 | 每个团队自己接模型、写日志、做权限、做成本报表、找审批人 | platform team 提供 X-as-a-Service，减少重复心智负担 |
| Germane load | 团队为了掌握 AI delivery 需要投入的有效学习 | eval design、prompt versioning、RAG quality review、risk-based release | enabling team 通过 facilitation 提升能力 |
高级判断：
不是所有复杂度都要平台化。
Intrinsic load 需要被业务团队理解；
extraneous load 应该由平台和清晰交互消除；
germane load 应该由 enabling team 转化成组织学习资产。
5.2 AI stream team cognitive load heatmap
| 负载来源 | AML AI team | 客服 AI team | 信贷 AI team | 降负载机制 |
|---|---|---|---|---|
| Domain policy and exception | 高 | 高 | 高 | 保留在 stream team，明确 process owner 和 knowledge owner |
| Model provider selection | 中 | 中 | 中 | AI gateway 提供 approved model catalog |
| Prompt / config versioning | 中 | 高 | 中 | prompt registry + release diff |
| RAG retrieval quality | 中 | 高 | 中 | RAG platform + retrieval eval + knowledge owner SLA |
| Tool permissions and audit | 高 | 中 | 高 | tool gateway + HITL + audit log |
| Eval design and regression | 高 | 高 | 高 | EvalOps platform + enabling facilitation |
| Model risk evidence | 高 | 中 | 高 | model risk criteria + evidence binder |
| Cost attribution | 中 | 高 | 中 | cost ledger and budget dashboard |
| Production monitoring | 高 | 高 | 高 | AI observability SLO + incident runbook |
5.3 Cognitive load threshold signals
| Signal | 说明 | 推荐动作 |
|---|---|---|
| Stream team 每次改 prompt 都需要 5 个团队同步 | 交互模式过度 collaboration | 把 prompt diff、eval、approval 变成平台 workflow |
| 业务团队绕过平台自接模型 | 平台没有减少认知负载 | 重写平台 Team API，先解决 gateway 最小可消费路径 |
| Model risk 每次都提出相同证据缺口 | evidence API 不存在 | EvalOps 和 risk criteria 前移到 release template |
| RAG 质量问题反复出现 | knowledge owner 和 platform owner 分离 | 建立 source owner registry、freshness dashboard、feedback loop |
| 平台团队 backlog 全是定制需求 | 平台边界过宽或产品化不足 | 将高频需求产品化，低频定制回到 stream team |
| Enabling team 长期驻扎某团队 | enablement 变成 delivery outsourcing | 设定退出条件，转为 documented practice 和 office hour |
| Complicated-subsystem 团队被当成 ticket team | 专家能力没有服务化 | 输出 service API、model card、method guide、review cadence |
5.4 Cognitive load review questions
| 问题 | 好答案特征 |
|---|---|
| 这个复杂度是否是业务价值的一部分？ | 如果是，stream team 需要掌握；如果不是，平台应抽象掉。 |
| 这个团队是否同时背负业务、模型、平台、风险和运维所有复杂度？ | 如果是，需要拆出 platform 或 complicated-subsystem 能力。 |
| 当前交互是否需要高带宽沟通？ | discovery 期间可以 collaboration，稳定后应转为 X-as-a-Service。 |
| 是否因为审计和风险证据增加了重复劳动？ | 证据应由平台流程自动生成，而不是靠人工补文档。 |
| 团队学习负载是否带来长期能力？ | 如果只是专家代劳，不是有效学习。 |
6. Team API for AI Platform
Team API 的目标不是写组织介绍，而是让别的团队知道：
这个团队提供什么、如何消费、什么不负责、质量承诺是什么、
如何升级、如何变更、如何共同处理风险。
6.1 AI Gateway Team API 示例
| Field | 内容 |
|---|---|
| Team name | AI Gateway Platform Team |
| Team type | Platform team |
| Mission | 为企业 AI 应用提供统一模型访问、routing、fallback、quota、logging、PII control、cost attribution 和 audit metadata。 |
| Consumers | AML AI team、Customer Service AI team、Credit AI team、Employee Copilot team、EvalOps platform、Security monitoring。 |
| Provided services | approved model catalog、single inference API、streaming API、embedding API、policy-aware routing、fallback profile、cost dashboard、request metadata log。 |
| Service levels | P1 production use case 99.9% gateway availability；critical model provider outage 15 分钟内切换到 approved fallback；cost dashboard T+1 可见。 |
| Consumer responsibilities | 提供 use case id、risk tier、data classification、prompt version、business owner、budget code、eval gate link。 |
| Explicit non-ownership | 不决定业务用例是否值得做；不维护业务知识库；不替 model risk 签字；不为单个团队私接未批准模型。 |
| Change policy | 新模型进入 allowlist 需要 security、privacy、model risk、platform review；routing policy 变更进入 release note 和 regression run。 |
| Support channels | production incident channel、weekly gateway office hour、self-service docs、service catalog ticket。 |
| Escalation | data leakage suspicion 立即转 Security / Privacy；model behavior regression 转 EvalOps + Model Risk；cost anomaly 转 Platform FinOps。 |
| Evidence produced | request log、model version、routing decision、fallback event、token/cost ledger、blocked request、policy decision metadata。 |
6.2 EvalOps Team API 示例
| Field | 内容 |
|---|---|
| Team name | AI EvalOps Platform Team |
| Team type | Platform team with complicated-subsystem support |
| Mission | 把 eval 变成企业 AI 发布控制面，提供 dataset、evaluator、experiment、release gate、production sample mining 和 evidence binder。 |
| Consumers | AI product teams、model risk、QA、platform team、risk/compliance、internal audit。 |
| Provided services | dataset registry、rubric template、LLM judge registry、human review workflow、batch eval runner、slice regression dashboard、gate memo generation。 |
| Consumer responsibilities | 定义 use case scope、风险等级、失败严重度、business acceptance criteria、sample owner 和 human reviewer。 |
| Explicit non-ownership | 不替业务定义可接受风险；不保证 judge 可以替代专家；不维护业务系统数据质量。 |
| Change policy | evaluator 版本、judge prompt、threshold、dataset composition 变更必须可追溯，并与 release gate 关联。 |
| Support model | 新 use case 前两轮 collaboration；成熟后 X-as-a-Service；高风险场景保留 monthly calibration review。 |
| Evidence produced | eval run report、dataset card、evaluator card、calibration report、critical failure list、release gate memo、production issue linkage。 |
6.3 Model Risk Team API 示例
| Field | 内容 |
|---|---|
| Team name | AI Model Risk Effective Challenge Team |
| Team type | Complicated-subsystem / governance capability，不是普通 delivery team |
| Mission | 对模型、LLM-enabled capability、AI decision support 和高风险 AI workflow 提供独立有效挑战、验证期望、监控要求和风险接受建议。 |
| Consumers | AI product owners、credit risk、AML operations、AI platform、EvalOps、executive risk committee。 |
| Provided services | risk tiering rubric、validation expectation、model card review、monitoring criteria、fairness / bias review guidance、exception memo review。 |
| Consumer responsibilities | 提供 use case card、intended use、prohibited use、data lineage、eval report、monitoring plan、human oversight design。 |
| Explicit non-ownership | 不拥有业务 outcome；不替代 first-line control；不负责平台运维；不为缺证据项目背书。 |
| Interaction modes | Early-stage facilitation for risk-by-design；pre-release effective challenge；quarterly monitoring review；incident-specific collaboration。 |
| Evidence produced | risk tier decision、validation memo、challenge log、conditioned approval、monitoring requirement、issue closure record。 |
6.4 Stream-Aligned Team API 示例：客服 AI
| Field | 内容 |
|---|---|
| Team name | Customer Service AI Stream Team |
| Team type | Stream-aligned team |
| Mission | 在客户服务流程中提供 AI-assisted response、policy retrieval、case summary 和 warm handoff，降低处理时间并控制错误话术和升级不足。 |
| Owned outcome | first contact resolution、average handle time、rework rate、complaint rate、AI-assisted quality score、under-escalation incidents。 |
| Owned systems | service console AI panel、conversation summary、handoff payload、feedback taxonomy、customer-service-specific prompt configs。 |
| Consumed platform services | AI gateway、RAG platform、prompt registry、EvalOps、policy guardrails、telemetry、audit log。 |
| Domain responsibilities | 知识源 owner 协调、客服 SOP 对齐、例外分类、supervisor QA、frontline adoption。 |
| Non-ownership | 不自建模型供应商接入；不维护通用 RAG 平台；不批准企业模型 allowlist。 |
| Interaction needs | 与 RAG platform collaboration 4 周建立 permission-aware retrieval；成熟后 X-as-a-Service；与 enabling team facilitation 2 周训练客服主管使用 feedback loop。 |
7. Interaction Modes for AI Work
7.1 三种交互模式的 AI 迁移
| Interaction mode | AI 场景 | 何时使用 | 退出条件 |
|---|---|---|---|
| Collaboration | stream team 与 platform / complicated-subsystem team 高带宽共同探索 | 新 use case、新风险模式、新平台能力、新模型类型、高不确定性 | API、contract、gate、runbook 或 service interface 已稳定 |
| X-as-a-Service | 一方提供可消费服务，另一方按清晰契约使用 | gateway、EvalOps runner、RAG ingestion、tool gateway、model service、observability dashboard | 服务持续满足 consumer needs；若频繁定制，回到 collaboration 重塑边界 |
| Facilitation | enabling team 帮助 stream team 解除障碍和提升能力 | eval 能力不足、risk-by-design 不熟、RAG 设计薄弱、frontline adoption 阻塞 | stream team 能独立运行实践，有证据和节奏接管 |
7.2 AI interaction pattern matrix
| From team | To team | 推荐模式 | 例子 | 风险 |
|---|---|---|---|---|
| AML stream team | AI gateway platform | X-as-a-Service | 通过 approved model profile 调用模型 | 如果需要私接模型，说明 gateway Team API 不足 |
| 客服 stream team | RAG platform | Collaboration -> X-as-a-Service | 共同建立权限过滤和 policy source registry 后转服务消费 | 长期 collaboration 会拖慢双方 |
| 信贷 stream team | Credit model complicated-subsystem | Collaboration + X-as-a-Service | 联合定义解释需求，最终消费 score / explanation service | stream team 复制模型逻辑会增加风险 |
| EvalOps platform | Model risk | Collaboration | 设计高风险 release gate 和 calibration approach | 如果 model risk 只末端审批，证据会断裂 |
| Enabling team | 多个 stream teams | Facilitation | 训练 teams 建立 eval contract 和 evidence binder | 若 enabling 长期接 tickets，会变成交付瓶颈 |
| Security / privacy | Tool gateway platform | Collaboration -> X-as-a-Service | 定义 tool risk tiers、RBAC、audit metadata | 若规则只写在文档中，agent 运行时不可控 |
7.3 Interaction contract 模板
| Field | 金融零售 AI 示例 |
|---|---|
| Interaction purpose | 客服 AI stream team 与 RAG platform team 建立 permission-aware policy retrieval。 |
| Mode | 前 4 周 collaboration，第 5 周后转 X-as-a-Service。 |
| Entry condition | 客服 AI 有 3 个高频 policy domains、已指定 knowledge owner、已有 200 条失败样本。 |
| Joint work | source metadata schema、permission filter、retrieval eval、citation UX、freshness dashboard。 |
| Decision rights | stream team 决定业务可接受答案；RAG platform 决定 index architecture；risk 决定高风险话术 gate。 |
| Exit condition | retrieval eval 达到约定阈值；knowledge owner cadence 运行；接入文档和 API 稳定；生产反馈进入 issue queue。 |
| Cadence | 每周两次 working session，周五 release evidence review。 |
| Evidence | source registry、retrieval eval report、known failure list、release decision memo。 |
8. AI Platform Operating Model
8.1 Operating model 总图
Executive AI portfolio governance
-> AI platform product council
-> risk-tiered use case intake
-> stream-aligned AI product teams
-> platform services as product
-> complicated-subsystem expertise as service
-> enabling teams for capability uplift
-> EvalOps release and monitoring gate
-> model risk / security / privacy effective challenge
-> production operations, incident, cost, adoption and continuous learning
这不是一个静态组织图，而是一套流动机制：
| Layer | 关键问题 | Owner | 运行证据 |
|---|---|---|---|
| Portfolio | 哪些 AI use case 值得投资、扩展或停止 | AI portfolio council + business sponsors | use case inventory、value/risk map、funding decision |
| Stream teams | 谁对业务 outcome 和 adoption 负责 | Stream-aligned AI product owner | KPI, adoption, release report, incident review |
| Platform | 哪些能力应作为企业产品复用 | AI Platform PM / Platform Owner | service catalog、Team API、SLO、consumer satisfaction |
| Complicated subsystem | 哪些复杂能力需要专家团队稳定拥有 | Model / Data Science / Risk Method leads | model card、validation, service API, calibration report |
| Enabling | 哪些团队需要短期提升能力 | AI Enablement lead | enablement plan、exit evidence、practice adoption |
| Risk and governance | 风险如何进入设计、发布和运营 | Model Risk / Compliance / Security / Privacy | gate criteria、challenge log、monitoring requirement |
| Operations | 上线后谁监控、修复、复盘和学习 | Ops lead + Platform SRE + Stream team | SLO dashboard、incident log、postmortem、change log |
8.2 Platform-as-a-product backlog
| Capability | Consumer job | MVP service | 成熟服务 |
|---|---|---|---|
| AI gateway | 安全调用 approved models | unified API、model allowlist、request log、cost tag | policy-aware routing、fallback、data boundary enforcement、provider comparison |
| Prompt / config registry | 管理 prompt 版本和审批 | versioning、owner、environment、diff | risk-tiered approval、rollback、eval linkage、policy snippets |
| EvalOps | 用证据支持 release | golden set、rubric、batch run、gate report | production trace mining、judge calibration、slice regression、evidence binder |
| RAG platform | 让知识检索可靠可控 | ingestion、metadata、permission filter、citation | freshness SLO、retrieval eval、source owner workflow、hybrid search |
| Tool gateway | 让 agent 调用工具可控 | tool catalog、RBAC、audit、HITL flag | idempotency、transaction boundary、rollback、risk-tiered approval |
| Observability | 看见质量、延迟、成本和风险 | trace log、latency、error、token cost | quality signal、incident correlation、model drift、business outcome linkage |
| Policy guardrail | 控制敏感输出和高风险动作 | blocked content、escalation rules、approved disclaimers | policy-as-code、contextual controls、explainable policy decision |
| Evidence binder | 让审计和模型风险证据自动形成 | release report archive、approval log | lineage graph、control evidence、exception register、quarterly review pack |
8.3 Risk-tiered operating model
| Risk tier | 示例 | Team interaction | Release gate | Monitoring |
|---|---|---|---|---|
| Low | 内部知识搜索、会议摘要、非客户可见草稿 | stream team consumes platform X-as-a-Service | lightweight eval + owner approval | usage、feedback、cost |
| Medium | 客服 agent assist、员工流程建议、运营 case summary | stream + platform collaboration during setup, then X-as-a-Service | eval report、knowledge owner signoff、ops readiness | quality sampling、handoff failures、incident log |
| High | 信贷 decision support、AML SAR narrative、客户可见合规话术 | stream + complicated-subsystem + model risk collaboration | formal model risk review、critical failure threshold、human oversight | ongoing monitoring、override review、drift、quarterly effective challenge |
| Restricted | 自动拒贷、高影响客户行动、无人工审批的资金/账户动作 | executive risk review and constrained pilot only | explicit risk acceptance, legal/compliance decision, compensating controls | continuous monitoring、manual review、kill switch、audit evidence |
8.4 Governance cadence
| Cadence | Meeting | Inputs | Decisions |
|---|---|---|---|
| Daily | Production AI operations check | incidents、latency、fallback、critical feedback、cost anomaly | containment、rollback、owner assignment |
| Weekly | Stream AI quality review | eval failures、frontline feedback、override samples、knowledge changes | prompt/index/tool fixes、training actions |
| Biweekly | Platform product review | platform adoption、consumer pain、Team API issues、backlog | TVP scope、service improvements、boundary changes |
| Monthly | AI risk and model monitoring review | risk register、model drift、gate exceptions、incidents、audit evidence | risk acceptance、control strengthening、model review actions |
| Quarterly | AI operating model review | portfolio value、team cognitive load、platform maturity、Conway map | reorganize boundaries、fund platform capabilities、retire weak use cases |
8.5 Decision rights
| Decision | Accountable owner | Consulted | Evidence |
|---|---|---|---|
| AI use case enters discovery | Business sponsor / AI portfolio council | Risk, data, architecture, operations | use case card、value-risk score |
| Stream team release to pilot | Stream AI Product Owner | Platform, EvalOps, risk, ops | eval report、risk tier、runbook |
| Model allowlist change | AI Platform Owner | Security, Privacy, Model Risk, Legal | vendor review、data boundary、model behavior report |
| High-risk AI production release | Business owner + Model Risk approval path | Compliance, Security, Architecture, Operations | gate memo、validation、monitoring plan |
| Prompt / RAG / tool config change | Stream Product Owner within policy | EvalOps, Knowledge Owner, Platform | diff、regression run、approval log |
| Incident severity and containment | Stream owner + Operations lead | Risk, Security, Platform | incident trace、customer impact、containment decision |
| Platform capability retirement | Platform Product Council | consumers, architecture, finance, risk | usage, cost, replacement path, migration evidence |
9. 金融零售案例
9.1 AML Investigation Copilot
| 设计项 | 推荐团队拓扑 |
|---|---|
| Stream-aligned team | AML Investigation AI Team，拥有 case workflow、analyst UX、typology usage、SAR narrative support、quality outcome。 |
| Platform services | AI gateway、case system tool connector、EvalOps、audit log、RAG policy store、entity resolution API。 |
| Complicated-subsystem | AML graph typology model、entity resolution、sanctions / watchlist matching methodology、LLM narrative judge calibration。 |
| Enabling | EvalOps enablement 帮 AML team 建 SAR narrative rubric；risk-by-design clinic 建立 use case risk tier 和 evidence binder。 |
| Key cognitive load | AML policy、typology、case evidence、model risk、监管口径和 analyst workflow 同时很重。 |
| Conway risk | 如果 AML operations、data science、case platform、model risk 各自排队，系统会长成难以追溯的拼接链。 |
| Operating model | 高风险 release gate；human analyst owns decision；AI 只建议和起草；每个 narrative 有 evidence citation、model version、prompt version 和 reviewer override。 |
关键评审问题：
- SAR narrative 的 AI 生成内容是否始终可追溯到 case evidence。
- Analyst 是否有足够上下文和时间进行有效监督。
- Model risk 是否在 eval rubric 和 monitoring criteria 中前置，而不是只审最终文档。
- Entity resolution 错误是否进入 production failure mining。
- 高风险 typology 是否有 complicated-subsystem owner。
9.2 Customer Service AI
| 设计项 | 推荐团队拓扑 |
|---|---|
| Stream-aligned team | Customer Service AI Team，拥有 service console、agent assist、handoff、frontline adoption、QA loop。 |
| Platform services | RAG platform、AI gateway、policy guardrails、prompt registry、telemetry、feedback platform。 |
| Complicated-subsystem | Conversation evaluation、policy retrieval tuning、sensitive scenario classifier、PII protection。 |
| Enabling | Frontline adoption enablement、conversation design clinic、retrieval eval coaching。 |
| Key cognitive load | 话术、政策、客户情绪、投诉、困难援助、欺诈意图和系统操作混在同一工作台。 |
| Conway risk | 如果知识团队、客服运营、AI 团队分离，RAG 错误会变成“谁都知道但没人拥有”的长期质量债。 |
| Operating model | Knowledge owner cadence；under-escalation 作为 critical failure；warm handoff payload；supervisor QA 抽样接入 EvalOps。 |
高级设计判断：
客服 AI 不只看回答准确率。
它必须证明没有降低升级质量，没有让员工过度依赖，
没有把客户风险隐藏在满意度或 handle time 指标后面。
9.3 Credit Underwriting Copilot
| 设计项 | 推荐团队拓扑 |
|---|---|
| Stream-aligned team | Credit Underwriting AI Team，拥有申请审查流程、underwriter UX、policy checklist、human decision support。 |
| Platform services | document AI pipeline、feature store、AI gateway、EvalOps、decision log、model registry。 |
| Complicated-subsystem | credit score / affordability model、fair lending methodology、explainability service、policy rules engine。 |
| Enabling | Model risk evidence coaching、underwriter adoption enablement、policy-to-eval workshop。 |
| Key cognitive load | 信贷政策、监管公平性、数据质量、模型解释、人工 override 和客户影响高度耦合。 |
| Conway risk | 如果 underwriting、risk modeling、compliance、AI platform 分裂，系统会把决策逻辑散落在模型、prompt、rules 和人工备注中。 |
| Operating model | AI 提供 evidence summary 和 policy checklist，不自动做最终拒贷；release gate 包含 fairness slice、override review、complaint linkage、model monitoring。 |
9.4 AI Gateway as Platform Product
| 设计项 | 推荐做法 |
|---|---|
| Team type | Platform team |
| Product promise | 让 stream teams 安全、低摩擦、可追溯地使用 approved models。 |
| Team API | model catalog、single API、routing profile、fallback、usage/cost、logs、data boundary controls。 |
| Cognitive load removed | provider SDK、密钥、日志、token 账单、基础 retry、allowlist、fallback。 |
| Cognitive load retained by consumer | use case intent、risk tier、prompt behavior、business acceptance criteria。 |
| Conway risk | 如果 gateway team 只按基础设施思维运作，业务团队会绕过它追求速度。 |
| Success metric | 新 AI use case 默认通过 gateway；gateway adoption 与 release evidence、cost attribution、incident trace 绑定。 |
9.5 EvalOps as Platform Control Plane
| 设计项 | 推荐做法 |
|---|---|
| Team type | Platform team + complicated-subsystem support |
| Product promise | 让每次 AI 变更都有可重复、可比较、可审计的质量和风险证据。 |
| Team API | dataset registry、evaluator registry、batch run、release gate report、production failure mining。 |
| Cognitive load removed | eval infra、experiment storage、report generation、evidence binding。 |
| Cognitive load retained by consumer | 失败严重度、业务样本、专家判断、risk appetite。 |
| Conway risk | 如果 eval 属于 QA、模型团队、产品团队各自一套，release decision 不可比较。 |
| Success metric | 关键 AI release 100% 关联 eval run；production failures 进入 golden set；risk review 使用同一证据链。 |
9.6 Model Risk as Effective Challenge
| 设计项 | 推荐做法 |
|---|---|
| Team type | Complicated-subsystem / governance capability |
| Product promise | 通过独立有效挑战提高 AI capability 的可信、可控和可监控程度。 |
| Team API | risk tier rubric、validation expectation、monitoring criteria、exception memo、challenge log。 |
| Cognitive load removed | 模型风险方法、验证要求解释、监控期望、风险接受格式。 |
| Cognitive load retained by first line | 业务用途、控制执行、数据证据、人工监督、运营监控。 |
| Conway risk | 如果 model risk 只在末端审批，组织结构会鼓励团队先建完再补证据。 |
| Success metric | 高风险 AI 在 discovery 阶段就有 risk tier 和 evidence plan；上线后有 ongoing monitoring review。 |
10. 模板
10.1 AI Team Topology Canvas
| Field | 示例 |
|---|---|
| Business stream | AML investigation |
| Stream-aligned team | AML Investigation AI Team |
| Owned outcome | analyst productivity、SAR narrative quality、false positive handling、missed escalation risk |
| Core domain load | AML typology、case evidence、regulatory expectation、analyst workflow |
| Consumed platform services | AI gateway、EvalOps、case tool gateway、audit log、RAG policy store |
| Complicated-subsystem dependencies | graph typology model、entity resolution、narrative judge calibration |
| Enabling needs | EvalOps rubric coaching、risk-by-design facilitation、analyst adoption training |
| Interaction modes | 6-week collaboration with typology team；gateway X-as-a-Service；EvalOps facilitation for first two releases |
| Key risks | evidence hallucination、under-escalation、analyst automation bias、case data leakage |
| Operating evidence | use case card、eval report、model risk memo、audit trace、override review、incident runbook |
10.2 Cognitive Load Assessment
| Load item | Rating | Evidence | Decision |
|---|---|---|---|
| Domain complexity | High | SAR narrative and typology require expert analyst judgment | Keep in stream team with SME capacity |
| Model provider complexity | Medium | Teams compare 4 vendors manually | Move behind AI gateway |
| Eval complexity | High | Critical failures require expert rubric and regression | Use EvalOps platform plus enabling facilitation |
| RAG source governance | High | Policy documents have multiple owners and retention rules | Assign knowledge owner registry and RAG freshness SLO |
| Tool action risk | High | Case update and escalation actions affect regulated workflow | Use tool gateway with HITL and audit |
| Evidence burden | High | Model risk asks for lineage, eval, monitoring and approval evidence | Generate binder from platform workflow |
10.3 Team API Card
| Field | 示例 |
|---|---|
| Team name | RAG Knowledge Platform Team |
| Team type | Platform team |
| Mission | 为企业 AI 应用提供 governed ingestion、permission-aware retrieval、citation、freshness monitoring 和 retrieval eval。 |
| Consumers | Customer Service AI、Employee Copilot、AML AI、Wealth Advisor AI。 |
| Services | source connector、metadata schema、indexing pipeline、retriever API、citation API、source freshness dashboard。 |
| Consumer duties | 指定 knowledge owner、source approval、domain acceptance criteria、feedback triage owner。 |
| Non-ownership | 不负责业务政策正确性；不批准客户可见话术；不替代 knowledge owner。 |
| SLO / SLE | approved source T+1 indexed；P1 source rollback 2 小时内完成；retrieval service 99.5% availability。 |
| Change rules | chunking/rerank/index policy 变更必须关联 retrieval eval run 和 consumer release note。 |
| Support | service catalog、office hour、P1 incident channel、monthly consumer review。 |
10.4 Conway Mirror Review
| Question | Evidence to inspect | Strong design signal |
|---|---|---|
| 系统组件是否对应清晰团队 owner？ | architecture diagram、team map、service catalog | 每个 gateway、RAG、eval、tool、model service 都有 Team API |
| 审批路径是否复制了部门墙？ | release flow、risk review、ticket history | 风险 criteria 前置，证据由平台自动形成 |
| 平台是否减少 stream team 负载？ | cognitive load heatmap、consumer feedback | stream team 少处理 provider、logging、audit、cost 等通用复杂度 |
| complicated expertise 是否服务化？ | model card、API、review cadence | 专家不被低价值 ticket 消耗，复杂能力可被稳定消费 |
| enabling 是否真正退出？ | enablement plan、training asset、team maturity | 被辅导团队能独立运行新实践 |
10.5 AI Platform Operating Model One-Pager
| Section | 示例内容 |
|---|---|
| Scope | 面向 AML、客服、信贷和员工 copilot 的企业 AI 平台 operating model。 |
| Team topology | 4 个 stream teams，1 个 AI platform team，3 个 complicated-subsystem teams，2 个 enabling teams。 |
| Platform products | AI gateway、EvalOps、RAG platform、tool gateway、observability/cost、evidence binder。 |
| Risk model | risk-tiered intake、release gate、model risk effective challenge、ongoing monitoring。 |
| Cadence | weekly quality review、biweekly platform review、monthly AI risk review、quarterly topology review。 |
| Metrics | time-to-pilot、release with eval、platform adoption、cost per successful task、critical incident、cognitive load trend。 |
| Evidence | use case inventory、Team API cards、eval reports、model cards、approval logs、incident records。 |
11. 评审清单
11.1 Team topology review
- 是否至少区分了 stream-aligned、platform、complicated-subsystem、enabling 四类团队。
- 每个 stream team 是否对明确业务 outcome 负责，而不是只负责一个技术组件。
- 平台团队是否以 product 和 Team API 方式对外提供能力。
- complicated-subsystem 团队是否拥有真正需要深度专业知识的能力。
- enabling team 是否有进入条件、介入方式和退出证据。
- 是否避免把 AI CoE 设计成永久专家池和审批中心。
- 是否用 cognitive load 解释团队边界，而不是只用汇报线解释。
11.2 Conway and architecture review
- 是否画出了当前组织通信路径和当前 AI 系统结构的映射。
- 是否识别重复 gateway、重复 eval、重复 RAG、重复 audit 等 Conway 症状。
- 是否用目标 AI platform architecture 反推目标团队边界。
- 是否把 risk、security、privacy、model risk 设计成 flow 中的能力，而不是末端阻塞。
- 是否有明确的 Team API 和 interaction contract 支撑目标架构。
- 是否定义了 topology review cadence，允许团队边界随平台成熟演进。
11.3 Cognitive load review
- stream team 是否被要求同时理解模型供应商、RAG infra、eval infra、tool security、cost、audit 和业务 policy。
- 哪些复杂度是 intrinsic，必须由业务团队掌握。
- 哪些复杂度是 extraneous，应由平台抽象。
- 哪些复杂度是 germane，应由 enabling team 转化成能力建设。
- 是否有证据显示平台服务减少了重复工作和等待时间。
- 是否有团队长期处于高负载但没有 boundary change。
11.4 Platform operating model review
- AI gateway 是否统一了模型访问、日志、成本、fallback 和数据边界。
- EvalOps 是否贯穿开发、release、生产监控和失败回流。
- RAG platform 是否有 knowledge owner、freshness、permission、retrieval eval。
- Tool gateway 是否有 tool risk tier、RBAC、HITL、idempotency、audit。
- Observability 是否覆盖质量、延迟、成本、fallback、人工覆盖和 incident。
- Evidence binder 是否能自动串联 use case、model、prompt、dataset、eval、approval、monitoring。
11.5 Financial retail risk review
- AML 场景是否保留 analyst decision right 和 SAR evidence trace。
- 客服场景是否把 under-escalation、错误话术、客户投诉作为高优先级风险。
- 信贷场景是否处理公平性、解释、人工 override、申诉和模型监控。
- 客户可见输出是否有 policy guardrails 和人类接管路径。
- 高影响决策是否有 model risk effective challenge 和 ongoing monitoring。
- 监管、审计、内控证据是否从运行流程产生，而不是上线后补材料。
12. 反模式
| Anti-pattern | 表现 | 后果 | 修正 |
|---|---|---|---|
| AI CoE as ticket factory | 所有 AI 项目都找 CoE 专家交付 | 专家过载，业务团队不成长 | CoE 拆成 enabling、platform、complicated-subsystem 能力 |
| Platform as permission office | 平台团队主要审批谁能用模型 | 团队绕过平台，平台价值弱 | 平台提供 self-service gateway、eval、observability 和 evidence |
| Stream team owns everything | AML / 客服 / 信贷团队自建 gateway、RAG、eval、audit | 认知负载爆炸，重复建设 | 通用复杂度进平台，复杂算法进 complicated-subsystem |
| Risk at the end | model risk 最后审材料 | 大量返工，证据断裂 | risk tiering 和 evidence plan 前置到 discovery |
| Permanent collaboration | 所有团队长期密集会议 | 速度慢，责任模糊 | collaboration 只用于探索，稳定后转 X-as-a-Service |
| Fake X-as-a-Service | 服务名义上自助，实际每次都要找人 | 平台没有真正产品化 | 重写 Team API、docs、SLO、service catalog 和 support model |
| Enabling without exit | enablement team 永久驻场 | 变成交付外包 | 设置退出证据和 capability transfer |
| Complicated team as bottleneck | 专家团队接所有低层需求 | 高价值复杂工作被挤压 | 输出 service、library、model card、office hour、review cadence |
| Org chart first | 先画汇报线，再让系统适配 | 架构复制权力结构 | 先画 flow、cognitive load、Conway map，再定边界 |
| Platform maximalism | 第一版平台追求全能力 | 上线慢，业务不用 | Thinnest Viable Platform，从 gateway + EvalOps + observability 起步 |
| Metrics without ownership | 看 adoption、quality、cost 但无人负责 | dashboard 变展板 | 每个指标绑定 owner、decision 和 cadence |
| Governance theater | 有委员会和模板，但不影响 release | 风险控制形式化 | gate criteria、critical failures、rollback 和 evidence 自动化 |
13. 30 天训练计划
Week 1: Conway diagnosis and topology baseline
| Day | 训练主题 | 产出 |
|---|---|---|
| 1 | 阅读 Conway 原文和 Team Topologies key concepts | 1 页读书笔记：AI 平台为什么会复制组织通信结构 |
| 2 | 选择一个 AI 场景：AML、客服或信贷 | use case card + current team map |
| 3 | 画当前 Conway mirror map | 当前组织通信路径和系统组件映射 |
| 4 | 识别重复建设和等待点 | duplicate gateway / eval / RAG / risk approval 清单 |
| 5 | 定义目标 AI platform architecture | target capability map |
| 6 | 用 inverse Conway 反推团队边界 | target topology diagram |
| 7 | 写 Week 1 reflection | 500 字：组织边界如何影响 AI 架构 |
Week 2: Cognitive load and Team API
| Day | 训练主题 | 产出 |
|---|---|---|
| 8 | 做 stream team cognitive load heatmap | intrinsic / extraneous / germane load matrix |
| 9 | 设计 AI gateway Team API | gateway Team API card |
| 10 | 设计 EvalOps Team API | EvalOps Team API card |
| 11 | 设计 model risk Team API | model risk effective challenge card |
| 12 | 定义 RAG / knowledge platform owner model | knowledge owner registry sample |
| 13 | 设计 interaction contract | collaboration -> X-as-a-Service transition plan |
| 14 | 复盘 cognitive load | 1 页 memo：哪些负载应平台化，哪些不应平台化 |
Week 3: Financial retail case build
| Day | 训练主题 | 产出 |
|---|---|---|
| 15 | AML investigation copilot topology | AML team topology canvas |
| 16 | AML EvalOps and model risk gate | SAR narrative eval rubric + risk gate |
| 17 | Customer service AI topology | customer service team API + RAG operating model |
| 18 | Customer service failure loop | under-escalation incident flow and feedback-to-eval loop |
| 19 | Credit underwriting copilot topology | credit AI topology + decision rights |
| 20 | Credit model risk evidence | fairness slice, override review, monitoring plan |
| 21 | 形成三案例对比 | AML / 客服 / 信贷 topology comparison table |
Week 4: Operating model and portfolio package
| Day | 训练主题 | 产出 |
|---|---|---|
| 22 | 设计 AI platform operating model | one-pager |
| 23 | 设计 governance cadence | weekly / monthly / quarterly cadence table |
| 24 | 设计 platform-as-product backlog | TVP backlog |
| 25 | 设计 evidence binder | evidence map from use case to monitoring |
| 26 | 写反模式诊断 | anti-pattern heatmap |
| 27 | 准备面试答案 | 8 个问题的 30 秒和 2 分钟版本 |
| 28 | 打磨作品集故事线 | portfolio narrative |
| 29 | 做 executive memo | 1 页汇报：为什么组织拓扑决定 AI 平台成败 |
| 30 | 模拟评审 | 15 分钟 presentation + Q&A notes |
14. 面试答案
Q1: Conway's Law 对企业 AI 平台有什么实际影响？
30 秒版本
Conway's Law 的实际含义是：AI 平台架构会复制组织通信结构。如果业务、平台、数据、风险、模型团队之间只有排队和末端审批，系统就会长成重复 gateway、重复 eval、断裂证据和难以审计的拼接架构。我会先做 Conway mirror map，再用 inverse Conway 设计团队边界、Team API 和交互模式。
2 分钟版本
在 AI 平台里，Conway's Law 比传统软件更明显，因为 AI 依赖模型、数据、知识、工具、评估、风险和运营多个能力。如果组织结构分裂，系统组件也会分裂。例如客服团队自接模型，AML 团队自建 eval，信贷团队单独维护 risk evidence，最后企业没有统一日志、成本、fallback、模型风险监控和审计证据。我的做法是先把当前组织通信路径和系统组件画在一张图上，识别重复建设、审批瓶颈和责任漂移。然后用目标平台架构反推团队拓扑：stream-aligned team 负责业务 outcome，platform team 提供 AI gateway / EvalOps / RAG / observability，complicated-subsystem team 管理复杂模型和方法，enabling team 提升业务团队能力，model risk 通过前置 criteria 和 evidence API 嵌入 flow。
Q2: 如何把 Team Topologies 应用到 AI 平台组织？
30 秒版本
我会把 AI 组织拆成四类团队：stream-aligned team 负责业务流 AI 产品，platform team 提供可复用 AI 能力，complicated-subsystem team 管理高复杂模型和方法，enabling team 短期提升其他团队能力。然后用 collaboration、X-as-a-Service、facilitation 三种交互模式控制依赖和认知负载。
2 分钟版本
AI 平台不能只靠一个 AI CoE。业务 AI 场景需要 stream-aligned teams，例如 AML investigation、客服、信贷 underwriting，它们拥有业务 outcome 和 adoption。通用能力应该平台化，例如 AI gateway、EvalOps、RAG ingestion、tool gateway、observability、cost 和 evidence binder。复杂专业能力不应复制到每个团队，例如 credit risk model、AML graph typology、LLM judge calibration、retrieval science，这些属于 complicated-subsystem teams。Enabling teams 则通过 2 到 6 周的 facilitation 帮团队建立 eval、risk-by-design、RAG quality 和 adoption 能力。关键不是画组织图，而是定义每类团队的 Team API、服务边界、交互模式和退出条件。
Q3: AI stream team 的 cognitive load 应该如何管理？
30 秒版本
我会把 AI 负载分成 intrinsic、extraneous、germane。业务政策和真实工作复杂度是 intrinsic，stream team 必须掌握；模型接入、日志、成本、基础 eval infra 是 extraneous，应由平台抽象；eval thinking 和 risk-by-design 是 germane，应通过 enabling 转成团队能力。
2 分钟版本
以客服 AI 为例，客服政策、客户情绪、投诉升级和前线工作方式是业务本身复杂度，不能完全外包给平台。但如果客服团队还要自己比较模型供应商、写 gateway、做日志、做 RAG 权限、维护 eval runner、生成审计证据，它就会被 extraneous load 压垮。平台团队应该提供 gateway、RAG platform、EvalOps、observability 和 cost ledger。另一方面，客服团队确实需要学会把失败样本转成 eval、把 under-escalation 定义成 critical failure、使用 feedback loop，这属于有效学习负载，可以由 enabling team 短期辅导。管理 cognitive load 的目标不是让团队什么都不用懂，而是让团队只承担与业务 outcome 直接相关的复杂度。
Q4: AI platform team 的 Team API 应该包含什么？
30 秒版本
Team API 应该说明平台团队提供什么服务、谁消费、消费者必须提供什么、平台不负责什么、SLO 是什么、如何支持、如何变更、产生什么证据。对 AI gateway 来说，核心是 approved model catalog、unified API、routing、fallback、quota、logging、cost attribution 和 audit metadata。
2 分钟版本
Team API 是跨团队契约，不是团队简介。以 AI gateway 为例，它要告诉 stream teams：你可以用哪些 approved models，通过哪个 API 调用，如何传 use case id、risk tier、data classification、prompt version 和 budget code。它也要明确不负责什么，比如不决定业务 use case 是否有价值，不维护业务知识库，不替 model risk 签字。它还要给出服务水平，例如 production gateway availability、provider outage fallback、cost dashboard 可见时间。最重要的是 evidence，它应自动产生 request log、model version、routing decision、fallback event、token cost 和 blocked request metadata，让 EvalOps、model risk 和 audit 能复用。
Q5: Collaboration 和 X-as-a-Service 在 AI 项目中如何切换？
30 秒版本
新场景、高不确定性和新能力建设时用 collaboration，因为需要高带宽探索。接口、责任、评估和运行证据稳定后，应转为 X-as-a-Service，降低长期协作成本。如果一直 collaboration，说明服务边界没有产品化。
2 分钟版本
例如客服 AI 第一次接入 RAG platform 时，stream team 和 RAG platform team 需要 collaboration，共同定义 source metadata、permission filter、citation UX、retrieval eval 和 freshness dashboard。这个阶段沟通成本高但合理。等检索 API、source owner workflow、eval threshold、failure triage 稳定后，就应该转为 X-as-a-Service：客服团队按 Team API 接入和配置，平台团队提供服务和 SLO。如果每次新增知识源都要多人会议，说明 RAG platform 没有减少认知负载，需要重写 Team API 或扩大平台能力。Enabling team 则不同，它是短期 facilitation，目标是让 stream team 能独立运行实践，而不是长期代劳。
Q6: Model risk 在 AI Team Topologies 中属于哪类团队？
30 秒版本
Model risk 不是普通平台团队，也不是 stream team。它更接近 complicated-subsystem / governance capability，提供风险分级、验证期望、monitoring criteria 和 effective challenge。它不拥有业务 outcome，也不应变成末端审批队列。
2 分钟版本
模型风险能力需要深度专业知识，包括模型验证、公平性、漂移、用途限制、监控和风险接受。它应该提供清晰 Team API：risk tier rubric、validation expectation、model card review、monitoring criteria、challenge log 和 exception memo。对高风险 AI，如信贷 underwriting copilot 或 AML SAR narrative support，model risk 应在 discovery 阶段参与定义 evidence plan 和 release gate，而不是等系统建完后审文档。它的正确交互模式包括 early facilitation、pre-release effective challenge、quarterly monitoring review 和 incident collaboration。这样风险进入 flow，而不是制造返工。
Q7: 如何判断 AI 平台是否真的降低了团队认知负载？
30 秒版本
看 stream team 是否减少了通用复杂度：是否不再自接模型、不再自建 eval infra、不再手工补审计证据、不再重复处理成本和日志。同时看 time-to-pilot、release with eval、platform adoption、incident traceability 和 consumer satisfaction。
2 分钟版本
平台价值不能只看 API 调用量。一个好 AI 平台应该让业务团队更快、更安全地交付真实 use case。证据包括：新 AI app 默认通过 gateway；release 自动关联 eval report；prompt / model / RAG 变更可回滚；线上 incident 能追溯到 model、prompt、dataset、tool 和 user context；成本能按 use case 和团队归因；业务团队不用为每个项目重复写日志、权限、provider retry、audit binder。还要看 qualitative feedback：stream team 是否认为平台是 path of least resistance，而不是额外审批层。如果团队持续绕过平台，说明平台没有减少认知负载。
Q8: 金融零售 AI 场景中，组织拓扑最大的风险是什么？
30 秒版本
最大风险是责任和证据断裂。AML、客服、信贷都涉及客户影响、监管、模型风险和运营监控，如果团队边界不清，AI 输出会散落在 prompt、模型、规则、人工备注和审批文档中，出事时无法解释、无法复盘、无法改进。
2 分钟版本
金融零售 AI 的高风险点不只在模型准确率，而在组织连接处。AML 需要 analyst 决策权和 SAR evidence trace；客服需要控制错误话术和 under-escalation；信贷需要公平性、解释和人工 override。若业务团队、AI platform、data science、model risk、compliance 和 operations 没有明确 Team API 和交互模式，系统就会出现证据断裂：谁定义可接受失败、谁维护知识、谁监控漂移、谁批准变更、谁处理 incident 都不清。我的做法是用 team topology 设计 owner 和 flow，用 EvalOps 形成 release and monitoring evidence，用 model risk effective challenge 保持独立性，用 platform services 降低重复建设。
15. 作品集交付物
15.1 最小作品集包
| Deliverable | 内容 | 展示能力 |
|---|---|---|
| AI Team Topology Diagram | AML / 客服 / 信贷 stream teams、platform teams、complicated-subsystem teams、enabling teams 和 interaction modes | 能设计 team-of-teams |
| Conway Mirror Map | 当前通信结构、当前系统映射、目标 inverse Conway 设计 | 能用组织结构解释架构问题 |
| Cognitive Load Heatmap | stream team 负载、平台化建议、enablement 建议 | 能做高级组织架构诊断 |
| Team API Cards | AI gateway、EvalOps、Model Risk、RAG platform、一个 stream team | 能定义跨团队接口 |
| AI Platform Operating Model One-Pager | portfolio、risk-tiered intake、platform services、governance cadence、decision rights | 能把组织、平台和治理落成运行机制 |
| Financial Retail Case Pack | AML、客服、信贷三案例 | 能把抽象框架转成行业方案 |
| Review Checklist | topology、Conway、cognitive load、platform、risk、financial controls | 能主持评审 |
| Interview Answer Sheet | 8 个高阶问答 | 能面向架构、产品、风险和管理层沟通 |
15.2 作品集叙事结构
Problem:
AI use cases 增长很快，但平台能力、风险证据、评估方式和团队边界分散。
Diagnosis:
我用 Conway mirror map 发现系统正在复制组织墙：
重复 gateway、重复 eval、知识 owner 缺失、model risk 末端返工。
Design:
我用 Team Topologies 重新设计 team-of-teams：
stream teams owning outcomes；
platform team offering AI gateway / EvalOps / RAG / tool gateway；
complicated-subsystem teams owning hard model and evaluation expertise；
enabling teams improving capabilities with exit criteria。
Operating Model:
我定义了 Team API、interaction modes、risk-tiered release gates、
governance cadence、cognitive load review 和 evidence binder。
Financial Retail Proof:
我用 AML、客服、信贷三个场景验证设计，
展示不同风险等级下团队交互、平台能力和模型风险证据如何变化。
15.3 管理层汇报版本
AI 平台不是一个工具采购项目，而是一套组织和平台共同演进的 operating model。
如果团队边界不变，系统会复制当前组织沟通问题：
重复建设、审批拥堵、证据断裂和风险责任漂移。
建议采用 Team Topologies：
1. 业务 stream teams 对 AI outcome 和 adoption 负责。
2. AI platform team 提供 gateway、EvalOps、RAG、tool gateway、observability、cost 和 evidence。
3. complicated-subsystem teams 管理高复杂模型、检索、评估和风险方法。
4. enabling teams 短期提升业务团队 AI delivery 能力。
5. model risk、security、privacy 和 compliance 通过 risk-tiered gates 和 evidence API 嵌入交付流。
衡量成功不只看上线数量，还要看：
time-to-pilot、release with eval、platform adoption、cost attribution、
critical incident reduction、audit evidence completeness 和 team cognitive load trend。
16. 最终记忆卡片
| Concept | 一句话 |
|---|---|
| Conway's Law | AI 系统会复制组织通信结构，因此组织边界就是架构决策。 |
| Inverse Conway | 先定义目标平台架构和 flow，再设计团队边界和交互模式。 |
| Stream-aligned team | 对业务流 AI outcome 负责，而不是对某个技术组件负责。 |
| Platform team | 把通用 AI 能力产品化，成为 stream teams 的低摩擦路径。 |
| Complicated-subsystem team | 拥有不应被每个团队重复掌握的高复杂模型、算法和风险方法。 |
| Enabling team | 短期提升团队能力，留下实践和证据后退出。 |
| Cognitive load | 用 intrinsic、extraneous、germane 区分哪些复杂度该保留、抽象或教学。 |
| Team API | 跨团队契约，说明服务、边界、SLO、消费责任、升级和证据。 |
| Interaction modes | collaboration 用于探索，X-as-a-Service 用于稳定消费，facilitation 用于能力提升。 |
| AI platform operating model | 把 AI gateway、EvalOps、RAG、tool gateway、observability、model risk 和业务 stream 串成可运行机制。 |
| 金融零售重点 | AML、客服、信贷 AI 的核心风险是责任、证据、人工监督和持续监控断裂。 |