AIBOM Parameters: The Field-by-Field Checklist Every AI Bill of Materials Needs

An AIBOM (AI Bill of Materials) is only as useful as the fields it captures. A document that lists "we use an LLM" is theatre; one that names every model, dataset, dependency, license and known risk is an asset you can audit, hand to a customer, or file with a regulator. This is the field-by-field checklist of what to put in one — and why each parameter earns its place — mapped to the two standards that matter, CycloneDX ML-BOM and the SPDX 3.0 AI Profile.

New here? Start with what an AIBOM is and why it matters, and the SBOM vs AIBOM vs MLBOM distinction. This post is the "what fields" companion to our how to build an AIBOM walkthrough.

Why the parameters matter

AIBOMs crossed from research artifact to procurement requirement: enterprise buyers now ask for one in due diligence, and high-risk-system documentation under regimes like the EU AI Act expects equivalent content. The value is entirely in the fields. A missing license field is how a non-commercial or copyleft model licence silently ends up in a paid product. A missing dataset provenance field is how training data you cannot legally use gets baked into a model. A missing version field is how you fail to answer "are we affected?" when a model or library has a disclosed vulnerability. Each parameter below exists because its absence has already burned someone.

The parameters, field by field

1. Models — every one, as a first-class component

Each base model and each fine-tune is its own component. Capture:

• Name & version — the exact model and revision/commit, so "are we affected?" has an answer.
• Source / registry — where it came from (Hugging Face repo, internal registry, vendor API), the single most important provenance signal.
• License — the model licence and any acceptable-use terms. This is the field that catches the silent licence trap.
• Model card / intended use — purpose, intended and out-of-scope uses.
• Architecture & size — family, parameter count, modality.
• Relationship — for a fine-tune, which base model it derives from.

2. Datasets — training and evaluation

• Name & source — each training and evaluation dataset and where it came from.
• License & usage rights — whether you may use it the way you are using it.
• Provenance — origin and collection method; synthetic vs. scraped vs. licensed.
• Sensitivity flags — PII, regulated or copyrighted content present in the data.

3. AI/ML code dependencies — the SBOM layer

An AIBOM still contains a normal SBOM underneath it: the frameworks and libraries (the ML stack, serving layer, orchestration) pinned to versions and licenses, so known-vulnerability and licence checks work exactly as they do for any software. Our AI Dependency Scanner → reads these from a manifest.

4. Configuration & runtime

• Training configuration — method (pre-train, fine-tune, LoRA, RAG), key hyperparameters where disclosable.
• Inference configuration — serving setup, context limits, tool/function access the model is granted.
• Deployment context — where it actually runs (cloud, on-prem, edge), because a model with tool access in production is a different risk than the same weights on a laptop.

5. Risk & assurance metadata

• Performance / evaluation metrics — how it was measured, on what.
• Bias & safety considerations — documented limitations and known failure modes.
• Known vulnerabilities (CVEs) — against the model, its loader, and its dependencies.
• Provenance & integrity — signing / attestation and a hash of the weights, so you can prove what you shipped. Pair this with a scan: our Model Risk Scanner → reads a Hugging Face model against risk policies before it enters your environment.

6. Document metadata & format

• Author, timestamp, version of the AIBOM itself, and the supplier it describes.
• A machine-readable standard — CycloneDX ML-BOM (machine-learning-model + data component types; common in security/CI-CD tooling) or the SPDX 3.0 AI Profile (model type, training methods, data handling, explainability, limitations, energy use; Linux-Foundation/ISO-rooted, often preferred for regulatory filings). A PDF is not an AIBOM — your tools cannot read it.

The copy-paste AIBOM checklist

Run this against any AIBOM you produce or receive:

• ☐ Every base model and fine-tune listed as its own component (name + version + source)
• ☐ A license on every model and every dataset
• ☐ Provenance for each model (registry/repo) and dataset (origin + collection method)
• ☐ Sensitive-data flags on datasets (PII / regulated / copyrighted)
• ☐ AI/ML code dependencies pinned to versions and licenses
• ☐ Training and inference configuration, and where the model runs
• ☐ Evaluation metrics and documented bias/safety limitations
• ☐ Known CVEs for the model, loader and dependencies
• ☐ Integrity: a weights hash and signature/attestation
• ☐ Document metadata (author, timestamp, supplier) in CycloneDX ML-BOM or SPDX 3.0 AI Profile — not a PDF

Generate and check an AIBOM free on PlayCISO

You do not need a platform licence to start. All of these are free, no signup:

• AI BOM generator → — turn a package.json or a models/datasets manifest into a CycloneDX-style inventory with a per-component licence-risk read.
• AIBOM Template → — a correct starting structure so no field is forgotten.
• AIBOM Validator → — check an AIBOM is structurally valid and complete.
• ML-BOM Converter → — produce a CycloneDX ML-BOM from your model/dataset inputs.
• AIBOM Diff → — see exactly what changed between two AIBOMs across releases.
• Model License Checker → — flag the non-commercial/copyleft licence before it ships.

Open-source examples to learn from (GitHub)

If you want real, working references for the fields above:

• OWASP AIBOM Generator — extracts model metadata from Hugging Face into a CycloneDX AIBOM and scores its completeness (a good model for which fields to fill).
• cdxgen (CycloneDX) — generates BOMs across many ecosystems and integrates into CI/CD and Dependency-Track.
• CycloneDX Tool Center and SPDX — the specifications themselves, which define every field precisely.

An AIBOM without these fields is a document; an AIBOM with them is a control. Capture the parameters, emit them in a machine-readable standard, and you can answer every supply-chain question a customer, auditor or incident will ever ask about your AI. Next: compare the AIBOM tools and vendors that produce them, and read what an ML-BOM is for the model-specific layer.

Build your first one now with the free AI BOM generator, validate it with the AIBOM Validator, and keep up with AI supply-chain security in PlayCISO AI Labs.