The Technical File sits at the centre of EU AI Act compliance for high-risk AI systems. It is the document a notified body or market surveillance authority will inspect. It must exist before the CE marking is applied. And for organisations whose AI systems were built before the Regulation came into force, it requires a level of retrospective documentation that most development teams were never asked to produce.
Article 11 introduces the requirement. Annex IV specifies the content. What neither conveys clearly is how much work assembling a complete file involves for a system that was not designed with this documentation in mind.
What Annex IV requires
The Regulation groups the Technical File's contents into eight areas.
General description of the system. The intended purpose, the categories of users, and the conditions under which the system is designed to operate. This sounds straightforward. In practice, many systems have drifted from their original intended purpose as they were deployed across new use cases — and the Technical File must accurately describe the system as deployed, not as originally conceived.
Description of the elements of the AI system. The software architecture, the logic of each component, and the relationships between them. For systems built on third-party foundation models, this includes a description of how the model was selected, configured, and integrated, and what the provider's obligations are under any applicable GPAI rules.
Detailed information about the monitoring, functioning and control of the AI system. How the system is monitored in production, what metrics are tracked, and how anomalies are detected and escalated. Many organisations have operational monitoring for uptime and latency but not the AI-specific monitoring — drift detection, output quality, edge-case performance — that the Regulation has in mind.
Description of the risk management system. Annex IV cross-references Article 9 here. The Technical File must describe the risk management process, not just its conclusions. That means documenting the methodology used to identify risks, the tests performed, the residual risks accepted, and the reasoning behind those acceptances.
Changes made in the development lifecycle. Any significant modification to the system — a new training run, a change in intended purpose, a major update to the software — must be recorded. For systems that have been iterated on continuously over several years, reconstructing this history is often the most time-consuming part of Technical File preparation.
Assessment of the measures applied to achieve accuracy, robustness and cybersecurity. The performance metrics the system is evaluated against, the datasets used for testing, and the results. The Regulation does not set specific accuracy thresholds — it requires that providers establish appropriate measures for the intended use case and document how those measures were chosen.
Technical specifications for training, validation and testing. The datasets used — their provenance, scope, and any known biases or limitations. For systems trained on proprietary data, this section requires the organisation to be candid about what the data represents and where it may not generalise.
Declaration of conformity and CE marking documentation. The Technical File must contain the signed declaration of conformity required by Article 47 and a record of the CE marking applied under Article 48.
The retrospective problem
Building a Technical File for a system designed from the outset with EU AI Act compliance in mind is tractable. The documentation is produced as part of the development process. The harder problem — and the one most organisations face — is assembling a Technical File for a system that has been in production for two or three years.
The common gaps we encounter are as follows.
Training data lineage is unclear. The team that originally sourced the training data has turned over. The datasets have been updated without full records of what changed. The pipeline that produced them no longer exists in its original form. Reconstructing a credible account of the training data for Annex IV requires forensic work that the Regulation does not make optional.
Architectural decisions were not documented at the time. Why was a particular model architecture chosen? What alternatives were considered? What testing determined that the current approach was adequate? In fast-moving development environments, these decisions are made and implemented without producing the written records that the Technical File requires.
The risk management process was informal. The team identified risks — they always do — but not through a formal process that produced documented risk registers, test results, and explicit acceptance of residual risks. Reconstructing this after the fact is not impossible, but it requires the honest acknowledgement that the documentation is retrospective.
Post-market monitoring was not designed. Article 9 and Annex IV both require a description of how the system will be monitored once deployed. Many organisations have not designed this — monitoring for AI-specific failure modes (output drift, distributional shift, misuse by users) is distinct from conventional software monitoring.
How long it takes
For a system that was designed without AI Act compliance in mind, a complete Technical File typically requires eight to sixteen weeks of focused effort. The range is wide because the difficulty depends almost entirely on the state of existing documentation.
The eight-week end of that range applies when: the original development was well-documented; the team that built the system is still largely in place; the training data is well-governed; and the organisation has operational monitoring it can extend for AI-specific purposes.
The sixteen-week end applies when: documentation is sparse or scattered; the system has iterated significantly since its original version; the training data pipeline is poorly understood; and post-market monitoring needs to be designed and implemented rather than extended.
What to do before August 2026
The full application date for high-risk AI systems under Article 6(2) and Annex III is 2 August 2026. That is not when organisations need to start working on their Technical Files — it is when the files need to be complete and the CE marking applied.
Given realistic timelines, an organisation that has not begun Technical File preparation by the time this is published is at material risk of non-compliance by the deadline.
The practical starting point is a classification decision (is this system high-risk?) followed by a documentation audit (what do we have, and what do we need to produce?). The gap between the two determines the scope of the work.
Reference: Regulation (EU) 2024/1689, Articles 9, 11, 18, 47, 48, Annex IV, Annex VI.
