An AIBOM, an AI bill of materials, is a structured, machine-readable inventory of an AI system's components: model, datasets, and lineage. For clinical AI the emerging standards stack is the CISA and G7 SBOM for AI minimum elements plus the CycloneDX ML-BOM, and the missing piece is a signed provenance chain over execution.
The concept is defined in the recent literature as an extension of the software bill of materials into the AI supply chain, so an AIBOM records not only software libraries but the model, its training and evaluation datasets, its weights and parameters, and the provenance and lineage behind them.[5] For an AIBOM in healthcare that matters more than it does for generic software, because a clinical AI model is a learned artifact whose behavior is a function of the data it was trained on: you cannot understand what a model will do, or defend how it was built, from a list of the software around it. What an AIBOM does not do, on its own, is prove what executed. It is an inventory on the shelf, not a record of what ran. That is where RankShieldMD works: it can emit a clinical AIBOM in CycloneDX and add a signed provenance chain over execution, sealed to an externally-anchored, post-quantum-signed transparency ledger. It produces evidence that supports your submission, never the submission itself, never makes you compliant or cleared, and works on model, dataset, and execution identity, never on protected health information.
And it puts device makers ahead of where practice is heading, not past a rule that already exists: an AIBOM is a voluntary, emerging best practice, not a current FDA §524B statutory requirement, and we say so plainly and repeatedly.
What is an AIBOM and how is it different from an SBOM?
An SBOM inventories software components; an AIBOM inventories the model, datasets, lineage, weights, and training-data provenance that a software list was never designed to capture.
A software bill of materials, an SBOM, is the ingredient list for software: the libraries and packages a program depends on, with their versions and cryptographic hashes, so a reviewer or a pipeline can see exactly what is inside a build. That works because software is code, and code is enumerable. An AI system is different. A clinical AI model is a learned artifact, and its behavior depends not on a library version but on the data it was trained on, the way it was evaluated, and the parameters it settled into. An SBOM has no place to record any of that. An AIBOM, an AI bill of materials, fills the gap: it inventories the model itself, the training and evaluation datasets, the weights and parameters, and the training-data provenance and lineage that explain where the model came from.[5] It does not replace the SBOM; it complements it, and for an AI-enabled device you would typically produce both, the SBOM for the software and the AIBOM for the model and its data. The AIBOM healthcare use case is exactly this: giving clinical AI the same kind of transparent, machine-readable inventory that software already has, so that what a model is, and where its data came from, is documented rather than assumed. An AIBOM remains a voluntary, emerging practice, not an FDA mandate, and RankShieldMD can emit both an SBOM and an AIBOM in CycloneDX. It produces evidence that supports your submission; it never makes your submission, and it never makes you compliant or cleared.
What are the CISA and G7 minimum elements for an SBOM for AI?
The minimum-elements idea comes from CISA-led SBOM work reflected in G7 discussions, and the emerging AI version extends the baseline toward component inventory, model and dataset identity, and provenance fields.
The phrase minimum elements comes from the software bill of materials effort, where the goal was to define a baseline set of fields a bill of materials should always carry so that it stays useful as it moves across a supply chain, from a vendor to an integrator to a hospital. That effort has been led in the United States by CISA and is reflected in G7-level discussions about a common approach. As attention has turned to AI, that same instinct is being extended: an SBOM for AI, an AIBOM, would carry a baseline component inventory, model and dataset identity, and provenance or lineage fields, so that an AI system can be described the way software already is.[5] It is important to be precise about status here, because precision is the honest thing to do. This is active, emerging standards work, not a finalized federal mandate, and there is no FDA AIBOM requirement today. We present the minimum-elements direction as where practice is heading, not as a rule that already binds. The direction is clear even where the final text is still being written, and adopting it now is a way to be early rather than late. RankShieldMD builds a clinical AIBOM aligned to this direction and expresses it in the CycloneDX format so it is machine-readable, portable, and consistent with the software SBOM it sits beside. It produces evidence that supports your submission, never the submission itself, and it is non-device and PHI-free.
What fields does a CycloneDX ML-BOM capture?
CycloneDX, standardized as ECMA-424, extends the bill-of-materials model with machine-learning components: a model card, considerations, datasets, model parameters, and cryptographic hashes.
CycloneDX is a widely adopted bill-of-materials standard, published as ECMA-424, and its machine-learning extension is often called an ML-BOM. Where a software SBOM lists libraries, an ML-BOM adds the parts of an AI system that matter for understanding and governing a model. It can capture a model card that describes the model and its intended purpose, a considerations section that records intended use, limitations, and known concerns, the datasets used for training and evaluation, the model parameters, and cryptographic hashes that pin the exact artifacts so a listed model is the model actually shipped.[5] Because an ML-BOM uses the same format and structure as a software SBOM, the two live side by side in one consistent, machine-readable document rather than in two disconnected systems. A reviewer, an auditor, or an internal pipeline can then parse the AI supply chain the same way it already parses the software supply chain, which lowers the cost of adopting an AIBOM in the first place. RankShieldMD emits the clinical AIBOM in CycloneDX ML-BOM form, produces human-readable views alongside the machine-readable file, and can seal each AIBOM to a post-quantum-signed transparency ledger tied to a specific build, so the exact model and datasets on a given device version are a confirmable fact rather than a claim that drifts out of date between releases. The AIBOM stays a voluntary, emerging practice, not a §524B mandate. It produces evidence that supports your submission; it does not satisfy anything on your behalf.
What is missing from a static AIBOM, and why does execution provenance matter?
A static inventory does not prove which model actually ran on which data for a given decision; the missing layer is a signed, per-decision provenance chain over execution.
Everything an AIBOM captures is, by nature, an inventory. It tells you what a clinical AI system is made of: this model, these datasets, this lineage. That is genuinely useful, and it is more than most AI systems can produce today. But an inventory describes the system on the shelf, and it says nothing about what happened at run time. A perfectly accurate AIBOM can sit in a repository while a different model version, or a shadow copy, or a silently updated weight file, is what actually produces a clinical output for a specific patient input at a specific moment. The inventory and the execution are two different facts, and only one of them is captured by a static AIBOM.[5] The missing layer is a signed, per-decision provenance chain over execution: a record that binds a specific decision to the exact model version and the exact inputs that produced it, sealed cryptographically so it cannot be altered after the fact and can be recomputed by someone who does not trust the dashboard. This is the genuine whitespace, and it is RankShieldMD's angle. RankShieldMD adds a signed provenance chain over execution on top of the CycloneDX AIBOM, so the inventory of what a system is made of is matched by verifiable evidence of what actually ran. Crucially, this provenance binds a decision to a model version without ingesting the patient data itself, which is how it stays PHI-free by construction. It produces evidence that supports your submission, never the submission itself, and it never makes you compliant or cleared.
How does an AIBOM map to the FDA §524B SBOM requirement?
The §524B(b)(3) SBOM is statutory and mandatory; an AIBOM is a voluntary, emerging best practice that strengthens the record and is not an FDA mandate.
It helps to keep two things clearly separate. The FDA §524B(b)(3) software bill of materials is a statutory, mandatory requirement: a cyber-device premarket submission must include an SBOM covering commercial, open-source, and off-the-shelf software components, and the premarket guidance describing how that is expected was finalized June 27, 2025.[7][3] An AIBOM is not that. An AIBOM is a voluntary, emerging best practice that documents the model, datasets, and lineage behind an AI-enabled device, and there is no FDA AIBOM mandate today. The two coexist cleanly: an AI-enabled device still produces the required §524B SBOM for its software, and the AIBOM sits alongside it to describe the AI supply chain the SBOM was never designed to capture. Adopting an AIBOM therefore does not satisfy §524B; it strengthens the overall record for an AI-enabled device and puts a manufacturer ahead of where practice is heading rather than past a rule that already exists. We say this plainly because getting the status right is part of doing it honestly: presenting a voluntary practice as a mandate would be wrong, and presenting a mandate as optional would be worse. RankShieldMD emits both the required §524B SBOM and the voluntary AIBOM in CycloneDX, and can add a signed provenance chain over execution on top. It produces evidence that supports your submission; the FDA remains the deciding authority, and RankShieldMD never makes you compliant or cleared.
