AIBOM for healthcare: CISA and CycloneDX ML-BOM for clinical AI.
An AIBOM inventories the model, datasets, and lineage behind clinical AI. This guide maps the emerging standards stack and the missing piece: a signed provenance chain over execution.
An AIBOM, an AI bill of materials, is a 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.[5] An AIBOM is a voluntary best practice, not an FDA mandate. RankShieldMD produces evidence that supports your submission, not the submission itself, and it is non-device and PHI-free by design.
Not just software.
The model itself.
An SBOM inventories software components: libraries, versions, hashes. An AIBOM inventories what an SBOM was never built to capture: the model, datasets, weights, and training-data provenance.[5] A clinical AI model is a learned artifact whose behavior depends on the data behind it, so listing the software around it does not tell you what the model is or where it came from. The AIBOM fills that gap and complements the SBOM rather than replacing it. RankShieldMD can emit both in CycloneDX, and it stays non-device and PHI-free.
An emerging
baseline.
The minimum-elements idea comes from SBOM work led by CISA and reflected in G7 discussions: a baseline set of fields a bill of materials should carry. For AI, that work extends the baseline toward a component inventory, model and dataset identity, and provenance or lineage fields.[5] This is active, emerging standards work, not a finalized federal mandate, and we present it that way. RankShieldMD builds a clinical AIBOM aligned to this direction and expresses it in CycloneDX, producing evidence that supports your submission.
Model card.
Datasets. Hashes.
CycloneDX, standardized as ECMA-424, extends the bill-of-materials model with machine-learning components, an ML-BOM. It can capture a model card, considerations such as intended use and limits, the training and evaluation datasets, model parameters, and cryptographic hashes that pin the exact artifacts.[5] Because it is the same format used for software SBOMs, the AI supply chain sits alongside the device software in one consistent structure. RankShieldMD emits the AIBOM in CycloneDX and can seal it to a post-quantum-signed transparency ledger tied to a build.
What ran,
not just what's listed.
A static AIBOM is an inventory: it tells you what a system is made of. It does not prove which model actually ran on which data for a given decision.[5] The missing layer is a signed, per-decision provenance chain over execution: a record binding a specific decision to the exact model version and inputs, sealed so it cannot be altered later. That is RankShieldMD's angle. It adds a signed provenance chain over execution on top of the CycloneDX AIBOM, so the inventory is matched by evidence of what ran.
The standards,
and the whitespace.
Below: what an AIBOM is versus an SBOM, the CISA and G7 minimum elements for AI, the fields a CycloneDX ML-BOM captures, what a static AIBOM leaves out, and how an AIBOM maps to the FDA §524B SBOM requirement. Emerging best practice, produced as verifiable evidence, PHI-free, non-device.
What an AIBOM is, in one paragraph.
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.
Where to go next.
A clinical AIBOM plus execution provenance
Emit a clinical AIBOM in CycloneDX ML-BOM form and add a signed provenance chain over execution, produced as verifiable evidence for regulatory and product-security leads.
Explore → FDA §524BThe §524B obligations, as evidence
The postmarket, secure-design, and SBOM artifacts a §524B submission relies on, including the required software bill of materials, produced as signed evidence.
Explore → §524B EXPLAINEDFDA §524B, in plain language
What a cyber device is, the three §524B(b) obligations, and the SBOM formats the FDA accepts, mapped to the evidence a submission actually needs.
Explore →What we are careful never to claim.
An AIBOM is voluntary, not a mandate
An AIBOM is a voluntary, emerging best practice, not a current FDA §524B statutory requirement. We say so plainly and repeatedly. The §524B SBOM is mandatory; the AIBOM strengthens the record.
It supports your submission
RankShieldMD produces evidence that supports your submission. It never makes your submission, never renders an FDA decision, and cannot make an organization compliant or cleared.
It's model identity, not PHI
RankShieldMD works on the model, datasets, hashes, lineage, and signed execution records. It is non-device and PHI-free by construction; the provenance chain binds a decision without ingesting patient data.
References
- [5] Frontiers in Computer Science (Jan 2026). AI bill of materials (AIBOM / ML-BOM) definition, Radanliev et al. frontiersin.org/journals/computer-science/…/fcomp.2026.1735919
- [3] FDA (June 27, 2025, final). Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. federalregister.gov/documents/2025/06/27/2025-11669
- [7] FD&C Act §524B (added by the Consolidated Appropriations Act 2023, effective March 29, 2023). fda.gov/medical-devices/…/cybersecurity
- STD Standards referenced above: CycloneDX / ECMA-424 (cyclonedx.org) and CISA, Software Bill of Materials (cisa.gov/sbom).
AIBOM for healthcare: questions, answered.
What is an AIBOM?
An AIBOM, an AI bill of materials, is a structured, machine-readable inventory of an AI system's components: the model, the datasets, and the lineage that produced them.[5] It extends the software bill of materials idea into the AI supply chain, so instead of only listing software libraries, it also records the model, its training and evaluation datasets, weights, parameters, and provenance. 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. An AIBOM is a voluntary, emerging best practice, not a current FDA requirement. RankShieldMD can emit a clinical AIBOM in CycloneDX and add a signed provenance chain over execution. It produces evidence that supports your submission, never the submission itself, and it is non-device and PHI-free.
How is an AIBOM different from an SBOM?
An SBOM, a software bill of materials, inventories software components: libraries, packages, and their versions and hashes. An AIBOM inventories the parts of an AI system that an SBOM was never designed to capture: the model itself, the training and evaluation datasets, the weights and parameters, and the training-data provenance and lineage.[5] A clinical AI model is not just code; it is a learned artifact whose behavior depends on the data it was trained on, so listing the software around it does not tell you what the model is or where it came from. The AIBOM fills that gap. It complements an SBOM rather than replacing it, and for an AI-enabled device you would typically produce both. An AIBOM remains a voluntary, emerging practice, not an FDA mandate. RankShieldMD can emit both in CycloneDX.
What are the CISA and G7 minimum elements for an SBOM for AI?
The idea of minimum elements comes from the SBOM work led by CISA and reflected in G7 discussions, which frames a baseline set of fields a bill of materials should carry so it is useful across the supply chain. For AI, that emerging minimum-elements work extends the baseline toward a 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: this is active, emerging standards work rather than a finalized federal mandate, and we present it that way. The direction is clear even where the final text is not. RankShieldMD builds a clinical AIBOM aligned to this direction and expresses it in CycloneDX so it is machine-readable and portable. It produces evidence that supports your submission, never the submission itself.
What fields does a CycloneDX ML-BOM capture?
CycloneDX, standardized as ECMA-424, extends the bill-of-materials model with machine-learning components, often called an ML-BOM. It can capture a model card describing the model, considerations such as intended use and limitations, the datasets used for training and evaluation, model parameters, and cryptographic hashes that pin the exact artifacts.[5] Because it is the same format used for software SBOMs, an ML-BOM sits alongside a device software SBOM in one consistent, machine-readable structure. That means a reviewer or a pipeline can parse the AI supply chain the same way it parses the software supply chain. RankShieldMD emits the clinical AIBOM in CycloneDX ML-BOM form and can seal it 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. It is a voluntary practice, not a mandate.
What is missing from a static AIBOM?
A static AIBOM is an inventory: it tells you what a clinical AI system is made of, the model, datasets, and lineage. What it does not do is prove which model actually ran on which data for a given decision. A published inventory can be accurate on the shelf and still say nothing about what executed at 2:14 in the afternoon on a specific patient input. 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 inputs, sealed so it cannot be altered after the fact.[5] That is RankShieldMD's angle. It adds a signed provenance chain over execution on top of the CycloneDX AIBOM, so the inventory is matched by evidence of what ran. It produces evidence that supports your submission, never the submission itself, and it is PHI-free.
How does an AIBOM map to the FDA §524B SBOM requirement?
The FDA §524B(b)(3) software bill of materials is statutory and mandatory: a cyber-device premarket submission must include an SBOM covering commercial, open-source, and off-the-shelf components.[7][3] An AIBOM is different. It is a voluntary, emerging best practice that strengthens the record for AI-enabled devices, and it is not an FDA mandate. Practically, an AI-enabled device would still produce the required §524B SBOM, and the AIBOM sits alongside it to document the model, datasets, and lineage the SBOM was never designed to capture. Adopting an AIBOM puts a device maker ahead of where practice is heading rather than past a rule that already exists. RankShieldMD emits both in CycloneDX and can add a signed provenance chain over execution. It produces evidence that supports your submission; it never makes you compliant or cleared.
Is RankShieldMD a medical device, and does it touch patient data?
No on both. RankShieldMD is security and quality tooling that helps AI-enabled device makers inventory and evidence their AI supply chain. FDA classification turns on intended use, and RankShieldMD attests the identity and provenance of the model, datasets, and execution; it never renders, drives, or influences a clinical decision, so it stays non-device by design. It also works on model identity, dataset identity, hashes, lineage, and signed execution records, never on protected health information, so it is PHI-free by construction. A clinical AIBOM describes the model and its datasets, not patient records, and the provenance chain over execution binds a decision to a model version without ingesting the patient data itself. It attests; it never renders. And it produces evidence that supports your submission; it does not make you compliant or cleared.
Give your clinical AI a bill of materials and signed execution provenance.
Bring an AI-enabled device or model. We'll show you a clinical AIBOM emitted in CycloneDX ML-BOM form, aligned to the emerging CISA and G7 minimum elements, plus a signed provenance chain over execution that proves what ran. A voluntary best practice we make easy, produced as evidence that supports your submission, verifiable, PHI-free, non-device.