Picture a manufacturer’s artificial intelligence-powered quality-inspection system, one that has reliably caught defects for months, suddenly start missing critical defects after a routine vendor update. The operations team scrambles. Is it model drift? Corrupted training data? A compromised software component? An undisclosed third-party dependency? Without a clear map of the AI system’s internal components, there’s no fast way to identify the source of the failure or determine who’s responsible.

Across global supply chains, AI now drives predictive maintenance, inventory optimization, logistics routing and quality control. These systems also introduce a category of cyber risk that traditional security frameworks weren’t designed to address. But with these innovations, there’s also an increased risk. The components inside an AI system such as models, datasets, application programming interfaces, cloud services, and open-source libraries each represent potential attack surfaces that can be exploited, corrupted or compromised without detection.

AI bills of materials (AI-BOMs) and model provenance documentation address this visibility gap. Adapted from manufacturing and software security practices, these frameworks give supply chain leaders the tools to identify vulnerabilities, trace failures to their source and hold vendors accountable when AI systems fail.

A BOM is a comprehensive list of components, parts and materials that go into a finished product. In recent years, cybersecurity teams have applied the same principle to software, documenting the libraries, dependencies and code components inside digital products. The concept is now extending to AI. In 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and its G7 partners issued guidance applying supply-chain transparency principles to AI, acknowledging that AI systems present unique cyber risks that traditional security questionnaires fail to capture. Under this framework, an AI-BOM documents the key components and dependencies that influence how an AI system functions, including:

• Models and model versions; 
• Training and fine-tuning datasets and their provenance; 
• Software and infrastructure dependencies; 
• APIs and external services, and 
• Update mechanisms and security-relevant configurations.

Model provenance is the companion concept: essentially a chain-of-custody record for an AI model and its data. It documents where the model originated, who trained or modified it, what validation and security testing was performed, and how changes have been tracked over time. Together, AI-BOMs and model provenance records give procurement, security  and operations teams the documentation they need to evaluate AI systems before deployment, and to investigate effectively and after an incident.

AI cybersecurity risk doesn’t stop at the vendor’s network perimeter. A production-facing AI system may include a vendor-developed application, pre-trained foundation model, open-source machine learning libraries, cloud-hosted inference services, customer-provided operational data, and periodic vendor retraining cycles. Each layer introduces distinct cyber risks: vulnerable code, insecure integrations, opaque data flows or dependencies controlled by subcontractors and third parties invisible to the end user.

A traditional vendor security questionnaire may describe the vendor’s general security program, but it won’t reveal the specific open-source model embedded in the product, the third-party image-labeling service used to train it, the external API powering real-time inference, or the cloud provider hosting the model weights. Without this component-level visibility, supply chain leaders are flying blind, unable to determine which dependencies to monitor, which vulnerabilities demand immediate remediation, or which supplier relationship introduced the risk.

Model provenance addresses a related but distinct problem, which is integrity over time. The National Institute of Standards and Technology’s (NIST) adversarial machine learning taxonomy recognizes that attackers can target training data, model parameters, or code during the learning process, and can also attack deployed models through evasion, data extraction or manipulation. Emerging supply chain attack vectors, including model poisoning through fine-tuning pipelines, insecure model serialization formats and prompt injection targeting downstream integrations, further expand the attack surface. Attackers can compromise AI systems not only by targeting the model directly, but by tampering with the tools, data pipelines and third-party services feeding into development and deployment. If a logistics routing model begins generating inefficient paths, a predictive maintenance system starts missing equipment failures, or a demand forecasting tool produces anomalous recommendations, provenance records help determine whether the problem stems from corrupted training data, a compromised model artifact, unauthorized version change, or ordinary model drift. Without these records, establishing causation becomes nearly impossible.

Organizations deploying AI systems across their supply chains should build transparency and accountability requirements into procurement from the start. The following six steps provide a practical roadmap for ensuring AI vendors deliver the visibility necessary to manage cyber risk:

Require a comprehensive AI BOM. Before deploying any AI system, require the vendor to provide a detailed inventory of what’s inside: models and model versions, software dependencies, datasets or dataset categories, APIs, cloud services, update mechanisms and security-relevant configurations. Unlike traditional software BOMs, for which mature formats like Software Package Data Exchange (SPDX) and CycloneDX exist, AI-BOM standards are still evolving. If a vendor can’t disclose certain details due to intellectual property concerns, consider alternatives such as escrow arrangements, third-party security reviews, or tiered disclosure under enhanced confidentiality protections.

Demand model provenance documentation. Require vendors to document the model’s origin, training and fine-tuning history, data sources, validation methodology, security testing performed and known limitations. This documentation should include assurances regarding data rights, licensing compliance and the controls used to protect model and data artifacts from tampering throughout the development and deployment lifecycle.

Establish ongoing transparency obligations. AI systems change over time. AI-BOMs and provenance records should be updated whenever the vendor retrains the model, changes material datasets, swaps out components, or modifies update pipelines. Require advance notice of material changes, particularly those that may affect security monitoring, data exposure, vulnerability management or incident response procedures. Build these notification requirements into vendor agreements and procurement specifications.

Tie disclosures to accountability. Transparency requirements have limited value without accuracy assurances. Require vendors to stand behind their AI-BOM and provenance documentation with representations of completeness and accuracy. Vendors should also commit to promptly notifying customers of compromised components, unsupported dependencies, data integrity issues, or newly discovered vulnerabilities affecting AI components. Include provisions for audit rights and cooperation if inaccurate or incomplete documentation contributes to a security incident or operational failure.

Address the extended supply chain. Many AI vendors rely on subcontractors, cloud providers, data labeling services, foundation model providers or open-source components. Ensure that transparency requirements flow down through the vendor’s supply chain so they can obtain and pass along the component, data and model information needed to maintain complete and current AI-BOM and provenance records.

Integrate documentation into governance and risk programs. AI-BOMs and provenance packages should be incorporated into IT and OT risk assessments, vendor-management programs, incident response playbooks, vulnerability management workflows, and AI governance frameworks, including those aligned with ISO/IEC 42001. For organizations subject to regulatory oversight, this documentation forms part of the record used to demonstrate reasonable security practices, supplier oversight and root-cause analysis capabilities. The evidentiary value of these records depends on establishing clear requirements for accuracy, update frequency, retention, and independent verification.

Asking whether an AI vendor is “secure” is no longer sufficient. The critical question is whether the organization can identify, verify and prove what is inside its AI systems and how it got there. As CISA, NIST, ISO/IEC 42001, the EU AI Act and international regulators move toward greater AI supply chain transparency, organizations that embed AI-BOM and model provenance requirements into vendor relationships now will be best-positioned to detect emerging threats, evaluate vendor performance objectively, preserve evidence when incidents occur, and allocate responsibility when AI systems fail.

AI adoption across supply chains is accelerating, and so are the cyber threats targeting these systems. Organizations that wait for industry standards to fully mature or for a breach to force their hand will find themselves at a disadvantage with regulators, customers and insurers alike. The time to act is now. Establishing AI-BOM and model provenance requirements today convert opaque AI systems into auditable, manageable assets, and positions supply chain leaders ahead of the curve for one of the most consequential cybersecurity challenges of the next decade.

The authors are four attorneys with Foley & Lardner LLP: Chanley Howell is a partner and intellectual property lawyer; Vanessa Miller is a litigation partner and chair of the national Automotive Team; Leighton Allen is a technology transaction, cybersecurity, and data privacy attorney; and R.J. McVeigh is a commercial supply chain litigator.