A Guide to Technical Documentation: What Needs to be in your Annex IV File?

Technical Compliance · 12 min read · Updated March 2026

The Annex IV Technical Documentation package is the cornerstone of EU AI Act compliance for high-risk AI providers. It is the “living document” that proves your system was built, tested, and validated properly — and must be maintained for the entire lifecycle of the AI system. This guide walks through every required element, with practical guidance on what regulators expect to see for each one.

Key Takeaways

Annex IV of the EU AI Act specifies a mandatory list of documentation elements — providers must address all of them for each high-risk AI system before market placement.
The technical documentation is a living document — it must be updated whenever the system changes significantly. Outdated documentation is non-compliant documentation.
National market surveillance authorities can request your Annex IV documentation at any time. It must be provided within a reasonable period — typically 15 working days.
All technical documentation must be retained for 10 years after the AI system is placed on the market (Article 18).

Table of Contents

What is the Annex IV Technical Documentation?
Element 1: General description of the AI system
Element 2: Design specifications and development process
Element 3: Training methodology and datasets
Element 4: Validation and testing procedures and results
Element 5: Risk management system documentation
Element 6: Post-market monitoring plan
Element 7: Logs, instructions, and additional documentation
Managing the living document
FAQ

1. What Is the Annex IV Technical Documentation?

Article 11 of the EU AI Act requires providers of high-risk AI systems to draw up technical documentation before placing the system on the market. Annex IV of the Act specifies exactly what this documentation must contain across seven main elements.

Think of the Annex IV documentation as a comprehensive technical dossier that answers the fundamental question a regulator would ask: “How do we know this AI system is safe, accurate, and properly governed?” Every element of the documentation contributes an answer to part of that question.

Years it must be retained after market placement (Art. 18)

Working days typical window to produce documentation to authorities

Always

Must be current — outdated documentation = non-compliant documentation

⚠️

Who must prepare this documentation? Providers — the organisations that develop the AI system and place it on the market. Deployers (organisations that use third-party AI systems) do not prepare Annex IV documentation for their vendors’ systems, but they must be able to verify that their vendor has done so and access a summary. If you are a deployer who has substantially modified a third-party AI system, you may be reclassified as a Provider and must prepare your own Annex IV file. Use our free risk assessment tool to check your classification.

The Seven Elements of Annex IV Documentation

Element 1 General Description of the AI System

This section provides the foundational overview that contextualises all other documentation elements. Regulators read this first — it should be clear, complete, and written for a technically literate non-expert audience.

Required Sub-Element	What to Include
Intended purpose	Exactly what the system is designed to do; the specific task it performs; the decision it supports or makes
Version and date	System version number (aligned with your internal release management) and documentation date
AI category and Annex III classification	Which Annex III category applies and why; the classification rationale; Article 6(3) exception assessment if applicable
Hardware and software components	Key hardware requirements; software dependencies; third-party components and APIs integrated into the system
Forms of the AI system	Whether it is provided as software, embedded in a product, as an API, or otherwise
Provider details	Full legal name, registered address, and EU Authorised Representative details (if applicable)

Element 2 Design Specifications and Development Process

This is the technical architecture section — the “how was it built” documentation. It covers the design decisions, computational methods, model architecture, and development decisions that shape the system’s behaviour.

System architecture diagram: A visual representation of the AI system’s components and their interactions — inputs, processing layers, outputs, human interfaces, external integrations
Model type and algorithm: The class of model used (e.g. supervised classification, reinforcement learning, large language model); the specific algorithm or architecture (e.g. gradient boosted trees, transformer); justification for this approach
Key design choices and trade-offs: Why was this architecture chosen? What trade-offs were made between accuracy, interpretability, speed, and other factors?
Computational methods: Description of the computational methods used, including any approximation techniques and their expected effects on accuracy
Development methodology: The software development lifecycle approach; version control practices; testing gates in the development pipeline

The ISO 42001 AI Management System standard and the NIST AI RMF provide useful frameworks for structuring this section if you do not already have a formal AI development methodology.

Element 3 Training Methodology and Datasets

This is typically the most scrutinised element for AI systems that have caused harm — because biased or poor-quality training data is the most common source of AI failures. The documentation must be detailed enough for a regulator to assess whether the data was appropriate for the intended use case.

Training data sources and provenance

Where did the training data come from? Who collected it, when, and under what conditions? Is it proprietary, licensed, or publicly available? What are the relevant copyright and data rights considerations?

Data characteristics and coverage

Volume of training data; geographic, demographic, and temporal coverage; what populations or scenarios are well-represented and which are not; data cutoff dates; known gaps in coverage.

Data preprocessing and quality measures

What cleaning, normalisation, augmentation, and labelling steps were applied? How were labels verified? What quality thresholds were applied before data was accepted into the training set?

Bias detection and mitigation

What protected characteristics were tested for bias (age, gender, race, disability, nationality, religion)? What statistical tests were applied (demographic parity, equal opportunity, disparate impact)? What were the results? What mitigation steps were taken and what residual bias remains?

Special category data handling (if applicable)

If special category personal data was used in training: the strict necessity justification under Article 10(5), the GDPR legal basis, the additional safeguards applied, and the data minimisation measures taken.

Element 4 Validation and Testing Procedures and Results

This section demonstrates that the AI system was rigorously tested before deployment and that it achieves the accuracy levels claimed. Testing documentation must include both the procedures used and the actual results — not just a statement that testing was conducted.

Testing Type	Required Documentation
Accuracy testing	Accuracy metrics (precision, recall, F1, AUC-ROC, etc.) tested against an independent validation dataset; target thresholds; achieved levels; test conditions
Robustness testing	Performance under edge cases, unusual inputs, and degraded data conditions; sensitivity analysis showing how performance varies with input quality
Bias and fairness testing	Disaggregated performance metrics across protected characteristics; statistical tests for disparate impact; results and any identified disparities
Cybersecurity testing	Results of adversarial testing (model evasion, data poisoning attempts); penetration testing scope and results; any identified vulnerabilities and mitigations applied
Human oversight testing	Testing of the override mechanism, halt procedure, and explainability outputs with representative end-users; usability testing results
Real-world pilot testing	If a pilot was conducted before full deployment: scope, duration, outcomes, and any issues identified and resolved

Testing results must show actual numbers — not just statements that testing was “satisfactory.” A regulator reviewing your documentation will check whether your claimed accuracy metrics are plausible for your use case and whether your test dataset was representative of real-world deployment conditions.

Element 5 Risk Management System Documentation

The Annex IV file must include documentation of the Article 9 Risk Management System — including the identified risks, their assessed severity and likelihood, the mitigations applied, and the residual risk level accepted before deployment.

Risk register: A structured list of all identified foreseeable risks in normal use and reasonably foreseeable misuse conditions, with severity and likelihood ratings
Risk mitigation measures: For each identified risk, what technical or organisational measure was applied to reduce its likelihood or severity
Residual risk assessment: The risk level remaining after mitigations, and the documented decision to accept this residual risk before market placement
Risk management process description: How the RMS operates as a continuous, iterative process; who is responsible; when it is reviewed and updated
Known limitations: A frank description of the AI system’s known limitations, failure modes, and the conditions under which its performance degrades

Element 6 Post-Market Monitoring Plan

Before market placement, you must document how you will monitor the system’s real-world performance after deployment. This is the forward-looking element of the technical documentation — demonstrating that you have planned for ongoing compliance, not just point-in-time certification.

Performance KPIs to be tracked in production

Which accuracy and fairness metrics will be monitored in live deployment? At what frequency? What data will be collected to calculate these metrics? How will production performance be compared to pre-deployment benchmarks?

Incident detection and reporting thresholds

At what threshold does a performance deviation trigger a review? What constitutes a “serious incident” under Article 3(49) for your specific use case? What is the escalation path for potential serious incidents, and what is the 15-day reporting process?

Corrective action procedure

If a performance issue is detected, what is the process for investigation, remediation, and verification? Under what conditions would the system be withdrawn from the market? Who makes that decision?

Deployer feedback collection

How will you collect feedback from deployers about AI system performance and any issues encountered? What channels exist for deployers to report serious incidents to you as provider?

Element 7 Logs, Instructions for Use, and Supplementary Documentation

The final element consolidates the operational documentation that ensures the system can be used, monitored, and maintained compliantly.

Instructions for Use (Article 13 document): The complete user-facing documentation provided to deployers — covering intended purpose, known limitations, required human oversight measures, maintenance requirements, and technical interface specifications. This is both an Article 13 obligation and an Annex IV element.
Logging specification: Technical specification of what events are logged, at what level of detail, in what format, for how long, and how logs can be accessed by deployers and national authorities
Change management documentation: Version history; description of changes between versions; assessment of whether changes constitute a “substantial modification” requiring reassessment under Article 6
Conformity assessment record: Reference to the conformity assessment completed under Article 43, including whether self-assessment or Notified Body assessment was used and the date of completion
Standards applied: List of harmonised EU standards applied during development and testing (once these are published in the Official Journal, adherence creates a presumption of conformity for the requirements covered)
Declaration of Conformity reference: Cross-reference to the Article 47 Declaration of Conformity for this system

9. Managing the Annex IV File as a Living Document

The phrase “living document” in Article 11 is not metaphorical — it is a legal requirement. The technical documentation must be updated whenever the AI system changes in a way that could affect its compliance status. Presenting a two-year-old technical documentation file for a system that has been updated twelve times since will be treated as non-compliant documentation.

🔄

Mandatory review triggers: Any significant change to training data; any change to model architecture or algorithms; any change to intended purpose or target user group; any change to the deployment context; any significant change to performance metrics; any identification of a new risk not previously documented; and any market withdrawal followed by re-launch.

📂

Version control: Every version of the Annex IV documentation should be retained, not just the current version. Regulators investigating a historical incident may need to review the documentation as it existed at the time of the incident. Use a version-controlled document management system (SharePoint, Confluence, or equivalent) with dated version history.

👥

Ownership and accountability: Assign a named Documentation Owner for each high-risk AI system’s Annex IV file. This person is responsible for coordinating updates, ensuring review gates are completed before system changes are deployed, and maintaining the version history. Include documentation responsibility in their role description.

⚡

The 10-year retention obligation: Article 18 requires all technical documentation to be retained for 10 years after the AI system was last placed on the EU market. This means even after a product is discontinued, you must maintain the documentation in accessible storage for a decade. Plan your document retention infrastructure accordingly — and include Annex IV documentation in your data governance and retention policies.

Start your Annex IV documentation today

Our compliance checklist covers every step of preparing your Annex IV documentation package — with article references and practical “how to comply” guidance for each element.

View Compliance Checklist →

10. Frequently Asked Questions

Is the Annex IV documentation publicly available or kept private? +

The full Annex IV documentation is not made publicly available — it is retained by the provider and made available to national market surveillance authorities and the EU AI Office on request. What is publicly available (via the EU AI database) is a summary of the information sufficient to identify the system and verify that conformity assessment was completed. Trade secrets within the technical documentation are protected and do not need to be disclosed in full.

Can we use existing documentation (ISO 9001 QMS, MDR technical files, etc.) as part of the Annex IV? +

Yes — and you should. Existing documentation from ISO 42001, ISO 9001, ISO 27001, or EU MDR technical files can and should be incorporated into your Annex IV package where relevant. The key is ensuring you have documentation that addresses all the Annex IV elements — there are no bonus points for creating entirely new documents if existing ones already cover the required content. Create an index that maps your existing documentation to the Annex IV elements, identifying gaps that need to be filled with new material.

How long does it realistically take to prepare Annex IV documentation? +

For a single high-risk AI system, assuming your data science and engineering teams can provide the technical inputs (architecture diagrams, training data records, testing results), a well-resourced compliance team should expect 3–6 months to assemble and review a complete Annex IV file. The longest elements are typically bias testing documentation (which may require new testing to be commissioned) and post-market monitoring plan development. Start immediately — the August 2026 deadline does not leave time for a leisurely approach. See our EU AI Act Summary for the full compliance timeline.

Does every version update require a new full Annex IV file? +

No — updates are additive, not replacements. When a system version changes, you update the relevant sections of the Annex IV file and add a change log entry describing what changed, why, and what re-testing or re-assessment was conducted. A full new conformity assessment is only required if the change constitutes a “substantial modification” under Article 6 — meaning a change that could affect the system’s compliance with the Act’s requirements or alter the risk associated with the system. Minor bug fixes and performance improvements that do not change the system’s fundamental behaviour generally do not trigger a full reassessment.

Sources: EU AI Act Articles 11 and Annex IV — EUR-Lex · NIST AI Risk Management Framework · ISO 42001 AI Management System · IAPP EU AI Act Resource Centre