AI Act Technical Documentation (Annex IV): The Complete Checklist

Technical documentation is the backbone of EU AI Act compliance for high-risk AI systems. Article 11 of Regulation (EU) 2024/1689 requires all providers to draw up and maintain it. Annex IV specifies in detail what it must contain. It is the document that national market surveillance authorities will request first when auditing a provider, and the document that notified bodies will review when conducting third-party conformity assessments.

Many providers have technical documentation — but technical documentation that satisfies the AI Act is not the same as standard software product documentation. This checklist identifies every required element under Annex IV and explains what "complete" means for each one.

How to Use This Checklist

Work through each section. For each item, mark it as: Complete, Partially Complete, or Missing. Any "Missing" item is a compliance gap that must be addressed before the system can lawfully be placed on the EU market. Any "Partially Complete" item requires expansion before an audit.

Annex IV is organised into seven main sections.

Section 1: General Description of the AI System

1.1 Intended purpose

Clear statement of what the system is designed to do
Identification of the specific context and use case (e.g., "credit scoring for consumer loans under €25,000")
Identification of the persons or organisations who will use the system (deployers) and the persons affected by it (subjects)
Statement of the geographic and temporal scope of intended deployment

What "complete" means: The intended purpose must be specific enough that a regulator can determine which Annex III category applies and can assess whether the system's actual capabilities match its stated purpose.

1.2 System categorisation

Identification of the applicable Annex III category (e.g., §1 biometric identification, §5 critical infrastructure, §6 employment and workers management)
Explanation of why this category applies
Confirmation that Article 6 classification rules have been applied

1.3 System description and architecture

Overview of the components of the AI system (data inputs, model, outputs, interfaces)
Description of hardware requirements
Description of software dependencies and versions
Description of interfaces with other systems
Block diagram or architecture overview

Section 2: Detailed Description of Elements and Development Process

2.1 Training methodology

Description of the learning method used (supervised, unsupervised, reinforcement, etc.)
Description of the training algorithms, parameters, and optimisation approach
Description of how the model was trained (computational resources, training environment)

2.2 Training data

This is one of the most scrutinised sections. Article 10 requirements for training data quality flow into the technical documentation obligation.

Description of the training datasets used (source, size, format, content categories)
Description of data collection methodology and provenance
Description of data pre-processing steps (cleaning, normalisation, augmentation)
Description of data labelling methodology and quality controls
Statement on data representativeness: does the dataset represent the population the system will operate on?
Description of known limitations and biases in the training data
Description of measures taken to identify and address bias
Description of the split between training, validation, and test sets
If using third-party datasets: dataset names, providers, and licensing basis

2.3 Validation and testing

Description of the validation methodology
Description of the test datasets (separate from training data)
Performance metrics used and their justification (accuracy, precision, recall, F1, AUC-ROC, as appropriate)
Performance results on test datasets, disaggregated by relevant subgroups (e.g., by age, gender, ethnicity where applicable)
Description of identified failure modes
Description of robustness testing (performance under distribution shift, adversarial inputs, edge cases)
Comparison against baseline or benchmark systems where applicable

2.4 Changes to system over development lifecycle

Description of any significant changes made to the system during development and their impact on performance

Section 3: Information on Monitoring, Functioning, and Control

3.1 System capabilities and limitations

Explicit statement of what the system can and cannot do
Identified performance thresholds below which the system should not be used
Known edge cases where the system may underperform
Description of foreseeable misuse scenarios and how they were addressed in design

3.2 Risk management measures (Article 9)

Description of the risk management process used throughout the development lifecycle
Identification of all foreseeable risks to health, safety, and fundamental rights
Description of risk estimation and evaluation methodology
Description of risk control measures implemented
Residual risks after control measures
Results of testing for foreseeable unintended outcomes

3.3 Human oversight features (Article 14)

Description of the technical features enabling human oversight
Description of stop/pause/override controls available to deployers
Description of how the system flags low-confidence or out-of-distribution outputs
Description of any automated monitoring or alert mechanisms

3.4 Robustness, accuracy, and cybersecurity (Article 15)

Achieved accuracy levels on representative test sets
Description of robustness measures against errors and inconsistencies in input data
Description of technical measures against adversarial attacks
Cybersecurity assessment and measures implemented
Description of data resilience and backup provisions

Section 4: Monitoring, Functioning, and Control of the High-Risk AI System

4.1 Post-market monitoring plan

Description of how the system's real-world performance will be monitored after deployment
Key performance indicators tracked in production
Frequency of performance review
Process for detecting and responding to performance degradation or unexpected outputs
Responsible persons for post-market monitoring

4.2 Logging capabilities (Article 12)

Description of the logging functionality built into the system
Events that are automatically logged
Log retention period and format
Access controls for logs

Section 5: Description of the Conformity Assessment Procedure

Identification of the applicable conformity assessment procedure (Annex VI self-assessment or Annex VII notified body)
If Annex VII: name and identification number of the notified body, certificate number and date
Summary of how each Article 9–15 obligation was assessed and verified

Section 6: EU Declaration of Conformity

Copy of the signed EU Declaration of Conformity (Annex V) included in the documentation package

Section 7: Instructions for Use (Article 13)

The instructions for use are typically a separate document provided to deployers, but they must be referenced in and consistent with the technical documentation.

Intended purpose and context of use
Level of accuracy, robustness and cybersecurity
Known limitations and performance characteristics
Any pre-processing of inputs required
Human oversight requirements
Hardware and software specifications
Identification of changes that would require re-assessment
Any specific measures needed for deployment in particular contexts
Contact information for provider technical support

Common Gaps Found in AI Act Technical Documentation

Overly generic descriptions. "We use a neural network trained on large datasets" is not compliant. The documentation must describe the specific architecture, training data, and validation approach in sufficient detail that an independent expert could evaluate the system's compliance.

Missing disaggregated performance data. Reporting aggregate accuracy (e.g., "92% accuracy") without reporting performance by relevant demographic subgroups is insufficient for high-risk systems where fairness is material.

No treatment of failure modes. Technical documentation that only describes the system working correctly and does not analyse failure modes will fail review.

Incomplete data provenance. Listing dataset names without describing their provenance, licensing basis, and known limitations is insufficient.

Outdated documentation. Technical documentation must reflect the current deployed version. Documentation prepared during development and never updated after model changes or retraining is a common compliance failure.

Maintaining the Technical Documentation

Article 18 of the AI Act requires technical documentation to be kept for at least 10 years after the system is placed on the market or put into service. Article 16(e) requires it to be updated when the system is substantially modified.

Build documentation updates into your model development and release process as a required step, not an afterthought.

How DilAIg Helps

DilAIg's 50-question audit generates your Annex IV Technical Documentation automatically — structured to satisfy every element in this checklist. The audit is designed so that your answers map directly to the required Annex IV sections, producing a complete, regulator-ready document.

Start your free audit at dilaig.com and generate your Technical Documentation in under an hour.

FAQ: AI Act Technical Documentation

Q: Do deployers need to create technical documentation, or only providers? Technical documentation under Article 11 is a provider obligation. Deployers are not required to create Annex IV documentation. However, deployers are required under Article 26(1) to verify that the provider has fulfilled their documentation obligations, and may request access to it for their own due diligence and for FRIA preparation.

Q: How long must technical documentation be? The AI Act does not set a page count. The documentation must be complete — covering every Annex IV element — but it can be as concise or detailed as necessary to accurately describe the system. A simple automated decision-support tool may require 30 pages; a complex multi-modal system may require hundreds. Substance over volume.

Q: Can technical documentation reference other documents? Yes. Technical documentation can reference other documents (test reports, third-party assessments, dataset documentation) rather than reproducing all content inline. Ensure that all referenced documents are available to provide to authorities on request and are identified with sufficient precision (document name, version, date).

Q: Is the technical documentation the same as the instructions for use? No. The technical documentation is an internal compliance document produced by and held by the provider. The instructions for use (Article 13) are a document provided to deployers describing how to use the system. Both are required, and both are distinct.

Key Takeaways

Annex IV of the EU AI Act specifies seven sections of required content for technical documentation, covering system description, development process, monitoring, conformity assessment, and instructions for use.
The most common gaps are: overly generic descriptions, missing disaggregated performance data, no failure mode analysis, and outdated documentation.
Technical documentation must be maintained and updated throughout the system lifecycle and retained for 10 years.
It is the primary document that regulators and notified bodies will review first — invest in quality from the start.