The EU AI Act does not use the phrase software supply chain, but several articles ask for what supply chain controls produce: records of components, written agreements with suppliers, resilience against tampering, and documentation that follows a model downstream. This is our working map, not an official crosswalk, so check it against your counsel's reading.
Which obligations apply, and when?
Most of the heavy requirements fall on providers of high-risk AI systems. The Act's explorer site shows Article 15 coming into force on 2 December 2027 for high-risk systems under Annex III and on 2 August 2028 for those under Annex I, per Article 113(c). Its timeline page, last updated 31 August 2026, lists the same split. Obligations for providers of general-purpose AI models began on 2 August 2025.
Dates have moved before. Confirm them against the Official Journal text before you plan.
Article 15: accuracy, resilience and cybersecurity
Article 15 requires high-risk systems to reach an appropriate level of cybersecurity and to stay resilient against unauthorised third parties trying to alter use, outputs or performance by exploiting vulnerabilities. Its list of AI-specific attacks names manipulation of training data (data poisoning), pre-trained components used in training (model poisoning), adversarial examples, confidentiality attacks and model flaws.
Supply chain mapping: vetting and scanning third-party models and datasets before use, pinning versions, verifying integrity and watching for tampering all speak to the poisoning language. The article says technical solutions should "prevent, detect, respond to, resolve and control" such attacks, which is the same lifecycle a vulnerability program runs.
Article 25: responsibilities along the AI value chain
Paragraph 4 requires the provider of a high-risk system and any third party supplying an AI system, model, tools, services, components or processes used in it to specify, by written agreement, the information, capabilities, technical access and assistance needed for the provider to comply. The paragraph does not apply to third parties making tools, services or components publicly available under a free and open-source licence, other than general-purpose AI models.
Supply chain mapping: a supplier inventory, contract clauses for security information and notification, and a way to request a component list from vendors. Note the open-source carve-out is narrow. It still leaves you responsible for the system you ship.
Article 53: documentation that travels downstream
Providers of general-purpose AI models must keep technical documentation and make information available to providers who integrate the model, so those providers understand its capabilities and limitations and can meet their own obligations. There is an exception for some open-source models, but it does not apply to models with systemic risk.
Supply chain mapping: when you integrate someone else's model, ask for that documentation and store it with your component records. If you cannot get it, write down the gap.
Articles 11 and 17: documentation and quality management
Article 11 requires technical documentation drawn up before market placement and kept up to date, with at least the elements in Annex IV. We did not review Annex IV for this post, so read it directly. Article 17 requires a quality management system covering, among other things, change management, data management, test and validation procedures, record-keeping, post-market monitoring, serious incident reporting and resource management including security-of-supply measures.
Supply chain mapping: a living bill of materials for software and models, change records, provenance for data and a supplier-continuity plan feed these documents. They do not substitute for them.
What about proof?
Controls only count if you can show them. Keep inventories, scan results, supplier agreements and change records in a form you can hand to an assessor. A tool can produce evidence for these records, and it does not make you compliant with the Act.
What to do
- Decide whether you are a provider, deployer, importer or distributor for each AI system. Article 25 can turn a deployer into a provider.
- Inventory every model, dataset, library and service inside each system.
- Add security and documentation clauses to supplier contracts, per Article 25(4).
- Request model documentation from general-purpose model providers and file it.
- Add integrity checks and scanning for models, datasets and dependencies before they enter a build.
- Link change management and incident procedures to your quality management system.
- Re-check the application dates each quarter.
Quick check
Does the EU AI Act require an SBOM?
Not by that name, in the articles we reviewed. It requires technical documentation, supplier agreements and resilience against tampering. A bill of materials is a practical way to support them.
Does using open-source components remove supplier obligations?
Only partly. Article 25(4) excludes some free and open-source third parties, but not general-purpose AI models, and you remain responsible for your high-risk system overall.
Sources
- AI Act Explorer, Article 15 (accuracy and cybersecurity)
- AI Act Explorer, Article 25: Responsibilities Along the AI Value Chain
- AI Act Explorer, Article 53: Obligations for Providers of General-Purpose AI Models
- AI Act Explorer, Article 17: Quality Management System
- AI Act Explorer, Article 11: Technical Documentation
- AI Act Explorer, Implementation Timeline
Last reviewed: 18 October 2026.
