TL;DR: Annex IV technical documentation is required for all high-risk AI providers before placing a system on the EU market. The deadline for most Annex III systems is now December 2, 2027 (extended by the Digital Omnibus). Article 50 obligations still apply August 2, 2026; GPAI model provider obligations have been in effect since August 2, 2025. Start building documentation now: nine sections, each with a clear template.
If your organization develops an AI system that falls into an Annex III high-risk category, EU AI Act Article 11 requires you to draw up technical documentation before placing the system on the market. The documentation demonstrates that your system meets the Act's requirements. It is also the file a national supervisory authority or notified body will review if your system is ever investigated or audited.
The good news from the Digital Omnibus: the original August 2, 2026 deadline for most Annex III stand-alone systems has been extended to December 2, 2027. This gives providers additional time to build complete documentation. The bad news: documentation assembled under deadline pressure is typically worse than documentation built iteratively during development. Starting now, with the December 2027 deadline ahead, is the right approach.
Who needs Annex IV documentation
Annex IV applies to providers of high-risk AI systems. High-risk AI systems are defined by inclusion in Annex III, which covers AI used in:
- Biometric identification and categorization of natural persons
- Management and operation of critical infrastructure
- Education and vocational training (access decisions, student assessment)
- Employment and workers management (recruitment, task allocation, performance monitoring, promotion, termination)
- Access to essential private services and essential public services (credit scoring, life insurance risk assessment)
- Law enforcement
- Migration, asylum, and border control management
- Administration of justice and democratic processes
If you build an AI system in any of these categories and place it on the EU market or put it into service in the EU, you are a provider subject to Annex IV obligations. Deployers who substantially modify a high-risk system also become providers for that modified system.
The deadline situation
| System type | Original deadline | Post-Omnibus deadline |
|---|---|---|
| Annex III stand-alone high-risk AI | August 2, 2026 | December 2, 2027 |
| AI embedded in Annex I regulated products | August 2, 2027 | August 2, 2028 |
| GPAI model providers | August 2, 2025 | August 2, 2025 (not extended) |
| Article 50 transparency obligations | August 2, 2026 | August 2, 2026 (not extended) |
The Digital Omnibus extension covers Articles 9-15, including the Annex IV documentation requirement. GPAI and transparency obligations are outside the scope of the extension.
What Annex IV requires: all 9 sections
Annex IV specifies nine required elements of technical documentation. The depth and format of each section should be proportionate to the complexity of your system. An SME with a relatively simple AI-assisted HR screening tool will produce a shorter document than an enterprise provider of a complex biometric identification system, but both must address all nine sections.
Section 1: General description
This section introduces the system at a high level. It should be readable by a regulator who has not previously encountered your product.
Required content:
- The intended purpose of the AI system, stated concisely
- The version(s) of the system covered by this documentation
- How the AI system interacts with hardware or software it is intended to be used with
- The versions of software, firmware, and algorithms used
- A description of the hardware on which the AI system is intended to run
- Where applicable, a description of how the AI system interacts with persons or other AI systems
Template structure:
1. General Description
1.1 Intended Purpose
[Name of system] is an AI system designed to [specific intended purpose]. The system is deployed in [deployment context] and intended for use by [intended user categories].
1.2 System Version
This documentation covers version [X.Y.Z], released [date].
1.3 System Interactions
The system interfaces with [downstream systems], receives input from [upstream systems or users], and produces [output type] for [downstream use].
1.4 Software and Algorithm Versions
Foundation model: [name, version, provider]
Additional models: [list]
Application framework: [name, version]
1.5 Hardware Requirements
[Minimum hardware specification required to run the system]
Section 2: Design specifications and development process
This section describes how the system was built. It should give an auditor enough information to understand the technical design choices and why they were made.
Required content:
- Design specifications of the system including general logic and key design choices
- Training methodologies, techniques, and any fine-tuning used
- Training data and datasets used, including data sources, data processing steps, and data governance measures
- Validation and testing procedures used during development
- Evaluation metrics and known limitations
Template structure:
2. Design and Development
2.1 System Architecture
[Description of the AI system's architecture, key components, and information flow]
2.2 Training Methodology
[Description of training approach, fine-tuning, or in-context learning methods used]
2.3 Training Data
Data sources: [list of datasets, including provenance and curation method]
Data governance: [how data quality, representativeness, and absence of bias were evaluated]
Data retention: [whether training data is retained and under what controls]
2.4 Testing and Validation
[Description of testing procedures, benchmarks used, and performance against those benchmarks]
2.5 Known Limitations
[Documented limitations in accuracy, coverage, or reliability, including identified edge cases]
Section 3: Monitoring, functioning, and control
This section explains how the system's performance is monitored over time and how users can exercise control over its outputs.
Required content:
- Capabilities and limitations in performance, including accuracy for specific persons or groups
- Foreseeable unintended outcomes and sources of risks to health, safety, and fundamental rights
- Human oversight measures, including the technical measures facilitating human interpretation of outputs
- Specifications for input data, including data formats and data specifications
Template structure:
3. Monitoring and Control
3.1 Performance Characteristics
[Accuracy, precision, recall, or other relevant metrics, disaggregated by relevant subgroups where applicable]
3.2 Known Risks
[Documented foreseeable failure modes and their potential impacts on individuals]
3.3 Human Oversight Measures
[How the system presents outputs to human reviewers, what information is displayed to support review, and how reviewers can override or reject AI-generated outputs]
3.4 Input Data Specifications
[Required input format, data types, acceptable value ranges, and handling of out-of-distribution inputs]
Section 4: Performance metrics and appropriateness assessment
This section justifies why the metrics used to evaluate the system are appropriate for its specific use case, including for persons who may be particularly affected.
Required content:
- Description of evaluation metrics and why they are appropriate for the intended purpose
- Performance broken down by relevant demographic groups or use contexts where the system may perform differently
- Assessment of whether performance metrics are adequate to detect discriminatory effects
Section 5: Risk management system documentation
Article 9 requires providers to establish, implement, document, and maintain a risk management system for the full lifecycle of the system. Section 5 of Annex IV requires that system to be documented.
Required content:
- Description of the risk management process
- Identification and analysis of known and foreseeable risks to health, safety, and fundamental rights
- Risk mitigation measures implemented
- Residual risks and how they are communicated to deployers
Template structure:
5. Risk Management
5.1 Risk Management Process
[Description of the ongoing process for identifying, assessing, and mitigating risks]
5.2 Identified Risks
[Table listing: Risk ID, risk description, likelihood, severity, affected persons or groups, and mitigation measure]
5.3 Mitigation Measures
[Description of technical and procedural controls implemented to address identified risks]
5.4 Residual Risks
[Risks that cannot be fully mitigated and how they are communicated to deployers in the system's instructions for use]
Section 6: Changes and versions
This section tracks changes to the system across versions, including changes made after the initial conformity assessment.
Required content:
- Description of any changes made after the initial conformity declaration
- Assessment of whether changes constitute a "substantial modification" triggering a new conformity assessment
- Updated documentation sections for each change
This section is often underdeveloped in initial documentation submissions. Establish a change log discipline from the start. Any change to model weights, training data, system architecture, or deployment scope should be documented with an assessment of whether it is a substantial modification.
Section 7: Standards and common specifications applied
This section lists which harmonised standards or common specifications the system was designed to meet.
Required content:
- Harmonised standards applied, including standard number and edition
- Common specifications applied (if harmonised standards do not exist for the relevant requirements)
- Where neither exists: a description of the solutions adopted to meet the Act's requirements
As of mid-2026, harmonised standards for the EU AI Act are still being finalized by CEN/CENELEC. Monitor the Official Journal of the EU for publications. Until harmonised standards are finalized, document the solutions adopted and the requirements they address.
Section 8: EU Declaration of Conformity
The EU Declaration of Conformity is a formal declaration by the provider that the high-risk AI system conforms to the requirements of the EU AI Act.
Required content:
- Provider name and address
- System name and version
- Statement that the system conforms to applicable AI Act requirements
- Reference to the applicable conformity assessment procedure
- Signature of authorized signatory
The Declaration of Conformity must be kept with the technical documentation file and made available to national competent authorities on request.
Section 9: Post-market monitoring plan
Article 72 requires providers to have a post-market monitoring system in place. Section 9 documents that plan.
Required content:
- Process for collecting and reviewing information about performance after deployment
- Key performance indicators and thresholds that trigger review
- Procedures for handling serious incidents and reporting them to competent authorities
- Process for updating documentation and re-assessing conformity in response to post-market findings
Template structure:
9. Post-Market Monitoring Plan
9.1 Monitoring Process
[Description of how operational performance data is collected, analyzed, and reviewed]
9.2 Key Performance Indicators
[List of metrics monitored, measurement frequency, and thresholds that trigger formal review]
9.3 Serious Incident Response
[Definition of a serious incident for this system, escalation path, and reporting obligations to national competent authorities]
9.4 Documentation Update Process
[How the technical documentation file is updated in response to monitoring findings or system changes]
SME simplification provisions
Article 11(2) allows SMEs and start-ups to provide technical documentation "in a simplified manner." Until the Commission publishes its simplified documentation form, practical simplifications for SMEs include:
- Proportionate depth: A less complex system requires less documentation. A rule-based screening tool with transparent logic requires less Section 2 documentation than a black-box neural network.
- Combined sections: Where sections overlap naturally (e.g., Section 5 risk management and Section 3 foreseeable unintended outcomes), document them in combined form with clear cross-references.
- Living document: Documentation does not have to be complete and polished on day one. A living document updated iteratively as the system develops is more useful and more defensible than a document assembled entirely in the final weeks before a deadline.
- EU AI Office helpdesk: The EU AI Act SME helpdesk provides free guidance on documentation questions. See EU AI Act SME sandbox and support measures for access details.
How to start building documentation now
Given the December 2, 2027 deadline for most Annex III systems, the practical starting point is establishing a documentation structure now and populating it as the system develops.
Month 1:
- Confirm whether your system is in-scope for Annex III (classification analysis)
- Create an Annex IV documentation shell with all 9 sections
- Complete Sections 1 and 3 for current system state
- Establish the change log for Section 6
Months 2-6:
- Populate Section 2 as training and development decisions are documented
- Begin Section 5 risk management documentation with initial risk table
- Review Section 7 for applicable harmonised standards as they are published
6-12 months before deadline:
- Complete all 9 sections
- Commission conformity assessment (third-party notified body if required for your category)
- Sign the EU Declaration of Conformity (Section 8)
- Finalize the post-market monitoring plan (Section 9)
For the timeline of what applies when, see the EU AI Act what is delayed vs what applies August 2026 guide and the EU AI Act Digital Omnibus deadline extension article.
Related reading
- EU AI Act compliance guide for small teams
- EU AI Act Digital Omnibus August 2026 deadline extension
- EU AI Act deployer evidence gaps SME August 2026
- EU AI Act first enforcement actions Q3 2026
- EU AI Act SME sandbox and support measures
- ISO 42001 vs NIST AI RMF for small teams
- AI governance checklist 2026
- AI compliance checklist by team size 2026
- AI regulation deadline calendar 2026
