AI BOM：AI 物料清单定义、构成与治理价值
AI BOM 是记录 AI 系统组件与生命周期信息的物料清单。它区别于 SBOM，聚合数据集、许可、敏感性分类和模型架构，适合模型治理与 AI 供应链透明化。
AI BOM 是什么？
AI BOM，即 AI 物料清单，是面向 AI 系统的结构化元数据清单，用于记录 AI 系统从开发到部署过程中的关键组成和生命周期信息。它不是只列出代码依赖，而是把数据集、模型架构、许可限制、敏感性分类等 AI 特有要素纳入清单管理。
可以把它理解为 BOM 概念在 AI 场景下的延伸：制造业 BOM 管理产品结构，SBOM 管理软件组件，AI BOM 则进一步覆盖 AI 系统中的数据、模型和治理信息。
要点： AI BOM 的核心价值不在于“多一份文档”，而在于让 AI 系统的组成、来源、使用边界和生命周期记录更清楚，便于后续审查和追踪。
AI BOM 与传统 BOM、SBOM 有什么区别？
AI BOM 与传统 BOM、SBOM 有继承关系，但管理对象和风险关注点并不相同。
| 类型 | 管理对象 | 主要记录内容 | 主要用途 | 风险关注点 |
|---|---|---|---|---|
| BOM | 实体产品及其结构 | 零部件、产品结构、工程与制造相关信息 | 支撑工程、供应链、制造、销售和服务等环节协同 | 物料、制造、供应链协同风险 |
| SBOM | 软件产品 | 软件组件、库、模块等，通常以机器可读格式列出 | 跟踪软件供应链元素，识别漏洞并降低安全风险 | 软件漏洞、依赖来源、供应链安全 |
| AI BOM | AI 系统 | 数据集、数据来源、许可限制、敏感性分类、模型架构、生命周期信息等 | 支撑 AI 系统透明化、审查、风险识别和模型治理 | 监管风险、知识产权风险、数据敏感性、模型治理和 AI 供应链安全 |
传统 BOM 更关注产品结构和跨部门协同；SBOM 更关注软件组成、依赖关系和漏洞识别；AI BOM 则在 SBOM 思路上扩展到 AI 系统的特征，例如训练或微调数据、模型架构以及从开发到部署的生命周期记录。
AI BOM 通常包含哪些核心要素？
不同组织、项目和标准化实现方式可能会采用不同字段，因此 AI BOM 不应被理解为固定唯一模板。结合现有资料，AI BOM 通常会围绕以下几类信息展开。
数据集信息
AI BOM 可记录训练或微调所需的数据集信息，包括数据集来源、用途和与模型开发相关的基础描述。对于数据来源复杂的项目，这类信息是后续审查和追踪的基础。
数据合规与使用边界信息
数据相关信息通常还会包括许可限制和敏感性分类。许可限制会影响数据能否用于训练、微调、分发或商业化使用；敏感性分类则关系到数据处理边界和合规审查。
模型信息
AI BOM 可包含模型架构等模型层面的元数据。模型架构记录有助于团队理解 AI 系统由哪些关键部分构成，也便于后续对系统变更进行追踪。
生命周期信息
AI BOM 可记录 AI 系统从开发到部署过程中的关键生命周期信息，例如开发、训练、微调、交付或部署阶段形成的关键记录。生命周期信息有助于把“模型是怎么来的、经过哪些变化、当前处于什么状态”表达得更清楚。
AI BOM 的工作方式可以如何理解？
AI BOM 的工作方式可以概括为：用标准化或结构化清单记录 AI 系统的关键元数据，再把这些信息用于审查、追踪和治理。
收集关键元数据
团队首先需要识别 AI 系统中的关键对象，例如训练或微调数据集、模型架构、许可限制、敏感性分类以及生命周期记录。这个阶段的重点是明确“哪些信息会影响系统使用、审查和风险判断”。
整理为清单化表达
随后，团队将这些信息整理为统一的清单。SBOM 中常见的机器可读软件组件清单可以作为理解参照：清单化的目的，是让复杂系统的组成信息更容易被检索、共享和追踪。
对于 AI BOM，也已有资料讨论使用 SPDX 3.0 等方式进行标准化表达。但在实际项目中，具体字段、实施步骤和适用边界仍需要结合组织要求、项目复杂度和可获得的标准资料谨慎确认。
用于审查、追踪和治理
当 AI BOM 建立后，它可以作为风险审查、内部治理和供应链透明化的基础材料。例如，在检查数据许可、确认敏感数据边界或追踪模型生命周期变化时，AI BOM 能提供更集中、更结构化的信息入口。
AI BOM 能解决哪些风险和治理问题？
AI BOM 的价值主要体现在透明化和可追踪性上。它不能自动消除所有风险，但可以为风险识别和后续治理提供基础。
监管风险
通过记录数据来源、许可限制和敏感性分类，AI BOM 可以为后续合规审查提供依据。尤其是在训练或微调数据来源较多的项目中，清晰记录数据边界有助于减少审查时的信息缺口。
知识产权风险
数据和组件的许可限制会影响 AI 系统的使用边界。AI BOM 通过集中记录这些限制，帮助团队识别来源不清、授权不明或使用范围不匹配的问题。
AI 供应链安全风险
SBOM 的一个重要作用，是帮助组织跟踪软件供应链元素、识别漏洞并降低安全风险。AI BOM 可以借鉴这一思路，把 AI 系统中的数据、模型和相关生命周期信息纳入供应链透明化管理，从而为风险追踪提供基础。
模型治理问题
AI BOM 记录模型架构和生命周期信息，有助于团队理解 AI 系统如何构成、如何变化以及哪些信息需要被审查。对于跨团队协作的 AI 项目，这种统一记录可以降低沟通成本，并为内部治理提供依据。
哪些场景适合引入 AI BOM？
AI BOM 更适合那些组成复杂、风险边界需要被说明，或需要跨团队审查的 AI 项目。
| 用户需求 | 解决方式 | 效果 |
|---|---|---|
| 数据来源复杂的训练或微调项目 | 记录数据集来源、许可限制和敏感性分类 | 便于后续审查数据使用边界，降低来源不清带来的风险 |
| 需要跨团队交付的 AI 系统 | 用统一清单描述模型架构和生命周期信息 | 减少交接时的信息缺口，提高系统透明度 |
| 关注 AI 供应链安全的组织 | 将数据、模型和相关组成信息纳入清单化管理 | 为识别组成要素和追踪风险提供基础材料 |
| 存在监管、知识产权或内部治理要求的项目 | 将许可、敏感性分类和生命周期记录集中管理 | 支撑后续核查、责任界定和治理流程 |
如果项目只是一次性实验，且数据来源、模型结构和交付范围都比较简单，AI BOM 可以从轻量记录开始；如果项目需要进入交付、部署或审查流程，则更需要系统化建设。
建设 AI BOM 前应先确认什么？
在建设 AI BOM 前，建议先明确清单的覆盖范围和使用目标，避免把它做成无法维护的静态文档。
确认要覆盖的对象
先判断 AI BOM 是否需要覆盖以下内容：
- 训练或微调数据集；
- 数据来源；
- 许可限制；
- 敏感性分类；
- 模型架构；
- 开发到部署过程中的生命周期记录；
- 与 AI 系统相关的软件组件或依赖信息。
确认要记录的风险信息
不同项目的风险重点不同。数据密集型项目应重点关注数据来源、许可和敏感性分类；交付型或平台型项目还应关注模型架构、生命周期记录和供应链可追踪性。
确认清单的使用目标
AI BOM 可以服务于多种目标，包括：
- 风险识别；
- 供应链透明化；
- 审查准备；
- 知识产权管理；
- 内部模型治理；
- 跨团队交付和变更追踪。
目标不同，字段深度和维护频率也会不同。建设前先明确目标，有助于控制清单范围。
确认是否需要标准化格式
如果 AI BOM 需要在多个团队、工具或流程之间流转，就应考虑采用更标准化的表达方式。已有资料讨论用 SPDX 3.0 实施 AI BOM，但具体是否适配，需要结合项目要求、组织流程和可获得的标准资料进一步评估。
检查清单： 开始建设 AI BOM 前，至少应回答三个问题：要记录哪些对象、要支撑哪些风险判断、清单未来由谁维护和使用。