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

> Exactly what to capture in an AI Bill of Materials (AIBOM) — models, datasets, AI/ML dependencies, configuration, and risk metadata — mapped to CycloneDX ML-BOM and SPDX 3.0 AI Profile, with a copy-paste checklist and the free tools to generate and validate one.

Source: https://playciso.com/blog/aibom-parameters-checklist · Published: 2026-10-02 · Publisher: PlayCISO (https://playciso.com)

---

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](https://cyclonedx.org/capabilities/mlbom/) and the [SPDX 3.0 AI Profile](https://spdx.dev/). New here? Start with [what an AIBOM is and why it matters](/blog/what-is-an-aibom-ai-bill-of-materials), and the [SBOM vs AIBOM vs MLBOM](/blog/sbom-vs-aibom-vs-mlbom) distinction. This post is the "what fields" companion to our [how to build an AIBOM](/blog/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 →](/tools/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](/blog/aibom-tools-vendors-compared-2026) that produce them, and read [what an ML-BOM is](/blog/ml-bom-explained) for the model-specific layer. _Build your first one now with the free [AI BOM generator](/tools/aibom), validate it with the [AIBOM Validator](/tools/aibom-validator), and keep up with AI supply-chain security in [PlayCISO AI Labs](/ai-labs)._