EU AI Act and SBOMs: Software Transparency for High-Risk AI Systems
An AI system is still a software system. An SBOM gives the EU AI Act the software-component transparency its technical documentation and cybersecurity requirements depend on.
- High-risk AI systems run on conventional software; the AI Act's documentation and security duties reach that software too.
- An SBOM documents the libraries and dependencies behind an AI system, feeding Annex IV technical documentation.
- Article 15 requires resilience and cybersecurity, which depends on knowing and patching your components.
- An SBOM pairs with an AI BOM: software components plus models and datasets give the full picture.
An AI system is a software system
The EU AI Act, Regulation (EU) 2024/1689, governs AI systems, but every high-risk AI system is built on ordinary software: web services, data pipelines, inference servers and a long tail of open-source libraries [1]. The Act's technical documentation and cybersecurity duties cannot be met without visibility into that software, which is exactly what an SBOM provides.
SBOMs and Annex IV documentation
Article 11 and Annex IV require a description of the system and its components [2]. For the software layer, an SBOM in CycloneDX or SPDX is the machine-readable answer: every package and version, its licence, and its known vulnerabilities. It is the same evidence the EU Cyber Resilience Act expects, reused for the AI Act.
Article 15: you cannot secure what you cannot see
Article 15 requires high-risk AI to reach an appropriate level of accuracy, robustness and cybersecurity, and to be resilient against attempts to alter its use, outputs or performance [3]. Defending against those attacks starts with knowing your components and keeping them patched. An SBOM correlated with vulnerability data is the foundation:
| AI Act need | SBOM contribution |
|---|---|
| Annex IV component description | Full software inventory with versions and licences |
| Article 15 cybersecurity | Components correlated with CVEs and fix status |
| Supply-chain transparency | Provenance and third-party dependency visibility |
SBOM plus AI BOM
An SBOM covers the software; an AI BOM covers the models and datasets. Together they give an AI Act provider a complete, machine-readable account of what the system is made of.
How IntelliXBOM helps
IntelliXBOM generates and ingests SBOMs in CycloneDX and SPDX, correlates them with vulnerabilities, licences and end-of-life data, and keeps them alongside the AI BOM for the same system. It supplies evidence for AI Act documentation and security; conformity remains the provider's responsibility.
Frequently asked questions
Does the EU AI Act require an SBOM?
It does not name the SBOM, but Article 11 and Annex IV require a description of the system's components, and Article 15 requires cybersecurity. An SBOM is the standard, machine-readable way to meet both for the software layer.
Can one SBOM serve both the AI Act and the CRA?
Yes. The same CycloneDX or SPDX SBOM supports CRA component documentation and AI Act technical documentation, which is why a single, well-maintained SBOM programme is efficient.
How does an SBOM help with Article 15 cybersecurity?
Article 15 requires resilience against attacks that exploit vulnerabilities. An SBOM correlated with CVE data shows which components are vulnerable so you can patch them before they are exploited.
Sources
- Regulation (EU) 2024/1689 (Artificial Intelligence Act)EUR-Lexeur-lex.europa.eu/eli/reg/2024/1689/oj
- AI Act Article 11 and Annex IV: Technical documentationEU AI Act explorerartificialintelligenceact.eu/article/11/
- AI Act Article 15: Accuracy, robustness and cybersecurityEU AI Act explorerartificialintelligenceact.eu/article/15/
- CycloneDX Bill of Materials standardOWASP CycloneDXcyclonedx.org/
- SPDX specification (ISO/IEC 5962)Linux Foundationspdx.dev/
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.