AI 物料清单：追踪实际运行的内容

AI 物料清单只有在能够回答两个问题时才有用：部署前声明了什么，以及在某次决策、事故或审计发生时，实际上运行了什么。一个无法同时回答这两个问题的有效 JSON 文件，只是在进行库存表演。

实用的设计是配对清单。在构建或采购期间生成基于标准的记录，在运行时观察实时系统，为每个字段保留证据，并对两者进行差异比较。当关键模型、数据集、运行时、API、代理工具或许可证未解决时，阻止发布。

读者级别： 高级。本指南面向运营基于模型的系统的工程师、安全团队、平台负责人和技术治理负责人。

目录

AI 物料清单应回答什么问题

AI 物料清单通常简称为 AIBOM 或 AI BOM，是 AI 系统组件及其背后证据的机器可读清单。它将传统软件物料清单从软件包和库扩展到了更多内容。

清单应让审查人员能够回答：

CycloneDX 介绍了其 AI/ML-BOM 能力，用于表示模型、数据集、配置、来源和依赖项。SPDX 3.0.1 也定义了 AI 配置文件，用于 AI 专属元数据。这些是可互操作的数据模型，但不能替代缺失的证据本身。

模型卡回答的是一个更窄的问题：这个模型 intended 做什么、如何评估，以及可能在哪些地方失败。最初的 Model Cards 论文提出了涵盖预期用途、评估条件以及相关群体表现的文档。数据卡记录数据集的来源、收集和标注、预期用途，以及影响下游性能的决策；Data Cards 论文总结了 20 多次部署中的经验。

两者都应保留。模型卡或数据卡提供人工上下文。AIBOM 则将这些文档连接到版本化的系统清单。

为什么有效的 AIBOM 文件仍可能包含薄弱证据

一项发表于 2026 年 7 月的研究大规模测试了这种区别。作者收集了 2,942,466 条公开 Hugging Face 模型记录的快照，保留了下载量超过 100 次的 97,940 个模型，并使用 OWASP AIBOM Generator 生成 CycloneDX AIBOM。他们根据生成器的报告检查了 100 个工件的样本，然后测量了完整数据集中的字段存在情况。

报告的平均完整度得分为 54.31（满分 100）。生成工件中必需的结构字段存在率为 100%。模型卡文档的平均存在率为 19.51%。

这个差距才是重要结果。文件在结构上可以有效，但决策所需的信息可能缺失。

字段级结果更加明显：

描述字段几乎出现在每个工件中，但 97,940 条描述中只有 211 条包含超出占位文本的信息。模式存在性检查会将其余描述也计为完整。

作者测量了什么： 从经过筛选的公开 Hugging Face 快照生成的 AIBOM 中，字段和类别的覆盖率。

作者推断了什么： 模型卡和外部引用文档在很大程度上造成了薄弱工件与更强工件之间的差异。

作者没有确立什么： 任何模型是否安全、公平、性能良好、法律上可用，或适合特定部署。

作者还警告说，他们的结果取决于 Hugging Face API、生成器提取逻辑，以及排除下载量不超过 100 次模型的快照。私有注册表、受限模型、其他托管平台以及之后的仓库变化可能呈现不同结果。他们的结果支持语义验证，但并未设定通用的分数阈值。

构建时清单和运行时清单解决的是不同问题

构建时 AIBOM 记录意图。运行时清单记录观察结果。

仅有构建时证据会遗漏紧急变更、影子部署、可变标签、提供商重新路由和配置漂移。仅有运行时观察则可能只能看到进程名称或端点，却不知道其已批准用途、许可证、训练来源或评估边界。

Google 于 2026 年 7 月 14 日开源了 k8s-aibom，用于探索运行时侧。该控制器监视 Kubernetes 工作负载和 Pod 状态，应用检测规则，并生成 CycloneDX 1.6 ML-BOM 文档。其文档化覆盖范围包括推理运行时、代理框架、向量数据库、训练任务和评估工具链。它无需特权 DaemonSet 或内核访问权限即可运行。

该项目提出了一个有用的架构观点：构建时和运行时 AIBOM 是互补的。它也仍属于早期软件。仓库将 v1.0 标记为 alpha，适用于非关键的观察场景。它没有提供托管镜像或 Helm 仓库，其当前的 `NoopVerifier` 也无法将身份标记为经过加密验证。

一位 NVIDIA AICR 维护者提出了 k8s-aibom 与 AICR 的集成方案，希望将 k8s-aibom 的运行时观察结果与 AICR 的部署意图和签名证明连接起来。作者将目标描述为证明团队部署的内容就是系统正在运行的内容。该 issue 没有关联的实现、负责人或里程碑。应将其视为实践者提案，而不是官方路线图或已完成的设计。

不要将一个新控制器变成通用的产品推荐。应采用这一模式：将声明状态与观察状态配对，保留证据，并让不确定性可见。

_实用的 AI 物料清单将构建意图连接到运行时证据、语义检查和版本化决策。_

值得记录的七个层面

确切的 schema 取决于你的标准和部署方式。以下层面构成了生产清单的实用最低要求。

1. 模型身份

记录供应商、模型系列、不可变修订版本或摘要、格式、基础模型、适配器、量化方式、分词器和服务路由。诸如 `support-model` 这样的友好别名便于人们使用，但不足以支持可追溯性。

对于外部 API，记录提供商的稳定模型标识符，以及选择该模型的网关路由。如果提供商可以在别名背后静默更新模型，应将修订版本标记为未解决，而不是虚构精确性。

2. 数据和检索依赖项

在信息存在时，记录声明的训练、微调、评估和校准数据集。对于 RAG 系统，添加源集合、嵌入模型、分块版本、向量存储服务、访问策略和新鲜度边界。

存储数据集标识符、版本、哈希、合同或受控目录引用。不要将原始客户记录或私有训练示例复制到 AIBOM 中。

3. 运行时和软件

将 AI 清单连接到普通 SBOM。记录容器摘要、推理引擎、框架、相关库、驱动和加速器类别，以及可能改变模型行为的配置。

4. 工具、API 和代理权限

列出代理能够访问的工具，而不是公司某处安装的所有工具。包括模型网关、MCP 服务器、浏览器或代码执行工具、外部 API，以及管理每项操作的策略引用。

5. 评估和运行限制

引用用于批准的确切评估集、评估器版本、阈值、日期和条件。记录已知失败模式、预期用途和排除用途、回退行为、监控负责人，以及该决策的到期日期。

不要只写“通过评估”而不提供测试身份。模型发生变化而结果字符串不变，是薄弱证据。

6. 权利、策略和来源

记录模型和数据集许可证、使用限制、再分发条款、源代码仓库、模型卡、数据卡、论文、批准和证明。来源受访问控制时，存储引用和哈希。

这一层支持审查，但不会决定法律问题。缺失或冲突的权利信息应转交给对该决策负责的人员。

7. 所有权和生命周期

每条记录都需要负责人、系统用途、环境、创建时间、观察时间、被取代版本和保留规则。没有所有权，清单就会变成一座被遗弃事实的档案库。

包括一个能够跨部署保持稳定的系统 ID。版本化 AIBOM 应展示发生了什么变化、谁接受了变化，以及哪些证据支持该决策。

将每条事实标记为已声明、已推断、已验证或未解决

AIBOM 应在字段级别携带证据状态。为整个文档设置一个标签会隐藏太多信息。

前三个标签描述了不同强度的证据。“已声明”不是“已验证”的较弱写法。供应商声明可能是训练数据唯一可用的来源，而镜像摘要则可以通过机械方式验证。

k8s-aibom 项目目前实现了 `declared`、`inferred` 和 `unresolved`，并为属性提供证据定位信息。其 README 将加密的 `verified` 状态列为未来路线图，而不是声称当前已经支持。在你自己的系统中也应保持这种诚实。

概念记录可以如下所示：

{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }

这是设计草图，不是符合 CycloneDX 或 SPDX 的文档。实际工件应使用所选标准的 schema 和验证器。

可复现的 AIBOM 工作流

第 1 步：定义系统边界

命名范围内的应用、环境、负责人和面向用户的决策。确定清单覆盖的是单个模型端点、代理工作流，还是完整产品。

“所有 AI”这样的边界无法测试。“生产支持代理，以及所有能够改变其回答或操作的服务”则可以。

第 2 步：收集构建和采购证据

生成普通 SBOM，解析模型和数据集标识符，捕获不可变摘要，并关联模型卡、数据卡、许可证、评估和批准记录。

OWASP AIBOM Generator 可以将 Hugging Face 元数据提取到 CycloneDX 1.6，并报告缺失字段。将其输出视为初始清单。大规模研究说明了为什么自动填充的字段仍需要内容检查。

第 3 步：生成标准文档

选择消费者能够解析的格式。CycloneDX 提供 AI/ML-BOM 能力和实现指南。SPDX 3 提供 AI 和数据集配置文件。

格式选择应遵循接收系统、策略引擎、证明流水线和客户要求。除非确实有消费者需要两种格式，否则避免维护两种格式。

第 4 步：补充自动化无法知道的信息

指定负责人填写预期用途、限制、数据集来源、评估条件、权利和风险决策。当字段对决策至关重要时，拒绝“N/A”“标准模型”或复制的营销文本等占位内容。

要求对未知值给出明确原因。“供应商不披露训练数据”比空数组更好的证据，因为它区分了工作缺失和信息不可用。

第 5 步：观察实时部署

通过可用的最小权限机制收集运行时模型 ID、镜像摘要、端点、连接的存储、代理工具和配置。在 Kubernetes 中，这可能是一个监听 API 的控制器。在托管 API 技术栈中，这可能是网关配置、部署清单、提供商响应和审计日志。

当扫描器只是匹配了一个字符串时，不要声称完成了运行时验证。应将其标记为已推断，并保留匹配证据。

第 6 步：验证语法、语义和漂移

运行三项独立检查：

第一项检查可以自动化。第二项需要领域规则，某些字段还需要人工审查。第三项需要版本化记录和稳定的比较边界。

第 7 步：签名、存储、比较差异并设置到期时间

对工件进行哈希，将其绑定到构建或部署，存储在追加式或受控的证据系统中，并生成可供人阅读的差异报告。AIBoMGen 是一个研究原型，在训练期间结合模型和环境捕获、哈希、签名以及 in-toto 证明。

签名可以保护创建后的完整性，但不会让不完整或虚假的声明变成真实。

设置到期或审查日期。上季度完美的清单并不能描述今天可变的生产系统。

将清单转化为发布门禁

当清单能够改变决策时，它才真正有用。应在发布窗口之前定义策略。

根据系统调整严重性。写作助手和医疗决策工具不应共享一个通用阈值。

跟踪四项运营指标：

不要优化已填充字段的数量。这会重现完整度研究揭示的确切失败模式。

排除机密和个人数据

AIBOM 很可能会在工程、安全、审计人员、客户和自动化系统之间流转。应将其视为清单，而不是机密存储。

不要包含：

通过 secret-manager 路径或逻辑标识符引用机密，但不要包含其值。通过受治理的目录 ID、版本、分类、负责人和完整性哈希引用敏感数据集。当完整工件的元数据本身也敏感时，应对其应用访问控制。

AIBOM 无法证明什么

AI 物料清单可以改善可追溯性，但无法证明：

7 月份的完整度研究测量的是文档覆盖率，而不是模型质量。k8s-aibom 仓库明确表示其输出不认证合规性。这两项限制都很重要。

将 AIBOM 用作从某项决策通往可检查证据的地图。将其与评估、授权、监控、事故响应、隐私控制和负责人的审查配合使用。地图能够告诉每位审查人员正在评估哪个系统，从而让这些流程更快。

常见问题

什么是 AI 物料清单？

AI 物料清单是 AI 系统背后模型、数据集、软件、运行时、工具、来源、限制和证据的机器可读清单。实用的 AIBOM 会标识不可变版本、负责人、未解决事实，以及已批准状态与实时状态之间的变化。

AI BOM 与 SBOM 相同吗？

不相同。SBOM 清点软件组件和依赖项。AI BOM 将该软件清单与模型、数据集、适配器、评估、预期用途、限制和运行时路由等 AI 专属组件连接起来。生产 AI 系统通常需要两者。

AIBOM 应该使用 CycloneDX 还是 SPDX？

使用下游工具和证据消费者支持的格式。CycloneDX 具有文档化的 AI/ML-BOM 能力；SPDX 3 具有 AI 和数据集配置文件。首先验证一种规范格式。只有在策略、客户或集成要求时，才添加第二种格式。

声明核查

来源