AI Supply Chain, AI BOM and Provenance Architecture Playbook

版本：v1.0 日期：2026-06-30 适用对象：AI PM、AI BA、Enterprise Architect、Solution Architect、Model Risk、Security、Vendor Risk、Data Governance、Procurement、Legal、Compliance、Internal Audit、金融零售业务负责人

定位：把 AI supply chain、AI Bill of Materials、component provenance、vulnerability/change response、license/data rights、concentration risk 和 exit readiness 统一成一套金融零售可执行架构手册。

核心结论：AI BOM 不是普通 SBOM 的改名版，也不是供应商清单。它是 AI workflow 的 component-level traceability layer，覆盖模型、供应商、数据集、RAG 语料、prompt、工具、MCP servers/connectors、eval datasets、人审供应商、telemetry stores、开源包、许可证、版本、签名、provenance、变更响应和退出路径。

重要说明：本文是学习、架构和作品集材料，不构成法律、监管、审计、采购或正式模型风险管理意见。真实项目必须由 business owner、model risk、security、privacy、legal、compliance、procurement、data governance、architecture 和 internal audit 共同确认。

---

1. Executive Framing

金融零售机构正在把 GenAI、RAG、Agent、MCP connector、AI workflow SaaS、评估工具和人工标注服务接入客户与运营流程。

AI supply chain 的真实边界比传统软件复杂:

• 模型可能来自多个 provider，并通过 gateway 动态路由。
• RAG 语料来自内部政策、客户记录、供应商文档、网页和第三方数据。
• Prompt pack 和 tool schema 能改变系统行为，却常常没有正式版本治理。
• MCP server 和 connector 把 Agent 能力扩展到 CRM、工单、支付、邮件和数据仓库。
• Eval dataset 和 human review rubric 会决定系统能否上线。
• Telemetry store 和 trace schema 决定审计和事故复盘是否可行。
• 开源模型、package、embedding model、reranker、tokenizer 和 license 会引入权利与漏洞风险。

核心问题:

Can we identify every component that can influence AI behavior, data exposure, evidence, cost, resilience or legal rights,
and can we trace that component to outputs, customers, workflows, owners, approvals and response actions?

AI BOM 提供四种能力:

AI BOM 不是:

SR 26-2 is a current model-risk anchor, but AI BOM must be broader than formal model inventory. Model inventory tells the institution what models it owns or uses; AI BOM tells the institution what exact component chain produced a behavior and what must be changed, tested, paused or exited when any component becomes risky.

---

2. Source Anchors

Anchor interpretation:

---

3. AI Supply Chain Scope

AI supply chain includes every external or internal component that can influence model behavior, retrieved context, prompt construction, tool/action execution, output safety, customer data exposure, audit replay, evaluation, incident response, operating cost, concentration or exit.

Relationship to existing inventories:

---

4. AI BOM Schema

Every component record should answer: what is it, where did it come from, who owns it, which version is approved, what rights apply, which workflows use it, how it is verified, and how it exits.

Runtime usage record:

Production release manifest should be signed:

{
  "ai_bom_manifest_id": "aibom-card-dispute-copilot-2026.06.30",
  "workflow_id": "card-dispute-copilot",
  "risk_tier": "high",
  "release_id": "release-2026.06.30",
  "approved_by": ["card-servicing-owner", "model-risk-reviewer", "security-architect"],
  "components": [
    {"id": "model-route-primary", "class": "model_route", "version": "2026-06"},
    {"id": "prompt-card-dispute-sop", "class": "prompt_pack", "version": "v9"},
    {"id": "rag-corpus-card-fee-policy-2026q2", "class": "rag_corpus", "version": "2026q2-v17"},
    {"id": "tool-transaction-summary", "class": "tool_api", "version": "v4"},
    {"id": "mcp-crm-case-reader", "class": "mcp_server", "version": "v3.2.1"},
    {"id": "eval-card-dispute-golden", "class": "eval_dataset", "version": "2026q2-v3"},
    {"id": "trace-schema-ai-high-risk", "class": "telemetry_schema", "version": "v6"}
  ],
  "release_gate": {"eval_result": "passed", "critical_failures": 0, "license_exceptions": 0}
}

Required relationships:

---

5. Component-Level Design Notes

Design principle:

If changing a component can change an answer, permission, evidence record, customer impact, cost, legal right or exit path, it belongs in the AI BOM.

---

6. Provenance Graph

AI BOM gives the node list; provenance graph gives the edges and events. Without a provenance graph, the organization knows components exist but cannot prove how they produced a specific output.

PROV-style mapping:

Graph example:

flowchart LR
  A[Policy Source v12] --> B[Chunking Activity v5]
  B --> C[RAG Corpus 2026Q2-v17]
  C --> D[Retrieval Run trace-88172]
  E[Prompt Pack v9] --> F[Prompt Assembly]
  D --> F
  G[Transaction Summary Tool v4] --> F
  F --> H[Model Invocation enterprise-chat-2026-06]
  H --> I[Employee Copilot Draft]
  I --> J[Human Review QA Rubric v3]
  J --> K[Customer Response Logged]
  L[AI BOM Registry] -. component ids .-> C
  L -. component ids .-> E
  L -. component ids .-> G
  L -. component ids .-> H

Minimum provenance events:

Impact queries:

SELECT output_id, workflow_id, customer_case_hash, trace_id, generated_at
FROM ai_component_usage
WHERE component_id = 'rag-corpus-card-fee-policy-2026q2'
  AND component_version = '2026q2-v17'
  AND generated_at BETWEEN '2026-06-01' AND '2026-06-30';

SELECT DISTINCT workflow_id, business_owner, risk_tier, fallback_mode
FROM ai_bom_dependency_graph
WHERE dependency_component_id = 'mcp-crm-case-reader'
  AND dependency_version = 'v3.2.1';

---

7. Change And Vulnerability Response

AI BOM response covers CVEs and AI-native component failures.

Response workflow:

Detect issue
  -> classify component and severity
  -> query impact graph
  -> identify owners and affected workflows
  -> choose containment: disable, rollback, pin, purge, reroute, human review
  -> run targeted regression and safety eval
  -> decide release, rollback or residual risk acceptance
  -> update AI BOM status and evidence binder

Severity matrix:

Containment patterns:

Response evidence:

---

8. License And Data Rights

Rights failures can block deployment, exit, audit or commercial use.

Examples:

• Open-source model license restricts commercial or financial-service use.
• Dataset terms allow evaluation but not fine-tuning.
• Vendor API terms allow prompt retention for abuse monitoring but not training.
• Generated output terms require attribution or restrict redistribution.
• Policy documents can be used internally but not shared with third-party annotation vendors.

Rights fields:

Review questions:

---

9. Vendor, Subprocessor, Concentration And Exit

Component-to-vendor view:

Concentration KRIs:

Exit mapping:

---

10. Dashboards And KRIs

Executive dashboard:

Operational dashboard:

Board / audit view:

---

11. RACI

RACI key: R = responsible, A = accountable, C = consulted, I = informed.

---

12. Financial Retail Examples

12.1 Customer Service RAG

Use case: employee assistant drafts answers for credit card fees, disputes and refunds.

AI BOM focus:

• Model route, prompt pack, card policy corpus, transaction summary tool, CRM MCP server.
• Eval set for stale policy, complaint escalation, vulnerable customer language and fee-waiver edge cases.
• Trace store with prompt, model, corpus, tool and human review versions.

Failure scenario:

A retired annual-fee policy remains in the RAG index.
Impact graph identifies 184 outputs and 17 customer complaints.
Containment purges policy chunks, rebuilds index, requires human review for fee responses, and reruns regression set.

12.2 Credit Underwriting Copilot

Use case: analyst Copilot summarizes income, debt, documents and policy exceptions.

AI BOM focus:

• Document OCR package, income classification model, policy RAG corpus, prompt pack, exception scoring tool.
• Strict rights on borrower documents and production-derived eval cases.
• Model risk linkage because outputs may influence credit decision support.

Failure scenario:

OCR package update changes extraction of paystub year-to-date income.
AI BOM query identifies underwriting workflows using the package version.
Containment pins prior package, samples affected summaries, and adds regression cases.

12.3 AML Case Copilot

Use case: investigator assistant summarizes alerts, customer profile, transaction patterns and narrative draft.

AI BOM focus:

• High sensitivity data sources, typology corpus, narrative prompt, graph query tool, red-team eval.
• Telemetry evidence for audit and suspicious activity review.
• Vendor access must be tightly restricted because AML typologies and case data are sensitive.

Failure scenario:

MCP graph connector exposes a broader query scope than approved.
Tool gateway disables connector for AML workflows, rotates token, reviews trace usage and reruns excessive-agency tests.

12.4 Marketing Content Generator

Use case: marketing team drafts campaign copy with product constraints and brand tone.

AI BOM focus:

• Brand prompt pack, product disclosure corpus, approved claims dataset, image/font/license assets.
• Lower customer data exposure but higher output rights and disclosure accuracy risk.

Failure scenario:

Open-source image generation dependency changes license.
Rights review flags commercial use restriction, production release is blocked, and approved asset library replaces the component.

---

13. Templates With Concrete Examples

13.1 AI BOM Component Record

component_id: rag-corpus-card-fee-policy-2026q2
component_class: rag_corpus
component_name: Credit Card Fee Policy Corpus
version: 2026q2-v17
workflow_ids:
  - card-dispute-copilot
  - branch-card-servicing-assistant
owner: Head of Card Servicing Knowledge
supplier_type: internal
supplier_name: Card Policy Operations
risk_tier: high
approved_use: Ground employee Copilot answers about fees, disputes and provisional credits.
prohibited_use: Autonomous customer fee-waiver decisions and external redistribution.
data_classification: confidential_internal_policy
license_or_rights: internal_use_only
source_uri: policy-repo://card/fees/2026Q2
checksum: sha256:4d8c91f0a72b6c20
signature_status: signed_by_policy_ops_release_key
approval_record: AI-CHANGE-2026-0619-044
deployment_state: production
replacement_option: Rebuild corpus from approved policy source registry into alternate vector index.
exit_readiness: tested_2026_06_20
last_reviewed_at: 2026-06-30

13.2 Component Intake Checklist

13.3 Vulnerability Response Record

13.4 License Review Record

13.5 Evidence Query

SELECT
  t.trace_id,
  t.workflow_id,
  t.generated_at,
  u.component_id,
  u.component_version,
  c.component_class,
  c.owner,
  c.risk_tier,
  c.license_or_rights,
  c.deployment_state
FROM ai_trace t
JOIN ai_component_usage u ON t.trace_id = u.trace_id
JOIN ai_bom_component c
  ON u.component_id = c.component_id
 AND u.component_version = c.version
WHERE t.trace_id = 'trace-card-complaint-88172'
ORDER BY c.component_class, c.component_id;

13.6 ADR Example

# ADR: AI BOM Registry For High-Risk GenAI Workflows

Decision date: 2026-06-30
Status: Accepted
Context: Card servicing, AML and credit Copilots depend on model, RAG, prompt, tool, MCP, eval and telemetry components. Existing model inventory and vendor inventory do not provide component-level runtime traceability.
Decision: Build an AI BOM registry connected to prompt registry, model gateway, RAG source registry, tool gateway, eval store and trace vault. Require signed release manifests for high-risk workflows.
Consequences: Release gates become stricter, but incident response can scope affected outputs and exit planning becomes evidence-based.

---

14. Operating Model

Lifecycle:

Plan component
  -> intake and classify
  -> verify source, license, signature and rights
  -> approve for use
  -> include in release manifest
  -> capture runtime usage
  -> monitor KRIs
  -> respond to change/vulnerability
  -> retire, replace or export

Governance forums:

Evidence binder:

---

15. 30-Day Lab

Goal: Build an AI BOM and provenance response pack for one financial retail AI workflow.

---

16. Interview Answers

16.1 30-Second Version

AI BOM is the component-level traceability layer for GenAI systems. I would not stop at SBOM or model inventory. For a financial AI workflow, I would track models, providers, datasets, RAG corpora, prompt packs, tools, MCP servers, eval datasets, human review vendors, telemetry stores, open-source packages, licenses, versions, signatures and runtime usage. The goal is to answer: which exact components produced this output, what rights and risks attach to them, and how fast can we contain or replace them if something changes.

16.2 2-Minute Version

In financial retail, AI supply chain is broader than software supply chain. A customer service Copilot might depend on a hosted model, an internal policy corpus, an embedding model, prompt templates, transaction summary tools, an MCP CRM connector, eval datasets, human QA reviewers and a trace store. Any one of those can change behavior, expose data, break audit replay or create vendor lock-in.

I would build AI BOM as a registry plus provenance event log plus impact graph. The registry stores each component's owner, supplier, version, rights, approved use, risk tier, signature and exit option. The provenance event log records registration, verification, approval, deployment, runtime use, evaluation, vulnerability and retirement. The impact graph lets us answer response questions such as which outputs used a stale corpus, which workflows rely on one MCP server, or which eval sets contain production-derived data.

I would connect this to NIST AI RMF for governance, NIST SSDF for secure build and response discipline, OWASP LLM Top 10 for AI-native supply-chain risks, CISA SBOM for component transparency, and SR 26-2 for the model-risk anchor. The nuance is that SR 26-2 model inventory remains important, but AI BOM must include non-model components that materially affect outcomes.

16.3 Q: How is this different from vendor risk management?

Vendor risk management evaluates supplier lifecycle, contracts, financial condition, controls, subprocessors, SLA and exit. AI BOM operates one level deeper: it identifies component versions and runtime usage. A single vendor may supply many components, and a single workflow may depend on many vendors. AI BOM lets us scope exactly which component caused risk and which workflows, traces and outputs are affected.

16.4 Q: What components belong in an AI BOM?

Everything that can influence behavior, data exposure, evidence, rights, cost or exit belongs in scope: foundation model, embedding model, reranker, datasets, RAG corpus, prompt pack, policy pack, tool schema, MCP server, connector, eval dataset, human review vendor, telemetry schema, trace store, open-source packages, licenses and provider contracts.

16.5 Q: How would you respond to a poisoned RAG corpus?

First, flag the corpus component and query the impact graph to find affected workflows, outputs and cases. Second, contain by marking the source inactive, purging chunks, rebuilding the index, and forcing human review for affected answer categories. Third, run regression tests focused on the poisoned content and related policy scenarios. Fourth, update the AI BOM status, preserve evidence, notify owners and decide whether customer remediation or regulatory escalation is needed.

16.6 Q: Why are eval datasets part of supply chain?

Eval datasets determine what the system is allowed to ship. If an eval set is stale, biased, leaked, production-derived without rights, or missing adversarial cases, the release gate becomes false confidence. Eval sets need owners, versions, provenance, sensitivity classification, rights, retention, reviewer calibration and coverage mapping.

16.7 Q: How do MCP servers change AI supply-chain risk?

MCP servers expose tools and context to agents. Their manifests, descriptions, tokens and tool results can influence model behavior. A malicious or over-permissioned MCP server can cause data exfiltration, unauthorized tool calls or cross-agent propagation. AI BOM should track MCP server version, allowed methods, token scope, sandbox, signature, owner, runtime usage and kill switch.

16.8 Q: What would you show an executive?

I would show a simple heatmap: high-risk AI workflows, critical components, provider concentration, unsigned or unreviewed components, vulnerabilities past SLA, traces with complete component evidence, and exit readiness. The executive message is that the institution can identify dependencies, prove what produced customer-impacting outputs, respond quickly to component issues, and avoid uncontrolled lock-in.

17. Minimum Practice Checklist