Why technical documentation decides whether you can sell at all
Businesses preparing for the EU AI Act tend to treat technical documentation as the paperwork that follows the real compliance work. It is closer to the opposite. Under Article 11, it is the artefact that demonstrates compliance — what a notified body assesses, what a market surveillance authority asks for, and what a customer’s procurement team will demand long before any regulator does. A high-risk AI system whose documentation is not in order does not have a paperwork problem; it cannot lawfully be placed on the market.
The timing catches companies out. The documentation must exist before the system is placed on the market or put into service, and be kept up to date thereafter. Much of what Annex IV calls for is retrospective — how the model was developed, what data shaped it, what assumptions were made, what was tested and with what result. Reconstructing it eighteen months later, from the memories of engineers who have moved on, is the most expensive mistake in this area.
What Article 11 requires, and who owes it
Article 11(1) requires the technical documentation of a high-risk AI system to be drawn up before it is placed on the market or put into service, and kept up to date. It must demonstrate compliance with the requirements for high-risk systems, and give national competent authorities and notified bodies the necessary information, to assess it. It must contain, at a minimum, the elements set out in Annex IV. The duty falls on the provider — and a business that puts its own branding on a third-party system, or substantially modifies one, can become a provider and inherit it in full.
Article 11(2) deals with AI related to products covered by the legislation listed in Section A of Annex I. There, a single set of technical documentation must be drawn up containing both the Annex IV information and the information required under the sectoral act. This is a deliberate anti-duplication rule worth taking up: for a medical device or regulated equipment, the AI Act content belongs inside the technical file the business already maintains, not in a parallel folder that will drift out of alignment within a year.
What Annex IV actually asks for
Annex IV sets out nine categories of information, introduced by a chapeau requiring the documentation to contain at least that information, as applicable to the system. The “as applicable” qualifier does real work where a category genuinely does not arise — but a category skipped without explanation reads as an omission.
What the system is and how it was built
The first category is a general description: intended purpose, provider and version; how the system interacts with hardware or software that is not part of it; the forms in which it is placed on the market; the user interface; and the instructions for use. The second is a detailed description of the system’s elements and of the development process — the methods and steps taken, including any use of pre-trained systems or third-party tools; the design specifications and general logic of the algorithm; the architecture and computational resources; the data requirements and training methodologies; the human oversight measures needed and any pre-determined changes; the validation and testing procedures with test logs and reports; and the cybersecurity measures. Businesses find the second hardest, because it describes engineering decisions that were rarely documented as legal evidence when they were made.
How it is monitored, and how well it performs
The third category covers monitoring, functioning and control: capabilities and limitations in performance, including accuracy for specific groups; foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights and discrimination; the human oversight measures needed under Article 14; and specifications on input data. The fourth asks why the chosen performance metrics are appropriate — a short item that is surprisingly hard to write honestly.
Risk management, changes and standards
The fifth, sixth and seventh categories require a detailed description of the risk management system in accordance with Article 9; a description of relevant changes made by the provider through the system’s lifecycle; and a list of the harmonised standards applied whose references have been published in the Official Journal. Where no such harmonised standards have been applied, the documentation must instead contain a detailed description of the solutions adopted to meet the high-risk requirements, including a list of other relevant standards and technical specifications applied.
Conformity, and life after launch
The eighth category is a copy of the EU declaration of conformity referred to in Article 47. The ninth is a detailed description of the system in place to evaluate the AI system’s performance in the post-market phase in accordance with Article 72, including the post-market monitoring plan — broader than the plan alone, and the reason the file cannot be finalised at launch.
The SME and small mid-cap simplification that does not yet exist
The Digital Omnibus made one substantive change to Article 11, aimed at smaller businesses. The second subparagraph of Article 11(1), as replaced, provides that SMEs including start-ups, and small mid-cap enterprises, may provide the Annex IV elements in a simplified manner using a form the Commission shall establish for their needs; that a business opting for simplification shall use that form; and that notified bodies shall accept it for the conformity assessment. The change from the 2024 text is twofold: small mid-caps were added, and the form’s target group was corrected, the original wording having promised a form for “small and microenterprises” while extending eligibility to all SMEs.
There is a practical gap to plan around: the Commission has not published the form. Because the amended text says a business opting for simplification “shall use the form”, the relief is not currently exercisable. Smaller providers should build to full Annex IV expectations for now, structured so the content can be mapped onto a simplified form when one appears. The related change to Article 17(2) extends the proportionality of quality management system implementation to small mid-caps, while adding that providers must in any event respect the degree of rigour and level of protection required. Proportionality goes to how obligations are implemented, never to the level of protection achieved.
Practical example
An Uppsala education technology company with forty employees sells an AI system that evaluates student work and helps determine progression between course levels. Education and vocational training is Annex III point 3, so the system is high-risk, and market surveillance for that point falls to Post- och telestyrelsen under the interim Swedish designations of June 2026.
The company qualifies as an SME and its instinct is to wait for the simplified form. That is wrong twice over: the form does not exist, and almost everything Annex IV requires is generated during development rather than after it. The realistic starting point is to capture, now, what will otherwise be lost — which pre-trained models and third-party tools went in and on what terms, how the data sets were assembled, what testing was run and what the logs showed, what accuracy the system achieves for different student groups, and what its known limitations are. Because no harmonised standard has been cited, the company also needs its own reasoned account of why what it built meets the requirements. And it should assume the file will be read by an authority that has never seen the product: Article 21 requires providers, on a reasoned request, to supply all information necessary to demonstrate conformity in a language easily understood by that authority, and to give access to the system’s automatically generated logs to the extent they are under the provider’s control.
Common mistakes companies make
The first is starting too late. The documentation must exist before the system is placed on the market, and most of its content records decisions already taken, so a company that begins the file when it begins the conformity assessment has already lost the evidence it needs.
The second is treating it as a one-off deliverable. Article 11(1) requires it to be kept up to date, and Annex IV expressly requires a description of relevant changes made through the lifecycle. A file reflecting version 1.0 of a system now running at 3.4 is not compliant, and the gap is easy for an assessor to spot.
The third is underestimating how long it must be kept. Article 18 requires the provider to keep the technical documentation at the disposal of national competent authorities for a period ending ten years after the system has been placed on the market or put into service, and where the provider is established outside the Union, Article 22(3) requires the authorised representative’s mandate to empower it to keep that documentation, the declaration of conformity and any notified body certificate available for the same ten years. That is longer than most companies retain almost anything, and longer than many will retain the staff who can explain it.
The fourth is duplicating rather than integrating. For AI inside products already covered by Section A of Annex I, Article 11(2) contemplates a single set of documentation covering both regimes; businesses that keep a separate AI Act file alongside their existing technical file end up with two documents that disagree, which is worse than either alone.
Recommended actions
Treat the Annex IV structure as the outline of a live document rather than a checklist completed at the end. The practical test is whether an engineer joining today could read the file and understand how the system was built, what it can and cannot do, what was tested and with what result, and what has changed since. If they could not, an assessor will not either. For anything you cannot yet evidence, record it as a known gap with a plan — a documented gap reads very differently from a silence.
Then build the retention and response capability, because documentation you cannot produce is documentation you do not have. Set a ten-year retention policy for the technical file and the declaration of conformity, decide now who holds it if the product is discontinued or the team disbands, and make sure logs stay retrievable. Smaller providers should build to full Annex IV expectations while the simplified form remains unpublished, and for AI embedded in regulated products, integrate the AI Act content into the existing technical file rather than running two documents in parallel.
Frequently asked questions
When does the technical documentation have to be ready?
Before the system is placed on the market or put into service, and it must be kept up to date after that. The Digital Omnibus deferred the high-risk obligations for Annex III systems to 2 December 2027 and for Annex I systems under Article 6(1) to 2 August 2028, but those are the dates the obligations bite, not the dates the work should begin.
We are a small company. Can we use the simplified documentation?
Article 11(1) as amended allows SMEs including start-ups, and small mid-cap enterprises, to provide the Annex IV elements in a simplified manner using a form the Commission is required to establish, and notified bodies must accept that form. The difficulty is that the form has not been published. Since the text says a business opting for simplification shall use the form, the option is not usable until one exists.
How long do we have to keep it?
Article 18 requires providers to keep the technical documentation at the disposal of national competent authorities for ten years after the system has been placed on the market or put into service. Providers established outside the Union must ensure their authorised representative is empowered to do the same under Article 22(3). Financial institutions subject to internal governance requirements under Union financial services law maintain it as part of the documentation kept under that law.
Conclusion
Technical documentation is where the AI Act’s abstract requirements become concrete and auditable, and where the gap between well-run and poorly-run development shows up fastest: a business that documented its design choices, data decisions and test results as it went will find Annex IV a matter of organisation, while one that did not will find it archaeology. With no harmonised standards yet cited, every provider must explain in its own words why what it built meets the requirements — and with a ten-year retention period attached, those words will outlast most of the people who wrote them.
Lawgent helps businesses build Annex IV technical documentation for high-risk AI systems, integrate it with existing product technical files, and set up retention and disclosure processes that hold up to regulatory requests.
