Every AI governance framework — the LGPD, ISO/IEC 42001, the EU AI Act, the NIST AI RMF — presupposes the same thing in its very first step: that the organisation knows which AI systems it uses. None of them calls it an AI-BOM, and none of them works without one.
It is the most requested and least existing document. When an auditor asks “show me the list of AI systems in use”, the most common answer is a spreadsheet assembled the week before, with the five tools somebody remembered. This guide is about building one that holds up.
What it is, and what it is not
An AI-BOM (AI Bill of Materials) is the structured inventory of the AI systems an organisation uses, buys or builds. The name is borrowed from the SBOM, the list of a software’s components, but the object is different: an SBOM describes what a system is made of; an AI-BOM describes what a system does, with which data, and who answers for it.
| Software inventory | AI-BOM | |
|---|---|---|
| Question answered | What is installed on the machines? | What generates, decides or processes, based on what? |
| Typical source | Inventory agent, MDM, licensing | Usage detection + contracts + area declarations |
| Sees browser-only SaaS | No | Yes — which is where most of it lives |
| Sees AI embedded in an approved tool | No, and this is the most forgotten case | Yes |
| Central field | Version and licence | Purpose, data processed, owner |
The row that surprises people most is the second to last. A meaningful share of the AI in use at a company was never bought as AI: it is a feature an already-approved vendor switched on in an update — meeting transcription, email summaries, autocomplete. The vendor inventory stays correct, and the processing inventory quietly stops being so.
The fields that matter
A useful AI-BOM fits in a table. The common mistake is the opposite of what people expect: it is not recording too little, it is creating forty fields nobody fills in. These are the ones that sustain an audit:
| Field | Why it exists |
|---|---|
| Name and vendor | Identification. Obvious in theory, but 'the legal team's AI' is not a record. |
| Type | Third-party tool, model, agent, pipeline or integration — the applicable control changes. |
| Business purpose | This is what links the system to the legal basis under data protection law and to the management objective under ISO 42001. |
| Input data | Whether personal data is involved, and whether sensitive data is. It determines practically everything else. |
| Output data | Where the result is used — and whether it feeds decisions about people. |
| Area and named owner | Without a person's name there is no accountability. 'The IT department' does not survive an audit. |
| Processing jurisdiction | Triggers the international-transfer analysis. |
| Training on your data | The central difference between the free and the corporate plan of the same tool. |
| Risk level | Prioritises. Without classification every item weighs the same and nothing gets addressed. |
| Status | Under assessment, approved, restricted, prohibited, discontinued. |
| Last verified | An inventory with no verification date is an assertion, not evidence. |
If you have the EU AI Act on your radar, add the regulation’s risk tier; if ISO/IEC 42001, add the link to the system’s impact assessment. Both are derivations of the fields above, not new fields.
Where the data comes from
No single source covers the inventory. The four, combined, do:
- Technical detection. An endpoint agent, NGFW/SSE/SIEM logs, or a browser extension. It is the only source that finds what nobody declared — which is precisely what matters most. See the guide on Shadow AI.
- Finance and procurement. Corporate cards and contracts reveal the AI paid for by business units, which rarely passes through IT.
- Declarations from the areas. A short form per manager. It captures context no detection captures: what it is for, who depends on it, what data goes in.
- Review of existing vendors. Which already-approved systems gained AI features since the last assessment. The most laborious source, and the one that produces the most findings.
Order matters: start with technical detection, not the form. A form sent before detection comes back with the list of what people find acceptable to declare. Sent afterwards, with the detected list in hand, the conversation shifts from “what do you use?” to “we found this, help us understand what it is for” — a far easier question to answer honestly.
The order to build it
A complete AI-BOM in the first month is fiction. What works is a sequence where each stage delivers value on its own:
- Weeks 1–2 — Raw discovery. Turn on detection and let it run without judging anything. The output of this phase is a list of domains and tools with usage frequency, not an inventory.
- Weeks 3–4 — Risk triage. Cross the list with a classified catalog and address critical and high first. The public catalog works as a starting point.
- Month 2 — Business context. Take the triaged list to the managers and fill in purpose, owner and data processed. Only here does it become an AI-BOM.
- Month 3 — Regulatory mapping. Link each item to its legal basis, to the record of processing activities and to the controls of your chosen framework.
- Ongoing — Maintenance. Automatic discovery, quarterly editorial review, and one rule: a newly detected tool generates a task with an owner and a deadline, not a line in a report.
Where the AI-BOM fits in each framework
| Framework | How the inventory appears |
|---|---|
| LGPD / GDPR | It is the input to the record of processing activities and the only way to answer a data subject's question about who their data was shared with. |
| ISO/IEC 42001 | It sustains the controls on resources for AI systems and on the AI system life cycle — you cannot demonstrate life-cycle management for systems that are not listed. |
| EU AI Act | A prerequisite for risk-tier classification: you can only classify what you know exists. |
| NIST AI RMF | The Map function, the framework's first, is essentially the exercise of inventorying and contextualising. |
| ISO/IEC 27001 | AI systems are information assets and suppliers; they belong in asset management and in third-party management. |
This is why it is worth building one good inventory rather than one artefact per framework: the same inventory answers all of them, with different projections.
Four expensive mistakes
- Inventorying only what was purchased. Leaves out exactly the risky part: what got in without passing through anyone.
- Stopping at the tool name.“ChatGPT” is not a record. A personal account and a corporate plan of the same tool sit in different legal situations — see LGPD and AI tools.
- Keeping it in an isolated spreadsheet. It survives the first quarter and dies in the second, when whoever maintained it changes teams.
- Not recording who answered. Without a named owner and a date, the inventory is not evidence — it is memory.
Frequently asked questions
What is an AI-BOM?
An AI-BOM (AI Bill of Materials) is the structured inventory of every artificial-intelligence system an organisation uses, buys or builds — including models, third-party tools, agents, pipelines and integrations. For each item it records purpose, input and output data, owner, vendor, processing jurisdiction and risk level.
How is an AI-BOM different from a software inventory?
A software inventory answers 'what is installed'. An AI-BOM answers 'what decides, generates or processes, based on which data, under whose responsibility'. An AI tool used only through the browser appears in no software inventory, and neither does an AI feature embedded in an already-approved system.
Who is responsible for maintaining the AI inventory?
In practice it works when responsibility is shared: IT maintains technical discovery and the record; privacy validates legal basis and purpose; and each area manager answers for usage within their team. An inventory maintained by IT alone ends up technically correct and without business context.
How often should the AI-BOM be updated?
Discovery should be continuous and automated; editorial review, quarterly. An inventory updated by hand once a year describes the past — the set of AI tools in use at a company changes in weeks, not years.