AI Bill of Materials (AI-BOM): What It Is and How It Supports EU AI Act Compliance
AI-BOM is an emerging practice, not a statutory term. Structures base models, datasets and GPAI dependencies to feed Article 11 / Annex IV docs.
An AI Bill of Materials is an inventory of the components that make up an AI system — the base models or foundation models it builds on, the datasets used in training and fine-tuning, the third-party libraries and frameworks, the external APIs and services it calls, and the configuration or prompt templates that shape its behaviour. The term borrows directly from software engineering, where a Software Bill of Materials (SBOM) documents every dependency in a codebase. Extending that practice to AI systems adds layers the classic SBOM doesn't cover: data provenance, model versioning, licensing terms for training data, and records of the downstream documentation received from model providers.
One thing to be clear about upfront: "AI-BOM" is an emerging industry practice, not a term defined in Regulation (EU) 2024/1689 (the EU AI Act). The Regulation has no article titled "AI Bill of Materials" and imposes no duty to produce a document by that name. What the Act does impose — on providers of high-risk AI systems — is a set of obligations that a well-structured AI-BOM directly feeds: the technical documentation required under Article 11 and Annex IV, the data governance record under Article 10, and the system-composition evidence needed for a conformity assessment under Article 43. Treat the AI-BOM as a practical tool for organising what the Act requires, not as a named legal deliverable.
Why the practice is gaining ground now
Three forces are converging. High-risk AI providers face an Article 11 / Annex IV documentation obligation that requires the general description, design choices, training data (Article 10), and development process — painful to assemble without a structured component inventory. GPAI model providers have obligations under Article 53 to supply downstream deployers with Annex XII information; deployers need somewhere to record what was provided. And the software SBOM practice is already required under US executive order and referenced in European cybersecurity procurement guidance, so organisations with existing SBOM processes are extending them naturally to AI assets.
Whether or not you call it an AI-BOM, the same underlying inventory emerges from EU AI Act compliance. Naming the practice makes it easier to own and audit.
What goes into an AI-BOM
The exact fields depend on your system and role, but the practical minimum breaks into four layers.
Foundation models and base models. For any system built on a third-party model — whether accessed via API or fine-tuned — record the provider name, the model identifier, the version or snapshot date, the licence terms, and the downstream documentation the model provider supplied under Article 53 / Annex XII. If the model carries a systemic-risk designation under Article 51, note that too: it affects your own risk exposure as a deployer building on it.
Training, validation, and fine-tuning datasets. Record the source of each dataset, its licence, any data-processing steps applied (cleaning, filtering, de-identification), and the data governance decisions that govern its use. This feeds Article 10's data-governance requirements directly. For high-risk systems, you also need to document representativeness and the steps taken to detect biases — so the dataset record should capture demographic scope and known limitations.
Libraries, frameworks, and infrastructure dependencies. This is the closest layer to a classic SBOM: your ML framework (PyTorch, TensorFlow, scikit-learn), versioned dependencies, cloud infrastructure, and any specialist libraries (FAISS for vector search, OpenCV for image processing). These feed the cybersecurity and accuracy obligations under Article 15 and the technical documentation's description of hardware requirements.
Third-party services, APIs, and external components. If your system calls an external API at inference time — a translation service, an image-recognition endpoint, a speech-to-text model — record it. This matters for the Article 25 role analysis: if that external service processes personal data or makes consequential sub-decisions, you need to understand whether your reliance on it changes anyone's obligations. It also matters for GDPR data-mapping: personal data leaving your system to a third-party processor requires a lawful basis and, often, a data-processing agreement.
Configuration, prompts, and decision logic. For systems that use a foundation model with a system prompt or structured instructions that materially shape outputs, those prompts are part of the system's design. Version them and record changes. A prompt change that alters how the system makes decisions relevant to high-risk use cases may constitute a substantial modification under Article 3(23), which can trigger a new conformity assessment.
How the AI-BOM feeds specific EU AI Act obligations
Article 11 and Annex IV technical documentation
An AI-BOM maps almost directly onto Annex IV's nine required documentation areas: general description, design choices, training data (Article 10), validation and testing, risk management, human oversight, change history, standards applied, and the EU declaration of conformity. If the inventory is maintained in a structured format, producing the Annex IV pack becomes a presentation exercise rather than an archaeological dig.
The deadline for stand-alone Annex III high-risk systems is 2 December 2027 (deferred from the original 2 August 2026 under the Digital Omnibus agreed in May 2026). High-risk AI in Annex I regulated products: 2 August 2028.
Article 53 and Annex XII GPAI transparency
If your system incorporates a GPAI model, the model provider must supply you with Annex XII information: technical documentation per Annex XI, a description of capabilities and limitations, information for downstream compliance, and a training-data summary including copyright. Your AI-BOM should record what documentation the provider actually delivered for each integrated model — demonstrating due diligence to a regulator and supporting your own Article 11 documentation.
GPAI obligations under Chapter V (including Article 53) have applied since 2 August 2025. This is a current, not a future, obligation.
Article 25 role analysis
One of the more consequential uses of an AI-BOM is supporting the Article 25 role analysis. If you place your own name on a third-party high-risk system, substantially modify it (Article 3(23)), or change its intended purpose, you become a provider with the full Article 16 obligation stack. An AI-BOM makes this assessment tractable: when you can see that your system wraps a third-party base model with a custom fine-tuning layer and a proprietary decision-logic layer, you can judge whether the totality constitutes a substantial modification. Without the inventory, that judgment is guesswork.
Article 15 security and vulnerability management
Article 15 requires high-risk AI systems to maintain appropriate accuracy, robustness, and cybersecurity throughout the lifecycle. Knowing your versioned dependencies lets you track CVEs immediately — when a security advisory affects a library or endpoint, the BOM tells you whether you are exposed. This extends classic SBOM CVE management to cover model-level issues: prompt injection, model poisoning, and inference attacks.
GDPR data-mapping
For any AI system that processes personal data, the AI-BOM intersects with your GDPR record of processing activities (GDPR Article 30). Training data containing personal data, inference logs, user-input data flowing to a third-party API — these all require a lawful basis and often impact assessments. The BOM's dataset and third-party-service layers surface the personal-data flows the GDPR record needs. For deployers who must conduct an Article 27 Fundamental Rights Impact Assessment, the BOM's data-layer information is an essential input.
The SBOM connection: SPDX and CycloneDX AI extensions
CycloneDX has published an ML-BOM profile that adds fields for model cards, dataset components, service components, and their licences. SPDX 3.0 includes a dataset profile for recording data provenance and licences. These are not EU legal requirements — they are industry standards — but they offer a ready-made structure for the fields above and integrate with existing software supply-chain tooling.
If your engineering team already produces SBOMs, extend that process: add model components, dataset components, and service components as additional types, then export the AI-relevant fields into your compliance documentation.
Practical: minimum viable AI-BOM fields
For a team starting from scratch, this is a workable starting point:
| Layer | Fields to capture |
|---|---|
| Base / foundation models | Provider, model ID, version/snapshot, licence, Annex XII documentation received, systemic-risk status |
| Training datasets | Name/source, licence, volume, demographics (where personal data is involved), preprocessing steps, data governance owner |
| Fine-tuning data | Source, licence, scope, relationship to base model training |
| Libraries / frameworks | Name, version, licence, security advisory tracking |
| Third-party APIs / services | Provider, endpoint, data sent at inference, DPA status, GPAI obligations if applicable |
| Prompts / configs | Version, description of decision-relevant instructions, change log |
| Documentation received | What each GPAI provider supplied under Art 53 / Annex XII, date received |
Keep this under version control alongside your codebase. When the system changes, update the BOM. When you do a conformity assessment under Article 43, the BOM is the starting point for the Annex IV documentation pack.
How Confir helps
Confir's AI inventory records the system composition information that feeds your Article 11 / Annex IV technical documentation pack — system description, design choices, data used, development process. For systems that integrate GPAI models, the inventory captures the GPAI dependencies and the Annex XII downstream documentation received from model providers. The classification engine — rule-based and deterministic, not AI-assisted — derives the correct role (Provider Article 16 / Deployer Article 26) from plain-English intake, flags whether an Article 25 role-conversion risk exists, and maps the system's components to the applicable compliance controls.
Frequently Asked Questions
Is an AI-BOM legally required under the EU AI Act?
No. The term "AI Bill of Materials" does not appear in Regulation (EU) 2024/1689. What the Act requires of high-risk AI providers is technical documentation per Article 11 and Annex IV, data governance documentation per Article 10, and evidence of a risk management system per Article 9. An AI-BOM is an organisational practice that structures the information those obligations need — it is the means, not the legal duty itself.
Which organisations should maintain an AI-BOM?
Any organisation that develops or substantially modifies AI systems (a provider under Article 16), particularly those in or near high-risk use cases, benefits most. Deployers who integrate GPAI models should also maintain at least a partial BOM recording the Annex XII documentation they receive from model providers under Article 53. Minimal-risk deployers using off-the-shelf tools with no customisation can often rely on the provider's documentation instead.
How does an AI-BOM relate to the Annex IV technical documentation?
Annex IV specifies nine areas providers must document for high-risk AI systems — general description, design choices, development data, validation and testing, risk management, human oversight measures, change history, standards applied, and the EU declaration of conformity. An AI-BOM's component inventory maps directly onto the system-description and data-governance sections. Maintaining the BOM continuously means your Annex IV pack can be assembled from existing records rather than reconstructed at the point of a conformity assessment under Article 43.
What should be recorded about a GPAI model integration?
At minimum: the provider name, model identifier, version or snapshot date, the licence terms for the model, and the documentation the provider supplied under Article 53 / Annex XII (capability description, training-data summary, copyright policy). If the model carries a systemic-risk designation under Article 51, record that. Note the date you received the documentation — this evidences your due diligence.
Does a prompt or system instruction count as a component?
Yes, where the prompt materially shapes the system's decisions. A system prompt that configures how a foundation model performs a consequential task is part of the system's design logic. Version it and record changes. A significant change to a system prompt — one that alters the intended purpose or decision criteria — may constitute a substantial modification under Article 3(23), which can require a fresh Article 43 conformity assessment.
How does an AI-BOM interact with GDPR obligations?
Training data and inference inputs that involve personal data must be covered by your GDPR record of processing activities under Article 30 GDPR. The AI-BOM's dataset and third-party-service layers surface exactly which personal data flows exist, which processors handle them, and where cross-border transfers occur. For deployers running a Fundamental Rights Impact Assessment under Article 27 of the EU AI Act, the BOM's data-layer information is an essential input.
When do GPAI-related BOM obligations actually apply?
GPAI model obligations under Chapter V (Articles 51–55) have applied since 2 August 2025. A deployer integrating a GPAI model should already be in receipt of Annex XII documentation from the model provider and should have that recorded. The Digital Omnibus high-risk deferral (which moved stand-alone Annex III deadlines to 2 December 2027) does not affect Chapter V — the GPAI obligations are already live.
Related guides
- AI system inventory software
- Annex IV technical documentation specifications
- mandatory technical documentation requirements
- high-risk AI classification criteria
- Article 8 compliance obligations
- Article 9 risk management obligations
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →