AI bill of materials (AIBOM): what to record and common mistakes

An AI bill of materials (AIBOM) is an inventory of the models, datasets, code and settings that make up an AI system. Record where each model and dataset came from, its version and hash, its license, and how it was trained and configured. The common mistake is recording names but not provenance.

What formats exist?

Two open formats cover this today.

CycloneDX calls its AI support ML-BOM. Its page says an ML-BOM represents datasets, models and configurations for AI and machine learning systems, and covers dataset provenance and ethical considerations, training methods, AI framework configuration, and risk areas such as bias, data integrity and model security.

SPDX 3.0 has an AI profile. Its namespace defines properties including autonomyType, domain, informationAboutTraining, informationAboutApplication, hyperparameter, limitation, metric, modelDataPreprocessing, modelExplainability, safetyRiskAssessment, standardCompliance, typeOfModel and useSensitivePersonalInformation, plus several energy consumption fields. The page also states that every AI package must have exactly one declared license and one concluded license relationship to conform.

OWASP points to both. Its supply chain entry (LLM03) recommends maintaining an up to date, accurate and signed inventory of components, evaluating AI BOM and ML SBOM options and starting with CycloneDX. Its poisoning entry (LLM04) says to track data origins and transformations with CycloneDX or an ML-BOM.

What should you record?

A practical minimum, mapped to the formats above:

• Model identity. Name, version or revision, publisher, and the exact source location.
• Integrity. File hash for each weight file, and signature details if available.
• Format. Serialization format, since some formats can run code on load.
• Type and purpose. Type of model, intended domain and level of autonomy.
• Training data. Datasets used, their sources, preprocessing and any known limits. Note whether sensitive personal information was used.
• Fine-tuning. Base model, adapters, who produced them and when.
• Configuration. Framework, hyperparameters and runtime settings that change behavior.
• Evaluation. Metrics, thresholds and known limitations.
• License terms. For the model and the datasets. OWASP recommends inventorying and auditing software and dataset licenses through BOMs.
• Risk notes. Safety or security assessment results and applicable standards.
• Owners and consumers. Who is responsible and which services use it.

What mistakes do teams make?

1. Recording the name but not the revision. "Model X" tells you nothing when the repository changes. Pin and record the revision and hash.
2. Leaving out data. Teams list models and forget datasets, fine-tuning data and retrieval sources, though OWASP treats data origin as central to poisoning defense.
3. Skipping adapters. OWASP notes that a malicious adapter can compromise a base model, and that collaborative merges add risk. An AIBOM that stops at the base model hides this.
4. Treating the model card as proof. OWASP says model cards document a model but do not verify its origin. Verify separately and record how.
5. Writing it once. An AIBOM that is not updated when the model changes is a historic document. Generate it in the pipeline.
6. Keeping it unsigned. OWASP calls for a signed inventory so tampering is detectable.
7. No link to the software SBOM. The inference service has libraries too. Keep the two inventories connected so one query finds both.
8. Forgetting the license fields. Missing license data often surfaces late, in a customer review.
9. Storing it where nobody looks. If the incident team cannot find it quickly, it does not help.

What to do

1. Pick one production AI system and list its models, datasets, adapters and retrieval sources.
2. Choose a format, CycloneDX or SPDX 3.0, and keep to it.
3. Add the fields above, starting with revision, hash and source.
4. Generate the record in your build or deployment pipeline, and sign it.
5. Link it to the system's software SBOM.
6. Review it when a model, dataset or adapter changes.
7. Test it with a drill: a model you use is reported as tampered with. How long to list every service affected?

Where Safeguard fits

Dependency inventory and reachability analysis cover the code that serves and trains your models. The model and data fields above come from your own pipeline and suppliers.

Quick check

Sources

• CycloneDX, ML-BOM capabilities
• SPDX 3.0.1 specification, AI profile
• OWASP, LLM03:2025 Supply Chain
• OWASP, LLM04:2025 Data and Model Poisoning

Last reviewed: 18 October 2026.