An AI Bill of Materials (AI-BOM) is an inventory of every AI element inside a software product: the code written by AI assistants, the AI models and LLMs the application calls, the frameworks and datasets behind them. BearingPoint scans your source code, detects code generated with AI tools, identifies the AI models, libraries and services your application relies on, and delivers an audit-ready AI-BOM alongside your SBOM in CycloneDX or SPDX format. The result is one clear answer to three questions: what is in your software, where it came from, and what it obliges you to do.
Why AI-generated code is the new blind spot in your software supply chain
AI coding assistants are part of everyday development, and developers accept their suggestions many times a day. Those snippets enter your repositories without ever appearing in a dependency manifest, so a classic SBOM cannot see them. The code may work perfectly, yet nobody can say where it came from, whether it reproduces licensed open source, or who reviewed it.
Built-in assistant safeguards help, but they do not give complete visibility across all potential sources. The principle we apply is simple: treat AI-generated code as third-party content until its provenance and obligations have been assessed. Developers stay accountable for every line they commit; however it was written.
The same blind spot exists for the AI your product uses at runtime. Foundation models, LLM APIs, agents, prompts and training datasets carry license terms, copyright questions and security exposure that a traditional software inventory was never designed to capture.
AI-generated code scanning: what we detect
Our AI code scanning combines AI code detection with advanced snippet matching, so findings hold up even after generated code has been edited or restructured. Every scan answer four questions.
-
Which code was written with AI?
We identify code sections likely generated with AI coding tools, so you know where AI-assisted contributions sit in your codebase. -
Does it reproduce open source?
Snippet matching compares AI-generated code with known open source, stays reliable when the code is later changed, and shows which license really applies. -
Which AI models and services are in use?
We identify the AI/LLM models, libraries, frameworks and external AI services your application uses, including usage that is undocumented or implicit. -
What do legal and governance teams need to review?
Licensing, copyright and provenance findings are documented in a form your legal, compliance and responsible AI reviewers can act on.
What your AI-BOM contains
An AI-BOM does not replace your SBOM; it extends it with the AI-specific elements a conventional SBOM misses. BearingPoint documents:
- AI-generated code and its provenance
- Foundation models and large language models (LLMs)
- Training and fine-tuning datasets, with data provenance
- AI frameworks and libraries
- Model provenance and lineage
- Support governance, legal review, and responsible AI initiatives
Delivered in CycloneDX or SPDX, the AI-BOM sits next to your SBOM in the same governance process, so there is no second compliance silo to maintain.
AI regulation makes transparency a business requirement
The EU AI Act has entered its implementation phase: obligations for general-purpose AI models already apply, and further transparency obligations apply from August 2026. They put the emphasis on documentation, copyright compliance and the ability to show how an AI system is built and operated. The U.S. Cybersecurity and Infrastructure Security Agency (CISA), together with G7 partners including the European Union, has published the Software Bill of Materials for AI – Minimum Elements guidance, confirming that AI models, datasets and dependencies need their own transparency.
Customers and auditors are asking the same questions in their supplier questionnaires. An AI-BOM built on the same foundation as your SBOM lets you answer regulators, auditors and customers from one source of truth.
SBOM management services: the foundation of your AI-BOM
A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in your software, with version, supplier, license and dependency information. We evaluate your development, DevSecOps and compliance processes to define the right SBOM approach for your business model, risk profile and regulatory exposure. We then build and maintain your SBOMs from source code or, when no source is available, from compiled binaries, and keep them current across every release.
- Reduce security risk by finding vulnerable components before they reach your customers.
- Meet the EU Cyber Resilience Act (CRA), NIS2 and U.S. Executive Order 14028 with less effort.
- Build customer trust through transparent, proactive governance.
- Strengthen your supplier ecosystem with standardized SBOM reporting and clear risk ownership.
- Release faster, with less rework, thanks to reliable component tracking.
Our AI-BOM experts:
Contact - Name:
Contact - Name:
Frequently asked questions
-
What is an AI-BOM (AI Bill of Materials)?
An AI-BOM is a structured inventory of the AI elements in a software product: AI-generated code, AI models and LLMs, datasets, frameworks, agents and prompts, together with their provenance and licence obligations. It extends the Software Bill of Materials (SBOM) so that AI components are governed the same way open source dependencies already are. The term is also written AIBOM or AI BOM.
-
How is an AI-BOM different from an SBOM?
An SBOM lists the software packages and libraries inside a product. An AI-BOM adds what an SBOM was never designed to capture: models, training and fine-tuning datasets, agents, model lineage and code produced by AI assistants. The two work together, and BearingPoint delivers them side by side.
-
Can you detect AI-generated code in our codebase?
Yes. We scan your source code to determine which parts were generated with AI tools and use advanced snippet matching to check whether that code reproduces existing open source, even after it has been modified. You see where AI-assisted code sits, where it may have come from and which license obligations could apply.
-
Why is AI-generated code a licensing risk?
An AI coding assistant can suggest code that closely resembles licensed open source without saying so. Because the snippet never appears in a dependency manifest, dependency scanners miss it, and a copyleft obligation or a missing attribution can ship unnoticed. Treating AI-generated code as third-party content until its provenance is checked closes that gap.
-
Don't AI coding assistants already filter out licensed code?
Some assistants offer code-reference or similarity filters, and they are a useful first layer. They do not provide complete visibility across all potential sources, so independent snippet and similarity detection, combined with policy enforcement and audit reporting, is still needed to demonstrate compliance.
-
Does the EU AI Act require an AI-BOM?
The AI Act does not prescribe a document called an AI-BOM. Its obligations focus on documentation, transparency and copyright compliance, and an AI-BOM is a practical way to hold the evidence they call for. How they apply depends on whether your organization acts as an AI provider, a deployer, or both.