TL;DR
Article 11 of the EU AI Act requires providers of high-risk AI systems to compile technical documentation before market placement and keep it current for the system’s lifetime. The compliance deadline for standalone high-risk systems has moved from August 2026 to December 2027, but the documentation burden itself hasn’t changed, and most organisations still can’t produce an accurate inventory of the AI components, models and data sources their own systems depend on.
EU AI Act Article 11: what technical documentation actually requires
Article 11 applies to providers of high-risk AI systems under the EU AI Act. It sets three obligations that sit alongside each other rather than in sequence. Technical documentation must exist before the system is placed on the market or put into service. It must be kept up to date throughout the system’s operational life, not just at the point of initial certification. And it must be made available to national competent authorities and notified bodies on request, in a form clear enough for them to assess compliance without needing to reverse-engineer the system themselves.
The content requirements are set out in Annex IV, covering the system’s general description, its design and development process, how it’s monitored and controlled, its performance metrics, its risk management measures, a record of changes across its lifecycle, the standards applied, and its post-market monitoring plan. Small and micro enterprises can use a simplified form covering the same ground, but the obligation itself isn’t reduced, only the format.
This documentation should be clear and comprehensive, including elements specified in Annex IV, and where a high-risk system is embedded in a product already covered by EU harmonisation legislation, a single unified set of documentation is required rather than parallel filings.
What deadline actually applies now?
The deferral pushes compliance for standalone high-risk AI systems under Annex III from 2 August 2026 to 2 December 2027, and for AI embedded in products already covered by EU product-safety law under Annex I, to 2 August 2028. This came via the Digital Omnibus on AI, which was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, days ahead of the original deadline.
The deferral is real, but it’s worth being precise about what it covers. Transparency obligations under Article 50, including labelling AI-generated content and informing people they’re interacting with an AI system, largely kept their original timeline. The watermarking-specific element of that requirement was pushed to December 2026. Article 11 itself wasn’t rewritten. What changed is the date by which providers of standalone high-risk systems need to have it done, not the substance of what “done” means.
Systems already on the market before the new deadlines can often avoid full high-risk obligations until they undergo a substantial modification, at which point the clock resets against the current requirements. Organisations that don’t know which of their deployed systems would count as substantially modified, or when, risk finding out at the least convenient moment.
Why does documentation break down in practice?
Most technical documentation efforts fail for a structural reason rather than a lack of effort. Annex IV asks for a description of the system as it actually is: its data sources, its development process, its components, its known limitations. But most organisations don’t have a reliable, current inventory of what’s actually inside their AI systems. Documentation gets written once, against the system as understood at the time, and then drifts as models are retrained, dependencies are swapped, and third-party components are added without anyone updating the record.
This is the same failure pattern that has played out for years in software composition analysis, and it applies directly to AI systems because most of them are built on open source foundations. A model built on an open source framework, fine-tuned with third-party datasets, and deployed through an open source inference stack carries provenance obligations at every layer. If the organisation can’t trace what’s actually running, the documentation it produces is a description of what it intended to build, not what it built.
What does source-level visibility add that an SBOM doesn’t?
A software bill of materials tells you what components a system declares. It doesn’t tell you what’s actually inside the code, and for AI systems specifically, it doesn’t capture the provenance of models, training data or fine-tuning sources, which is precisely the material Annex IV asks providers to describe. This is the gap between declared dependencies and actual composition that source-level detection is built to close.
SCANOSS’s AI Finder identifies AI and machine learning components at the code level, including model files and their origins, and outputs an AIBOM that maps what’s genuinely present rather than what a manifest claims. Combined with snippet-level detection against the SCANOSS Knowledge Base, this gives compliance teams something Annex IV implicitly requires but few tools actually provide: an inventory that reflects the system as built, not as documented in a spreadsheet that hasn’t been touched since the last audit. You cannot secure or comply with what you cannot see, and for most organisations preparing for Article 11, the visibility gap sits well below the documentation layer they’re currently focused on.
