An AIBOM for
clinical AI.
A structured, machine-readable inventory of your model, built to the emerging standards, and then something a static inventory cannot give you: proof of every decision it makes.
An AI bill of materials (AIBOM) is a machine-readable inventory of an AI system's components: model hash, datasets, framework, and lineage. RankShieldMD emits a CycloneDX, CISA-G7-conformant clinical AIBOM on its ledger, then adds the missing piece a static inventory lacks: a signed provenance chain over execution, per decision. PHI is rejected at the guard, so the AIBOM stays PHI-free.
Inventory the model,
not the patient.
Building an AIBOM means recording what shaped the model: a hash of the model and its container, the training and validation datasets, the framework and version, and the lineage. RankShieldMD captures these from the baseline it registers for the approved model, then serializes them in CycloneDX. Only digests are held, so the inventory is PHI-free by construction and never drifts out of date.
Four fields,
machine-readable.
A clinical AIBOM carries the model artifact and its hash, the datasets, the framework and runtime, and the model lineage, plus intended use, version, and a reference to the validation record. Each field is expressed in a structured schema so tooling can read and check it. RankShieldMD emits every field from what it already seals, so the inventory a buyer sees is derived from evidence, not typed by hand.
CISA / G7,
in CycloneDX.
The emerging AIBOM standards stack pairs the CISA-led G7 minimum elements for an SBOM for AI with the CycloneDX / ECMA-424 ML-BOM schema. Meet the guidance by capturing the model hash, datasets, framework, and lineage those documents call for and serializing them in that format. No AIBOM is FDA-mandated; it is a voluntary best practice adopted ahead of any requirement.
Supports your
submission.
Section 524B expects makers of cyber devices to provide a bill of materials, specifically the SBOM in 524B(b)(3), and to plan for postmarket cybersecurity. An AIBOM extends that SBOM to the AI components, so it supports the 524B(b)(3) bill-of-materials expectation and feeds the monitoring that follows. It supports your submission; it is not itself a clearance, and it makes no medical claim.
Inventory plus
proof.
Register a model baseline, emit a CycloneDX, CISA-G7-conformant AIBOM, and seal each decision so you have per-decision provenance a static inventory cannot give. Standards-aligned, PHI-free, non-device. The AIBOM and the signed provenance chain come out of the same sealed record.
How do you create an AIBOM for a clinical AI system?
You create an AIBOM by inventorying the model and everything that shaped it, then serializing that inventory in a machine-readable standard such as CycloneDX: a hash of the model and its container, the datasets used for training and validation, the framework and its version, and the model's lineage. An AI bill of materials is the AI equivalent of the software bill of materials that supply-chain security teams already rely on, and it exists to make an otherwise opaque model transparent, so a buyer, an auditor, or a regulator can see what actually went into it. The work is not filling in a form once; it is capturing the model's real composition and keeping that inventory current as the model is retrained or revised. That is exactly where a manual AIBOM tends to fail, because a document typed by hand drifts out of date the moment the model changes. RankShieldMD avoids that drift by generating the AIBOM from material it already holds. Because it registers a cryptographic baseline of the approved model and seals digests for every decision, the model hash, the framework, and the lineage are captured as a matter of operation. Emitting the AIBOM is therefore a by-product of sealing rather than a separate documentation exercise, and because RankShieldMD holds only digests, the inventory it produces is PHI-free by construction. The result is a standards-aligned inventory that reflects the model as it actually runs, not as someone remembered it at submission time.
What goes in an AI bill of materials for healthcare?
A clinical AIBOM carries the fields that make a model auditable, and a short list covers most of what matters. At minimum it records the model artifact and its cryptographic hash, so there is a fixed reference for exactly which model this is; the datasets used for training and validation, so the data provenance is visible; the framework and runtime with their versions, so the execution environment is known; and the model's lineage, so the path from raw model to deployed artifact can be traced. For a clinical context you extend that core with the model's intended use, its version, and a reference to the validation record that supports its clinical performance, because in healthcare the question is never only what the model is but what it is cleared or validated to do. Each of these fields lives in a structured, machine-readable schema rather than prose, which is what lets supply-chain tooling read, diff, and verify the inventory instead of a human skimming a PDF. One boundary belongs here in plain sight: a well-built AIBOM inventories the model, not the patient. It should never contain protected health information, because PHI is not a component of the model. RankShieldMD enforces that structurally. It emits each field from the baseline it registers for the approved model, it captures cryptographic digests rather than contents, and raw patient identifiers are rejected at the guard before anything is sealed. The AIBOM it produces describes the model, holds only digests, and is safe to hand to a buyer or a regulator precisely because there is no protected data inside it.
How do you meet CISA/G7 and CycloneDX AIBOM guidance?
You meet the emerging guidance by aligning the inventory to the published minimum elements and serializing it in a recognized machine-readable format, and the two halves of that stack fit together deliberately. On the content side, CISA led work with G7 partners on minimum elements for what is often described as an SBOM for AI: the baseline set of fields an AIBOM should carry so that different tools and organizations mean the same thing by it. On the format side, CycloneDX, standardized as ECMA-424, added a machine-readable model card and dataset component so a bill of materials can express an ML-BOM, which is the AIBOM in practice. Meeting the guidance therefore means two things at once: capturing the model hash, datasets, framework, and lineage the minimum-element work calls for, and emitting them in the CycloneDX schema so the document slots into tooling your buyers may already run. RankShieldMD builds a CISA-G7-conformant AIBOM in CycloneDX form from what it already seals, so alignment is a property of the pipeline rather than a manual mapping exercise. Two honest notes belong alongside this. First, these are emerging standards, and specific field sets and profiles continue to evolve, so meeting the guidance is a moving target that a living, generated AIBOM handles better than a static one. Second, and more importantly, no AIBOM is FDA-mandated. It is a voluntary best practice that device makers and hospitals are adopting ahead of any requirement, and conforming to CISA, G7, and CycloneDX guidance supports transparency and supply-chain obligations without, on its own, making anyone compliant.
How does an AIBOM support an FDA §524B submission?
An AIBOM supports an FDA Section 524B submission by extending the software bill of materials that section already expects to the AI components of the device. Section 524B of the Federal Food, Drug, and Cosmetic Act requires makers of cyber devices to meet cybersecurity expectations as part of a premarket submission, and among those, 524B(b)(3) calls for a software bill of materials covering commercial, open-source, and off-the-shelf software components. A modern clinical device increasingly includes an AI model whose components are not captured by a conventional software SBOM, so an AIBOM fills that gap: it inventories the model artifact, its datasets, its framework, and its lineage in the same machine-readable spirit as the SBOM 524B(b)(3) asks for. That is why an AIBOM supports the bill-of-materials expectation of a 524B submission, and why it also feeds the postmarket cybersecurity monitoring that 524B expects, by giving reviewers a current inventory to monitor against. The language here is deliberate and we hold it every time: an AIBOM supports your submission. It does not make you compliant, it is not an FDA clearance, and no regulation currently mandates an AIBOM specifically. The overall 524B submission is the device maker's responsibility across the bill of materials, the plan to monitor and address postmarket cybersecurity, and the reasonable assurance of device security. RankShieldMD contributes to the parts that depend on a trustworthy inventory and on decision integrity, by emitting a standards-aligned AIBOM and by backing it with signed, verifiable provenance, so the inputs to those obligations are evidence a reviewer can check rather than assertions to take on trust.
Why is a static AIBOM not enough, and what does RankShieldMD add?
A static AIBOM is necessary but not sufficient, because an inventory of ingredients does not prove what was served. An AIBOM tells you what the approved model is supposed to contain: its hash, its datasets, its framework, its lineage. It is a supply-chain artifact, a snapshot of what went into the system. But it says nothing about whether a given clinical decision actually ran on that model, on that version, with intact inputs. If the model drifts, is swapped for a fine-tuned variant, or the inputs are poisoned, the AIBOM reads exactly the same, because it describes the model in principle rather than the decision in fact. That is the gap between the supply-chain layer and the runtime layer, and it is the whole reason per-decision provenance exists as a distinct capability. RankShieldMD emits the CycloneDX, CISA-G7-conformant AIBOM that buyers and regulators expect, and then adds the missing piece a static inventory cannot provide: a signed provenance chain over execution, per decision. For each decision it seals digests of the model, the inputs, and the output to an append-only transparency log, signs them with composite ML-DSA-65 and Ed25519, and anchors the log root externally, so a specific decision can be verified in isolation. Tamper with the model, the data, or the record after the fact, and verification returns false. So the distinction is honest and it is the point: an AIBOM is the static inventory, provenance is the runtime proof, and RankShieldMD produces both from one fabric. Knowing what is generally in the kitchen is the AIBOM; a signed, tamper-evident receipt for the specific meal that was served is the provenance. The two are complementary, and shipping them together is RankShieldMD's distinguishing contribution.
What we are careful never to claim.
An AIBOM is voluntary
No AIBOM is FDA-mandated. It is a best practice that supports transparency, supply-chain security, and an FDA Section 524B submission. It supports your submission; it does not make you compliant, and it is not a clearance.
A static AIBOM is not per-decision proof
An AIBOM inventories the model at the supply-chain level. It does not prove that a given decision ran on the approved model. RankShieldMD adds a signed provenance chain over execution, which is a distinct, finer layer.
It never sees PHI
The AIBOM inventories the model, not the patient. RankShieldMD holds only digests and rejects raw identifiers at the guard, so the inventory is PHI-free. Quantum-safe, never quantum-proof.
Ask RankShieldMD about AIBOM for clinical AI.
What is an AIBOM (AI bill of materials)?
An AIBOM is a structured, machine-readable inventory of an AI system's components: the model hash, the datasets it was trained and validated on, the framework it runs in, and its lineage. It is the AI equivalent of the software bill of materials (SBOM) that supply-chain security teams already rely on, and it is sometimes called an ML-BOM. Its purpose is to make an otherwise opaque model transparent, so a buyer, an auditor, or a regulator can see what actually went into it.
How do you create an AIBOM for a clinical AI system?
You inventory the model and everything that shaped it, then serialize that inventory in a machine-readable standard such as CycloneDX. That means recording a hash of the model and its container, the datasets used for training and validation, the framework and version, and the lineage of how the model was produced. RankShieldMD generates this automatically from the same baseline and digests it already seals for each decision, so the AIBOM is a by-product of operation rather than a manual document that drifts out of date.
Is an AIBOM the same as an SBOM?
An AIBOM extends the SBOM idea to AI. An SBOM inventories software components and dependencies; an AIBOM adds the parts that are unique to AI systems, the model artifact and its hash, the training and validation datasets, and the model lineage. CISA and the G7 have published minimum-element guidance that treats the AIBOM as an SBOM for AI, so the two are related standards rather than competing ones.
What goes in an AI bill of materials for healthcare?
At minimum: the model artifact and its cryptographic hash, the datasets used for training and validation, the framework and runtime with versions, and the model lineage. For a clinical AIBOM you also want the intended use, the model version, and a reference to the validation record. RankShieldMD emits these fields from the baseline it registers for the approved model, and it holds only digests, so the AIBOM stays PHI-free.
Does an AIBOM contain patient data or PHI?
A well-built AIBOM should not. It inventories the model and its components, not the patient records the model runs on. RankShieldMD is PHI-free by construction: it captures cryptographic digests of the model, inputs, and output, and raw patient identifiers are rejected at the guard before anything is sealed. The AIBOM it emits describes the model, so there is no protected health information inside it to leak.
What is CycloneDX and how does it relate to AIBOM?
CycloneDX is an open bill-of-materials standard, standardized as ECMA-424, that added a machine-readable model card and dataset component so it can express an ML-BOM (an AIBOM). It lets you serialize a model, its datasets, and its lineage in a structured document that tooling can read and verify. RankShieldMD emits its clinical AIBOM in CycloneDX form so it slots into supply-chain tooling your buyers may already use.
How do you meet CISA/G7 and CycloneDX AIBOM guidance?
You align the inventory to the published minimum elements and serialize it in a recognized format. CISA led G7 work on minimum elements for an SBOM for AI, and CycloneDX (ECMA-424) provides the machine-readable ML-BOM schema. Meeting the guidance means capturing the model hash, datasets, framework, and lineage those documents call for and emitting them in that format. RankShieldMD builds a CISA-G7-conformant AIBOM in CycloneDX form from what it already seals.
Is there an FDA mandate to produce an AIBOM?
No. There is no FDA AIBOM mandate. An AIBOM is a voluntary best practice that many device makers and hospitals are adopting ahead of any requirement, because it supports transparency, supply-chain security, and postmarket obligations. We are careful to state this honestly: producing an AIBOM does not make you compliant, and no regulation currently requires one specifically.
How does an AIBOM support an FDA Section 524B submission?
Section 524B requires makers of cyber devices to provide a software bill of materials as part of a premarket submission, specifically the SBOM described in 524B(b)(3), and to plan for postmarket cybersecurity. An AIBOM extends that SBOM to the AI components of the device, so it supports the 524B(b)(3) bill-of-materials expectation and the monitoring obligations that follow. It supports your submission; it is not itself an FDA clearance.
Is an AIBOM enough for FDA cybersecurity requirements?
No single document is. Section 524B expects a bill of materials, a plan to monitor and address postmarket cybersecurity, and reasonable assurance of device security. An AIBOM supports the bill-of-materials part and feeds the monitoring part with a current inventory, but the overall submission is your responsibility. RankShieldMD produces evidence that supports specific requirements; it never claims to make you compliant.
What is the difference between an AIBOM and per-decision provenance?
An AIBOM is a static inventory of what went into a model, at the supply-chain level. Per-decision provenance attests an individual runtime decision, proving that a specific output came from the approved model on intact inputs at a given time. They live at different layers. A static AIBOM cannot tell you whether this decision came from the approved model, and provenance is the finer layer that survives the question prove this one. RankShieldMD emits both from one fabric, and that combination is its distinguishing contribution.
Why is a static AIBOM not sufficient on its own?
Because an inventory of ingredients does not prove what was served. An AIBOM tells you what the approved model is supposed to contain, but it says nothing about whether a given decision actually ran on that model, on that version, with intact data. If the model drifts, is swapped, or the inputs are poisoned, the AIBOM still reads the same. The missing piece is a signed provenance chain over execution, per decision, which RankShieldMD adds on top of the AIBOM.
What does RankShieldMD add on top of a standard AIBOM?
A signed provenance chain over execution. RankShieldMD emits a CycloneDX, CISA-G7-conformant clinical AIBOM on its ledger, and then goes further than a static inventory by sealing a tamper-evident, post-quantum-signed record for each decision. So you get both the supply-chain inventory a buyer expects and the per-decision proof that a static AIBOM cannot provide. That runtime provenance layer is the missing piece it contributes.
Is RankShieldMD a medical device?
No. It attests that a decision was genuine and emits inventory and evidence outputs; it never produces, scores, or drives the clinical decision. Under the FDA clinical-decision-support criteria, software becomes a regulated device when it produces or drives the decision itself (the fourth criterion). RankShieldMD stays on the attestation side of that line by design, which keeps it non-device.
Is the AIBOM RankShieldMD emits quantum-safe?
The provenance records that back it are. Every sealed record is signed with composite ML-DSA-65 and Ed25519, so the evidence stays defensible as cryptography evolves toward resisting quantum attack. It is quantum-safe, not quantum-proof: no quantum computer capable of breaking today's cryptography exists yet, and we never claim otherwise.
Will emitting an AIBOM make us compliant?
No software or document does that on its own. A CycloneDX, CISA-G7-conformant AIBOM supports transparency, supply-chain, and postmarket obligations, and it supports an FDA Section 524B submission, but compliance is your organization's overall posture and remains your responsibility. RankShieldMD produces verifiable evidence that supports specific requirements and never claims otherwise.
A standards-aligned AIBOM, backed by proof.
Register a baseline, emit a CycloneDX, CISA-G7-conformant clinical AIBOM, and seal each decision so your buyer, your auditor, or your regulator gets both the inventory and the per-decision provenance a static AIBOM cannot give.