AI Product Portfolio Rationalization / Capability Decommission Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_PRODUCT_PORTFOLIO_RATIONALIZATION_CAPABILITY_DECOMMISSION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

核心导读

AI 让企业更容易新增 copilot、RAG、agent、workflow automation，也更容易堆积重复能力、模型成本、供应商依赖、隐性运营负担和架构债。成熟的产品组合治理不是继续加功能，而是把产品、能力、应用、API、模型、prompt、RAG、工具和供应商依赖放到同一张证据图上，用客户价值、经济性、风险、约束和迁移可行性决定保留、合并、迁移、冻结或下线。

重要说明：本文是学习、作品集和内部架构训练材料，不构成法律、合规、审计、监管、客户通知、合同终止、记录删除或供应商退出建议。涉及客户影响、合同义务、records retention、legal hold、监管沟通、数据删除、供应商退出和风险接受的判断，应由机构授权角色结合内部政策和司法辖区要求确认。访问日期按 2026-06-30 记录。

---

Source Anchors

以下来源用于组织金融机构技术治理、架构、生命周期、韧性、AI 风险和 AI 管理体系语言。

---

1. 核心问题：AI 放大了 Portfolio Entropy

初级产品治理关心新增功能，中级产品治理关心 adoption 和 ROI，高级产品与架构治理必须关心 portfolio entropy：一个企业是否有能力停止低价值、重复、高风险或过时的工作。

AI 会放大这种熵增：

• 每个团队都能快速做 copilot、RAG、agent、workflow automation。
• 同一个客户问题会被不同业务线、渠道、供应商和平台重复解决。
• 模型调用、embedding 存储、eval、人工复核、日志保留和 trace analytics 形成新的 cost-to-serve。
• AI 工具链依赖供应商模型、插件、向量库、检索服务、标注平台、observability、policy engine 和 workflow SaaS。
• 旧能力没有退场机制，新能力就会与旧流程长期并行，增加培训、运营、审计、客户沟通和 incident 负担。

健康的产品组合不只看 launch 数量，也看企业能否合并重复能力、迁移客户和接口、释放团队容量、降低单位成本并减少控制复杂度。

成熟问题不是：

Which application can we retire?

而是：

Which capability should exist once, where should it live, who owns it,
what evidence proves it creates value, and what must be migrated before
the old version is shut down?

---

2. 架构贡献：Rationalization 的对象不只是应用

传统 application portfolio rationalization 常以应用为中心。AI 场景必须扩展到 product、capability、feature、API、model、prompt、RAG、tool 和 vendor。

架构贡献是把 portfolio decision 从 PowerPoint 变成证据链：inventory、signal mining、dependency graph、decision scorecard、architecture decision packet、migration orchestration、decommission certificate 和 benefit/risk realization monitoring。

---

3. Inventory：先建立可查询对象

Rationalization 的第一步不是开会投票，而是建立可查询 inventory。

Product / capability inventory 至少包括：

Application portfolio inventory 至少包括：

AI dependency inventory 必须单独建模：

每个新增 AI 对象都应能回答：

Who owns it?
Who uses it?
What does it cost?
What risk does it introduce?
What depends on it?
How do we retire it?

---

4. Decision Model：价值、成本、风险、债务、约束、迁移

Rationalization 不能只看 usage。金融零售中，低使用能力可能是关键控制；高使用能力也可能是低利润、高风险、训练成本高的复杂路径。

决策模式：

---

5. Dependency Graph：没有图谱的停用是猜测

Decommission 的核心架构资产是 dependency graph。

Customer segment
  -> Product / channel
  -> Business capability
  -> Journey / process step
  -> Feature
  -> API / event / batch job
  -> Application / service
  -> Data product / record store
  -> Model / prompt / RAG index / tool
  -> Vendor / contract / region
  -> Control / evidence / owner

关键 graph queries：

参考流程：

Portfolio inventory
  -> signal mining layer
  -> capability similarity and dependency graph
  -> rationalization scorecard
  -> architecture decision packet
  -> migration and sunset orchestration
  -> evidence binder
  -> benefit and risk realization monitoring

---

6. Feature / API / Model / Tool Sunset Controls

不同对象的 sunset 方式不同，不能用同一封通知解决所有问题。

Sunset 通知必须与 migration path 绑定。

下线完成后还要形成 decommission certificate：关闭了哪些入口、撤销了哪些权限、保留了哪些 records、导出了哪些数据、哪些消费者已迁移、哪些监控确认没有残余调用。

---

7. Governance：组合委员会、架构审查与授权约束

Rationalization 决策通常跨产品、运营、技术、风险、法务、财务和供应商。单个产品 owner 很难独立完成。

Architecture board 应批准的不是“关系统”这个口号，而是 rationalization decision type、impacted capability and systems、target-state architecture、migration sequencing、decommission evidence requirements、residual risk and exception owners。

---

8. AI 的角色：证据助手，不是停用决策者

AI 可以显著提升 rationalization 的证据生产速度，但不能拥有 customer-impacting shutdown 决策权。

AI 不能做：

• 决定关闭客户仍依赖的能力。
• 绕过 legal hold / records review。
• 以相似度自动合并 capability。
• 以 cost 最高为唯一关闭标准。
• 生成客户沟通后直接发送。
• 删除数据、日志、模型证据或 vendor records。

成熟边界是：AI proposes rationalization evidence and migration options; accountable humans decide customer impact, legal constraints, risk acceptance and final decommission。

---

9. 为什么有效：把新增、合并和下线纳入同一生命周期

这套架构有效，是因为它把 rationalization 从成本削减活动变成 capability lifecycle management。

第一，inventory 让组合对象可见。没有 product/capability/application/AI dependency inventory，讨论就会停留在主观印象。

第二，decision model 防止低使用率误杀关键控制，也防止高使用率掩盖高成本和高风险。

第三，dependency graph 把客户、渠道、流程、API、数据、模型、工具、供应商、records 和 controls 连接起来，避免局部下线造成系统事故。

第四，sunset controls 让 feature、API、model、prompt、RAG、tool 和 vendor 用不同机制退场，而不是靠统一邮件通知。

第五，governance 和 incentive 让团队因简化、合并、迁移和释放容量获得 credit，而不是只因 launch 获得 credit。

---

10. 局限和误用

常见 anti-pattern：

这套架构也有现实限制。依赖图谱不会自动准确；usage 可能低估隐性价值；客户迁移可能受合同、监管、语言、无障碍、渠道习惯和运营脚本约束；记录保留和法律保全可能使技术下线与数据删除分离。成熟做法是分阶段冻结、迁移、只读保留、证据归档和最终停用，而不是追求一次性清理。

---

11. 金融零售案例：重复的 Customer Service AI Assistant

场景：

• 信用卡、个人贷款、存款和财富团队分别建设了客服 AI assistant。
• 每个 assistant 都有自己的 RAG、prompt、模型供应商、case summary、知识库和 QA 流程。
• 客户看到的答案口径不一致，一线培训复杂，模型成本上升，audit evidence 格式不一致。

Rationalization analysis：

目标架构：

Customer service channels
  -> Shared AI service gateway
  -> Product policy profile
  -> Common RAG pipeline
  -> Common eval / trace / evidence
  -> Domain-specific workflow extensions

决策不是简单关闭四个 assistant，而是：

• 合并 policy retrieval、citation、case summary、trace logging、eval harness。
• 保留产品差异：产品政策、监管话术、审批角色、例外路径。
• 分三批迁移：内部 agent assist、低风险客户问答、复杂投诉场景。
• 下线旧 assistant 的新入口，保留 read-only evidence archive。
• 对旧 RAG index、prompt、tool connector 和 vendor route 分别执行 sunset control。

价值验证应看：答案一致性、投诉率、人工复核负载、token 成本、供应商集中风险、QA defect、evidence completeness 和迁移后旧调用量是否归零。

---

12. 架构和产品价值

成熟的 portfolio rationalization 能把“砍功能”的负面叙事改成“释放企业能力”的正向治理。

它改变了产品和架构讨论的单位：

健康指标包括 duplicate capability reduction、retired API/model/prompt count、old traffic decay、cost-to-serve reduction、incident reduction、records/evidence completeness、customer complaint stability、capacity released 和 platform reuse。

---

13. 学习验证

完成本文后，应能用架构对象回答以下问题。

最低可运行能力可以从 capability inventory、AI dependency inventory、usage/cost/risk signal mining、dependency graph、decision scorecard、sunset control checklist 和 decommission certificate 开始。规模化阶段再建设 portfolio health dashboard、architecture decision workflow、automated API/model deprecation telemetry 和 benefit realization review。

最终判断标准：

Can the organization prove what it stopped doing,
who was affected,
what dependencies were migrated,
which evidence was retained,
which risks were accepted,
and which capacity, cost or risk benefits were realized?

如果答案是否定的，问题不是企业缺少 AI 创新，而是还没有具备 AI-enabled decommission 的社会技术架构能力。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。