AI Bill of Materials (AIBOM): What NTIA, NIST, and EO 14110 Require - and What to Ship Now

An AI Bill of Materials (AIBOM) is a structured, machine-readable inventory of every component that contributes to an AI system - foundation models, fine-tuned variants, training datasets, embeddings, vector stores, evaluation suites, and the software dependencies that surround them. The federal anchor is NTIA's Minimum Elements for an SBOM (July 2021), the AI-extending standards are NIST AI 100-1 (January 2023) together with SPDX 3.0 and CycloneDX 1.6, and the regulatory pressure point is Executive Order 14110 (October 2023) reporting obligations for frontier models. This playbook covers what to ship now - the formats, the fields, the CI integration, and the contractual asks for AI vendors. Updated 2026-05-20.

An SBOM lists software components; an AIBOM lists software, data, and model components. The structural difference is that AI systems carry three additional categories of dependencies that have no clean analogue in classical software:

• Models and weights. Foundation models, fine-tuned checkpoints, LoRA adapters, quantised variants. Each is a unique component with its own provenance, license, and risk profile.
• Training data and evaluation data. Datasets used at pre-training, fine-tuning, RLHF, and evaluation. The license, consent basis, and known biases of each dataset propagate to the resulting model.
• Embeddings and vector stores. Vector indices created from proprietary data are a distinct asset that an AI system depends on; they often contain personal data or trade secrets and require their own lifecycle.

The NTIA SBOM Minimum Elements (supplier, component name, version, unique identifier, dependency relationship, author of the SBOM, timestamp) translate cleanly to AI components, but the data and model categories also require new fields - training-data lineage, evaluation metrics, license-for-output, and the model's safety classification. SPDX 3.0 and CycloneDX 1.6 both ship AI/ML profiles that codify these new fields.

The trap to avoid: shipping an SBOM that excludes the model and pretending it is an AIBOM. The whole point of an AIBOM is to give a procurer or auditor a complete picture of the AI system's supply chain, including the parts that are not software. Areebi customers ship one consolidated AIBOM per deployed AI system.

The 2021 NTIA Minimum Elements are still the federal baseline. The table below maps each element to its AI-adapted form, with concrete examples of what a CISO should expect to see in an AIBOM record.

Areebi's compliance team operationalises this mapping by requiring every AI vendor to deliver an SPDX 3.0 or CycloneDX 1.6 document with the AI profile fields populated. The policy engine refuses to register an AI vendor without an AIBOM attached.

SPDX 3.0 (April 2024) introduces an explicit AI profile that adds AI-specific classes on top of the core SPDX model. The key classes a CISO will see in a well-formed SPDX 3.0 AIBOM are AIPackage, DatasetPackage, and the relationships between them. The field-level expectations:

• AIPackage. Includes typeOfModel (eg. language model, image model), modelExplainability, energyConsumption, safetyRiskAssessment, useSensitivePersonalInformation, standardCompliance (eg. NIST AI 100-1, ISO/IEC 42001), limitation, hyperparameter list, modelDataPreprocessing, intendedUse, and informationAboutTraining.
• DatasetPackage. Includes datasetType (eg. training, evaluation, fine-tuning), datasetSize, datasetUpdateMechanism, sensor used to collect, sensitivePersonalInformation, anonymisationMethodUsed, knownBias, intendedUse, and confidentiality level.
• Relationships. trainedOn, fineTunedFrom, evaluatedOn, deployedWith, hasPackagePurpose. These relationships are how an AIBOM expresses the dependency graph of an AI system.

Source: SPDX 3.0 specification published April 2024 by the Linux Foundation under ISO/IEC 5962:2021 framework. The Areebi platform stores the parsed SPDX 3.0 document per vendor and exposes it to procurement, security, and audit teams via the audit log.

CycloneDX 1.6 (March 2024) ships an ML-BOM extension with a typed component model that is more procurement-friendly than SPDX 3.0 for some teams. The component types relevant to AI:

• component type=machine-learning-model. Captures the model identifier, version, and a structured modelCard subobject covering modelParameters, datasets, considerations (ethical, fairness, environmental), and quantitativeAnalysis (performance metrics, fairness metrics).
• component type=data. Captures dataset metadata - name, type, source, license, contents, governance, sensitivity, classification.
• component type=cryptographic-asset. Useful for model signatures and dataset hashes, allowing supply-chain integrity verification.

Source: CycloneDX v1.6 specification published by OWASP/CycloneDX Working Group in March 2024. The practical advantage of CycloneDX over SPDX 3.0 for many teams is that the modelCard subobject mirrors the Model Cards proposal from Mitchell et al (2019), so security and ML teams can reuse existing model card content directly.

Executive Order 14110 (Safe, Secure, and Trustworthy Development and Use of AI, October 30, 2023) imposed a set of reporting obligations on developers of dual-use foundation models and the federal contractors who depend on them. The relevant Section 4.2(a)(i) defines the threshold (models trained using a quantity of computing power greater than 10^26 integer or floating-point operations, or biological sequence models above defined thresholds) and requires:

• Notification of red-team test results. Developers must report the results of red-team testing of dual-use foundation models to the federal government.
• Information about training runs. Developers must report the location, scale, and ownership of compute clusters used for training above-threshold models.
• Information about cybersecurity protections. Developers must report on cybersecurity protections for training pipelines and model weights.

The status of EO 14110 in 2026 is itself a moving target - portions have been adjusted under subsequent executive action - but the operational expectation has not changed: federal contractors are expected to be able to produce AIBOM artefacts on demand to demonstrate the integrity, provenance, and safety profile of any AI system used on federal data. The Areebi OMB M-24-18 federal contractor checklist walks through the operational pattern.

The licence dimension of an AIBOM is where many teams stumble. Foundation models ship under a wide range of licences (Llama Community License, Apache 2.0, MIT, OpenRAIL, custom commercial), datasets often have ambiguous or undocumented licences, and the resulting compositions can create derivative-work obligations that the deploying organisation never reviewed.

ISO/IEC 5230:2020 (OpenChain Specification) is the conformance standard for open-source licence compliance programmes. Procurement and legal teams treating ISO/IEC 5230 as the baseline for software licence governance should extend it to AI components. The Areebi platform stores the parsed licence for every AI component in the AIBOM and surfaces conflicts (eg. a non-commercial-licensed model used in a commercial product) to legal review.

The AIBOM should be a build-time artefact, not a periodic spreadsheet. The pattern Areebi customers ship in production:

1. Inventory the components. Every model, dataset, embedding store, evaluation suite, and inference dependency in the build is registered in a manifest file (typically YAML).
2. Resolve provenance. CI fetches the SPDX or CycloneDX document for each upstream component (model card, dataset card, vendor SBOM) and stitches them into the build manifest.
3. Hash and sign. Each component's content hash is computed and verified against the supplier's published hash. The resulting AIBOM is signed with the build system's key.
4. Publish. The signed AIBOM is published to an artefact store and attached to the release. Areebi's audit log records the AIBOM hash so an auditor can verify the AIBOM that was actually shipped.
5. Diff on every release. CI diffs the new AIBOM against the previous release and fails the build if there are unapproved changes (new dataset, new model variant, licence drift).

The Areebi compliance team designs this control so the AIBOM is treated as a release artefact with the same rigour as the signed binary.

Most procurement teams sign AI vendor contracts without an AIBOM clause. That is the single biggest unforced error in 2026 AI procurement. The clauses Areebi recommends:

• SBOM/AIBOM delivery. Vendor delivers a current SPDX 3.0 AI profile or CycloneDX 1.6 ML-BOM document for every model version. Initial delivery within 30 days; updates within 14 days of any material change.
• Training-data warranty. Vendor warrants that training data was obtained on a lawful basis and that the vendor can identify the sources to the customer on request. This is the operational answer to the EDPB Opinion 28/2024 cross-phase contamination doctrine (see our EDPB Opinion 28/2024 playbook).
• Red-team evidence. Vendor delivers summary red-team and evaluation results for safety-relevant test suites (eg. red-teaming guide).
• Licence transparency. Vendor lists the licence of every model, dataset, and evaluation component that ships in the AIBOM, including any third-party licences that propagate.
• Notification of material change. Vendor notifies customer of any material change to the model architecture, training data, or safety profile.

Areebi's vendor onboarding workflow captures each of these as gating conditions; the policy engine refuses to enable an AI vendor that has not delivered the required artefacts.

NIST AI 100-1 (AI RMF 1.0, January 2023) does not mandate an AIBOM, but every function in the AI RMF assumes one. The mapping below is what Areebi customers use to defend their AI RMF programme to auditors.

The Areebi NIST AI RMF hub and the function-by-function deep dives (Govern, Map, Manage) walk through the auditor's checklist.

An AIBOM is not a compliance artefact - it is a control surface. Once you can enumerate every model, dataset, and embedding store in your AI estate, you can enforce policy on each one: licence checks, data residency, training-data lineage, red-team evidence, and notification of material change. Areebi's policy engine treats the AIBOM as the source of truth for what an AI system actually contains, and refuses to let a vendor or model into production without a complete, signed, current AIBOM. This is the single highest-leverage control we have shipped to regulated customers in the past year, and the reason most enterprise AI security questionnaires now lead with an AIBOM question.