Article 11: Technical Documentation
Article 11 requires providers of high-risk AI systems to draw up technical documentation before placing the system on the EU market or putting it into service. The documentation must demonstrate that the system complies with all requirements in Chapter III of the Act. It must be kept up to date throughout the system's lifecycle, and made available to national market surveillance authorities on request.
What Article 11 Requires and Why
Article 11(1) requires that technical documentation be drawn up before a high-risk AI system is placed on the market or put into service. The documentation must be prepared in such a way that it allows national competent authorities to assess the system's compliance with the requirements of Chapter III. It must contain, at minimum, the information set out in Annex IV.
The rationale is market surveillance: regulators cannot inspect AI systems the way they can inspect a physical product. Technical documentation is the primary mechanism by which a provider demonstrates compliance before and after market access. It is not a marketing document or a user manual — it is a technical audit trail that must be sufficiently detailed to verify compliance claims.
Article 11(3) provides for delegated acts that can update Annex IV as the technology evolves. This means the documentation requirements are not static — providers should monitor official guidance from the European AI Office for changes to what Annex IV requires.
The 9 Annex IV Categories — Full Breakdown
Annex IV specifies what must be included in technical documentation. Each of the 9 categories must be addressed. Below is a breakdown of what each category requires, along with practical notes on what reviewers look for.
General description of the AI system
- The intended purpose of the system
- The name, version number, and identifier of the system
- How the system interacts with hardware or software components not part of the system itself
- The form in which the system is placed on the market or put into service (standalone software, embedded component, API, etc.)
- Hardware on which the AI system runs
- A description of the relevant software or firmware, and version information
Description of elements and development process
- Methods and steps performed for development
- Design specifications including the general logic of the system and its algorithms
- Key design choices including the rationale, assumptions, and trade-offs considered
- Description of system architecture: how software components build on or feed into each other
- Data requirements: training methodologies, training data sets, testing data, and validation data (datasheets)
- Assessment of any known or foreseeable circumstances under which the system may fail or underperform
Monitoring, functioning and control
- Capabilities and limitations of the AI system's performance, including accuracy and error rates on defined test sets
- Known or foreseeable circumstances that may lead to failures or risks
- Description of the human oversight measures required, including technical measures for human-machine interface and oversight tools
- Specifications on input data and the technical measures ensuring the adequacy, sufficiency, and appropriateness of the input data
Appropriateness of performance metrics
- Description of the metrics used to evaluate the system's performance
- Justification that the chosen metrics are appropriate for the intended purpose
- Benchmark results on the defined test sets
- Description of how performance was validated across relevant subgroups where bias or disparate impact is a concern
Risk management system documentation
- The risk management system documentation required under Article 9
- Description of risks identified and their assessment
- Mitigation measures adopted
- Residual risk evaluation and acceptability judgment
Changes made through the lifecycle
- Description of any change made to the system through its lifecycle
- Records of changes after initial market placement or deployment
- Assessment of whether any change constitutes a substantial modification that would require a new conformity assessment
Standards, specifications, and conformity
- List of harmonised standards applied in full or in part
- Where no harmonised standards exist: description of technical solutions adopted to meet the requirements of Chapter III Section 2
- Reference to any common specifications used
EU Declaration of Conformity
- A copy of the EU declaration of conformity signed by the provider
- The declaration must confirm that the high-risk AI system complies with the requirements of Chapter III Section 2
- It must include the provider's identity, the system identifier, and the conformity assessment procedure applied
Post-market monitoring system
- Description of the post-market monitoring plan
- How performance data is collected in production
- How incidents and near-misses are detected and reported
- How monitoring data feeds back into the risk management system (Article 9)
- Procedures for incident reporting to national authorities
Keeping Documentation Current: The Ongoing Obligation
Article 11 does not permit a "complete at launch, file and forget" approach. The documentation must be kept up to date. This is not merely a best practice recommendation — it is a legal obligation.
The practical implication is that documentation must be treated as a living set of documents, version-controlled alongside the software it describes. When a model is retrained, a new version of the training data description (Annex IV category 2) must be created. When the system is deployed in a new context, the intended purpose section (category 1) and the risk management system (category 5) must be updated. When a defect is discovered and patched, the change log (category 6) must record it.
Category 6 — changes made through the lifecycle — exists precisely to capture this history. Market surveillance authorities investigating an incident will review this section to understand what changed between a safe deployment and a problematic one. An incomplete change log weakens your position significantly in any enforcement investigation.
Common Mistakes
Treating documentation as a one-time deliverable
Article 11 requires documentation to be kept up to date throughout the lifecycle. Many teams prepare a thorough document at the point of compliance audit and do not update it as the system evolves. This creates a gap between the documented system and the deployed system.
Vague system descriptions in Annex IV category 1
Statements like 'an AI system that helps HR teams evaluate candidates' do not satisfy the intended purpose requirement. The description must be specific enough that a reviewer can determine which Annex III category applies and what risks are foreseeable from that specific use.
Missing or thin data lineage in Annex IV category 2
Describing the model architecture without describing the datasets used to train and validate it is a common gap. The datasheets requirement in category 2 is substantive — it requires information about data sources, collection methods, known limitations, and steps taken to address bias.
Separating documentation from the risk management system
Article 11 requires the Annex IV technical documentation to include the risk management system documentation (category 5). Teams that maintain separate compliance silos often produce two documents that contradict each other. They must be consistent and cross-referenced.
Generate your full Annex IV documentation pack
Nytivo generates all 9 Annex IV categories from your system data. The documentation stays linked to your risk management system and post-market monitoring — so when something changes, the documentation updates to match.
Start free trialArticle 11 — Frequently Asked Questions
Can I self-certify the technical documentation under Article 11?
For most high-risk AI systems covered by Annex III, yes — providers can carry out the conformity assessment (which includes preparing the technical documentation) as a self-assessment, without a third-party notified body. Exceptions apply to biometric identification systems and AI safety components in regulated products under Annex I, where third-party assessment is required. Self-assessment does not mean light-touch — the documentation must be complete enough to withstand scrutiny from national market surveillance authorities.
What language must the technical documentation be in?
Article 11 does not specify a language requirement, but national competent authorities will review documentation in their own official language(s). In practice, English is widely used as the primary documentation language for multinational providers, but you may need to provide translations when a national authority requests access. The EU declaration of conformity may also need to be in the language(s) of the member states where the system is deployed.
How long must technical documentation be retained?
Article 18 requires providers to keep the technical documentation and the EU declaration of conformity for a period of ten years after the high-risk AI system has been placed on the market or put into service. This ten-year period begins from the date of the specific version placed on the market — updated versions restart the clock for those versions.
Does the technical documentation need to be made public?
No. Technical documentation is confidential commercial information and is not required to be published. It must be available to national market surveillance authorities on request, and to notified bodies where third-party assessment is required. A summary version of key parameters may be included in the instructions of use (required under Article 13), but the full Annex IV documentation is not public-facing.
What triggers an obligation to update the technical documentation?
Any material change to the AI system that affects its compliance with the requirements of Chapter III must trigger a documentation update. This includes changes to the model, training data, deployment context, intended purpose, or performance characteristics. Where a change constitutes a 'substantial modification' under Article 3(23), the entire conformity assessment process must be repeated for the modified system.
Related articles
Technical documentation by industry
Annex IV documentation requirements are the same across sectors, but the content differs — see what applies to your product category.