TL;DR
The EU AI Act sets binding obligations for AI systems placed on the EU market, with most high-risk and transparency requirements scheduled to apply on 2 August 2026. A proposed delay to December 2027 is under negotiation but has not been adopted. In practice, compliance with Article 11, Article 50 and Article 53 depends on being able to inventory and document the AI/ML components embedded inside the software being shipped. Most enterprises cannot yet do this at code level.
What is the EU AI Act?
The EU AI Act, formally Regulation (EU) 2024/1689, is the first comprehensive legal framework for artificial intelligence. It entered into force on 1 August 2024 and applies in phases, based on a risk classification of the AI systems concerned. Prohibited practices have been illegal since 2 February 2025. General-purpose AI model obligations applied from 2 August 2025. Most remaining obligations — including the requirements for high-risk AI systems listed in Annex III and the transparency duties under Article 50 — are scheduled to apply from 2 August 2026.
The Regulation applies to providers and deployers of AI systems placed on or used in the EU market, regardless of where the organisation is established
When does the EU AI Act actually apply?
The headline date for most enterprises is 2 August 2026. On 7 May 2026, the Council presidency and the European Parliament reached a provisional agreement on the Digital Omnibus package, which would postpone the application of high-risk obligations under Annex III by 16 months, with a separate 12-month postponement for AI embedded in regulated products such as medical devices, machinery and toys. The grace period for AI-generated content transparency solutions was reduced from six months to three, with watermarking compliance due on 2 December 2026.
The Omnibus agreement still requires formal adoption. Until it is adopted, the legally binding deadline remains 2 August 2026.The substantive obligations do not change materially across the possible outcomes. The date by which compliance must be demonstrated does.
Penalties under Article 99 reach up to €35 million or 7% of global annual turnover for prohibited-practice violations, €15 million or 3% for high-risk system non-compliance, and €7.5 million or 1% for supplying incorrect information to authorities.
What does the EU AI Act actually require?
For high-risk AI systems, providers must establish a risk management system, govern training and testing data, maintain technical documentation, log automated operations, ensure human oversight, and meet accuracy, robustness and cybersecurity standards. It includes a description of the AI system, its components, the data used in development, and the methods and tools applied.
Article 50 introduces transparency obligations for AI systems that generate or manipulate content, including the labelling of synthetic output.
Article 53 obligates providers of general-purpose AI models to publish a sufficiently detailed summary of the content used to train the model.
How does the EU AI Act affect software that contains AI components?
AI/ML capability is now embedded across mainstream software products, often without being declared at the package boundary. A typical enterprise application may include API calls to commercial large language model providers, open source ML libraries such as PyTorch or TensorFlow, model files distributed alongside containers, fine-tuned model weights stored as static assets, or orchestration code from frameworks such as LangChain. These components are AI systems or components of AI systems under the Regulation, but they are rarely visible to the procurement, compliance and legal functions that own the AI Act response.
The Regulation does not separate AI built in-house from AI integrated from third parties. If an AI system is placed on the EU market, the obligations follow the system. Article 11 technical documentation must describe the system’s components. Article 50 transparency rules apply to systems that generate or manipulate content, regardless of whether the underlying model is in-house or hosted by a third party. Article 53 obligations for general-purpose AI providers may flow to deployers that materially modify a model and present it as their own.
In practice, this means an AI Act response begins with an accurate, code-level inventory of every AI/ML component in scope. Without it, the technical documentation duties imposed by the Regulation sit on incomplete foundations.
How does SCANOSS support EU AI Act readiness?
SCANOSS addresses EU AI Act readiness through the AI governance dataset, based on the AI Finder. The dataset is built specifically for inventorying AI/ML components inside software. Detection operates at snippet level rather than at the package manifest, which is necessary because AI components — SDK calls, model file references, embedded API keys, machine learning library imports — are frequently inlined, vendored or copied in ways that manifest-only tools do not surface.
The AI Governance dataset identifies AI/ML SDKs and libraries across 12 programming languages and over 150 packages, including widely deployed components such as OpenAI, Anthropic, Hugging Face transformers, PyTorch, TensorFlow, ONNX and LangChain. It surfaces model file references, API keys and credentials with call-chain context showing which model and provider the credential is reaching, and package metadata covering versions, licences, maintainers and origin.
Output is produced in two standards-compliant AIBOM formats: OWASP AIBOM CycloneDX 1.6, and SPDX with AI BOM Profile. Both feed internal governance dashboards, procurement portals and SBOM aggregators; the CycloneDX AIBOM is additionally consumable by OWASP Dependency-Track.
In practice, this provides the inventory layer that Article 11 technical documentation, Article 50 transparency obligations and Article 53 general-purpose AI training-content summaries depend on but do not generate.
The other SCANOSS datasets attach to the same scan where the use case requires it. The Encryption dataset supports ECCN compliance and quantum-readiness planning. The Security dataset links components to vulnerability intelligence from the NVD, OSV, EUVD and GitHub Advisories. The Licence dataset identifies obligations attached to the open source elements bundled inside AI/ML packages.
What should organisations do now?
The next quarter’s work is the same regardless of how the Omnibus negotiation resolves. Inventory the AI systems placed on the EU market and the AI development tools used to build them. Classify each system against the Annex III categories in force today. Identify a single point of accountability in writing. Begin generating the Article 11 technical-file evidence that any future assessor will request, including the AIBOM coverage that documents AI-generated code.
Treating the Omnibus delay as permission to pause is not advisable. Evidence accumulated steadily over the coming months sits in a stronger position than evidence assembled under deadline pressure.
