AI 软件物料清单 (AIBOM)：当采购部门问起时，你的依赖树长什么样

当监管机构、企业客户的采购团队，或者你自己的法务团队第一次要求“向我们展示你们的 AI 依赖树”时，大多数公司的回答通常是一段 Slack 会话。平台频道的某人呼叫模型团队。模型团队呼叫 Prompt 负责人。Prompt 负责人抄送给数据负责人。两天后，一份填了一半的电子表格出现在审计员的收件箱里，里面充满了“待定”单元格和一条脚注：“我们认为这是截至上周的最新数据。”

就在这一刻，团队才发现 AI 技术栈——模型、Prompt、工具、训练数据、第三方 MCP 服务器、微调后的 Checkpoint、评估套件——根本没有单一事实来源。软件供应链合规产生了 SBOM 作为监管机构和客户期望的产物。AI 产品具有类似的暴露面，但 SBOM 的概念仅止于代码依赖。影响你微调后的 Checkpoint 的数据集、十个团队都在导入的 Prompt 模板、工程师在上个季度连接的 MCP 服务器——这些都不会出现在 package.json 中。

解决方案是 AI 软件物料清单（AI Bill of Materials），简称 AIBOM：一份持续更新的、机器可读的库存清单，记录了你产品依赖的每一个 AI 组件，它是通过自动化检测而非凭记忆生成的。这不只是一个文档编写工作。它正成为“下一个续约周期”时间线上的合同交付项，以及 2026 年 8 月《欧盟 AI 法案》对高风险系统核心义务生效时的合规产物。

为什么 SBOM 的概念无法涵盖 AI

SBOM 是为代码设计的：库、版本、许可证、漏洞。其模型是“哪些二进制文件进入了此次构建，其中哪些具有已知的 CVE”。这之所以有效，是因为软件行为是由代码决定的。

但 AI 系统并非如此。前沿模型的行为取决于其训练数据、训练后的处理程序、分词器（tokenizer）、随附的系统 Prompt、你设置的 Temperature、你连接的工具、它查询的检索语料库，以及你指定的版本锁定——如果你指定了的话。这些都不在你的依赖清单中。一个仅捕获推理服务所导入的 Python 包的 SBOM，遗漏了行为的实际来源。

这种差距以具体的方式显现出来。模型提供商发布了一个“小更新”，你的拒绝回复模式一夜之间发生了变化。一个微调数据集包含了来自你的合同未涵盖的许可证桶中的抓取内容。一名工程师添加了一个第三方的 MCP 服务器，而该服务器悄悄地获取了你 CRM 的凭据。一个 Prompt 模板在没有升级版本号的情况下被修改了，导致十个下游功能开始产生不同的输出。传统的供应链工具无法捕获这些情况，因为它们根本不知道 Prompt、数据集或模型 Checkpoint 的存在。

这就是为什么标准组织已经开始采取行动。OWASP AIBOM 项目正在现有的 CycloneDX 1.6 和 SPDX 3.0 模式之上构建开源实现，这两者现在都有专门针对 AI/ML 的组件类型。CycloneDX 规范——最近作为 Ecma 国际标准 ECMA-424 发布——支持将 AI/ML-BOM 作为与 SBOM 和 SaaSBOM 并列的一等文档类型。SPDX 3.0 增加了 AI 配置文件，以捕获模型元数据、训练数据引用和评估结果。格式之争基本已经尘埃落定。团队现在缺少的是生成流水线。

你必须追踪的四个维度

一个有用的 AIBOM 必须覆盖四个维度，而大多数团队至少低估了其中两个。

模型 (Models)：生产环境中的每一次模型调用，包括提供商、模型 ID、锁定的版本以及调用它的功能。这听起来很简单，直到你意识到“锁定版本”在多少情况下其实只是“提供商当前的 latest 别名”。我最近交谈过的一个团队发现，生产环境中同时运行着三个不同版本的同一个 Claude 模型，因为三个不同的服务是在不同时间部署的，且都没有锁定版本。他们的 AIBOM 缺少一行“跨服务的版本漂移”。当他们滚动注册表时，其中两个功能出现了他们此前未曾追踪的可测量行为差异。

提示词 (Prompts)：每一个系统 Prompt、每一个模板化的用户 Prompt、每一个助手预填（assistant pre-fill）。这些需要 ID、版本历史和明确的负责人。需要负责人的原因是 Prompt 已成为关键的业务逻辑，但在组织中没有明确的归属——有时归产品部门，有时归工程部门，有时两者都不归。如果没有负责人，变更管理就变成了“谁最后修改的就归谁”。一个真正的 Prompt 注册表会将这些存储为配置而非代码，并配备像数据库迁移一样的 Git 式 Diff 对比和 CI 门禁。MLflow 的 Prompt 注册表、LaunchDarkly 的 Prompt 管理以及 Vertex AI 的 Prompt 注册表都趋向于同一种形态：将 Prompt 作为版本化的、环境晋升的产物。

工具 (Tools)：每一个函数调用工具、每一个 MCP 服务器、每一个 Agent 可以访问的插件。能力范围（只读？写入？哪些资源？）、身份验证路径、弃用状态。这就是影子 AI（shadow AI）存在的地方。一次企业库存普查发现官方名单上有 150 个 Agent，而实际部署的超过 500 个。另一项针对 2240 万条企业 Prompt 的审计识别出企业环境中存在 665 种不同的生成式 AI 工具——其中大多数未经授权。如果你的工具注册表只是 tools.py 中的一个对象数组，那么你根本没有注册表。

数据集和 Checkpoint (Datasets and checkpoints)：每一个训练集、每一个微调数据集、每一个检索语料库、每一个评估集。溯源信息、许可证、最后更新时间戳，以及它产出的 Checkpoint。针对广泛使用的微调数据集血统的研究发现，许可证误分类率超过 50%，许可证信息遗漏率超过 70%。如果你在一个许可证分类错误的数据集上进行微调，你的模型就会带着一个你看不到的问题发布——而且如果没有将 Checkpoint、数据集和许可证关联起来的 AIBOM，你就无法修复它。

团队常犯的错误是将这四者视为四个独立的电子表格。但它们不是。一个生产环境中的 AI 功能是这四者的笛卡尔积：这个 Prompt，在那个模型版本上，调用这些工具，针对这个检索语料库。改变其中任何一个，行为都会改变。AIBOM 必须记录这种绑定关系，而不仅仅是零散的部件。

通过插桩生成，而非靠 Wiki 维护

AIBOM 的首次尝试几乎总是以 Wiki 页面开始。有人手动填写，获得感谢，但六周内页面内容就会出错。手动维护的 AIBOM 无法扩展；这一点在 OWASP 指南的首要解决问题中已有详尽记录。唯一可持续的方法是利用与可观测性（observability）相同的插桩（instrumentation）手段来生成 AIBOM。

具体而言：推理层的每一次 LLM 调用都会发出结构化遥测数据，包括模型 ID + 版本 + 供应商 + 提示词 ID + 提示词版本 + 工具列表 + 检索来源。你的 AIBOM 就是针对该流的查询。如果生产环境的遥测数据中出现了一行没有对应注册提示词的内容，你的 AIBOM 生成器会将其标记为“未记录”。如果出现了一个无人部署的模型版本，你的 AIBOM 会将其标记为“漂移（drift）”。交付物不再是人写的东西，而是系统持续产出的结果。

实践中行之有效的结构包含三个部分。控制平面（提示词、工具、模型的注册表），人类在此声明意图。数据平面（生产遥测），记录实际发生的情况。协调器（reconciler），负责比较两者并标记差异。AIBOM 是该协调器的物化输出，采用 CycloneDX 或 SPDX 格式，并带有签名和时间戳。当采购部门询问时，你不需要编写文档——你只需导出最新的运行结果。

这种结构也适用于变更管理问题。当提示词版本晋升时，注册表会发出一个事件。当遥测数据中开始出现新的模型版本时，协调器会触发。当工具的功能范围扩大时，CI 门禁会拦截。AIBOM 成为了以常规工程纪律进行 AI 开发的副产品，而非一个独立的合规项目。

推动因素：监管机构与采购部门

两股力量正推动 AIBOM 从“锦上添花”变为“势在必行”。

监管机构：欧盟《AI 法案》（EU AI Act）针对高风险 AI 系统的核心义务将于 2026 年 8 月 2 日生效，嵌入受规管产品的 AI 截止日期则延长至 2027 年 8 月 2 日。高风险供应商必须根据附件 IV 维护技术文档，根据第 71 条在欧盟数据库中注册系统，并在上线前完成符合性评估。第 99 条规定，违反记录保存规定的罚款最高可达 1500 万欧元或全球年度总营业额的 3%。NIST AI RMF 的治理（Govern）功能要求提供 AI 清单；ISO/IEC 42001 明确要求 AIMS 审计追踪。监管机构并不关心你使用什么格式，但他们都要求同一类产物：关于你的产品中包含哪些 AI、它依赖什么以及它在哪个风险等级运行的准确、实时清单。

采购部门：这是一个被低估的驱动因素。随着企业购买 AI 功能，其安全和采购团队开始要求将 AIBOM 风格的文档作为供应商问卷调查的回复。这种模式类似于十年前 SOC 2 的轨迹：最初是可选的交付物，随后变成频繁被要求提供的文档，现在已成为大多数企业交易中的合同交付物。AIBOM 正在以更快的速度重走这一曲线。你客户的采购团队不会等待行业标准统一。他们现在就在问，没有答案的团队会输给有答案的对手。

共同作用的结果是，AIBOM 不再仅仅是合规团队的问题，而变成了销售工程问题。在续约前八个月，采购部门的某人会索要依赖树。能在 20 分钟内通过插桩导出的团队获胜。必须开启一个 Slack 讨论组来查找答案的团队则会失败，有时失败的原因甚至与实际的技术状况无关。

AIBOM 所要求的工程纪律

如果你的 AIBOM 不仅仅是一个快照，那么其背后的工程实践就必须落地。其中关键的几点或许并不时髦。

显式锁定模型版本值，绝不使用 latest。每个团队最终都会吸取这个教训；唯一的悬念是在生产环境中发生隐性行为变化之前还是之后。版本锁定是 AIBOM 中最基础的条目，没有它，你无法拥有真实可信的记录。

将提示词视为带有注册表的配置，而非代码中的字符串。提示词是 AI 技术栈中最接近已部署交付物的东西，就像任何部署的交付物一样，它需要 ID、版本、所有者和晋升流水线。

维护具有功能范围（capability scope）的工具注册表，即便是“内部”工具也不例外。工程师上个季度添加的 MCP 服务器一旦暴露给与数据层对话的 Agent，就不再是“内部”的了。像对待任何其他可触达系统一样对其进行盘点，并设置明确的鉴权边界。

将数据集与带有溯源元数据的 Checkpoint 绑定。当微调运行生成 Checkpoint 时，记录输入数据集的版本、哈希和许可协议——不仅仅是在 MLflow 中记录，还要以 AIBOM 生成器随后可以提取的方式记录。审计员的问题不是“你用了什么训练”，而是“请向我展示当前承载流量的每个 Checkpoint 的谱系”。

使 AIBOM 支持按需导出。把它当作数据库查询，而不是 Word 文档。成功的标准是“我们能在五分钟内生成当前的 AIBOM”。如果生成 AIBOM 需要开会讨论，那么它还不足以支撑业务。

大多数团队最后才意识到的事实

定位陷阱在于将 AIBOM 视为一种合规练习 —— 也就是 GRC 团队在进行审计时的某种操作。这是十年前各团队在处理 SBOM 时犯过的同样错误，其代价也如出一辙：工具是事后补齐的，永远处于过期状态，只对审计有用，对工程决策毫无价值。

获益最多的团队将 AIBOM 视为工程基础设施，而合规只是顺带满足的需求。用于管控 Prompt 发布的同一个注册表，也能给审计员提供答案。在延迟仪表盘中捕获模型版本漂移的同一套遥测系统，也能生成库存清单条目。防止工程师将未经审计的 MCP 服务器接入 Agent 的同一个工具注册表，正是你客户的采购团队想要看到的交付物。

当 AIBOM 以这种方式构建时，第一次有人要求“展示你的依赖树”就不再是一场突击演习，而仅仅是一次查询。已经运行该查询的团队可以将合规带宽花在真正重要的事情上，而那些仍在翻找 Slack 聊天记录的团队，则不得不向法务解释为什么回答客户的一个问题需要两周时间。

AIBOM 规范从根本上来说是一场赌注，即随着时间的推移，你的 AI 技术栈将越来越频繁地接受检查 —— 无论是来自监管机构、客户，还是你自己的事件响应团队。现在参与这场赌注的团队，正在为自己赢得一个更从容的 2027 年。