When a vulnerability is announced in a common library, a team with a good software bill of materials can answer "are we affected?" in minutes. They search the inventory for the component and version, and they have their list.
Ask the same team "which of our AI applications use the model version the provider just deprecated?" or "which prompts were changed last month, and by whom?" or "which MCP servers can reach the customer database?", and the inventory has nothing to say. The packages are recorded. The components that most influence how an AI system behaves are not.
Langeberg Software is fictional, and its systems and figures are illustrative. Langeberg already generated SBOMs for Ledgerline's container images. After Part 5 turned up 40 unrecorded skills and servers, the platform team tried to answer the wider question: what is each of the six AI applications actually made of?
Where the SBOM stops
The bottom layer is the classic SBOM: packages and container images, which most software composition tools already produce. The layers above it are what AI adds.
Models. Name, provider or source, exact version identifier, and for self-hosted models the weights file and its hash and licence. A moving alias such as "latest" is not a version.
Prompts and policies. System prompts, prompt templates, guardrail rules and routing policies. These decide what the system will and will not do, so they are components with versions, not configuration trivia.
Tool servers and skills. MCP servers and agent skills, with their source, pinned version and the permissions and secrets they use.
Datasets. Retrieval corpora, fine-tuning data and reference data the system depends on, with their source, refresh process and classification. A retrieval index built from a document store inherits that store's sensitivity.
Evaluation sets. The test cases that decide whether a change ships. If the evaluation set changes, the meaning of "passed" changes, so it needs a version as much as the code does.
External services. Hosted model APIs, hosted search, embedded AI features in SaaS tools. You cannot inventory their internals, but you can record that you depend on them, under which account, in which region and under which terms.
Langeberg's first pass found good records for the bottom layer and almost none for the other six. The information existed, but in a gateway configuration file, three repositories, a provider console and several developers' laptops.
The formats exist; the policy is yours
Public standards have caught up with this. CycloneDX, published by Ecma International as ECMA-424, has had a machine-learning bill of materials capability since version 1.5 in 2023 for describing models and datasets, and its current version is 1.7. SPDX 3.0, released in 2024, added an AI profile and a dataset profile covering provenance, training and dataset details on top of its core model.
Both are useful, particularly if you need to exchange inventories with customers or suppliers, and both can be generated by tooling. Neither decides what you must record. A format gives your answers a shape; your inventory policy decides which questions you insist on answering. Start with a spreadsheet or a small repository if that is what you can maintain. Move to a standard format when you need to exchange or automate.
One row, filled in
Langeberg settled on six fields for every component, whatever its layer:
| Field | Question it answers |
|---|---|
| Component | What is it? |
| Version | Exactly which one, by number, hash or digest? |
| Source | Where did it come from? |
| Owner | Who decides when it changes? |
| Touches | Which data, tools, secrets and systems can it reach? |
| Reviewed | When was it last checked, and by whom? |
The touches column is the one that earns its keep. In an incident, the question is never only "do we have this component?" It is "what could this component affect?" A prompt that drives a support assistant with access to a refund tool is a different kind of risk from a prompt that drafts internal summaries. A dataset that feeds a retrieval index containing supplier banking details is a different kind of risk from one containing public product documentation.
Recording reach also exposes design problems early. When Langeberg filled in the touches column for its "ask your ledger" feature, it found the retrieval index had been built from a document store that included internal finance notes never meant for customer-facing answers. That was a data-boundary defect, found by an inventory exercise rather than by a customer. The RAG That Survives Production series covers why retrieval must respect the same permissions as its source.
Keeping it current
An inventory that is correct on the day it is written and wrong a month later is worse than none, because people trust it. Three habits keep it alive.
Generate what can be generated. Package and image layers come from the build pipeline. Model identifiers and prompt versions can be read from deployed configuration. The gateway knows which applications call which models.
Make changes write the record. A prompt change is a pull request that updates the version; a new MCP server goes through the registry from Part 5, which is itself part of the inventory; a model upgrade is a release that records the new identifier.
Review the manual fields on a rhythm. Owner, touches and review date are judgement calls. Langeberg reviews them quarterly per application, and immediately when an application gains a new tool or data source.
What it is for
An AI bill of materials is not a compliance artefact. It is the thing that lets you answer, quickly and from records:
- Which applications are affected by this advisory, deprecation or licence change?
- What could this compromised component reach?
- What changed between the version that worked and the version that does not?
- Who needs to approve a change to this component?
Customers buying AI-enabled software are beginning to ask these questions of their suppliers. Langeberg's larger customers now ask, in procurement, which models Ledgerline uses, where they run and what data reaches them. An inventory makes that answer a document rather than a scramble. For the procurement side of that conversation, see Buy, build or grow?.
Next: Part 7, Containment is an architecture feature. All parts are on the series page.
How CloudNala can help
We help teams build a first AI bill of materials for their applications: the components, versions, owners and, most importantly, what each component can reach. We start with whatever format the team can maintain and plan the move to CycloneDX or SPDX where exchange or automation needs it.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Supply Chain Review or write to us at consult@cloudnala.co.za