1. What is an AI SBOM?

An AI SBOM is a normal Software Bill of Materials, extended to cover AI and machine learning systems. A regular SBOM lists libraries, packages, versions and licenses. Think of it as the ingredient label for your code. An AI SBOM adds four extra things: Models and weights. Which model, what version, where it came from, its cryptographic hash. Training datasets. Source, license, version or snapshot date, bias audit notes if you have them. Inference engines. ONNX Runtime, TensorFlow, or PyTorch version, plus target hardware. Model cards. Performance bounds, known failure modes, drift metrics. I work on embedded and edge AI at ByteSnap Design. For us, the hash is non-negotiable. Without a hash, you can't later prove that the model you're looking at is the one that actually shipped.

2. What's created the need for AI SBOMs?

Three things. Supply chain attacks now target AI. Attackers upload backdoored weights to public hubs like Hugging Face, and they poison training data. Without an AI SBOM, you can't tell a trusted fine-tune from a malicious upload. This is happening now. Your dependencies have AI dependencies. You pull a library, that library pulls a tiny ONNX model for face detection, and three levels down that model has a known vulnerability in its preprocessing pipeline. A standard SBOM won't show that. An AI SBOM will. Regulators are asking for forensic evidence. EU AI Act transparency rules for providers and deployers take effect from 2 August 2026 (the machine-readable content-marking sub-obligation has since been pushed to December 2026 for systems already on the market, but the core transparency duties still land in August). In May 2026, CISA and its G7 partners published minimum elements for AI SBOMs. If you sell into medical, automotive or US federal, your compliance team will ask you for this.

3. Do all companies need an SBOM?

No. You probably don't need an SBOM, classic or AI, if: You only use off-the-shelf SaaS (Salesforce, Google Workspace, and so on). Your product has no internet connection. You're just writing internal automation scripts. Don't add work for no reason.

4. If not, who does need one?

You need a classic SBOM if you sell into US federal, EU, medical, automotive or industrial sectors, or if a customer procurement team has started asking for one. That's happening more and more, and it overlaps directly with the wider CRA and EN 18031 timeline that's already reshaping connected product compliance. You need an AI SBOM specifically if any of these are true: You ship embedded or edge AI. Firmware, model and runtime are all tied together. You're in medical devices . The MHRA in the UK and EU MDR both expect traceability from training data to inference, and international standards like IEC 81001-5-1 apply whether you're selling to the NHS or a clinic in Berlin. You're in automotive . ISO 21434 covers the whole supply chain, and AI for perception sits right in the middle of it. You host your own LLM or SLM. A fine-tuned Llama model for customer support needs checking: did that fine-tune use toxic data, or leak training secrets? Your largest customers are regulated. Even if you aren't, they'll push requirements down the supply chain. I've seen this with medical and industrial clients already.

Do You Need an AI SBOM? 5 Questions Embedded Teams Are Asking

⏩ TL;DR: AI SBOM - do I need one?
An AI SBOM extends a normal Software Bill of Materials to cover models, weights, training data, inference engines and model cards.
CISA and G7 partners published minimum elements for AI SBOMs in May 2026. EU AI Act transparency obligations land 2 August 2026.
Not every company needs an SBOM, classic or AI. You need one if you ship embedded/edge AI, work in medical or automotive, host your own LLM, or sell to customers who do.
Start minimal: extend your existing CycloneDX SBOM, hash every model with SHA256, automate generation in CI/CD, and link it to your firmware SBOM.

1. What is an AI SBOM?
An AI SBOM is a normal Software Bill of Materials, extended to cover AI and machine learning systems.
A regular SBOM lists libraries, packages, versions and licenses. Think of it as the ingredient label for your code.
An AI SBOM adds four extra things:
- Models and weights. Which model, what version, where it came from, its cryptographic hash.
- Training datasets. Source, license, version or snapshot date, bias audit notes if you have them.
- Inference engines. ONNX Runtime, TensorFlow, or PyTorch version, plus target hardware.
- Model cards. Performance bounds, known failure modes, drift metrics.
I work on embedded and edge AI at ByteSnap Design. For us, the hash is non-negotiable.
Without a hash, you can't later prove that the model you're looking at is the one that actually shipped.

2. What's created the need for AI SBOMs?
Three things.
Supply chain attacks now target AI. Attackers upload backdoored weights to public hubs like Hugging Face, and they poison training data. Without an AI SBOM, you can't tell a trusted fine-tune from a malicious upload. This is happening now.
Your dependencies have AI dependencies. You pull a library, that library pulls a tiny ONNX model for face detection, and three levels down that model has a known vulnerability in its preprocessing pipeline. A standard SBOM won't show that. An AI SBOM will.
Regulators are asking for forensic evidence. EU AI Act transparency rules for providers and deployers take effect from 2 August 2026 (the machine-readable content-marking sub-obligation has since been pushed to December 2026 for systems already on the market, but the core transparency duties still land in August). In May 2026, CISA and its G7 partners published minimum elements for AI SBOMs. If you sell into medical, automotive or US federal, your compliance team will ask you for this.
3. Do all companies need an SBOM?
No. You probably don't need an SBOM, classic or AI, if:
- You only use off-the-shelf SaaS (Salesforce, Google Workspace, and so on).
- Your product has no internet connection.
- You're just writing internal automation scripts.
Don't add work for no reason.
4. If not, who does need one?
You need a classic SBOM if you sell into US federal, EU, medical, automotive or industrial sectors, or if a customer procurement team has started asking for one.
That's happening more and more, and it overlaps directly with the wider CRA and EN 18031 timeline that's already reshaping connected product compliance.
You need an AI SBOM specifically if any of these are true:
- You ship embedded or edge AI. Firmware, model and runtime are all tied together.
- You're in medical devices. The MHRA in the UK and EU MDR both expect traceability from training data to inference, and international standards like IEC 81001-5-1 apply whether you're selling to the NHS or a clinic in Berlin.
- You're in automotive. ISO 21434 covers the whole supply chain, and AI for perception sits right in the middle of it.
- You host your own LLM or SLM. A fine-tuned Llama model for customer support needs checking: did that fine-tune use toxic data, or leak training secrets?
- Your largest customers are regulated. Even if you aren't, they'll push requirements down the supply chain. I've seen this with medical and industrial clients already.

5. How do I start building an AI SBOM?

Start minimal. Don’t build a platform on day one. You want something that works by Friday, not a six-month roadmap.

1. Extend what you already have. If you’re already generating CycloneDX SBOMs, you’re halfway there. Version 1.5 added native ML BOM support, so models and datasets become first-class components. No need to invent a new format.

2. Hash your models. Use SHA256.

Every exported .tflite, .onnx or .bin file gets a hash stored right next to it. Without that hash, you have no forensic trail.

3. Automate generation. Add it to your CI/CD pipeline:

				
					cyclonedx-bom -o bom.json --include-ml

That’s it. No manual paperwork, no engineer filling out spreadsheets. Every build produces its AI SBOM automatically.

4. Record provenance. At minimum, track who trained the model, which training run, which dataset version. A single line in a JSON file is fine. You just need to answer “where did this come from?” when someone asks.

5. Link it to your firmware SBOM. Use the same release ID across both. Then when a vulnerability drops, you can answer: which model was on which device, with which OS libraries, and what needs patching?

Where teams get into trouble...

Don’t treat this as a one-off compliance job. Generate it once, file it away, and you’ve wasted your time. The value comes when your team can answer “which products are affected by this new vulnerability?” in minutes, not days.

Don’t stop at direct dependencies. The risky component is often three levels down in the dependency tree, and that’s usually the one you didn’t know you had.

Don’t leave ownership to individual engineers. Someone needs to own the AI SBOM, the same as someone owns the firmware SBOM, with clear responsibility and a defined process for when a vulnerability shows up. That’s exactly what regulators look for under the CRA and EN 18031.

Main takeaways

AI SBOMs answer one specific question: did we ship that vulnerable model, and where is it?

Start with hashes and CycloneDX. Automate generation. Link it to your firmware SBOM. And don’t wait for the next Log4j-style AI disaster to find out you needed one.

Already shipping embedded Linux devices? ByteSnap Design’s Embedded Linux Security Management service already builds your SBOM into ongoing vulnerability tracking, ahead of the CRA 2027 and MDR 2026 deadlines. Ask us about extending that same discipline to your AI models.

Building a new edge AI product?

ByteSnap Design's Edge AI and Embedded AI Development team can help you build AI SBOM discipline in from the start. Book in a technical review to get started.

Speak to an engineer

Ritchie Perry

Ritchie Perry is an engineer working across ByteSnap Design and its EV charging engineering consultancy, Versinetic. With more than 30 years of experience in the electronics industry, he began his career as a sound engineer before moving into professional audio electronics, working with leading brands including Midas, Klark Teknik, Behringer and Lab Gruppen.

Recognising his potential, an early employer supported his professional development by funding a BEng in Electronic Engineering at Birmingham City University, where he graduated with first-class honours.

Ritchie divides his time between in-house production testing, electronics engineering, and on-site work with clients to deliver practical engineering solutions. Outside of work, he is a keen guitarist and performs with several tribute bands.