AI Third-Party Vendor：合同与退出架构
AI vendor architecture 是用合同、接口、控制、遥测、证据和退出方案管理供应商能力，而不是把模型或 SaaS 当成黑盒。供应商风险不是采购后才出现，它会进入数据治理、模型行为、服务连续性、成本、监管证据、客户体验和企业架构可替换性。
AI Third-Party Vendor Contract / Exit Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_THIRD_PARTY_VENDOR_CONTRACT_EXIT_ARCHITECTURE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Interagency Guidance on Third-Party Relationships | https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html | 参考银行第三方关系风险管理生命周期 |
| Federal Reserve Third-Party Risk Management | https://www.federalreserve.gov/supervisionreg/topics/third-party-risk-management.htm | 参考银行监管中的第三方风险管理主题 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将供应商风险映射到 AI govern/map/measure/manage |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 将供应商和外部提供方纳入 AI management system |
| NIST Cybersecurity Framework | https://www.nist.gov/cyberframework | 参考第三方安全、监控和事件响应 |
核心导读
AI vendor architecture 是用合同、接口、控制、遥测、证据和退出方案管理供应商能力，而不是把模型或 SaaS 当成黑盒。供应商风险不是采购后才出现，它会进入数据治理、模型行为、服务连续性、成本、监管证据、客户体验和企业架构可替换性。
对金融零售企业，第三方 AI 合同不能只谈价格和 SLA。它必须明确数据使用、模型变更、审计权、事件通知、输出权利、日志证据、子处理方、地理位置、退出迁移和监管协作。
系统价值在于把外部能力接入企业控制面：AI gateway、vendor adapter、数据最小化、遥测捕获、回归评测、fallback 和 evidence store 共同决定企业是否真正可控。评估供应商不应只看模型效果，还要看变更透明度、证据可得性、子处理方链路、成本弹性、退出演练和监管响应能力。
治理边界在于：合同定义权利义务，但技术架构决定实际可执行性。企业可以采购模型能力，却不应把知识库、日志、权限、评测、客户证据和退出路径完全交给供应商；关键场景必须能降级、替换、导出和证明删除。
问题定义
AI 供应商引入的风险具有架构性：
- 模型行为和版本变化由供应商控制，企业可能无法解释质量变化。
- 数据可能被用于训练、日志、调试或产品改进，边界不清会引发隐私和合规风险。
- 关键证据在供应商系统中，审计和监管问询时企业无法独立访问。
- 供应商 API、embedding、向量库或 agent 平台形成锁定，退出成本高。
- 子供应商和模型路由不透明，责任链复杂。
供应商架构要回答：
| 问题 | 能力 |
|---|---|
| 供应商承担哪些关键能力 | vendor capability map |
| 数据和输出如何被使用 | data use and retention clauses |
| 模型和服务如何变化 | change notification and regression testing |
| 如何证明控制有效 | vendor evidence exchange |
| 如何替换或退出 | abstraction layer、migration plan、exit test |
核心原理与方法
AI vendor management 应覆盖完整生命周期：
Need Definition
-> Due Diligence
-> Contract and Architecture Design
-> Onboarding Controls
-> Ongoing Monitoring
-> Change Management
-> Incident and Regulatory Support
-> Exit / Transition
合同条款应转化为架构控制：
| 合同主题 | 架构含义 |
|---|---|
| Data Use | 是否可用于训练、日志、调试；如何脱敏、保留、删除 |
| Model Change | 版本通知、重大变更定义、回归测试窗口 |
| Audit Rights | 企业和监管方可获取哪些证据 |
| Security | 加密、访问控制、漏洞、事件通知 |
| Availability | SLA、降级、灾备、区域故障 |
| Subprocessors | 子供应商披露、变更通知、地理位置 |
| Output Rights | 输出所有权、使用限制、责任边界 |
| Exit | 数据导出、删除证明、迁移支持、过渡期服务 |
系统与架构模型
Vendor abstraction architecture：
Business AI Application
-> Enterprise AI Gateway / Policy Layer
-> Vendor Adapter
-> Vendor AI Service
-> Evidence and Telemetry Store
-> Exit / Fallback Provider
关键设计：
| 架构机制 | 目的 |
|---|---|
| AI Gateway | 隐藏供应商差异，统一认证、策略、日志、成本和路由 |
| Vendor Adapter | 把供应商 API 转换为企业标准 request/response/evidence schema |
| Data Boundary | 在发送前执行最小化、脱敏、权限和地区控制 |
| Telemetry Capture | 保留企业侧 trace，不完全依赖供应商日志 |
| Fallback Strategy | 支持模型替换、降级模式和业务连续性 |
| Exit Runbook | 定义迁移数据、配置、prompt、eval、知识和证据的步骤 |
Exit architecture 不是合同附件，而是可演练能力：
| 退出对象 | 需要准备 |
|---|---|
| Prompts | 版本、测试集、配置导出 |
| Embeddings / Vector Store | 可重建语料、embedding 模型替代、索引重建脚本 |
| Fine-tuned Models | 权利、导出可能性、替代训练计划 |
| Logs / Evidence | trace export、retention、删除证明 |
| Tool Integrations | 企业侧接口抽象，避免绑定供应商 agent runtime |
| Workflows | 降级路径、人工处理、备用供应商 |
关键机制与取舍
| 取舍 | 判断原则 |
|---|---|
| Best-of-breed vendor vs Lock-in | 高差异能力可采购，但核心控制面和数据边界留在企业 |
| Deep integration vs Portability | 客户价值明显的能力可深集成，但必须有 adapter 和 exit test |
| Vendor telemetry vs Enterprise evidence | 供应商报告有用，但企业必须保留关键运行证据 |
| Cost optimization vs Resilience | 单一供应商折扣不能牺牲高关键场景的 fallback |
| Contract protection vs Technical control | 合同规定必要，但敏感数据最小化和网关控制更可靠 |
供应商分级：
| Criticality | 场景 | 要求 |
|---|---|---|
| Low | 内部低风险内容辅助 | 基础安全、数据使用限制、成本监控 |
| Medium | 员工工作流、客户草稿 | 变更通知、日志、评测、支持 SLA |
| High | 客户交互、受监管流程 | 审计权、独立证据、退出演练、供应商风险评审 |
| Critical | 核心业务连续性依赖 | 多供应商或降级方案、严密合同和持续监控 |
证据与控制
Vendor-control matrix：
| 控制目标 | 合同条款 | 技术证据 |
|---|---|---|
| 防止数据被未授权训练 | 禁止训练和二次使用 | request minimization log、DPA、vendor attestation |
| 管理模型变更 | 重大变更通知和测试窗口 | change notice、regression eval、approval |
| 支持监管问询 | 审计协作和证据提供义务 | evidence export、trace id、support ticket |
| 保持业务连续性 | SLA、灾备、退出支持 | availability report、fallback test |
| 确保删除和保留 | retention、deletion certificate | deletion proof、enterprise retention log |
持续监控指标：
- 供应商服务可用性、延迟、错误率。
- 模型质量回归和 failure class 变化。
- 成本异常和 token 使用趋势。
- 变更通知及时性和影响评估完成率。
- 供应商事件、漏洞和子处理方变更。
- Exit runbook 演练结果。
金融零售场景映射
以客户服务 RAG 使用第三方 LLM 为例：
| 风险 | 架构设计 |
|---|---|
| 客户数据外泄 | 网关执行 PII 最小化和 masking，供应商不得训练 |
| 模型变更影响回答 | 固定 eval suite，供应商变更触发回归 |
| 供应商不可用 | 降级到内部搜索、备用模型或人工队列 |
| 监管问询 | 企业侧保留 trace、source、版本和控制结果 |
| 锁定 | prompts、知识库、eval、logs 保持企业可导出 |
真实取舍：最强模型可能来自外部供应商，但客户服务属于品牌和监管敏感场景。合理做法是采购模型能力，但把知识库、权限、日志、评测、策略和证据控制在企业平台层。
反模式
- 合同签完才讨论数据边界、日志和退出。
- 直接在业务系统中调用供应商 API，没有企业网关和 adapter。
- 依赖供应商 dashboard 作为唯一证据。
- 把模型供应商 SLA 当成业务连续性方案。
- 没有模型变更通知和回归测试机制。
- 退出方案只写在合同里，从未演练。
最终心智模型
AI 供应商管理是架构能力，不只是采购流程。合同定义权利和义务，架构定义实际可控性，证据定义可证明性，退出设计定义谈判能力和韧性。成熟企业可以利用外部模型速度，同时把数据、控制、证据和可替换性留在自己手里。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。