某制造商在生产线上部署了一款基于人工智能的检测工具。在供应商更新模型后，该系统开始漏检缺陷。 这立即引发了一个网络安全问题：此次故障是源于普通的模型漂移、训练数据损坏、模型构建文件遭篡改、存在漏洞的开源组件、不安全的模型序列化格式，还是未公开的第三方 API？如果合同和文档中未明确标明模型、数据集、软件依赖项及更新历史，那么当生产中断、敏感运营数据泄露或客户要求解释时，该制造商可能无法回答这个问题。
该问题直接基于此前发表的两篇文章。我们Foley事务所同事最近发表的《强化供应链网络安全的5大策略》一文，探讨了供应商监管、事件响应规划以及“安全设计”等基础网络安全实践。我们此前发表的系列文章《制造业和供应链中人工智能预测性维护的合同策略》则解释了为何人工智能供应商协议往往未能反映制造业的实际情况。本文将更详细地探讨这些主题之间的一个重叠领域。 对于基于人工智能的制造系统而言，下一个网络安全合同方面的挑战在于：制造商能否充分了解人工智能供应链，从而识别、验证并保留系统组件、数据溯源及模型历史的相关证据。
AI-BOM 将一个熟悉的制造和网络安全概念应用到了人工智能系统中。制造商早已将物料清单（BOM）理解为构成产品的零部件清单，而网络安全团队也越来越多地使用软件物料清单（SBOM）来识别数字产品中的软件组件及其依赖关系。2026年，美国网络安全与基础设施安全局（CISA）及其七国集团（G7）合作伙伴发布了指导意见，将类似的供应链透明度原则应用于人工智能系统。 根据这一方法，AI-BOM 记录了影响 AI 系统运行的关键组件和依赖关系，包括模型及其版本、训练和微调数据集及其溯源信息、软件和基础设施依赖项、API 和外部服务，以及与网络安全、风险管理和供应链透明度相关的其他要素。模型溯源是与其相辅相成的概念。 通俗来说，它就是模型及其数据的保管链记录：它们来自何处、由谁修改、进行了哪些验证或安全测试，以及随时间推移如何追踪变更。这些记录共同作用，将原本不透明的AI工具转化为采购、法律、网络安全和运维团队在网络安全事件发生前后均可进行评估的对象。
AI 网络安全风险并不仅限于供应商的网络边界。一个面向生产环境的 AI 系统可能包含供应商应用程序、预训练模型、开源库、云端推理服务、客户提供的运营数据，以及供应商定期进行的重新训练。每一层都可能带来不同的网络安全风险，包括存在漏洞的代码、不安全的集成、不透明的数据流，或是由分包商或其他第三方控制的依赖项。
传统的供应商问卷调查或许能描述供应商的安全计划，但可能无法揭示AI产品中嵌入的开源模型、图像标注服务、第三方数据集、外部API或云端推理层。如果缺乏对AI物料清单（BOM）的组件级可视性，制造商可能无法确定应监控哪些依赖项、哪些漏洞需要修复，以及是哪一供应商关系导致了风险。
模型溯源旨在解决相关的完整性问题。美国国家标准与技术研究院（NIST）的对抗性机器学习分类法（NIST AI 100-2，2024年1月）指出，攻击者可能在学习过程中针对训练数据、模型参数或代码发起攻击，也可能通过规避、隐私或其他技术手段攻击已部署的模型。 新兴的供应链攻击途径——包括通过微调管道进行的模型中毒、不安全的模型序列化格式，以及针对下游集成的提示注入——进一步扩大了溯源记录必须协助应对的攻击面。换言之，恶意行为者如今不仅可以通过直接攻击模型来破坏AI系统，还可以通过篡改用于模型开发和部署的工具、数据管道及第三方服务来实施攻击。 如果模型开始漏检缺陷、错误分类库存、生成异常的维护建议，或泄露敏感的运营数据，溯源记录有助于确定问题源于受损的训练数据、遭篡改的模型工件、版本变更，还是普通的模型漂移。如果没有这些记录，因果关系将沦为猜测，责任归属也将难以界定。
制造商和供应链经理应在供应商协议中明确规定人工智能网络安全透明度相关条款，而非仅依赖一般性的安全条款。以下条款可能特别有用：
1. 明确所需的人工智能物料清单（AI BOM）。合同应明确规定人工智能物料清单的最低内容要求，包括模型、软件依赖项、数据集或数据集类别、API、云服务、更新机制以及与安全相关的依赖项。 与传统软件物料清单（SBOM）不同——后者已有SPDX和Cyclone DX等成熟且被广泛采用的格式——AI-BOM标准仍处于起步阶段，且仍在不断演进。如果供应商无法直接披露某些细节，合同应要求采取替代方案，例如托管、第三方安全审查，或在加强保密保护措施下的分级披露。
2. 要求提供以网络安全为重点的模型溯源包。供应商应记录模型的来源、训练和微调历史、数据溯源、验证方法、安全测试以及已知的局限性。协议还应包含关于数据权利、许可以及用于保护模型和数据 artifacts 免遭篡改的控制措施的声明。
3. 将透明度转化为切实可行的网络安全义务。当供应商对模型进行重新训练、更改重要数据集、更换组件或修改更新管道时，应相应更新 AI 物料清单（AI-BOM）和溯源记录。合同应规定，在重大变更影响生产系统之前，供应商须提前通知，尤其是在这些变更可能影响网络安全监控、数据泄露、漏洞管理或事件响应的情况下。
4. 将信息披露与网络安全问责制挂钩。供应商应声明其人工智能物料清单和来源记录在实质上准确且完整。此外，若因文档不准确导致系统故障，供应商还应向制造商通报受影响的组件、不受支持的依赖项、数据完整性问题或影响人工智能组件的漏洞，并应赋予制造商审计和合作权利。
5. 转嫁人工智能透明度要求。许多人工智能供应商依赖分包商、云服务提供商、标注服务商、基础模型提供商或开源组件。合同应规定转嫁义务，以便供应商能够获取维护人工智能物料清单和溯源包所需的组件、数据及模型信息。
6. 将文档用于网络治理和可辩护性。AI-BOM 和溯源包应纳入采购审查、IT/OT 风险评估、事件分析、漏洞管理、合规准备以及 AI 治理计划中，包括符合 ISO/IEC 42001 标准的计划。对于制造商而言，这些文档正日益成为用于证明其采取了合理的安全措施、实施了供应商监督、具备网络安全事件响应准备能力以及根因分析能力的记录组成部分。然而，这些记录的证据价值取决于合同中关于准确性、更新频率、保留期限及独立验证的要求。仅凭供应商的自我声明，可能无法提供足以应对高风险诉讼、监管审查或取证调查的、可独立验证的记录。
那些仅询问人工智能供应商是否“安全”的制造商，可能会忽略一个更重要的网络安全问题：我们能否识别、验证并证明人工智能系统中包含什么内容，以及这些内容是如何进入系统的？ 随着美国网络安全与基础设施安全局（CISA）、美国国家标准与技术研究院（NIST）、ISO/IEC 42001标准、《欧盟人工智能法案》的透明度要求以及国际监管机构纷纷推动提升AI供应链透明度，那些在与供应商的合作关系中明确纳入AI物料清单和模型溯源义务的制造商及供应链管理者，将更能有效识别网络风险、评估供应商表现、保留事件证据，并在AI系统出现故障时明确责任归属。
Foley公司的制造、供应链、网络 安全和人工智能团队可协助制造商和供应链经理，针对生产和供应链环境，制定人工智能供应商尽职调查方案、人工智能物料清单要求、模型溯源义务，以及侧重网络安全的合同保护条款。
