AI BOM Disclosure: The OWASP and SPDX Standards for AI Procurement

Why AI BOM Is Now Table Stakes for Procurement

Procurement questionnaires in 2026 routinely ask what AI a vendor uses, which foundation models sit beneath its product, what data was used to train or fine-tune those models, and which third-party components carry redistribution constraints. Vendors that answer these questions in prose rather than in a structured disclosure schema are offering unsubstantiated assurances. Buyers cannot diligence them, regulators cannot verify them, and downstream customers cannot rely on them. The fix is an AI Bill of Materials (AI BOM, also written AIBOM): a standardized, auditable record of the datasets, weights, and methodologies underpinning a modern AI model.

Two complementary standards now anchor that disclosure layer. The OWASP AIBOM initiative provides the conceptual framework, organizing AI system disclosures into six asset domains. The Linux Foundation's SPDX 3.0.1 AI Profile provides the machine-readable schema that lets those disclosures travel through procurement, security, and supply-chain tooling. As IBM Research has observed, both Linux and OWASP are now extending their SBOM standards to AI, signaling convergence rather than fragmentation across the open-standards community.

The regulatory floor arrived on January 1, 2026. California AB 2013 applies to any developer that, in Goodwin's reading of the statute, “designs, codes, produces, or creates a new version, release, or update that materially changes functionality or performance, including through retraining or fine-tuning, of a generative AI system or service for use by members of the public.” Fine-tuning a public-facing model now triggers disclosure obligations. Vendors selling into California cannot opt out by labeling themselves integrators rather than developers.

The market has caught up to the standards. The IAPP's 2026 AI Governance Vendor Report segments the governance market into policy and compliance, technical assessments, assurance and auditing, and consulting and advisory tooling — a maturity profile in which buyers expect demonstrable governance artifacts rather than policy claims alone. AI BOM is the procurement-side mirror of vendor capability claims: without it, a buyer cannot answer the next inquiry from its own customers, a state attorney general, or an EU AI Act conformity assessor about what is actually running inside its stack.

The OWASP AIBOM Six-Domain Framework

OWASP organizes the AIBOM around six asset domains that together describe an AI system end-to-end: models, datasets, code, hardware, data processing, and governance. IBM Research, working alongside the OWASP effort, articulates this same six-domain enumeration as the conceptual scope of an AI Bill of Materials. The OWASP AIBOM project frames the goal as transparency into how AI models are built, trained, and deployed — making AI systems auditable, traceable, and trustworthy by documenting model lineage, training data, risks, and dependencies, analogous to how SBOMs brought clarity to software supply chains.

OWASP supplies the conceptual taxonomy and an open-source AIBOM Generator; the SPDX 3.0.1 AI Profile (covered in Section 3) supplies the machine-readable field specifications that operationalize the taxonomy. OWASP has not published a single canonical document enumerating exact field names per domain, so the field lists below reflect practitioner conventions consistent with OWASP's published scope and with the foundation-model-specific elements the project flags as in-scope: model weights, downstream applications, provenance of training data, the hardware a model trained on and will require to run, and LLM-specific behavior whose outputs vary by prompt phrasing.

The six domains

1. Models. Name, version, architecture family, parameter count, intended use, and known limitations. For foundation models, OWASP's scope also contemplates model weights and the downstream applications a model is approved to support.
2. Datasets. Source, licensing status, size, known biases, sensitivity classification, and anonymization or de-identification posture. Provenance of training data is explicitly within OWASP's foundation-model scope.
3. Code. Dependencies, versions, licenses, and vulnerability disclosure posture for the software that trains, serves, and orchestrates the model.
4. Hardware. GPUs, accelerators, and deployment infrastructure where material — both the hardware the model trained on and what will be required to run it in production.
5. Data Processing. Pipelines, feature engineering, and preprocessing methods that transform raw inputs into model-consumable form.
6. Governance. Policies applied to the system, audit posture, and alignment with frameworks such as the NIST AI RMF and ISO/IEC 42001.

The OWASP Gen AI Security Project's AI SBOM Initiative frames its mandate as delivering open, standardized approaches to AI supply chain transparency and security by operationalizing the AIBOM concept. That operationalization — turning the six-domain taxonomy into structured fields a vendor can populate and a buyer can validate — is where SPDX enters the picture. Promise Legal advises clients drafting AI vendor diligence requirements to anchor procurement language in the six domains first, then layer SPDX field requirements on top. Section 3 walks through how SPDX 3.0.1's AI Profile maps to each domain.

SPDX 3.0.1 AI Profile: The Machine-Readable Schema

Where OWASP AIBOM defines what to document, the Linux Foundation's SPDX 3.0.1 AI Profile defines how to encode it. The specification states that the AI Profile is “designed to provide a standardized way of documenting and sharing information about AI software packages,” covering “a set of concepts and data elements related to AI system and model artifacts—the tangible outputs of the AI development process, such as software packages, models, and datasets.” That machine-readable framing is what separates SPDX from a narrative disclosure.

The AI Profile describes an AI component's capabilities for a specific system—domain, model type, and applicable industry standards—and details its usage within the application, limitations, training methods, data handling, explainability, and energy consumption. Each of those is a distinct field, not a paragraph, which means a procurement team can query a vendor's declared limitations or training methodology programmatically rather than parsing prose.

The companion SPDX Dataset Profile handles training and evaluation data. Its DatasetPackage fields include:

• anonymizationMethodUsed — technique applied to remove or obscure identifiers
• confidentialityLevel — sensitivity classification of the dataset
• dataCollectionProcess — how the data was gathered
• dataPreprocessing — transformations applied before training
• datasetAvailability — access and licensing posture
• datasetNoise — known quality and labeling issues
• datasetSize — volume of records or examples
• datasetType — structural classification (image, text, tabular, etc.)

Both profiles share a common floor of mandatory identification fields: spdxId, name, buildTime, downloadLocation, packageVersion, primaryPurpose, releaseTime, and suppliedBy. Those fields are what make an AI BOM behave like a conventional SBOM—each artifact has a stable identifier, a version, and a chain of custody.

The compliance payoff is operational. SPDX.dev describes the SPDX 3.0 AI and dataset profiles as offering “detailed, machine-readable documentation of AI systems” suited to regulated workflows. In practice, that means buyers can ingest vendor disclosures through existing supply-chain tooling, diff successive versions to detect material changes, and feed the output into audit pipelines without re-keying data. CycloneDX ML-BOM offers an interoperable alternative format that “represents datasets, models, and configurations for AI and machine learning systems,” and most enterprise SBOM platforms consume both. The implementation pattern is straightforward: the vendor publishes the AI BOM in SPDX (or CycloneDX) format, the buyer consumes it through standard supply-chain tooling, and updates are version-tagged and diffable against prior releases.

California AB 2013: The Regulatory Floor

California AB 2013, signed September 28, 2024 and effective January 1, 2026, requires developers of generative AI systems or services made available to the public since January 2022 to publicly post a high-level summary of the datasets used to train those systems. The statute enumerates twelve categories of disclosure that any covered developer must publish.

The enumerated categories require, in summary: (1) dataset sources or owners; (2) how the datasets further the system's intended purpose; (3) the number of data points, expressible in ranges or estimates for dynamic datasets; (4) the types of data points and labels where applicable; (5) whether the datasets include copyrighted, trademarked, or patented material, or are entirely public domain; (6) whether datasets were purchased or licensed; (7) whether they include personal information as defined in Civil Code section 1798.140(v); (8) whether they include aggregate consumer information under section 1798.140(b); (9) whether the developer cleaned, processed, or otherwise modified the data; (10) the collection time period, with notice if collection is ongoing; (11) dataset usage dates during development; and (12) whether synthetic data generation was used or is continuously used.

The disclosure obligation refreshes whenever a developer designs, codes, produces, or creates a new version, release, or update that materially changes functionality or performance, including through retraining or fine-tuning, of a system available to the public. Material modifications are not free passes from disclosure; they are triggers for it.

For procurement, the operational point is that these twelve categories largely map onto the OWASP AIBOM Datasets domain and the SPDX 3.0.1 Dataset Profile fields covered in Section 3, including anonymizationMethodUsed, dataCollectionProcess, dataPreprocessing, and datasetAvailability. A well-designed AI BOM should therefore satisfy most or all of AB 2013's disclosure requirements as a byproduct of the underlying inventory work. Procurement teams should require the AI BOM as the compliance artifact rather than treating AB 2013 as a separate workstream — and should review Promise Legal's broader AI regulatory compliance guidance when scoping vendor obligations across jurisdictions.

Procurement Implementation: Making AI BOM Work

Translating the standards above into procurement practice requires three concrete moves. None of them are exotic, but skipping any one leaves the buyer holding regulatory risk it cannot discharge.

1. Add AI BOM disclosure to the procurement questionnaire. Require vendors to deliver an AIBOM covering the six OWASP asset domains at minimum, with the SPDX 3.0.1 AI Profile as the preferred schema because machine-readable documentation is what scales for compliance review.
2. Tie the AI BOM to the contract. A questionnaire response is a marketing artifact until it is bound by the agreement. The disclosure obligation, update cadence, and breach consequences belong in the AI vendor contract itself — see Promise Legal's breakdown of the eight clauses missing from most AI vendor templates for the contract-side hook that makes AI BOM disclosure enforceable rather than aspirational.
3. Build internal tooling to consume and diff vendor AI BOMs. Vendor-delivered AI BOMs are frequently incomplete or inaccurate, so buyers cannot treat ingestion as a passive step. The OWASP AIBOM Generator is a reasonable open-source reference implementation to anchor an internal validator against. The diff layer, run across the vendor portfolio, becomes the buyer's own enterprise-level AI BOM — the upstream artifact that lets the buyer answer downstream California AB 2013, sectoral, and acquirer inquiries without re-interrogating each vendor.

For acquisition-side counsel, the same disclosure spine carries into representation and warranty architecture; Promise Legal's analysis of lawful training corpus warranties post-Bartz walks through how AI BOM-grade disclosures translate into deal reps. The procurement questionnaire, the contract clause, and the internal diff tool are the three artifacts that move AI BOM from standard to operational control.