AI Supply Chain / AI BOM：来源证明架构
AI BOM is the component-level traceability layer for AI systems: model, data, prompt, tool, eval, human operation, telemetry and vendor components must be versioned, provenanced, signed, monitored and
AI Supply Chain / AI BOM / Provenance Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_SUPPLY_CHAIN_AI_BOM_PROVENANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 本文采用方式 |
|---|---|---|
| CISA SBOM official page | https://www.cisa.gov/sbom | 用 SBOM 思维理解 component inventory、version、supplier、dependency、vulnerability response。 |
| NIST SSDF SP 800-218 | https://csrc.nist.gov/pubs/sp/800/218/final | 用 secure software development practice 扩展到 AI component build、verify、release、response。 |
| OWASP Top 10 for LLM Applications | https://genai.owasp.org/llm-top-10/ | 将 LLM supply chain、data/model poisoning、tool/plugin/MCP 风险纳入 AI BOM。 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI supply chain 风险治理和证据。 |
| Federal Reserve SR 26-2 | https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm | 作为当前模型风险管理锚点；AI BOM 必须比 formal model inventory 更宽。 |
核心导读： AI BOM is the component-level traceability layer for AI systems: model, data, prompt, tool, eval, human operation, telemetry and vendor components must be versioned, provenanced, signed, monitored and exit-ready.
核心导读
AI BOM 不是把模型名称登记到 inventory。它是 AI 系统的 component-level traceability layer：模型、prompt、RAG 语料、embedding、工具、插件、policy、eval set、人审标准、遥测管道、供应商和运行区域都可能改变输出和风险。金融零售 AI 一旦影响客户承诺、资金动作、适当性判断、投诉处理或合规记录，就必须能回答“这个结果由哪些组件共同产生，这些组件来自哪里，版本是什么，是否可信，出了问题如何定位、替换和退出”。
SBOM 关注软件依赖；AI BOM 需要覆盖行为依赖。没有 AI BOM，模型验证只能说明某一时刻系统表现，而无法解释后续哪个组件变化造成风险漂移。
问题定义
现代 AI workflow 的供应链风险来自组合复杂性：
- 一个 GenAI workflow 可能只有一个 formal model，但有数十个可改变行为的组件。
- RAG 语料、chunking 策略、prompt、工具权限、eval set、人审标准和 telemetry pipeline 都会改变结果。
- Vendor model 升级、embedding 模型替换或 API 默认参数变化，可能不经过传统 release review。
- 外部插件、MCP server、browser/tool adapter 和 no-code connector 可能扩大 data exfiltration 和 excessive agency 风险。
- 开源模型、开源评估脚本和第三方数据集可能带来 license、poisoning、provenance 和 vulnerability 问题。
- 缺少 component lineage 时，incident 只能靠团队回忆，而无法快速定位受影响客户和输出。
AI supply chain governance 的问题不是“供应商是否通过审查”，而是“生产中每个 AI 决策路径是否能被组件级重建和影响分析”。
核心原理/方法
AI BOM 应覆盖七类组件：
| 组件类型 | 示例 | 风险关注 |
|---|---|---|
| Model component | foundation model、fine-tuned model、embedding model、reranker | 版本变更、性能漂移、供应商依赖、许可和退出 |
| Data component | training data、RAG corpus、policy docs、customer data、synthetic data | 来源、授权、敏感性、有效期、污染和 lineage |
| Prompt / policy component | system prompt、prompt template、guardrail policy、decision table | 未审查变更、越权指令、控制绕过 |
| Tool / connector component | CRM、payment API、case tool、MCP server、browser action | 权限扩大、数据外流、审批前执行 |
| Eval component | test set、red-team set、scoring rubric、gold cases | 覆盖不足、泄漏、不可比、风险场景缺失 |
| Human operation component | review guideline、calibration set、queue rule、training material | 复核不一致、rubber stamp、能力不足 |
| Telemetry / evidence component | logs、trace schema、audit ledger、monitoring pipeline | 证据缺失、字段变更、无法复盘 |
每个组件要有 provenance、version、owner、approval、risk tier、dependency、allowed use、region、license、integrity check、change history 和 exit option。对高影响场景，还需要将组件版本绑定到每次输出或工具动作。
系统/架构模型
AI Component Registry
-> Provenance & Attestation Store
-> Dependency Graph
-> Build / Release Pipeline
-> Runtime Component Resolver
-> Policy / License / Region Gate
-> Telemetry Binding
-> Vulnerability & Incident Impact Analysis
-> Exit / Replacement Workflow
关键组件：
| 组件 | 职责 |
|---|---|
| Component registry | 登记模型、数据、prompt、工具、eval、人审和遥测组件 |
| Provenance store | 保存来源、供应商、hash、签名、许可、审批、数据权利和生成链路 |
| Dependency graph | 表示 use case 到组件、组件到供应商、组件到区域和组件到风险的关系 |
| Release pipeline | 在变更时执行安全、合规、模型、数据、eval 和证据 gate |
| Runtime resolver | 在每次请求时解析实际使用的 model/prompt/source/tool/policy version |
| Policy gate | 校验组件是否允许用于该产品、客户群、地区、数据类型和业务目的 |
| Impact analyzer | incident 时按组件版本查询受影响输出、客户、员工动作和系统写入 |
| Exit workflow | 管理供应商替换、模型迁移、数据回收、密钥撤销和历史证据保留 |
架构上的关键要求是“runtime binding”：BOM 不能只在发布时生成，还必须在生产事件中绑定组件版本，否则无法做精确影响分析。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 粗粒度 BOM vs 细粒度 BOM | 粗粒度维护成本低但无法定位风险；高影响场景需要精确到 prompt、source、tool 和 policy version |
| Vendor black box vs 内部可见性 | 商业模型未必提供完整内部 lineage；内部 gateway 至少要捕获可控组件和供应商声明 |
| 版本锁定 vs 自动升级 | 自动升级提升能力和安全补丁速度，但会破坏可比性；关键场景需要版本 pinning、canary 和回归 |
| 开源灵活性 vs 供应链责任 | 开源模型和工具降低锁定，但组织要承担 provenance、license、vulnerability 和维护责任 |
| 中央 registry vs 团队自治 | 中央 registry 保证标准；团队自治提高速度。可采用平台标准字段 + domain-specific metadata |
| 完整证据 vs 成本 | 每个 token 级记录成本高；应按风险定义 authoritative evidence，而不是无差别保存一切 |
AI BOM 不应被当成静态资产清单。它要与变更管理、运行监控、incident response、vendor risk、data governance 和 retention 连接。
证据与控制
AI BOM 的证据应支持三类问题：组件可信、变更可控、影响可查。
| 证据对象 | 关键字段 |
|---|---|
| Component record | component id、type、version、owner、supplier、license、approval、risk tier |
| Provenance attestation | source、hash/signature、build process、review evidence、data rights、region |
| Dependency edge | use case、component、allowed purpose、data class、region、fallback、criticality |
| Release gate result | security scan、policy review、eval result、model validation、privacy/security approval |
| Runtime binding event | request id、model version、prompt version、retrieved source id、tool version、policy version |
| Vulnerability response | affected versions、affected customers/actions、mitigation、replacement、customer remediation |
| Exit record | supplier offboarding、data deletion/return、key revocation、archive and evidence retention |
控制指标可包括：unknown component count、unapproved component usage、component drift、vendor concentration、unsupported version、missing provenance、runtime binding completeness、time-to-impact-analysis、exit readiness score。
金融零售/AI产品场景
信用卡争议 copilot：输出由争议政策文档、merchant category rules、case history、prompt、LLM、CRM 工具和复核指南共同决定。AI BOM 必须能定位某次错误拒绝是否来自政策版本、检索、prompt、工具映射还是 reviewer rubric。
贷款预审助手：即使模型只是生成解释，RAG 文档、eligibility rules、reason-code mapping 和 adverse-action 模板也都属于行为组件。版本变更必须触发回归测试和证据绑定。
财富内容生成平台：approved content、forbidden claims、product risk profile、disclosure template、sales campaign brief 和 human approval workflow 都应进入 BOM，否则 conduct incident 无法复盘。
零售营销 personalization：客户分群规则、consent policy、feature store、offer engine、prompt 和输出过滤器共同影响客户触达。AI BOM 要支持 purpose-bound 数据使用和营销 claim 审核。
反模式
- 只登记 foundation model，不登记 prompt、RAG、工具、eval 和人审标准。
- 把 vendor due diligence 当成 AI supply chain 的全部。
- 允许模型或 embedding 自动升级，但没有回归测试和版本绑定。
- 运行日志只能看到“调用了 AI”，无法重建具体组件组合。
- 组件 inventory 和 incident response 分离，出事后无法查询受影响输出。
- 开源组件没有 license、hash、来源和维护责任。
- 退出计划只写商业合同，不覆盖数据、key、日志、评估集和历史证据。
最终心智模型
AI BOM 是 AI 系统的“行为供应链地图”。在金融零售场景中，可治理的不是一个孤立模型，而是由模型、数据、prompt、工具、人员、政策和证据组成的生产链。
成熟架构的判断标准是：当某个组件被发现有风险、被供应商升级、被证据要求替换或被监管质疑时，组织能否快速定位它在哪里被使用、影响了哪些客户和业务动作、如何降级或替换、如何证明历史输出由哪个组件版本产生。做不到这一点，AI governance 就只停留在模型清单层。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。