AI-BOM: mapping dependencies in an AI system

Key takeaways · 1 minute

An AI-BOM can connect models, datasets, software, infrastructure and external services so organisations can quickly identify systems exposed when a dependency becomes vulnerable or compromised.

Action: identify the assets, dependencies and evidence involved before treating the topic as an isolated requirement.

When a vulnerability affects a software library, a traditional SBOM can help identify the applications that use it.

With artificial intelligence, the question becomes more complex.

An AI system does not depend only on software libraries. It can also rely on multiple models, datasets, frameworks, external services, infrastructure components and APIs. Some are developed internally. Others come from vendors or open-source projects. Some may continue to change after production deployment.

In May 2026, the G7 Cybersecurity Working Group published minimum elements for an SBOM adapted to AI. ANSSI describes this approach as a map of the AI supply chain, deployed components and their dependencies. One of its goals is to improve traceability and reduce response time when vulnerabilities or security flaws emerge.1

The operational challenge can therefore be reduced to one question:

if a model, dataset, library or external service is compromised tomorrow morning, how long will it take to identify every system actually affected?

A software SBOM describes only part of an AI system

The principles of the SBOM remain relevant to AI.

An AI system is also a software system: it uses packages, versions, third-party components and dependency relationships. The international work led by ANSSI and nineteen other authorities in 2025 highlights how an SBOM can help identify software components and support faster action when a vulnerability appears.2

But that information is not always enough to understand an AI system.

Consider an internal RAG assistant.

The application may use:

a front end and a business API;
several Python libraries;
a language model;
an embedding model;
a vector database;
internal documents;
an external API;
GPU or cloud infrastructure;
different security mechanisms.

An inventory limited to software dependencies may correctly identify the version of a Python library while still being unable to answer an essential question:

which applications use the same model or the same dataset?

That is one of the key differences between a traditional SBOM and an SBOM enriched for AI.

The G7 proposes seven families of information

The document published in 2026 does not replace the information found in a traditional software SBOM. It extends it with elements specific to AI systems.

These elements are organised around several families: SBOM metadata, system properties, models, datasets, infrastructure, security properties and performance indicators.1

This significantly changes what needs to be documented.

The focus is no longer only on a software component and its version, but on an entire technical chain.

| Domain | Example of useful information | |---|---| | System | components that make up the system and relationships between them | | Data flows | origin, destination and use of data | | Models | model used, version, provenance and properties | | Datasets | identity, provenance, use and sensitivity | | Software | packages, versions and dependencies | | Infrastructure | resources required to run the system | | Security | protection mechanisms and known vulnerabilities | | External services | APIs and dependencies outside the organisation’s direct control |

The objective is less about producing an exhaustive list than about making visible the relationships required to assess impact.

The real object to map is the dependency chain

A CMDB may indicate that an application contains an “AI” component.

A model catalogue may show that a specific model is used in the organisation.

A data register may list certain datasets.

A dependency manager may know which packages are installed.

Taken separately, each inventory can be accurate.

The problem appears when they need to be connected.

To handle a security alert, a useful representation could follow a chain such as:

business service → application → AI system → model → dataset → software → infrastructure → external service → provider

This is not a regulatory structure imposed by the G7. It is an operational translation of the traceability objective described in the work on SBOMs for AI.

It also enables analysis in both directions.

Starting from an application, teams can identify its dependencies.

But starting from a vulnerable component, they must also be able to work backwards to every application that depends on it.

That second capability becomes critical during an incident.

Constructed case: one vulnerable component used by three AI assistants

Consider a fictional company that has developed three AI systems.

The first is an assistant for customer support.

The second helps legal teams search contract clauses.

The third automatically summarises technical documents.

The three applications are managed by different teams.

Yet they use the same open-source framework to orchestrate their model calls.

A critical vulnerability is disclosed in that framework.

With a properly maintained software inventory, the company can probably identify applications using the vulnerable package quickly.

But now imagine the issue does not affect the framework.

Instead, it affects an embedding model supplied by a third party.

That model is declared directly in the legal assistant. In the support application, it is called indirectly through an internal service. In the third system, it is embedded in a shared platform operated by the Data team.

Three different architectures therefore depend on the same component.

An inventory organised only by application can hide that common dependency.

A usable AI-BOM should support the reverse operation:

affected component → systems using the component → applications → business processes → owners

The speed of that traversal determines part of the time required to assess actual exposure.

Models themselves need to become versioned objects

In many organisations, an application has an explicit version while the model it uses may be documented only by its commercial name.

That is not enough for real traceability.

Two versions of the same model can have different behaviours, dependencies or security characteristics.

The G7 document therefore includes information to identify the model, its producer, its version and certain properties related to its creation and use.1

The same logic should apply to models consumed through an API.

If a provider silently changes the model behind a generic alias, the actual composition of the system may change even though no application deployment has taken place.

An organisation should therefore be able to distinguish at least:

the requested service, the model actually used and the version or state of that model at a given point in time.

Otherwise, the inventory describes a theoretical architecture rather than the one actually running.

Dataset provenance becomes security information

Software can be reproduced from its source code and dependencies.

For an AI model, the dataset is part of its history.

The G7 work therefore calls for information about datasets used throughout the lifecycle, including their identity, provenance and use.1

This is not only useful to Data or legal teams.

It can become cybersecurity information.

Consider a dataset supplied by an external provider and reused to train four internal models.

If its provenance is challenged or it is found to have been compromised, the issue does not concern only the dataset.

Teams need to trace:

dataset → affected training runs → models produced → systems using those models → exposed business services

Without relationships between these objects, the answer often requires manual investigation across several teams.

An AI-BOM turns that sequence of searches into a chain that can be queried.

External APIs are part of the dependency surface

A modern AI system can depend on services that are never installed inside the information system.

Model APIs, search engines, vectorisation services, hosted databases or moderation tools may all sit entirely with a provider.

They may therefore never appear in a local software inventory.

Yet they directly contribute to how the system works.

The G7 document includes this dimension by addressing system flows and interactions with external services.1

This dependency matters especially when several applications rely on the same service.

An outage, behaviour change, vulnerability or provider compromise can then have a transversal effect that remains invisible if dependencies are documented only project by project.

An AI-BOM should not become a static document produced once a year

Another trap would be to treat the bill of materials as a compliance document.

AI systems can change quickly.

A library is updated. A dataset is enriched. A model is replaced. A new API is added. A pipeline is modified.

The G7 document notes that AI SBOM guidance will need to evolve as the field changes rapidly. The broader international SBOM work also emphasises the value of structured information for improving vulnerability management.1 2

The right question is therefore not simply:

“do we have an AI-BOM?”

But rather:

“does our AI-BOM still describe the system that is running today?”

A perfectly documented inventory that is six months old may be less useful than a smaller inventory that is updated whenever significant changes occur.

Composition and criticality are different things

A bill of materials describes what a system is made of.

It does not necessarily say what matters most to the organisation.

To become genuinely useful for cybersecurity, it should therefore be connected to other information:

technical owner;
business owner;
service criticality;
data handled;
environment;
Internet exposure;
relevant providers;
incident response process.

This distinction matters.

An AI-BOM may show that forty systems use the same package.

A broader information-system map may show that three of them support critical business processes and need to be handled first.

The bill of materials therefore provides composition.

Information-system mapping provides impact context.

The two become especially powerful when they can be connected.

The objective is to reduce the time between an alert and understanding its impact

The European Commission also considers AI to be reshaping the cybersecurity landscape: it can strengthen defence, but it can also accelerate and automate certain attacks. Its Action Plan published in July 2026 aims to structure the European response to the cybersecurity risks and opportunities created by advanced AI models.3

In that context, the quality of an inventory should not be measured only by the number of completed fields.

A more useful test is to simulate an alert.

Pick at random:

a model;
a dataset;
a library;
an external API.

Then ask:

Which systems use it?

Which versions?

In which environments?

Which business services depend on those systems?

Who needs to be contacted?

If those answers can be obtained within minutes, the organisation already has usable traceability.

If they require contacting Data, DevOps, Cloud and business teams one after another, the problem is probably not the absence of another security tool.

It is first the absence of a coherent view of AI dependencies.

And that is precisely the problem a well-built AI-BOM should begin to solve.