On this page
- What is an AI-BOM?
- AI-BOM vs SBOM: what is the difference?
- What does the EU AI Act actually require?
- What changed in 2026, and what did not
- Why is the inventory the part that fails?
- What does an AI inventory have to catch?
- Which AI-BOM format should you use?
- How do you build an AI-BOM that stays true?
- How CybeDefend generates the AI-BOM
- Frequently asked questions
- What is an AI-BOM?
- What is the difference between an AI-BOM and an SBOM?
- Does the EU AI Act require an AI-BOM?
- Did the AI Omnibus remove the technical documentation requirement?
- Which format should an AI-BOM use, CycloneDX or SPDX?
- Am I the provider if I only fine-tuned someone else's model?
- How do you find shadow AI in a codebase?
- How often should an AI-BOM be regenerated?
Article 11 of the EU AI Act asks for technical documentation. Annex IV then spends nine sections describing what that documentation has to contain, and almost every line of it is a question about composition: which models, which datasets, which design choices, which oversight, which changes over the lifecycle. None of that can be written before someone can answer a much smaller question first. What AI is in this codebase? Most organisations cannot answer it. Not because the regulation is unclear, but because the AI in a modern repository arrives one commit at a time, frequently written by an agent, and no document survives that cadence. This is what an AI Bill of Materials is for, and why the useful version of it is a build artifact rather than a spreadsheet.
What is an AI-BOM?
An AI-BOM, or AI Bill of Materials, is a machine-readable inventory of every artificial-intelligence component that a software system contains, together with the provenance and governance facts about each one. Where an SBOM lists packages, versions and licences, an AI-BOM lists models, datasets, prompts, agents, tools and guardrails, and records where each came from, what it is allowed to do, and which regulatory risk class it falls into.
The idea is a direct descendant of the software bill of materials. US Executive Order 14028 made SBOMs a condition of federal software procurement in 2021, and the practice outlived the executive order's own political fortunes because it turned out to be the only workable answer to "what is actually running here". AI systems raise the same question with a wider surface. A dependency has a version and a licence. A model has a version, a licence, a provider, a set of weights that may be local or remote, a training corpus you may not control, a fine-tune history, an inference configuration, an evaluation record, and a capability envelope. None of that fits in a package.json.
AI-BOM vs SBOM: what is the difference?
They answer different questions about the same repository, and the difference is not cosmetic. An SBOM is a list of things you installed. An AI-BOM is a list of things that make decisions.
| SBOM | AI-BOM | |
|---|---|---|
| Unit of inventory | Package, library, container image | Model, dataset, prompt, agent, tool, guardrail |
| Provenance question | Which registry, which version, which licence | Which provider, which training data, which fine-tune, which licence |
| Risk question | Is there a known CVE in this version | What can this component decide, and about whom |
| Change trigger | A dependency bump | A new model string, a re-tuned prompt, a new tool granted to an agent |
| Regulatory anchor | NIS2, CRA, procurement rules, EO 14028 | EU AI Act Art. 11 + Annex IV, NIST AI RMF, ISO/IEC 42001 |
| Detection | Manifest files, lockfiles | Code references, config, notebooks, agent definitions, prompt files |
The last row is where most tooling stops. A dependency declares itself in a lockfile. A model does not. openai/gpt-4o-mini appears as a string literal in a service file. A local model appears as a .gguf path in a config. An MCP server appears as a URL in .mcp.json. A prompt appears as a markdown file nobody registered anywhere. There is no manifest to parse, so an AI inventory has to be derived by reading the code itself.
What does the EU AI Act actually require?
Article 11 requires providers of high-risk AI systems to draw up technical documentation before the system is placed on the market or put into service, and to keep it up to date. Annex IV sets the minimum contents. Article 18 requires the provider to keep that documentation, along with the quality-management-system records and the EU declaration of conformity, for ten years after the system is placed on the market.
Read Annex IV as a questionnaire and its shape becomes obvious. It is nine sections, and the majority of them are questions about what the system is made of and where those pieces came from.
Mapped item by item, the correspondence is close enough that the documentation task becomes an export problem for most of the pack, and a genuine research task for the rest.
| Annex IV section | What it asks for | What answers it |
|---|---|---|
| §1 General description | Intended purpose, provider, version, interactions with other hardware and software | System entry, version, owner, plus every external model endpoint and tool the system talks to |
| §2(b) Design specifications | System logic, algorithms, key design choices | Model references, orchestration framework, versioned prompts, agent topology |
| §2(c) Architecture and compute | System architecture and computational resources used | Inference runtime, deployment target, local weights, hosted endpoints |
| §2(d) Data requirements | Datasheets on training methodologies, datasets, provenance, labelling, cleaning | Dataset references with origin, licence and role (train, fine-tune, eval, RAG corpus) |
| §2(e) Human oversight | The oversight measures built into the system | Guardrail coverage, plus an oversight design that no BOM format holds natively |
| §2(g) Validation and testing | Procedures, metrics, test logs and reports | Evaluation runs and performance metrics attached per component |
| §2(h) Cybersecurity | The measures protecting the system | Secret handling, tool scope, injection controls on agent inputs |
| §3 Capabilities and limitations | Accuracy, including for specific persons or groups | Fairness and subgroup metrics, which again no BOM format holds natively |
| §5 Risk management | The Article 9 risk-management system | Per-component risk classification under Articles 5, 6 and 50 |
| §6 Lifecycle changes | Changes made to the system through its lifecycle | The diff between two inventories, commit by commit |
| §9 Post-market monitoring | The monitoring plan under Article 72 | Continuous rescan, plus drift status per component |
Two sections in that table are marked as not natively held by any bill-of-materials format, and they are the two that consume the most audit time in practice: subgroup accuracy (§3) and human oversight design (§2(e)). No BOM standard has a field for "who can override this decision, through which interface, with what training". An AI-BOM gets you the composition. It does not get you the assessment. Anyone selling you the opposite is selling you a spreadsheet with a new name.
What changed in 2026, and what did not
The AI Omnibus entered into force on 27 July 2026, after the European Parliament adopted it on 16 June and the Council on 29 June. It is a targeted simplification of the AI Act rather than a rewrite, and the headline is a deferral.
The Omnibus also created a "small mid-cap" category, defined as fewer than 750 employees and turnover at or below 150 million euros, and extended to it the simplified technical-documentation templates and proportionate quality-management requirements that previously only SMEs could use. It did not touch Annex IV's contents. The list of things you have to be able to say about your system is the same list it was in 2024.
Two other Omnibus changes matter for documentation work specifically. Article 10(5) now provides a clearer legal basis for processing special-category personal data where it is strictly necessary to detect and mitigate bias, subject to safeguards, which removes a genuine catch-22: teams could not measure subgroup accuracy because they were not allowed to collect the attribute that would let them measure it. And Article 40(2) obliges the Commission to request unified standards covering the AI Act and existing harmonisation legislation together, so a single product does not have to satisfy two parallel documentation regimes.
Why is the inventory the part that fails?
Because AI components enter a codebase through channels that were not designed to be inventoried, and they now enter faster than any review cadence.
The measured version of this is stark. IBM's Cost of a Data Breach Report 2026, run by Ponemon across 602 breached organisations between March 2025 and February 2026, found that the share of security incidents involving shadow AI more than doubled year over year.
of security incidents involved shadow AI, more than double the year before
organisations have no governance process to limit shadow AI at all
of organisations restrict access to their AI systems; the rest do not
Shadow AI is usually discussed as an employee problem: someone pastes customer data into a consumer chatbot. That framing badly undercounts it. The larger and quieter version is shadow AI in the repository. A model string added to a service. A HuggingFace dataset pulled into a notebook. An MCP server pointed at a production database for a debugging session and never removed. A prompt file edited to loosen a constraint. Each is a one-line change. Each changes what the system is, and therefore what its Annex IV documentation would have to say. None of them announces itself.
That third step is the one that has changed since the AI Act was drafted. When a human engineer chose a model, there was a decision, usually a conversation, sometimes a design document. When an AI coding agent writes the integration, it selects a model, a client library and a default configuration in a single edit, and the record of that decision is a diff nobody reads line by line. We wrote about the general shape of this problem in why most SAST findings are noise and in business logic flaws in AI-generated code; the AI-BOM case is the governance version of the same cadence mismatch.
An inventory maintained as a document describes the day it was written. An inventory derived from the code describes today. Only one of those two survives an audit that arrives eighteen months after the last review meeting.
What does an AI inventory have to catch?
Six categories, and every one of them is a place where the composition of the system is decided. Miss any of them and the Annex IV pack has a hole an auditor will find by reading the code you handed over as evidence.
Models
Hosted model strings (OpenAI, Anthropic, Google, Mistral), HuggingFace identifiers, and local weights shipped as .gguf or .onnx files. Each needs a provider, a version pin, a licence and a card reference. A model referenced only as an environment variable default is still a model in production.
Datasets
Training, fine-tuning, evaluation and RAG corpora, each with an origin and a licence. Annex IV §2(d) asks specifically about provenance, labelling and cleaning. An internal dataset with no recorded licence and no documented origin is the single most common gap in a first scan.
Prompts
System prompts, templates and instruction files, versioned. A prompt is a design specification under Annex IV §2(b): it defines the system logic. Treating it as untracked content is the reason prompt drift is invisible until behaviour changes in production.
Agents and orchestration
LangChain, LlamaIndex, CrewAI, Semantic Kernel, AutoGen, and hand-rolled ReAct loops. The framework determines the capability envelope: what the system is permitted to attempt on its own, and how many steps it can take before a human sees anything.
MCP servers and tools
Every tool endpoint an agent can call, with its scope. This is the fastest-growing and least-inventoried surface of the six. A tool pointed at a production datastore turns a text-generation feature into a system that can act on records, which is a different risk class entirely.
Guardrails
Llama Guard, NeMo Guardrails, Guardrails AI, and any bespoke filter. What matters most here is the negative result: the component that has no guardrail at all. Coverage gaps are evidence under Annex IV §2(e), and they only surface if you enumerate them deliberately.
Which AI-BOM format should you use?
CycloneDX is the practical default. It has supported machine-learning models since version 1.5 in 2023, the current specification is 1.7 (released 21 October 2025) and it is standardised as ECMA-424, so it is a real standard rather than a vendor schema. SPDX 3.0 offers an ISO-aligned alternative through its AI Profile. Both are JSON-serialisable, both slot into existing SBOM pipelines, and both are supported by open tooling.
A minimal CycloneDX ML-BOM component looks like this.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"version": 1,
"components": [
{
"type": "machine-learning-model",
"bom-ref": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3",
"name": "support-triage-v4",
"version": "2026-06-11",
"modelCard": {
"modelParameters": {
"approach": { "type": "supervised" },
"architectureFamily": "Transformer (Mistral-7B, fine-tuned)",
"datasets": [
{ "ref": "urn:cdx:dataset-support-tickets-2025h2", "type": "training" }
]
},
"quantitativeAnalysis": {
"performanceMetrics": [
{ "type": "accuracy", "value": "0.881", "slice": "all locales" }
]
},
"considerations": {
"useCases": ["tier-1 support triage"],
"technicalLimitations": ["degrades below 0.72 on locales unseen in training"]
}
}
}
]
}
That covers Annex IV §1, §2(b), §2(c), §2(d) and part of §2(g) in one object. What it does not cover, and what you will therefore carry as custom properties or as separate documents, falls into three buckets.
Data lineage beyond a reference
A dataset ref says which corpus. Annex IV §2(d) asks how it was obtained, how it was labelled and cleaned, and what was excluded and why. That is a provenance record, not a pointer.
Bias and subgroup assessment
Which fairness metric, measured on which protected attribute, at which threshold. CycloneDX carries performance metrics; it does not carry a fairness methodology or its results.
Human oversight design
Article 14 wants intervention points, stop mechanisms and the competence profile of the person supervising. No BOM standard models this. It is a design document that the inventory should link to, not replace.
Risk classification rationale
Whether a component is prohibited, high, limited or minimal risk under Articles 5, 6 and 50, and why you concluded that. The classification is a judgement; the inventory is what makes the judgement auditable.
Alongside the format sits the reporting layer. The NIST AI Risk Management Framework (AI 100-1) organises AI risk work into Govern, Map, Measure and Manage, and its Map function is close to a definition of the inventory task: document the system's context, components, capabilities and limitations. ISO/IEC 42001 requires an AI management system with an AI inventory and risk assessment at its core. Neither is a format. Both consume the same underlying facts, which is the practical argument for generating those facts once, mechanically, and projecting them into whichever framework a given auditor or customer questionnaire speaks.
How do you build an AI-BOM that stays true?
The failure mode of every governance inventory is identical, and it has nothing to do with the initial effort. Someone runs a discovery exercise, interviews the teams, fills a spreadsheet, and the artefact is accurate for about a week. What follows is not laziness; it is arithmetic. Components change faster than review cycles.
So the design constraint comes first, and the steps follow from it.
-
Derive the inventory from the code, never from a questionnaire. A questionnaire captures what people remember. A scan captures what shipped. The two diverge immediately, and only one of them is what an auditor will be reading.
-
Pin every component to a file and a line. An inventory entry without a source location is an assertion. An entry with
src/lib/triage.ts:23next to it is evidence, and it is also what makes remediation assignable to a team instead of a committee. -
Classify at the component level, not the system level. Articles 5, 6 and 50 apply to what a component does. One repository routinely contains a minimal-risk chat helper, a limited-risk customer-facing assistant and a genuinely high-risk scoring model. A single system-level label hides exactly the component that matters.
-
Flag status, not just presence. Governed, shadow, drifted, missing. A component with a model card and a licence is a different object from the same component with neither, and the whole value of a first scan is the ratio between those two piles.
-
Regenerate on every push and diff it. Annex IV §6 asks for the changes made through the lifecycle. If the inventory is regenerated per commit, that section writes itself; the diff is the change log. If it is regenerated per quarter, someone has to reconstruct it from memory.
-
Gate the pipeline on new ungoverned components. A build that fails when a prohibited or high-risk component lands without documentation is the only control that keeps the ratio in step 4 from drifting. Everything softer than a gate degrades into a dashboard nobody opens.
-
Contract for the information you cannot scan. Your scan sees what your repository contains. It does not see a vendor's training corpus. Article 25(2) and 25(4) put the cooperation obligation on the upstream provider, so put it in the contract too: model cards, training-data summaries, and notification when a model version changes underneath you.
-
Keep it for ten years. Article 18 is explicit, and ten years is longer than most artefact-retention policies, longer than most CI providers' default retention, and considerably longer than the average tenure of the engineer who built the system. Export the pack somewhere durable.
How CybeDefend generates the AI-BOM
Everything above is the general case. Here is how we implement it, because the design constraint in the previous section is precisely the one we built for.
CybeDefend's AI-BOM scanner walks a repository and catalogues the six categories directly from the code: models (hosted strings, HuggingFace identifiers, local .gguf and .onnx weights), datasets referenced in code or config, versioned prompts, agent and orchestration frameworks, the MCP servers your agents consume, and the guardrail libraries in use. Every item lands with its source file and line, its version pin, and a status: governed, shadow, drift or missing. There is no questionnaire and no interview round.
One scan then emits three artefacts into ./.ai-bom/, which is the part that matters for the work described above.
The first is an EU AI Act compliance report mapped to Regulation (EU) 2024/1689, with each component sorted into prohibited, high, limited or minimal risk under Articles 5, 6 and 50, GPAI components counted separately, and systemic-risk components flagged. The second is a NIST AI RMF function-coverage mapping across Govern, Map, Measure and Manage, with gaps named rather than averaged away. The third is the machine-readable CycloneDX AI-BOM, so the inventory slots into whatever SBOM tooling you already run.
It runs where you ship. Add the cybedefend-action to a GitHub workflow, or call the CybeDefend CLI from GitLab CI, a Jenkinsfile or Tekton, and the scan executes on every push with the report published as a build artifact.
- name: CybeDefend Security Scan
uses: CybeDefend/cybedefend-action@v2
with:
pat: ${{ secrets.CYBEDEFEND_PAT }}
project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
branch: ${{ github.ref_name }}
break_on_severity: high
That is step 5 and step 6 of the list above, implemented: the inventory regenerates per commit, so Annex IV §6 becomes a diff, and the build exits non-zero when a new prohibited or high-risk component lands without governance documentation. The scan reads your repository and produces a structured inventory; source code does not leave your environment, and the dashboard receives component metadata only, never raw code or prompt content.
The AI-BOM sits alongside the rest of the platform rather than inside the agent loop. It is a repository-and-pipeline scanner, which is the right place for an inventory: it needs the whole tree, not the current edit. What runs inside the agent loop is VibeDefend, which loads your business and security rules into the agent before it writes, intercepts unsafe actions, and keeps SAST, SCA, secrets, IaC and CI/CD findings live in the agent's context. The two are complementary. VibeDefend governs what the agent does as it writes; the AI-BOM records what the codebase became.
Frequently asked questions
What is an AI-BOM?
An AI-BOM, or AI Bill of Materials, is a machine-readable inventory of every AI component in a system: models, datasets, prompts, agents and orchestration frameworks, the tools and MCP servers those agents call, and the guardrails applied to them. Each entry carries provenance and governance facts such as provider, version, licence, data origin, capability scope and risk classification. It extends the SBOM concept from software packages to AI assets, and it is the underlying evidence for EU AI Act Article 11 and Annex IV technical documentation, NIST AI RMF reporting, and ISO/IEC 42001 AI inventories.
What is the difference between an AI-BOM and an SBOM?
An SBOM lists software components (packages, versions, licences) and is used mainly to find known vulnerabilities. An AI-BOM lists AI components and their AI-specific governance facets: training-data origin, fine-tune lineage, prompt versions, agent capability scope, guardrail coverage and residual risk. They are complementary rather than competing, and CycloneDX can express both, so an AI-BOM can be produced in the same format and pipeline as your existing SBOM.
Does the EU AI Act require an AI-BOM?
Not by that name. The AI Act never uses the term. Article 11 requires providers of high-risk AI systems to draw up technical documentation before the system is placed on the market and to keep it up to date, and Annex IV sets the minimum contents: general description, design specifications, architecture, data requirements and provenance, human oversight, validation and testing, cybersecurity, capabilities and limitations, risk management, lifecycle changes and post-market monitoring. An AI-BOM is the practical way to produce most of that pack mechanically. Article 18 then requires the documentation to be kept for ten years after the system is placed on the market.
Did the AI Omnibus remove the technical documentation requirement?
No. The AI Omnibus entered into force on 27 July 2026 and deferred the high-risk obligations for stand-alone Annex III systems from 2 August 2026 to 2 December 2027, and for high-risk AI embedded in regulated products from 2 August 2027 to 2 August 2028. It also created a "small mid-cap" category (fewer than 750 employees, turnover at or below 150 million euros) that can use simplified technical-documentation templates. Annex IV's contents were not changed, Article 50 transparency obligations stayed on their original date, and GPAI obligations have applied since 2 August 2025 with Commission enforcement powers live from 2 August 2026.
Which format should an AI-BOM use, CycloneDX or SPDX?
CycloneDX is the pragmatic default. It has supported machine-learning models since version 1.5 (2023), the current specification is 1.7 (October 2025), and it is standardised as ECMA-424, with modelCard, modelParameters, dataset references and quantitativeAnalysis fields covering most of the composition facts. SPDX 3.0's AI Profile is the ISO-aligned alternative and is a reasonable choice if your organisation already standardises on SPDX. Neither has native fields for bias-assessment methodology or human oversight design, so those are carried as custom properties or as linked documents in both cases.
Am I the provider if I only fine-tuned someone else's model?
Usually yes. Article 25(1) treats a party as the provider of a high-risk AI system if they place it on the market under their own name or trademark, if they substantially modify it, or if they change its intended purpose so that it becomes high-risk. Fine-tuning an existing model on your own data and shipping it under your product name typically triggers all three. The original lab's model card documents the base model only; the Article 11 documentation obligation for your system rests with you, and Article 25(2) and 25(4) oblige the upstream provider to cooperate and supply information rather than to write your pack.
How do you find shadow AI in a codebase?
By scanning the code rather than surveying the teams. AI components rarely declare themselves in a manifest: a hosted model appears as a string literal, a local model as a weights path in config, a dataset as a URI in a notebook, an MCP server as a URL in an agent config, a prompt as an untracked markdown file. A repository scan resolves each of these to a component with a file and line, then flags the ones with no model card, no licence, no version pin and no recorded owner. IBM's Cost of a Data Breach Report 2026 found shadow AI involved in 43% of security incidents and more than two-thirds of organisations with no governance process to limit it, so the expectation for a first scan should be that the shadow pile is larger than the governed one.
How often should an AI-BOM be regenerated?
On every push. Annex IV §6 asks for the changes made to the system through its lifecycle, and a per-commit inventory turns that section into a diff instead of a reconstruction exercise. A quarterly inventory is stale within days in any repository where AI coding agents write integrations, because a model change, a new tool grant or a prompt edit is a one-line commit. Regenerating in CI and failing the build when a new high-risk or prohibited component lands without documentation is what keeps the artefact and the codebase in agreement.
