AI 扩展计划 / Playbooks
AI Third-Party / Vendor Risk Playbook
版本：v1.0
912 行AI_THIRD_PARTY_VENDOR_RISK_PLAYBOOK.md
AI Third-Party / Vendor / Procurement / Outsourcing Risk Playbook
版本：v1.0 日期：2026-06-29 适用对象：AI 产品经理、业务分析师、企业架构师、解决方案架构师、第三方风险管理、采购、法务、合规、隐私、信息安全、模型风险、内审、金融零售业务负责人
定位：把 AI 供应商、外包、采购和第三方风险管理统一成一套可落地的金融零售 AI 风险手册。重点不是背诵供应商清单，而是能把 foundation model、cloud AI、RAG SaaS、agent platform、data vendor、eval vendor、系统集成商和外包团队放进同一个风险生命周期里管理。
重要说明：本文是学习、架构和作品集材料，不是法律意见、监管解释、采购建议或合同文本。正式项目必须由 legal、compliance、procurement、third-party risk、privacy、security、model risk、business owner 和 internal audit 按机构类型、监管关系、司法辖区、数据分类和业务用途确认。
1. 核心观点
金融零售 AI 第三方风险不是传统供应商管理的简单延伸。它叠加了四类依赖：
- 供应商依赖：模型、云平台、SaaS、数据、评估、外包交付、支持服务。
- 数据依赖：客户身份、账户、交易、通话、投诉、授信、AML、KYC、内部政策、知识库、日志。
- 模型依赖：基础模型、embedding、reranker、prompt、RAG index、agent tool、judge model、guardrail、policy engine。
- 运营依赖：版本变更、事故通知、服务可用性、人员访问、子处理方、审计证据、退出迁移。
一句话定义：
AI third-party risk management = 对外部 AI 能力在数据、模型、流程、合同、运营、合规和退出上的全生命周期控制，确保机构在使用第三方时仍能对客户、监管、业务结果和风险后果负责。
本手册的核心判断：
- 买 AI 不是把风险转移给供应商。银行、支付、借贷、财富、零售金融机构仍然需要证明自己做了适当的风险识别、尽调、合同约束、持续监控和退出准备。
- AI vendor selection 不能只看 benchmark、demo 和单价。金融零售更关心数据使用边界、可审计性、变更可控性、SLA、监管协作、事故响应、集中度和可退出性。
- AI 采购不是采购部门的单线程流程。PM / BA 要定义问题和使用边界；Architect 要定义架构和替换点；Risk / Legal / Security 要定义控制；Procurement 要把控制写进合同和供应商治理节奏。
- 任何 vendor 声称“我们已经合规”都不等于客户机构已经完成治理。证据必须能映射到本机构用例、数据、版本、流程、角色、客户影响和控制运行记录。
2. 与现有学习资产的连接
| 已有文档 | 本手册如何连接 |
|---|---|
docs/AI_VENDOR_BUILD_BUY_ADOPTION_PLAYBOOK.md | 本手册是其供应商风险深水区：从 build / buy / hybrid 决策延伸到尽调、合同、SLA、变更、退出和集中度。 |
docs/AI_MODEL_RISK_MANAGEMENT_PLAYBOOK.md | 把模型风险扩展到第三方模型、供应商模型更新、vendor-hosted eval、RAG index 和 agent tool。 |
docs/AI_AUDIT_EVIDENCE_BINDER_PLAYBOOK.md | 把第三方尽调、SOC 2、ISO、合同、审计权、incident、subprocessor、exit evidence 纳入证据包。 |
docs/AI_PLATFORM_SECURITY_GATEWAY_LAB.md | 把模型网关、访问控制、日志、数据脱敏、密钥管理和 vendor routing 作为技术控制落点。 |
docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md | 把 vendor demo、RFP、PoC、release gate 和 ongoing monitoring 转成可评估需求。 |
docs/AI_OPERATING_MODEL_RACI_RUNBOOK.md | 把 AI vendor owner、business owner、procurement、risk、security、legal、model risk、incident commander 的职责落到 RACI。 |
学习顺序建议：
- 先用 build / buy / hybrid 文档判断是否需要第三方。
- 再用本文建立第三方风险生命周期、供应商版图和合同控制。
- 用 model risk、eval、audit evidence 文档把供应商承诺转成验证证据。
- 用 platform security 和 operating model 文档把控制接入生产系统与日常运营。
3. Source Anchors And Use Boundaries
以下锚点用于组织学习语言和证据结构。它们不自动等同于某个机构的合规结论。
| Anchor | Official source | 本手册使用方式 |
|---|---|---|
| Interagency Guidance on Third-Party Relationships: Risk Management | https://www.federalreserve.gov/supervisionreg/srletters/sr2304.htm | 采用 planning、due diligence、contract negotiation、ongoing monitoring、termination 的生命周期；强调按风险、复杂度和关键性调整控制。 |
| OCC Bulletin 2023-17 | https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html | 作为 OCC 对联合指引的官方公告；注意其 rescinds OCC Bulletin 2013-29 和 OCC Bulletin 2020-10。 |
| FDIC FIL-29-2023 | https://www.fdic.gov/news/financial-institution-letters/2023/fil23029.html | 作为 FDIC 对联合指引的官方公告；强调银行使用第三方不减少自身安全稳健经营和合规责任。 |
| Federal Register final guidance | https://www.federalregister.gov/documents/2023/06/09/2023-12340/interagency-guidance-on-third-party-relationships-risk-management | 用作联合指引正式文本锚点，便于引用生命周期、治理、合同、持续监控和终止阶段。 |
| Federal Reserve SR 13-19 / CA 13-21 | https://www.federalreserve.gov/newsevents/pressreleases/bcreg20131205a.htm | 历史外包风险管理锚点；Fed SR 23-4 已 supersedes 该信件，正式项目以当前联合指引为基准。 |
| OCC Bulletin 2013-29 | https://www.occ.gov/static/rescinded-bulletins/bulletin-2013-29.pdf | 历史第三方风险管理锚点；OCC 2023-17 已 rescinds 该 Bulletin，学习时可对比术语演进。 |
| OMB M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government | https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-22-Driving-Efficient-Acquisition-of-Artificial-Intelligence-in-Government.pdf | 虽面向美国联邦机构，但对 AI 采购很有参考价值：跨职能采购、竞争性市场、性能追踪、风险管理、开放格式/API、避免锁定。 |
| NIST AI RMF 1.0 | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern、Map、Measure、Manage 组织 AI 供应商风险、评估、监控和治理证据。 |
| ISO/IEC 42001:2023 | https://www.iso.org/standard/42001 | 用 AI Management System 语言审查供应商是否具备 AI 生命周期、责任、风险、变更、持续改进和治理体系。 |
| AICPA SOC Suite / SOC 2 | https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services | 用于审查服务组织控制证据，重点关注 security、availability、confidentiality、privacy、processing integrity。 |
| ISO/IEC 27001:2022 | https://www.iso.org/standard/27001 | 用作信息安全管理体系证据锚点，辅助审查供应商 ISMS、风险管理和安全控制。 |
使用边界：
- 银行第三方风险锚点偏向安全稳健、责任不外包、生命周期管理和合同控制。
- OMB M-25-22 偏向 AI acquisition 方法论，不是银行监管要求；本文借用其“跨职能采购、避免锁定、性能和风险追踪”的采购思想。
- NIST AI RMF 与 ISO/IEC 42001 提供 AI 治理语言，但不能替代行业监管、隐私法规、消费者保护、模型风险、网络安全和机构内部政策。
- SOC 2、ISO 27001、ISO 42001 证书只能证明某个范围内的管理体系或控制经过审查，不能证明某个金融 AI 用例已经适合上线。
4. AI Vendor Landscape：供应商版图
AI vendor landscape 要按“能力层”而不是按品牌记忆。一个金融零售 AI 系统常常同时依赖多个供应商：基础模型在 A，云和数据管道在 B，RAG SaaS 在 C，评估平台在 D，系统集成由 E 交付。第三方风险管理必须看到完整供应链。
| Vendor type | 典型价值 | 典型风险 | 尽调重点 | 合同与控制重点 |
|---|---|---|---|---|
| Foundation model provider | 提供 LLM、vision model、embedding、speech、reranker、fine-tuning | 数据被用于训练、模型静默更新、跨区域处理、输出不可解释、速率限制、单模型集中度 | 数据使用条款、模型版本、训练边界、日志保留、eval evidence、red-team、区域和子处理方 | 数据不训练、不微调、不共享；版本通知；可冻结或回滚；日志保留；SLA；incident notice |
| Cloud AI platform | 托管模型、MLOps、向量库、AI gateway、IAM、日志、监控 | 云集中度、跨服务数据流、权限复杂、配置错误、账单失控、region failover | IAM、tenant isolation、encryption、networking、regionality、SOC/ISO、DR、billing guardrail | 责任共担矩阵；可用性与灾备；数据驻留；访问日志；密钥管理；成本上限 |
| RAG SaaS / knowledge platform | 文档摄取、搜索、权限同步、引用、知识库治理 | 权限泄露、旧政策引用、embedding 敏感性、索引不可导出、source lineage 不清 | connector 权限、ACL 同步、index version、source freshness、citation correctness、export | 权限继承；索引导出；删除证明；数据保留；知识更新 SLA；审计日志 |
| Agent platform / workflow automation | 多步骤任务、工具调用、审批流、case handling、自动执行 | excessive agency、越权操作、工具误用、不可复现、prompt injection、下游系统写入风险 | tool permission、approval gates、sandbox、idempotency、trace、kill switch、human override | 工具权限边界；高风险动作人工批准；完整 trace；kill switch；变更审批 |
| Data vendor | KYC、制裁名单、企业数据、收入估计、商户数据、信用/欺诈信号、地理和行为数据 | 数据授权不清、偏差、覆盖不足、更新滞后、二次使用限制、消费者权益风险 | 数据来源、许可、覆盖率、质量、刷新频率、偏差测试、纠错机制、使用限制 | 用途限制；再分发限制；数据质量 SLA；纠错与删除；监管配合；赔偿条款 |
| Eval vendor / red-team vendor | 离线评估、LLM-as-judge、红队、安全测试、bias testing、monitoring | 评估集泄漏、judge bias、测试不贴合业务、供应商既当运动员又当裁判 | methodology、calibration、negative cases、domain rubric、independence、data handling | 评估数据保密；方法透明；可复现报告；独立性声明；证据导出 |
| AI observability vendor | trace、latency、cost、quality、feedback、drift、prompt/version logging | 日志含敏感信息、观测供应商变成数据集中点、保留过长、访问控制弱 | data minimization、redaction、RBAC、retention、export、SIEM integration | 日志脱敏；最小保留；审计导出；访问控制；删除证明 |
| System integrator / outsourcing partner | 需求、实施、数据迁移、集成、UAT、运维、变更支持 | 交付质量、人员访问、离岸外包、知识流失、隐藏子承包、SOW 模糊 | staffing、background check、secure SDLC、IP ownership、deliverable acceptance、subcontractors | 明确交付物；代码和文档归属；人员替换；访问回收；subcontractor approval |
| Managed service provider | 托管运维、模型监控、知识库运营、case review、人工标注 | 操作错误、权限滥用、客户数据暴露、服务质量不稳、流程黑盒 | SOP、quality assurance、training、access logging、segregation of duties、location | 操作 SLA；质量抽检；访问日志；培训证据；事故通知；退出交接 |
供应商版图的第一原则：
不要只登记“主合同供应商”。要登记所有进入 AI 系统链路的模型、云服务、数据源、评估工具、日志平台、外包人员和子处理方。
5. Build / Buy / Hybrid 连接
AI 第三方风险从 build / buy / hybrid 决策开始。选择方式不同，风险残留位置不同。
| Strategy | 适用场景 | 优势 | 风险残留 | 第三方控制重点 |
|---|---|---|---|---|
| Build | 核心差异化能力、强监管场景、需要深度集成、数据高度敏感、供应商无法满足控制 | 控制力强、可定制、可审计、可逐层替换 | 内部人才、速度、成本、模型与平台仍可能依赖第三方 | 云、模型、数据、工具链仍需供应商风险管理 |
| Buy | 标准化场景、成熟 SaaS、低到中风险 workflow、快速验证价值 | 上线快、功能完整、运维压力低 | 黑盒、锁定、合同边界、数据使用、模型更新、审计不足 | 尽调、合同、SLA、日志、数据限制、退出 |
| Hybrid | 业务流程自建，模型/平台/评估外购；或核心决策自建，辅助能力外购 | 平衡速度与控制，适合金融 AI 主流路径 | 接口复杂、责任边界模糊、供应链更长 | 架构分层、责任矩阵、版本控制、集成监控 |
| Partner / co-development | 与 fintech、模型公司或 SI 共创行业方案 | 获取专业能力，缩短探索周期 | IP、客户数据、交付依赖、商业排他、监管配合 | SOW、IP、数据、人员、审计、交接、共同责任 |
5.1 分层决策法
不要用一个 build / buy 结论覆盖整个 AI 系统。按层决定：
| Layer | 默认建议 | 何时外购 | 何时自建或强控制 |
|---|---|---|---|
| Foundation model | 多供应商可替换 | 通用语言、总结、分类、抽取、低风险 copilot | 关键决策、高敏感数据、模型输出影响客户权益 |
| AI gateway | 强烈建议自控或由核心平台控制 | 小型团队早期试点 | 金融零售生产系统，需要统一日志、策略、路由、成本、审计 |
| RAG ingestion / index | 视数据敏感度 hybrid | 普通知识库、低敏文档 | 政策、客户数据、内部控制、法律文档、强权限文档 |
| Workflow / agent | 高风险场景自控审批和权限 | 内部效率、只读辅助 | 任何写入账户、支付、授信、投诉、AML case 的动作 |
| Evaluation | 内部 owner + 外部工具 | 通用 red-team、观测、测试平台 | 业务 acceptance、监管证据、模型风险验证 |
| Data vendor | 外购但强合同 | KYC、制裁、商户、市场、地理数据 | 数据直接影响拒绝、授信、收费、风控或客户通知 |
| Frontline operations | hybrid | 低风险标注、质检、知识运营 | 客户敏感、投诉、争议、监管响应、人工复核 |
5.2 决策门禁
| Gate | 核心问题 | 必要证据 | 停止信号 |
|---|---|---|---|
| Problem gate | 业务痛点是否清楚，是否必须用 AI | Opportunity canvas、baseline、no-AI option、owner | 只有“想试 AI”，没有可衡量问题 |
| Risk gate | 用例是否涉及客户权益、敏感数据、监管义务或关键运营 | Risk tier、data classification、customer impact、process map | 高风险但无人工复核、无审计日志、无退出 |
| Option gate | build / buy / hybrid 是否基于证据 | Decision matrix、TCO、control gap、architecture option | 只因供应商 demo 漂亮而选型 |
| Vendor gate | 供应商是否满足进入 PoC 的最低要求 | Due diligence pack、security evidence、data terms、subprocessor list | 不接受数据限制、审计权、事故通知或模型变更通知 |
| Pilot gate | PoC 是否证明价值和控制 | Eval report、workflow UAT、risk sign-off、contract path | 准确率不稳定、无法解释、无法复现、业务不信任 |
| Production gate | 是否能运营、监控、响应、退出 | Runbook、SLA、monitoring、incident plan、exit plan | 没有 owner、没有日志、没有 kill switch、没有回滚 |
6. 第三方风险生命周期
联合指引的生命周期语言可转成 AI 项目执行流：
Strategy and planning
-> use case and criticality tiering
-> market scan / RFI / RFP
-> due diligence
-> contract negotiation
-> onboarding and implementation
-> pilot and validation
-> production monitoring
-> change management
-> incident management
-> renewal / expansion
-> termination and exit
| Stage | 关键问题 | AI-specific evidence | 主要责任方 |
|---|---|---|---|
| Strategy and planning | 为什么需要第三方，是否符合目标架构和风险偏好 | Build/buy/hybrid memo、target architecture、risk tier、TCO | PM、Architect、Business、Enterprise Architecture |
| Use case tiering | 数据和客户影响有多大，是否关键活动 | Data classification、customer impact assessment、criticality assessment | BA、Risk、Privacy、Compliance |
| Market scan | 市场有哪些供应商，是否存在集中度和锁定 | Vendor landscape map、longlist、dependency map | Procurement、PM、Architect |
| RFI / RFP | 需求是否足够具体，供应商是否按同一标准比较 | Requirements-to-eval matrix、RFP response matrix、demo script | PM、BA、Procurement |
| Due diligence | 供应商能否安全、合规、稳定地支持用例 | Security pack、AI governance pack、model evidence、data flow、subprocessor list | Third-party Risk、Security、Model Risk、Legal |
| Contract negotiation | 控制是否写入可执行合同 | MSA、DPA、SLA、AI addendum、audit rights、exit terms | Legal、Procurement、Risk、Business |
| Onboarding | 账号、权限、网络、数据、日志、培训是否受控 | Access approval、integration checklist、training evidence、runbook | Security、IT、Platform、Business Ops |
| Pilot | 是否证明价值、风险可控、用户接受 | Eval report、UAT、red-team result、pilot metrics、issue log | PM、BA、Model Risk、Business |
| Production monitoring | 供应商表现和 AI 行为是否持续可控 | SLA dashboard、quality metrics、incident log、cost dashboard、vendor review minutes | Vendor Owner、Ops、Risk、SRE |
| Change management | 模型、数据、prompt、工具、子处理方变更是否受控 | Change notice、impact assessment、regression eval、approval record | Vendor Owner、Architect、Model Risk |
| Incident management | 数据、模型、安全、服务、客户影响事故如何通知和处置 | Incident notice、timeline、customer impact、root cause、remediation evidence | Incident Commander、Legal、Security、Business |
| Renewal / expansion | 是否继续、扩大或限制供应商 | Renewal scorecard、risk acceptance、audit findings、cost trend | Procurement、Business、Risk |
| Termination and exit | 如何迁移、删除、证明、替换 | Exit plan、export package、deletion certificate、parallel run result | Vendor Owner、Architect、Legal、Data |
生命周期原则：
- 风险管理从计划阶段开始，不是在合同签完后补材料。
- 高风险或关键活动供应商需要更深的尽调、更强的合同、更频繁的监控和更完整的退出计划。
- 采购完成不是治理结束；AI 系统的模型、数据、知识库、prompt、agent tool 和供应商子处理方都会变化。
- 任何生产使用都需要 owner、RACI、日志、SLA、incident path、change path 和 exit path。
7. 风险分级：Criticality And AI Impact
第三方关系的风险强度取决于活动关键性、数据敏感度、客户影响、替代难度和操作复杂度。
| Tier | 金融零售 AI 例子 | 关键风险 | 控制强度 |
|---|---|---|---|
| Tier 1: Critical / High impact | 授信建议、反欺诈拦截、AML alert triage、KYC 决策辅助、催收策略、支付风险、财富适当性、监管报告、客户投诉处置 | 客户权益、合规、消费者保护、模型风险、操作风险、声誉风险 | 深度尽调、法务合同红线、独立验证、人工复核、审计权、强 SLA、事故通知、退出演练 |
| Tier 2: Important / Controlled impact | 客服 copilot、网点/呼叫中心知识助手、贷款文档抽取、支付争议摘要、运营质检、内部政策问答 | 错误建议、隐私泄露、员工过度依赖、知识陈旧 | 标准尽调、RAG 评估、日志、HITL、监控、变更通知、供应商季度评审 |
| Tier 3: Low impact / Internal productivity | 内部会议摘要、代码辅助、非敏感文档草稿、培训内容生成、市场研究摘要 | 数据泄露、版权/IP、输出质量、员工误用 | 轻量尽调、数据分类限制、使用政策、访问控制、成本监控 |
| Tier 4: Sandbox / Learning | 无真实客户数据的学习、原型、非生产 demo | 数据误投、shadow AI、误认为可上线 | 禁止敏感数据、明确环境隔离、短期账号、无生产连接 |
风险升级触发：
- 使用真实客户 PII、账户、交易、收入、信用、投诉、健康、身份或生物识别数据。
- 影响授信、收费、账户限制、欺诈拦截、催收、投诉结论、客户沟通或监管报告。
- AI 输出直接写入核心系统、case management、CRM、支付、贷款、AML 或 KYC 系统。
- 供应商模型或数据源不可替代，或迁移成本高。
- 供应商拒绝合同化数据限制、模型变更通知、审计权、事故通知或退出协助。
8. Due Diligence：AI 供应商尽调框架
尽调不是收一份 SOC 2 报告就结束。AI vendor diligence 至少覆盖业务、财务、数据、模型、安全、隐私、治理、评估、集成、运营、合同和退出。
8.1 尽调问题总表
| Dimension | 核心问题 | 要求证据 | 红旗信号 |
|---|---|---|---|
| Business fit | 供应商是否真正支持目标 workflow，而不是通用 demo | Reference architecture、case study、workflow demo、customer references | 只展示聊天窗口，不展示异常路径和审批流程 |
| Financial viability | 供应商是否能持续运营，是否依赖单一融资或大客户 | 财务概况、保险、业务连续性说明、客户集中度说明 | 现金流不稳、服务依赖小团队、无连续性安排 |
| Data usage | prompt、completion、embedding、日志、support ticket、telemetry 是否用于训练或改进模型 | Data processing terms、DPA、retention schedule、training opt-out confirmation | “默认不训练”但日志和人工审核条款模糊 |
| Data residency | 数据处理和存储在哪些国家、云区、支持中心 | Data flow diagram、region list、subprocessor location、support access policy | 销售口径说本地，但合同允许全球处理 |
| Privacy | 是否支持 PII 最小化、删除、更正、访问请求和数据主体权利 | Privacy policy、DPA、deletion process、DSAR support | 删除只覆盖主库，不覆盖日志、embedding 和备份 |
| Security | SSO、RBAC、SCIM、加密、密钥、网络隔离、漏洞管理是否成熟 | SOC 2、ISO 27001、pen test summary、secure SDLC、incident policy | 无企业级 SSO、共享管理员、弱租户隔离 |
| AI governance | 供应商是否有 AI policy、risk assessment、model change、red-team、human oversight | AI governance policy、ISO 42001 evidence、model cards、risk register | 只有伦理原则网页，没有生命周期证据 |
| Model identity | 使用哪些模型、版本、routing、fallback、fine-tune、embedding 和 reranker | Model inventory、version policy、release notes、eval report | 模型身份模糊，无法说明何时升级 |
| Evaluation | 是否能按客户业务数据和 rubric 做 eval，而不是只给通用 benchmark | Eval methodology、sample report、negative cases、calibration record | 只给总准确率，不给失败分类和样本 |
| RAG controls | 权限、引用、索引、来源、刷新、删除如何管理 | ACL sync design、index version、citation eval、freshness metrics | 引用不可验证，权限只在 UI 层控制 |
| Agent controls | 工具权限、审批、回滚、幂等、沙箱、kill switch 是否完整 | Tool permission matrix、approval workflow、trace schema | agent 可直接写入系统且无人工批准 |
| Integration | 与 IAM、SIEM、DLP、CRM、core、case、data lake 是否可控集成 | API docs、auth pattern、integration architecture、sandbox | 要求共享数据库账号或长期高权限 token |
| Operations | 生产 SLA、support、DR、RTO/RPO、status page、incident postmortem 是否成熟 | SLA、DR test、support matrix、status history、postmortem sample | SLA 排除关键依赖，支持时间不覆盖业务时段 |
| Auditability | 能否重建 case-level 证据链 | Audit log schema、export API、admin log、trace sample | 日志只有聊天记录，没有模型、prompt、source、tool 版本 |
| Subprocessors | 是否列明所有模型、云、数据、标注、支持、观测和外包子处理方 | Subprocessor schedule、change notice policy、approval workflow | “按需使用子处理方”但不提前通知 |
| Contractability | 销售承诺是否能写入合同 | MSA、DPA、SLA、AI addendum、security addendum | 演示承诺无法进入合同或 order form |
| Exit | 数据、配置、prompt、index、日志、eval、case history 能否导出 | Export docs、termination assistance、deletion certificate | 只能导出原始文档，无法导出审计日志和配置 |
8.2 分角色尽调
| Role | 必问问题 | 产出 |
|---|---|---|
| AI PM | 供应商是否解决目标用户的真实 workflow，是否支持 pilot metric 和 adoption metric | Vendor value scorecard、pilot success criteria |
| AI BA | AS-IS / TO-BE 流程、异常路径、人工复核、证据链是否清楚 | Workflow map、requirements-to-eval matrix |
| Architect | 数据流、系统边界、模型路由、RAG、agent tool、日志、替换点是否合理 | Architecture review、ADR、dependency map |
| Security | IAM、加密、tenant isolation、logging、vulnerability、incident 是否达标 | Security assessment、risk findings |
| Privacy | 数据分类、用途限制、保留、删除、跨境、支持访问是否可控 | Privacy impact notes、DPA issues |
| Model Risk | 模型用途、验证、变更、监控、限制和有效挑战是否充分 | Model risk assessment、validation plan |
| Third-party Risk | 关键性、财务、运营、分包、持续监控和退出是否符合供应商政策 | TPRM risk assessment |
| Legal | 数据、IP、责任、审计权、监管配合、事故通知、终止权是否合同化 | Contract issue list |
| Procurement | 商业条款、价格、续费、SLA credit、替代供应商、集中度是否可管理 | Commercial analysis、negotiation plan |
8.3 最小可接受证据包
Tier 1 / Tier 2 AI 供应商进入生产前，应至少拿到以下证据：
| Evidence | Why it matters | 验收要点 |
|---|---|---|
| End-to-end data flow diagram | 确认数据进入哪些系统和地区 | 覆盖 prompt、completion、embedding、logs、telemetry、support、backup |
| Data processing terms / DPA | 把数据用途、保留、删除、跨境、子处理方合同化 | 明确禁止训练、再识别、再销售和未授权二次使用 |
| SOC 2 Type II or equivalent control evidence | 验证服务组织控制运行 | 范围覆盖所采购服务，报告期有效，例外项有整改 |
| ISO 27001 certificate or ISMS evidence | 验证安全管理体系 | 证书范围覆盖产品、云环境、运营组织 |
| AI governance policy or ISO 42001 evidence | 验证 AI 生命周期管理 | 覆盖风险评估、模型变更、评估、监控、人工监督 |
| Model inventory and version policy | 防止模型黑盒和静默升级 | 说明模型、版本、fallback、升级通知和回滚 |
| Eval methodology and sample report | 验证质量而非只听销售承诺 | 包含业务样本、负例、失败分类、阈值、复测机制 |
| Subprocessor list | 识别供应链和跨境处理 | 覆盖模型、云、数据、支持、标注、监控、外包 |
| Incident response policy | 定义通知、升级和补救 | 覆盖安全、隐私、AI 质量、服务中断、模型异常 |
| Exit and export documentation | 降低锁定和终止风险 | 包含数据、配置、日志、eval、索引、删除证明 |
9. 合同条款：AI Vendor Contract Control Pack
合同条款要把“供应商说可以”变成“供应商必须做”。下面是金融零售 AI 项目的核心条款类别。
| Clause area | 控制目标 | 推荐写入点 | 不可接受写法 |
|---|---|---|---|
| Data use restrictions | 供应商不得把客户数据、prompt、completion、embedding、日志用于训练、微调、产品改进、再销售或第三方共享，除非本机构明确书面同意 | MSA、DPA、AI addendum、order form | “用于改进服务”未限定范围 |
| Data retention and deletion | 数据保留期限、备份删除、日志删除、embedding 删除、终止后删除证明 | DPA、security addendum、termination clause | 只删除原始文档，不覆盖衍生数据和日志 |
| Model update notice | 模型、embedding、reranker、guardrail、prompt template、agent tool、RAG pipeline 重大变更需提前通知 | AI addendum、change management clause | 供应商可单方随时变更核心模型 |
| Approval for high-impact change | 对客户权益、合规、关键运营有影响的变更需客户审批或可选择延迟 | AI addendum、SLA、service description | 通知即生效，无测试窗口 |
| Audit rights | 客户、监管、内审、外审可获得合理审计证据或进行审查 | Audit clause、regulatory cooperation clause | 仅提供营销白皮书，不提供控制证据 |
| SOC / ISO / AI governance evidence | 定期提供 SOC 2、ISO、penetration test summary、AI governance evidence、bridge letter | Security addendum、vendor review schedule | 证据只在签约前提供，续约前不更新 |
| SLA and service credits | 可用性、延迟、支持响应、DR、RTO/RPO、data freshness、quality defect response | SLA schedule | SLA 排除模型供应商、云依赖和高峰期 |
| Incident notification | 安全、隐私、AI 质量、模型异常、错误输出、数据暴露、服务中断、子处理方事故需在约定时限通知 | Incident clause、DPA、security addendum | 只通知法律意义上的 data breach，不通知 AI 事故 |
| Subprocessors | 子处理方清单、变更提前通知、异议权、同等保护义务 | DPA、subprocessor schedule | 供应商可随意新增子处理方 |
| Data residency and support access | 限制处理地区、支持访问地区、人员背景、离岸访问审批 | DPA、support terms | “全球支持”未定义访问控制 |
| IP and output ownership | 明确输入、输出、prompt、配置、workflow、评估数据、业务规则归属 | MSA、SOW、AI addendum | 供应商拥有客户配置和业务规则 |
| Regulatory cooperation | 协助监管问询、审计、证据导出、事故说明、模型和控制解释 | Regulatory cooperation clause | 供应商只承诺普通客户支持 |
| Termination and exit | 终止权、迁移协助、数据导出、格式、时间、费用、删除证明、过渡服务 | Termination clause、exit schedule | 终止后立即断供且无导出义务 |
| Liability and indemnity | 数据泄露、IP 侵权、监管罚款、故意或重大过失、保密违约、服务中断的责任边界 | Liability clause、indemnity clause | 责任上限低于可能损失，排除核心风险 |
| Pricing and renewal | token、seat、case、storage、connector、eval、support、overage、续费涨价、预算告警 | Order form、pricing schedule | 无成本上限，无使用明细，无续费涨幅约束 |
9.1 数据使用限制条款要点
金融零售 AI 合同中，数据限制应覆盖以下对象：
| Data object | 风险 | 条款要求 |
|---|---|---|
| Prompts | 可能包含客户、账户、交易、内部政策、业务策略 | 不得训练、再识别、共享、人工查看，除非受控支持场景 |
| Completions | 可能包含推断、建议、风险标签、客户沟通草稿 | 不得用于供应商模型改进或其他客户服务 |
| Embeddings | 可泄露语义信息，删除和迁移常被忽略 | 视为敏感衍生数据，支持删除、导出、重建 |
| Logs / traces | 包含输入、输出、工具调用、source、用户行为 | 最小化、脱敏、保留期限、访问审计、导出 |
| Fine-tuning data | 高价值业务样本和标注 | 明确所有权、隔离、删除、用途、模型归属 |
| Eval dataset | 包含负例、风险场景、业务规则 | 不得纳入供应商通用 benchmark 或共享 |
| Support tickets | 常包含截图、日志、客户信息 | 支持数据同样受 DPA、访问控制和删除约束 |
| Telemetry | 可能揭示业务量、客户行为、系统使用 | 只允许服务运营必要指标，禁止商业画像和再销售 |
推荐原则：
- 默认禁止训练、微调、产品改进和跨客户学习；例外必须由数据 owner、legal、privacy、risk 书面批准。
- 禁止把客户数据输入供应商公共或消费者版 AI 工具。
- embedding、vector index、trace、prompt cache 和 backup 都属于数据治理范围。
- 供应商人工访问生产数据必须有审批、最小权限、时间限制、日志和定期复核。
9.2 模型更新与变更通知
AI vendor 的核心风险之一是模型行为可变。合同和运行机制都要定义变更等级。
| Change type | 例子 | 通知要求 | 客户动作 |
|---|---|---|---|
| Major model change | GPT-4.x 到新一代模型，embedding 维度变化，reranker 替换 | 提前 30-90 天，提供 release notes、eval delta、回滚方案 | 回归评估、风险审批、业务 UAT |
| Material RAG change | chunking、index schema、permission sync、citation algorithm 变化 | 提前 15-30 天，提供影响说明 | citation eval、权限测试、知识 freshness 检查 |
| Agent/tool change | 新增工具、扩大写权限、改变审批流 | 变更前客户批准 | threat model、tool permission review、HITL 测试 |
| Guardrail/policy change | 拒答策略、敏感内容策略、金融建议边界变化 | 提前通知并提供测试结果 | policy regression、frontline training |
| Minor patch | 安全补丁、UI bug fix、低风险性能优化 | 发布说明或定期摘要 | 监控异常和用户反馈 |
| Emergency change | 安全漏洞、重大故障、紧急禁用模型 | 立即通知，事后报告 | incident review、临时控制、风险接受 |
最低要求：
- 供应商不得对高风险生产用例进行无通知的重大模型替换。
- 客户应有测试窗口、延迟升级权、回滚路径或模型版本 pinning。
- 变更必须进入内部 AI release gate：eval、security、privacy、model risk、business sign-off。
- 供应商 release note 必须能映射到本机构使用的模型、API、region、feature 和数据流。
9.3 Audit rights：审计权不是形式条款
AI 供应商审计权应覆盖：
| Audit object | 要看什么 | 证据例子 |
|---|---|---|
| Data handling | 数据流、保留、删除、访问、子处理方 | DPA、data flow、access log、deletion certificate |
| Security controls | IAM、加密、漏洞、SDLC、incident、tenant isolation | SOC 2、ISO 27001、pen test summary、policy |
| AI governance | risk assessment、model inventory、eval、red-team、change management | AI policy、ISO 42001 evidence、model cards、release gate |
| Operational resilience | DR、RTO/RPO、status、support、capacity、dependency | DR test report、SLA dashboard、incident postmortem |
| Case-level trace | 输入、输出、模型、prompt、source、tool、approval、final action | Trace export、audit log、workflow record |
| Subprocessor controls | 子处理方尽调、合同传递、变更通知 | Subprocessor list、control inheritance matrix |
审计权设计要现实：
- 对大型云和模型供应商，现场审计可能受限，应争取 SOC 2、ISO、第三方审计报告、桥接信、监管协作和专项问询。
- 对高风险垂直 SaaS、数据供应商、外包团队，应争取更具体的客户审查、样本抽查、人员访问记录和整改跟踪。
- 监管机构问询时，供应商必须提供合理协助，不能把“商业秘密”作为拒绝所有解释的理由。
10. SOC 2 / ISO / AI Governance Evidence：如何看证据
证书和报告要读范围、例外、期间和相关性。
| Evidence | 看什么 | 常见误读 | 金融 AI 审查问法 |
|---|---|---|---|
| SOC 2 Type I | 某一时间点控制设计 | 误以为证明控制长期有效运行 | 报告日期是什么，覆盖服务是否包括本次采购的 AI 产品 |
| SOC 2 Type II | 一段期间控制设计与运行 | 只看是否有报告，不看例外项 | 例外项是否影响数据、可用性、访问、变更、incident |
| ISO 27001 | 信息安全管理体系 | 误以为覆盖 AI 模型治理 | 证书范围是否覆盖产品、云、运营和支持组织 |
| ISO 42001 | AI 管理体系 | 误以为证明某个模型无风险 | AIMS 范围是否覆盖供应商提供的 AI 服务和生命周期控制 |
| Pen test summary | 安全测试结果 | 把摘要当完整安全保证 | 高危漏洞是否关闭，测试是否覆盖 API、tenant、agent、RAG |
| AI model card | 模型用途、限制、评估 | 模型卡替代系统级验证 | 是否覆盖本机构用例、语言、数据、客户群和失败场景 |
| Red-team report | 对抗测试和安全边界 | 只看通过率 | 是否覆盖 prompt injection、data exfiltration、financial advice、tool misuse |
| Responsible AI policy | 治理原则和流程 | 把原则当控制运行证据 | 是否有 risk register、change log、eval gate、incident workflow |
| Bridge letter | 报告期后控制变化说明 | 以为可长期替代审计报告 | 覆盖期、变化、未审计性质是否清楚 |
审查技巧：
- 先看 scope，再看 period，再看 exception，再看 mapping to purchased service。
- 证据要和合同、架构、数据流一致。销售口径、白皮书、DPA、SOC 报告、实际配置不能互相矛盾。
- 对 Tier 1 用例，供应商证据只是输入；机构仍要完成内部 risk assessment、eval、UAT、release approval 和 monitoring。
11. SLA / SLO：AI 供应商服务指标
传统 SLA 只看 uptime 不够。AI 系统还要看质量、延迟、成本、数据新鲜度和恢复能力。
| SLA / SLO category | 指标例子 | 金融零售解释 |
|---|---|---|
| Availability | monthly uptime、API availability、region availability | 客服、支付争议、AML case 等流程不能在关键时段不可用 |
| Latency | p50 / p95 / p99 response time、streaming latency | 前台坐席 copilot、实时欺诈辅助对延迟敏感 |
| Throughput | rate limit、concurrent users、batch capacity | 月末、促销、工资日、欺诈峰值要能扩容 |
| Disaster recovery | RTO、RPO、region failover、backup restore test | 关键运营场景需要降级和恢复路径 |
| Support | severity response、resolution target、named support | 事故时不能只有普通工单队列 |
| Data freshness | knowledge sync frequency、data vendor refresh | 政策、费率、制裁名单、KYC 数据过期会造成错误 |
| Quality SLO | groundedness、citation correctness、extraction accuracy、tool success rate | AI 输出质量是业务 SLA 的一部分 |
| Safety SLO | policy violation rate、unsafe action block rate、PII leakage test | 保护客户和机构不被模型错误伤害 |
| Cost SLO | token budget、case cost、overage alert、monthly cap | 防止 agent loop、异常调用和账单失控 |
| Observability | trace completeness、audit log export success、SIEM delivery | 没有日志就无法审计、复盘和验证 |
示例指标设计：
| Use case | Minimum SLA / SLO |
|---|---|
| Contact center copilot | 99.9% availability；p95 响应小于 3 秒；引用正确率大于 95%；高风险答案人工确认 |
| Loan document extraction | 批处理完成时间小于业务 SLA；关键字段准确率按字段分别监控；低置信度自动进入人工复核 |
| AML alert summarization | case trace 100% 保留；source citation 必填；模型不可直接关闭 alert |
| Payments dispute assistant | 服务中断时回退到人工流程；客户沟通草稿必须由员工确认 |
| Internal policy RAG | knowledge freshness 小于 24 小时；过期文档不可检索；权限与源系统一致 |
12. Exit Plan：退出计划和可替换性
退出计划不是合同终止时才写。高风险 AI 供应商进入生产前就要有 exit design。
12.1 退出触发
| Trigger | 例子 | 处置 |
|---|---|---|
| Performance failure | 质量长期低于阈值、幻觉率上升、SLA 反复违约 | 限制范围、暂停扩展、启动替代方案 |
| Security / privacy incident | 数据暴露、未授权访问、子处理方事故 | 临时停用、取证、客户影响评估、合同权利执行 |
| Model change risk | 供应商强制升级且不支持验证或回滚 | 冻结版本、转移流量、重新评估 |
| Commercial risk | 价格大幅上涨、续约条款不可接受 | 迁移计划、替代供应商、内部构建 |
| Regulatory concern | 监管或内审质疑控制不足 | 提供证据、补控制、必要时退出 |
| Strategic mismatch | 供应商路线图不再支持目标架构 | 逐步替换、减少依赖 |
| Concentration risk | 过度依赖单一模型、云、数据或平台 | 多供应商策略、抽象层、数据可迁移 |
12.2 退出资产清单
| Asset | 退出要求 |
|---|---|
| Customer data | 结构化导出，字段说明，完整性校验，删除证明 |
| Documents and knowledge base | 原始文档、处理状态、metadata、权限映射、索引版本 |
| Embeddings / vector index | 可导出或可重建，说明 embedding 模型和维度 |
| Prompts and policies | prompt、system instruction、policy rule、guardrail 配置导出 |
| Workflow config | case flow、approval rules、tool permission、routing rules |
| Audit logs and traces | 输入输出摘要、模型版本、source、tool call、用户、审批、时间戳 |
| Eval assets | eval dataset、rubric、结果、失败分类、阈值 |
| Integration code | API mapping、connector config、auth pattern、webhook |
| Operational history | SLA report、incident、support ticket、change log |
| Deletion evidence | 主存储、日志、备份、embedding、support artifact 的删除证明 |
12.3 退出演练
Tier 1 供应商建议至少年度做桌面演练：
- 选择一个关键流程，如 AML summary 或客服知识助手。
- 模拟供应商 30 天后停止服务或强制涨价。
- 检查数据、日志、配置、prompt、eval、知识库是否能导出。
- 设计替代路径：人工回退、第二供应商、内部模型、功能降级。
- 记录 gap、补充合同条款、更新 runbook。
退出原则：
- 架构上保留 provider abstraction，不把业务规则完全埋在供应商黑盒里。
- 数据和日志要定期导出或同步到机构控制范围。
- 高风险流程必须有 manual fallback 或 degraded mode。
- 续约前必须重新评估退出可行性，不让“已经太难迁移”成为被动续约理由。
13. Concentration Risk：集中度风险
AI 集中度不是只看一个供应商金额。要看关键能力是否集中在单点。
| Concentration type | 例子 | 风险 | 控制 |
|---|---|---|---|
| Foundation model concentration | 大量用例都依赖同一模型家族 | 模型故障、政策变化、价格上涨、区域限制 | 多模型评估、路由抽象、fallback、版本 pinning |
| Cloud concentration | AI workloads 全部在单一云和单一区域 | 区域故障、合同谈判弱势、技术锁定 | 多区域、DR、可移植架构、出口带宽计划 |
| RAG platform concentration | 所有知识库、权限、索引都在单一 SaaS | 数据迁移困难、权限黑盒 | 定期导出、源系统为 master、索引可重建 |
| Data vendor concentration | 欺诈/KYC/制裁依赖单一数据源 | 覆盖缺口、数据偏差、供应中断 | 双源校验、质量监控、手工补充流程 |
| Eval vendor concentration | 质量判断完全依赖外部 judge | 独立性不足、评估偏差 | 内部 gold set、人工 calibration、第二评估方法 |
| Agent platform concentration | 业务 workflow 和 tool 权限绑定平台 | 迁移成本高，流程不可解释 | workflow 文档化、API 抽象、配置导出 |
| Outsourcing concentration | 关键知识运营由单一外包团队掌握 | 人员流失、交付中断、知识流失 | 双人制、SOP、交接材料、访问最小化 |
集中度仪表盘建议：
| Metric | 解释 |
|---|---|
| Number of critical AI use cases per vendor | 单一供应商承载多少关键 AI 用例 |
| Percentage of AI spend by vendor | 采购金额集中度 |
| Percentage of customer-impacting decisions supported by vendor | 客户影响集中度 |
| Model family dependency count | 模型家族依赖数量 |
| Exit readiness score | 数据、日志、配置、评估、替代方案成熟度 |
| Subprocessor overlap | 多个供应商背后是否都依赖同一云或模型 |
14. Subprocessors：子处理方治理
AI 供应商常常是供应链组合：云、模型、向量库、日志、监控、标注、支持、支付、CRM、数据源都可能成为子处理方。
| Subprocessor category | 风险 | 要求 |
|---|---|---|
| Cloud infrastructure | 数据存储和处理地点、区域故障 | region、encryption、DR、SOC/ISO、数据驻留 |
| Foundation model provider | 数据输入、训练、模型变化 | 数据不训练、模型版本、日志保留、变更通知 |
| Annotation / human review | 人工接触敏感数据 | 背景检查、最小访问、地点限制、培训、日志 |
| Observability / logging | 日志集中，含敏感信息 | 脱敏、保留、访问、导出、删除 |
| Support platform | 工单截图和日志泄露 | DPA 覆盖、访问控制、工单删除 |
| Data provider | 数据授权、偏差、更新 | 来源、许可、刷新、纠错、使用限制 |
| Security tooling | 扫描和监控访问系统 | 最小权限、保密、审计 |
| Offshore delivery partner | 跨境访问、人员控制 | 明确地点、审批、客户数据访问限制 |
子处理方合同要求：
- 签约前提供完整清单，包含名称、服务、地点、数据类型、控制证据。
- 新增或替换关键子处理方前提前通知，并给客户合理异议或退出权。
- 子处理方承担不低于主合同的数据保护、安全和保密义务。
- 主供应商对其子处理方行为承担责任。
- 供应商定期提供子处理方变更摘要和控制复核结果。
15. Incident Notification：AI 事故通知
AI 事故不只包括 data breach。金融零售 AI 需要覆盖安全、隐私、模型、质量、操作和客户影响。
| Incident type | 例子 | 通知触发 | 初始通知内容 |
|---|---|---|---|
| Security incident | 未授权访问、凭证泄露、漏洞被利用 | 影响客户数据、系统安全或服务完整性 | 时间、范围、系统、数据类型、初步控制措施 |
| Privacy incident | PII 暴露、错误共享、跨境处理异常 | 涉及个人信息或隐私义务 | 受影响数据、人数估计、处理地点、补救 |
| AI quality incident | 批量错误摘要、错误建议、引用错误导致业务误判 | 影响客户沟通、决策、投诉、合规或关键运营 | 影响用例、模型版本、样本、错误类型、暂停措施 |
| Model behavior incident | 模型升级后拒答、幻觉、偏见、越权建议明显上升 | 指标超过阈值或高风险失败出现 | 变更内容、eval delta、回滚计划 |
| RAG incident | 权限泄露、旧政策被引用、引用伪造 | 敏感文档或错误来源影响输出 | source、index version、权限影响、修复 |
| Agent/tool incident | agent 执行错误动作、重复调用、越权写入 | 下游系统被修改或可能造成客户影响 | tool、action、records affected、rollback |
| Availability incident | 服务中断、延迟严重、区域故障 | 超过 SLA 或影响关键业务时段 | 当前状态、ETA、workaround、根因初判 |
| Cost incident | runaway token/tool calls、异常账单 | 超过预算阈值或异常调用 | 调用量、原因、限制措施、费用处理 |
通知节奏建议：
| Severity | 例子 | 初始通知 | 更新频率 | 事后报告 |
|---|---|---|---|---|
| Sev 1 | 客户数据暴露、关键业务中断、错误影响大量客户、监管报告风险 | 1-4 小时 | 每 4-8 小时 | 5-10 个工作日 |
| Sev 2 | 高风险用例局部受影响、可通过人工回退控制 | 24 小时内 | 每日 | 10 个工作日 |
| Sev 3 | 低风险质量问题、非关键服务降级 | 2 个工作日内 | 按需 | 月度汇总 |
事故条款原则：
- 通知时限不能只绑定法律定义的 breach；AI 质量和模型异常也要纳入。
- 供应商必须支持客户进行客户影响评估、监管沟通、证据保全和补救。
- 供应商应提供 root cause、timeline、受影响范围、修复、预防措施和验证结果。
- 客户应保留暂停、降级、切换、禁用特定模型或终止的权利。
16. 金融零售 AI Use Case 风险地图
| Use case | 典型供应商 | 主要风险 | 控制设计 |
|---|---|---|---|
| 客服知识助手 | RAG SaaS、LLM、contact center platform | 错误费率、旧政策、过度承诺、PII 泄露 | 权限同步、引用必填、人工确认、知识 freshness、话术边界 |
| 投诉处理摘要 | LLM、case management、speech-to-text | 客户陈述被错误总结、证据链缺失 | 原文引用、人工复核、日志保留、不可自动关闭投诉 |
| 贷款文档抽取 | OCR、document AI、LLM | 字段抽取错误影响授信 | 字段级置信度、双人复核、抽样验证、模型变更评估 |
| 信贷 policy copilot | RAG、内部政策库、LLM | 错误解释政策，员工过度依赖 | 只读辅助、来源链接、政策版本、生效日期、培训 |
| 欺诈 case assistant | 数据 vendor、LLM、agent | 错误拦截或放行交易 | 人工审批、特征解释、下游写入权限控制、审计 |
| AML alert summarization | AML data、LLM、case workflow | 漏掉可疑活动、误导调查员 | 不得自动 SAR 决策、source trace、model risk review |
| KYC onboarding | IDV vendor、data vendor、document AI | 身份误判、偏差、数据授权 | 数据来源审查、纠错流程、人工升级、fairness check |
| 支付争议助手 | LLM、RAG、payment platform | 错误解释规则，客户沟通风险 | 模板化输出、人工确认、监管话术审查、日志 |
| 催收策略辅助 | LLM、CRM、collections platform | 不当催收、消费者保护、敏感群体影响 | 合规规则 guardrail、人工审批、禁用高风险话术 |
| 财富/投资适当性辅助 | LLM、portfolio data、market data | 误导性建议、适当性风险 | 适用范围限制、持牌人员复核、强披露、模型验证 |
| 员工代码助手 | Foundation model、IDE plugin | 代码泄露、开源许可证、漏洞 | 禁止敏感代码外传、代码扫描、许可证检查 |
| 供应链/采购文本分析 | LLM、contract AI | 合同条款误读 | Legal review、source citation、不可替代律师审批 |
17. PM / BA / Architect / Risk 角色分工
| Activity | PM | BA | Architect | Risk / Compliance | Legal | Procurement | Security / Privacy | Model Risk | Internal Audit |
|---|---|---|---|---|---|---|---|---|---|
| Define use case | A | R | C | C | C | I | C | C | I |
| Data classification | C | R | C | C | I | I | A | C | I |
| Build/buy/hybrid memo | A | C | R | C | C | C | C | C | I |
| Vendor RFI/RFP | R | R | C | C | C | A | C | C | I |
| Due diligence | C | C | C | A | C | R | R | R | I |
| Contract negotiation | C | C | C | C | A | R | C | C | I |
| Architecture review | C | C | A | C | I | I | R | C | I |
| Eval and pilot | A | R | C | C | I | I | C | R | I |
| Production approval | A | C | R | A | C | I | R | R | I |
| Ongoing monitoring | A | C | C | R | I | R | R | R | C |
| Incident response | A | C | R | R | R | C | A | C | C |
| Renewal decision | A | C | C | R | C | A | C | C | C |
| Exit execution | A | C | R | C | R | R | C | C | I |
RACI 说明：R = Responsible，A = Accountable，C = Consulted，I = Informed。
关键角色能力：
| Role | 必须能说清楚的问题 |
|---|---|
| AI PM | 为什么要买，成功指标是什么，用户如何采用，风险如何不伤害体验 |
| AI BA | 流程、异常、数据、人工复核、证据链如何落地 |
| Architect | 供应商在系统边界内做什么，哪些部分可替换，如何记录和回滚 |
| Risk / Compliance | 用例风险、监管义务、客户影响、控制和 residual risk 是否可接受 |
| Legal | 数据、责任、审计、监管配合、事故、终止和 IP 是否合同化 |
| Procurement | 商业条款、供应商治理、续约、集中度和退出是否可管理 |
| Security / Privacy | 访问、加密、数据、跨境、日志、漏洞、隐私权利是否受控 |
| Model Risk | 模型和 AI 系统是否被验证、监控、变更管理和有效挑战 |
| Internal Audit | 控制是否真实运行，证据是否完整、准确、及时、可复现 |
18. Templates：可复制工作产物
以下模板使用“字段 + 填写规则 + 示例值”，便于直接迁移到工作文档。
18.1 AI Vendor Intake One-Pager
| Field | 填写规则 | 示例值 |
|---|---|---|
| Use case name | 写业务场景，不写供应商品牌 | Retail banking contact center policy copilot |
| Business owner | 明确最终业务负责人 | Head of Customer Operations |
| Vendor category | 选择供应商类型 | RAG SaaS + foundation model provider |
| Data involved | 列出数据类别 | 内部政策、产品费率、客户对话摘要、坐席用户 ID |
| Customer impact | 说明是否影响客户权益 | AI 只生成坐席建议，客户沟通前必须人工确认 |
| Risk tier | 使用本手册 Tier | Tier 2: Important / Controlled impact |
| Build/buy/hybrid rationale | 说明选择理由 | Buy RAG SaaS for speed，AI gateway and audit logs controlled internally |
| Key controls | 列出前五个控制 | SSO、RBAC、引用必填、知识 freshness、人工确认 |
| Required evidence | 列出供应商必须提供的材料 | SOC 2 Type II、DPA、model change policy、subprocessor list、exit docs |
| Pilot success metric | 可衡量 | Average handle time 降低 12%，引用正确率大于 95%，坐席信任评分大于 4/5 |
| Stop criteria | 明确停止条件 | PII 泄露测试失败、旧政策引用超过阈值、供应商拒绝数据不训练条款 |
18.2 Vendor Scorecard
| Dimension | Weight | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|
| Business workflow fit | 10 | 通用 demo | 支持部分流程 | 支持端到端流程和异常路径 |
| Data restrictions | 12 | 条款模糊 | 可配置部分限制 | 明确不训练、不共享、可删除、可审计 |
| Security evidence | 10 | 无成熟证据 | 有 SOC 或 ISO 但范围有限 | SOC 2 Type II、ISO、pen test、SSO/RBAC 完整 |
| AI governance | 10 | 原则性材料 | 有部分流程 | 有模型清单、变更、eval、red-team、incident |
| Evaluation capability | 10 | 只给 benchmark | 支持客户样本测试 | 支持业务 gold set、负例、阈值、失败分类 |
| Auditability | 10 | 聊天记录级日志 | 有基础日志 | case-level trace 可导出 |
| SLA / resilience | 8 | Best effort | 基础 SLA | SLA、DR、RTO/RPO、degraded mode 完整 |
| Integration | 8 | 手工导入导出 | API 可用 | IAM、SIEM、DLP、workflow 集成成熟 |
| Contractability | 8 | 销售承诺多 | 部分可写入合同 | 关键控制可合同化 |
| Exit readiness | 8 | 无明确导出 | 可导出部分数据 | 数据、配置、日志、eval、索引可导出或重建 |
| Concentration risk | 4 | 单点依赖严重 | 有部分替代 | 支持多模型、多区域、抽象层 |
| Commercial clarity | 2 | 价格不可预测 | 基本价格清楚 | 单 case 成本、预算告警、续费上限清楚 |
评分解释：
- 0-50：仅适合无敏感数据学习环境。
- 51-70：低风险 pilot，限制数据和功能。
- 71-85：可进入受控 pilot 或 Tier 2 生产候选。
- 86-100：生产候选，仍需通过内部 release gate 和合同审批。
18.3 Contract Redline Checklist
| Clause | 最低可接受要求 | 示例审查结论 |
|---|---|---|
| Data training | 客户数据默认不用于训练、微调、产品改进 | Vendor agrees to no training for prompts, outputs, logs and embeddings |
| Change notice | 重大模型和 RAG 变更提前通知 | 30-day notice for model family or embedding change |
| Audit rights | 可获得审计证据和监管协助 | SOC 2 annually, bridge letter, regulatory cooperation included |
| Incident notice | 覆盖安全、隐私、AI 质量和服务中断 | Sev 1 initial notice within 4 hours |
| Subprocessors | 清单、提前通知、异议权 | 30-day notice for new critical subprocessor |
| Exit | 数据、配置、日志、eval、删除证明 | Export available in JSON/CSV plus deletion certificate |
| SLA | 可用性、延迟、支持、DR | 99.9% availability, p95 latency, named support |
| Liability | 高风险违约不被过低责任上限吞掉 | Data breach and confidentiality carve-out negotiated |
18.4 Model Change Notice Review Memo
| Field | 填写规则 | 示例值 |
|---|---|---|
| Change summary | 一句话说明变更 | Vendor will upgrade embedding model from Embed-A v2 to Embed-A v3 for enterprise RAG |
| Impacted systems | 列出系统和用例 | Contact center policy copilot, complaint summarization assistant |
| Vendor evidence | 列出收到材料 | Release notes, eval delta, migration guide, rollback option |
| Internal tests | 列出必须复测 | Citation correctness, permission leakage, stale policy retrieval, Chinese-English query set |
| Risk decision | 选择 approve、defer、reject、limited rollout | Defer production upgrade until regression eval passes |
| Owner and date | 记录责任人和日期 | AI Platform Owner, 2026-07-15 |
18.5 Incident Intake Template
| Field | 填写规则 | 示例值 |
|---|---|---|
| Incident category | 选择类型 | AI quality incident |
| Severity | Sev 1 / Sev 2 / Sev 3 | Sev 2 |
| Use case | 业务场景 | Payments dispute assistant |
| Vendor component | 受影响组件 | RAG citation service |
| Customer impact | 描述影响 | 42 draft letters cited an outdated dispute policy; no letters sent without human approval |
| Immediate containment | 立即控制 | Disabled outdated source, switched workflow to manual review |
| Evidence preserved | 保存证据 | Trace IDs, model version, source document version, user actions |
| Regulatory / legal review | 是否需要 | Legal and compliance reviewing customer communication obligation |
| Next update | 时间 | 2026-07-02 10:00 America/Chicago |
18.6 Exit Plan Template
| Field | 填写规则 | 示例值 |
|---|---|---|
| Exit trigger | 明确触发条件 | Supplier discontinues model version required by Tier 1 workflow |
| Replacement path | 写替代方案 | Route through internal AI gateway to approved secondary model |
| Data export | 列出导出范围 | Documents, metadata, ACL, prompts, workflow config, traces, eval results |
| Format | 明确格式 | JSON for config, CSV for logs, source files in original format |
| Parallel run | 说明并行验证 | Two-week shadow run with 500 historical cases |
| Deletion proof | 说明证明方式 | Written deletion certificate covering primary store, logs, embeddings and backups |
| Business fallback | 说明人工或降级流程 | Contact center returns to existing knowledge base and supervisor approval |
| Exit owner | 明确负责人 | Vendor Owner under Customer Operations |
19. 30-Day Lab：AI Vendor Risk 实战训练
目标：30 天内完成一个金融零售 AI 供应商风险案例包，可作为面试和作品集材料。
| Day | 训练任务 | 产出 |
|---|---|---|
| 1 | 选择场景：客服 copilot、AML summary、贷款文档抽取、支付争议助手四选一 | Use case one-pager |
| 2 | 画 AS-IS / TO-BE 流程，标出 AI 介入点和人工复核 | Workflow map |
| 3 | 做数据分类，列出 prompt、completion、embedding、logs、support data | Data inventory |
| 4 | 做 customer impact 和 risk tier | Risk tier memo |
| 5 | 写 build / buy / hybrid 决策 | Decision matrix |
| 6 | 建 vendor landscape：foundation model、cloud、RAG、agent、data、eval | Vendor dependency map |
| 7 | 写 RFI 问题清单 | RFI questionnaire |
| 8 | 写 demo script，要求供应商展示异常路径 | Demo script |
| 9 | 建 vendor scorecard 权重 | Scorecard |
| 10 | 设计 due diligence evidence request | Evidence request list |
| 11 | 写数据使用限制条款要点 | Data use addendum notes |
| 12 | 写模型变更通知要求 | Model change clause notes |
| 13 | 写审计权和监管协作要求 | Audit rights notes |
| 14 | 写 SLA / SLO 指标 | SLA schedule draft |
| 15 | 设计 eval 数据集和失败分类 | Eval plan |
| 16 | 设计 RAG 权限和引用测试 | RAG control test |
| 17 | 设计 agent tool permission matrix | Tool permission matrix |
| 18 | 做 subprocessor inventory 模板 | Subprocessor review sheet |
| 19 | 做 concentration risk dashboard 草稿 | Concentration risk view |
| 20 | 写 incident notification matrix | Incident severity matrix |
| 21 | 写 production monitoring dashboard 指标 | Monitoring spec |
| 22 | 写 renewal review checklist | Renewal checklist |
| 23 | 写 exit plan | Exit plan |
| 24 | 把所有证据映射到 NIST AI RMF Govern / Map / Measure / Manage | Control mapping |
| 25 | 把所有证据映射到 ISO/IEC 42001 AIMS 思路 | AIMS evidence map |
| 26 | 做 PM / BA / Architect / Risk RACI | RACI |
| 27 | 写 executive decision memo | Executive memo |
| 28 | 做 10 分钟面试讲解脚本 | Interview storyline |
| 29 | 进行一次自我红队：找 10 个供应商绕过控制的方式 | Red-team notes |
| 30 | 整理成作品集案例包 | Portfolio case pack |
30 天交付标准：
- 能讲清楚为什么选 buy、build 或 hybrid。
- 能展示供应商链路、数据流、风险分级和控制。
- 能把尽调问题转成合同条款和运行证据。
- 能说明 model update、subprocessor、incident、exit 和 concentration risk。
- 能从 PM、BA、Architect、Risk 四个视角回答面试追问。
20. Interview Answers：面试答案
Q1：AI 供应商风险和传统 SaaS 供应商风险有什么不同？
30 秒回答：
AI 供应商风险多了模型行为、数据二次使用、prompt / embedding / trace 泄露、模型静默更新、RAG 权限、agent 工具误用和评估不可复现。传统 SaaS 主要看安全、可用性、隐私和运营；AI 还必须看模型生命周期、输出质量、变更门禁和人机协作责任。
2 分钟展开：
- 传统 SaaS 的风险对象通常是系统、数据和服务可用性。
- AI 系统的风险对象包括 model、prompt、RAG index、embedding、tool、judge、guardrail 和 human override。
- 供应商如果更新模型，系统行为可能变化，即使 API 没变。
- 金融零售场景下，错误输出可能影响授信、投诉、AML、欺诈、支付争议和客户沟通。
- 所以要把第三方生命周期和 AI lifecycle 合并：尽调、合同、eval、change notice、SLA、incident、audit、exit 都要 AI-specific。
Q2：如何判断一个 AI vendor 是否可以进入 pilot？
30 秒回答：
先看用例风险和数据分类，再看供应商是否能满足最低证据包：数据不训练、数据流清楚、SOC/ISO 证据、模型版本和变更政策、eval 方法、subprocessor list、incident 通知和退出路径。pilot 也必须有成功指标和停止条件。
2 分钟展开：
- 先定义业务问题、baseline 和 no-AI option。
- 做 risk tier：是否影响客户权益、监管义务、关键运营或敏感数据。
- 供应商至少要回答数据如何处理、模型如何更新、日志如何保留、如何审计、如何退出。
- pilot 必须限制数据和范围，不能因为是 PoC 就输入真实敏感数据。
- 成功指标同时包括业务价值和控制指标，例如准确率、引用正确率、人工复核通过率、用户信任、PII 泄露测试、延迟和成本。
Q3：合同中最重要的 AI 条款是什么？
30 秒回答：
我会优先看数据使用限制、模型变更通知、审计权、事故通知、subprocessor、SLA、退出计划和监管协作。金融零售 AI 不能只签普通 SaaS MSA，因为 prompt、completion、embedding、trace 和 eval dataset 都可能包含敏感业务信息。
2 分钟展开：
- 数据条款要明确不用于训练、微调、产品改进、再销售或跨客户学习。
- 模型变更条款要覆盖 foundation model、embedding、reranker、RAG pipeline、agent tool 和 guardrail。
- 审计权要能拿到 SOC/ISO、AI governance、case-level trace 和监管协作。
- 事故通知不能只覆盖 data breach，还要覆盖 AI quality incident、model behavior incident、RAG permission issue 和 service outage。
- 退出条款要包括数据、配置、日志、eval、索引、删除证明和过渡支持。
Q4：如何管理模型更新风险？
30 秒回答：
把模型更新当成生产变更管理，而不是供应商 release note。重大模型、embedding、RAG、agent tool 或 guardrail 变更要提前通知，进入内部回归评估、风险审批、UAT 和回滚计划。
2 分钟展开：
- 先要求供应商提供 model inventory、version policy 和 change notice。
- 对高风险用例，争取 version pinning、延迟升级权和 rollback。
- 内部做 regression eval：历史 case、负例、边界样本、敏感政策、权限测试、引用测试。
- 如果输出影响客户或监管流程，还要 model risk、compliance 和 business sign-off。
- 上线后监控 hallucination、citation correctness、override rate、complaints、latency 和 cost drift。
Q5：如何防止供应商锁定？
30 秒回答：
架构上做 provider abstraction，合同上要求数据、配置、日志、eval 和索引可导出，运营上定期做 exit review。锁定不只来自模型，也来自 RAG index、workflow、agent tool、审计日志和供应商特有配置。
2 分钟展开：
- 在 AI gateway 层隔离模型调用，保留多模型路由和 fallback。
- 业务规则、prompt、policy、eval dataset 尽量由机构控制。
- 源文档系统作为 master，RAG index 可重建。
- 合同写清导出格式、终止协助、删除证明和过渡服务。
- 续约前评估替代供应商和内部方案，不让迁移难度变成被动续约。
Q6：如何看 SOC 2 和 ISO 证书？
30 秒回答：
先看范围、期间、例外和是否覆盖本次采购服务。SOC 2 或 ISO 27001 证明安全控制或管理体系的一部分，不证明 AI 用例自动合规。ISO 42001 可作为 AI 管理体系证据，但仍要看它是否覆盖模型变更、eval、risk assessment 和供应商实际产品。
2 分钟展开：
- SOC 2 Type II 比 Type I 更能说明控制运行，但也要看报告期和例外。
- ISO 27001 看 ISMS 范围是否覆盖产品、云环境、运营和支持组织。
- ISO 42001 看 AIMS 范围、AI 生命周期、风险、责任、持续改进。
- 对 AI 供应商，还要额外看 model card、eval report、red-team、AI incident process、change log。
- 任何证据都要映射到机构自己的用例、数据、架构和控制要求。
Q7：如何处理 subprocessor 风险？
30 秒回答：
要求供应商提供完整子处理方清单，说明每个子处理方处理什么数据、在哪个地区、承担什么控制。新增关键子处理方要提前通知，客户有异议权，主供应商对其子处理方承担责任。
2 分钟展开：
- AI 供应链里子处理方可能包括云、模型、日志、标注、支持、数据、监控和外包人员。
- 风险不是只看主供应商品牌，还要看背后的模型和云是否集中。
- 合同要求同等数据保护、安全、保密和 incident notification 义务下传。
- 对高风险用例，子处理方变更也要触发影响评估和可能的回归测试。
- 供应商季度评审时要核对清单变化和控制证据。
Q8：金融零售 AI use case 中哪些最需要强第三方风险控制？
30 秒回答：
授信、欺诈、AML、KYC、支付争议、催收、投诉、财富建议和监管报告最需要强控制，因为它们可能影响客户权益、合规义务、消费者保护、财务损失和声誉风险。
2 分钟展开：
- 如果 AI 只做内部低敏摘要，风险较低。
- 如果 AI 影响客户是否被批准、拦截、收费、催收、投诉结论或监管报告，就进入高风险。
- 高风险不一定禁止外购，但要有深度尽调、合同条款、人工复核、eval、监控、审计日志和退出。
- 尤其要防止 vendor demo 直接跳到生产，绕过 model risk、privacy、security 和 legal。
Q9：PM 和 BA 在供应商风险里有什么价值？
30 秒回答：
PM 定义价值、范围、pilot 指标和 adoption；BA 把流程、数据、异常、人工复核和证据链讲清楚。没有 PM/BA，供应商风险容易变成采购和安全清单，无法判断 AI 是否真的适合业务流程。
2 分钟展开：
- PM 能明确目标用户、业务结果、优先级和停止条件。
- BA 能把 AS-IS / TO-BE、异常路径、角色权限和数据字段拆出来。
- 这些内容会变成 RFP、demo script、eval dataset、contract requirements 和 runbook。
- Architect、Risk、Legal、Security 需要 PM/BA 的业务上下文才能设计控制。
- 面试时可以强调自己能把业务语言翻译成供应商尽调和工程控制。
Q10：如果供应商拒绝模型变更通知或审计权怎么办？
30 秒回答：
先根据用例风险判断是否可接受。低风险内部场景可以通过限制数据和范围缓解；高风险金融场景如果供应商拒绝关键变更通知、审计证据或监管协作，通常不能进入生产。
2 分钟展开：
- 可谈判替代：SOC 报告、bridge letter、第三方审计、release note、客户专属测试窗口、监管协作承诺。
- 可降低风险：只用于低敏、只读、人工复核、不接核心系统、不影响客户权益。
- 如果是 Tier 1，缺少审计权和变更通知会破坏可验证性和可控性。
- 最终结论应记录为 risk acceptance、scope limitation 或 vendor rejection，不能口头带过。
21. 自检清单
本文已覆盖以下要求：
| Requirement | Coverage |
|---|---|
| Vendor landscape | Section 4 覆盖 foundation model、cloud AI、RAG SaaS、agent platform、data vendor、eval vendor，并扩展 observability、SI、managed service。 |
| Build / buy / hybrid link | Section 5 连接 build、buy、hybrid、partner 和分层决策。 |
| Third-party risk lifecycle | Section 6 使用 planning、due diligence、contract negotiation、ongoing monitoring、termination 等生命周期。 |
| Due diligence | Section 8 提供尽调框架、角色问题和最小证据包。 |
| Contract clauses | Section 9 覆盖数据、变更、审计、SOC/ISO、SLA、incident、subprocessor、exit、IP、liability。 |
| Data use restrictions | Section 9.1 专门覆盖 prompt、completion、embedding、logs、fine-tuning、eval、support、telemetry。 |
| Model update / change notice | Section 9.2 专门覆盖模型、RAG、agent、guardrail、emergency change。 |
| Audit rights | Section 9.3 专门覆盖数据、安全、AI governance、case trace、subprocessor。 |
| SOC2 / ISO / AI governance evidence | Section 10 专门说明如何读证据。 |
| SLAs | Section 11 覆盖 availability、latency、quality、safety、cost、observability。 |
| Exit plan | Section 12 覆盖触发、资产、演练和原则。 |
| Concentration risk | Section 13 覆盖模型、云、RAG、数据、eval、agent、外包集中度。 |
| Subprocessors | Section 14 覆盖子处理方类别和合同要求。 |
| Incident notification | Section 15 覆盖安全、隐私、AI quality、model behavior、RAG、agent、availability、cost。 |
| Financial retail use cases | Section 16 覆盖客服、投诉、贷款、信贷、欺诈、AML、KYC、支付、催收、财富、代码、合同分析。 |
| PM / BA / Architect / Risk roles | Section 17 覆盖 RACI 和角色能力。 |
| Templates | Section 18 提供 intake、scorecard、contract checklist、change memo、incident intake、exit plan。 |
| 30-day lab | Section 19 提供 30 天实战训练。 |
| Interview answers | Section 20 提供 10 个面试答案。 |
| Source anchors | Section 3 覆盖 Interagency Guidance、OCC Bulletin、SR references、OMB M-25-22、NIST AI RMF、ISO/IEC 42001。 |
质量自检：
- 未使用未完成标记。
- 模板均包含填写规则和示例值。
- 文档保持为学习和架构手册，不替代法律、合规或采购审批。
- 本文件可由主索引后续登记，不依赖同时修改其他文件。