返回 Papers
AI 底层逻辑 / 经典论文

AI Third-Party Vendor:合同与退出架构

一句话:

181ai-foundations/papers/97-ai-third-party-vendor-contract-exit-architecture.md

AI Third-Party Vendor Contract / Exit Architecture 解读

面向对象: AI Platform PM / Vendor Risk Lead / Enterprise Architect / Procurement Product Lead / Senior BA。 核心问题: AI vendor risk 不是采购打分表。模型供应商、RAG 平台、agent 工具、数据处理商和评测工具都会影响数据、模型行为、可观测性、审计、事故响应、成本和退出能力。合同条款必须被架构化。 学习目标: 将第三方风险管理、合同控制、架构抽象、证据交换、变更通知和 exit strategy 连接成 AI vendor architecture capability。


Source Anchors

SourceLink用途
Interagency Guidance on Third-Party Relationshipshttps://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html参考银行第三方关系风险管理生命周期
Federal Reserve Third-Party Risk Managementhttps://www.federalreserve.gov/supervisionreg/topics/third-party-risk-management.htm参考银行监管中的第三方风险管理主题
NIST AI RMFhttps://www.nist.gov/itl/ai-risk-management-framework将供应商风险映射到 AI govern/map/measure/manage
ISO/IEC 42001https://www.iso.org/standard/81230.html将供应商和外部提供方纳入 AI management system
NIST Cybersecurity Frameworkhttps://www.nist.gov/cyberframework参考第三方安全、监控和事件响应

一句话:

AI vendor architecture 是用 contract、control、interface、telemetry、evidence 和 exit plan 管理供应商能力, 而不是把供应商当黑盒。


1. AI Vendor Risk Is Architectural

AI vendor risk 影响:

AreaRisk
Datatraining use, retention, cross-border transfer, prompt logging
Modelbehavior change, deprecation, benchmark mismatch
Securityprompt/tool attack surface, access control
Observabilitymissing trace, no raw logs, weak incident data
Complianceno audit rights, no evidence handoff
Costtoken/GPU pricing volatility, hidden usage
Availabilityregion outage, model route failure
Exitno portable prompts/evals/embeddings/logs

如果 vendor decision 没有 architecture abstraction, 未来退出会非常昂贵。


2. Contract Clauses That Matter for AI

ClauseArchitecture implication
Data useno training / retention limits / processing purpose
Loggingwhat is logged, retained, accessible
Audit rightsevidence and independent assessment
Model change noticerevalidation trigger
Security incident noticeincident runbook integration
Subprocessor disclosuresupply chain visibility
Evaluation accessability to run regression and red-team
SLA/SLOlatency, availability, support response
Explainability/documentationmodel/system cards, limitations
IP/output ownershipproduct and legal boundary
Termination assistancemigration support
Data deletion/returnverifiable deletion evidence
Price changeFinOps and budget guardrail

3. Vendor Abstraction Patterns

PatternUse
Model gatewayroute, fallback, logging, policy, cost
Prompt registryavoid vendor-specific prompt sprawl
Eval harnesscompare vendors and catch regressions
Tool gatewayavoid direct vendor-agent action
Data boundary proxyredact, classify, route
Evidence adapternormalize logs, trace, usage, incidents
Contract metadata registrytrack clauses, dates, obligations

目标不是把所有供应商完全替换, 而是保留 architecture optionality。


4. Exit Architecture

Exit plan should exist before scale.

Exit objectNeed
Promptsexportable versions and tests
Eval setsvendor-independent regression
Embeddingsmigration plan or dual-index strategy
Fine-tunes/adaptersownership and portability
Logs/tracesevidence retention
Knowledge indexesrebuildable ingestion pipeline
Tool contractsnot vendor-native only
User datareturn/delete certification
Cost modelreplacement cost estimate

Exit trigger examples:

  • material price increase。
  • model deprecation。
  • policy change on data usage。
  • repeated SLO failure。
  • regulatory concern。
  • concentration risk threshold breached。
  • better internal/platform capability available。

5. Financial Retail Case: LLM Provider for Customer Service RAG

ConcernContract/control
customer datano training, retention limit, region restriction
model updatesadvance notice and regression window
trace evidencerequest metadata, route, model version, latency, cost
incidentnotification SLA and cooperation
evalright to run red-team and benchmark
auditdocumentation and evidence access
exitprompt/eval/export, deletion certificate

Architecture:

Customer service app
  -> model gateway
  -> data boundary proxy
  -> vendor model
  -> observability/evidence adapter

No product team calls the vendor directly.


6. Templates

Vendor Architecture Review

QuestionEvidence
What data is sentdata flow diagram
Is data used for trainingcontract clause
How are model changes handlednotice clause + revalidation
Can we run evalseval access
Can we auditaudit rights
How do we exitexit plan
What is abstractedgateway/adapter design

Contract-Control Matrix

Contract clauseControlEvidenceOwner
no trainingdata usage attestationvendor reportprocurement/risk
change noticemodel update reviewchange logplatform
deletiondeletion certificateevidence binderprivacy
incident noticeincident runbookincident recordsecurity

7. Common Failure Modes

Failure modeFix
Vendor direct integrationmodel/tool gateway
Contract not linked to controlscontract-control matrix
No model change noticeclause + revalidation trigger
No exit planexit architecture before scale
No evidence accessaudit/logging clause
Cost surpriseFinOps clause and usage telemetry

8. 面试表达

30 秒版本:

AI vendor risk 不是采购评分, 是架构问题。我会通过 model gateway、prompt/eval registry、data boundary proxy、telemetry adapter 和 contract-control matrix 管理供应商。合同必须覆盖数据使用、日志、审计、模型变更、incident、eval access、SLO、退出和删除证明。

2 分钟版本:

以 customer service RAG 选 LLM provider 为例, 我不会让应用直接调用供应商。所有请求走 model gateway 和 data boundary proxy, 记录 model version、prompt version、latency、cost 和 policy decision。合同要求不训练客户数据、变更提前通知、允许红队和回归评测、提供 incident 协作和审计证据。退出计划包括 prompt/eval export、index rebuild、logs retention、data deletion certificate 和 replacement cost estimate。