High-risk AI systems must maintain a complete technical file before placing on the EU market. Art. 11 and Annex IV define exactly what to include — from system architecture to training data governance and post-market monitoring plans.

What Is the Technical File?

The technical documentation — commonly called the "technical file" — is the master evidence package that demonstrates a high-risk AI system meets all EU AI Act requirements. Mandated by Art. 11 and structured by Annex IV, it must be drawn up before the system is placed on the EU market and kept up to date throughout the system's lifecycle.

The technical file is not submitted centrally. The provider holds it and presents it on request to market surveillance authorities and notified bodies. This is a pull model: authorities come to you; you must be ready to hand over a complete, coherent package, not an improvised stack of files assembled under pressure.

Art. 11 imposes three duties on providers:

  1. Draw it up before market placement or putting into service.
  2. Keep it up to date — any substantial change to the system requires updating the file and reassessing conformity.
  3. Make it available to competent authorities and notified bodies on request, within a defined timeframe (typically 10 business days under national market surveillance rules).

The standard for "up to date" is functional: the technical file must reflect the system as actually deployed, not the system as originally designed. If a model update changes performance characteristics, accuracy thresholds, or training data, the file must be revised accordingly.


Who Needs Technical Documentation?

Technical documentation under Art. 11 and Annex IV is mandatory for providers of:

Technical documentation is not required for:

If you are a deployer (not a provider), you are not required to prepare the technical file. However, deployers must maintain logs of system use (Art. 26(5)), and providers are entitled to draw on these logs when updating technical documentation or handling incident reports.


The 14 Elements of Annex IV

Annex IV specifies the minimum content of the technical file. There is no rigid format — providers may organise the documentation as they see fit — but all 14 elements must be present and substantive. Tick-box entries without supporting evidence do not satisfy Annex IV.

# Annex IV element What it must contain
1 General description System name, version identifier, intended purpose, intended users, geographic markets, provider name and address, any authorised representative
2 System components Hardware requirements, software components, third-party models or libraries used, training methodology overview, algorithmic approach (e.g. supervised learning, reinforcement learning, transformer architecture)
3 Design specifications System architecture, data flow diagrams, key design decisions and their rationale, trade-offs made (e.g. accuracy vs. explainability), output format and how outputs feed into downstream decisions
4 Training, validation and testing data Datasets used at each stage, data sources, data governance procedures, statistical properties of datasets (size, distribution, coverage), data processing and pre-processing protocols, measures taken to detect and address dataset biases
5 Risk management documentation The complete Art. 9 risk management system: identified risks to health, safety, and fundamental rights; risk estimation and evaluation; risk mitigation measures adopted; residual risks accepted; basis for accepting residual risks
6 Lifecycle changes Description of all substantial modifications made after initial deployment, their nature and scope, how conformity was reassessed after each change, version history with dates
7 Human oversight measures How Art. 14 requirements are implemented: override and stop mechanisms, interfaces enabling human operators to monitor outputs, training or qualification requirements for operators, documented procedures for human intervention
8 Validation and testing procedures Performance metrics used (accuracy, precision, recall, F1, AUC, fairness metrics), test dataset descriptions, test conditions and environment, bias testing methodology and results, robustness and stress testing, out-of-distribution performance
9 Cybersecurity measures Technical measures against model theft, data poisoning, adversarial attacks, prompt injection (for LLM-based systems), access controls, encryption in transit and at rest, vulnerability management procedures
10 Bias and accuracy monitoring Ongoing monitoring procedures post-deployment, accuracy thresholds below which the system triggers a review, performance benchmarks disaggregated by demographic groups where relevant, procedures for acting on detected drift or bias
11 Instructions for use The Art. 13 deployer-facing document: intended purpose and use cases, performance characteristics and limitations, known constraints, maintenance and update requirements, logging obligations for deployers, contact point for reporting incidents
12 Post-market monitoring plan The Art. 72 monitoring system design: data collected from deployers, frequency of monitoring cycles, thresholds triggering a review or update, serious incident reporting procedure (Art. 73), procedure for feeding monitoring data back into risk management
13 Description of interfaces APIs and integration points, input data formats and constraints, output formats and their semantics, integration with other systems or components, version compatibility
14 Harmonised standards and common specifications List of harmonised standards applied (e.g. ISO/IEC 42001:2023, EN standards under the AI Act standardisation programme), common specifications adopted under Art. 41, the extent to which each standard was applied, any deviations and their justification

Practical note on element 4 (training data): Annex IV does not require you to disclose the datasets publicly or to authorities by default. It requires that the documentation exists and can be produced. For proprietary datasets, a description of data governance procedures, statistical summaries, and bias-testing results will typically satisfy the requirement without disclosing commercially sensitive data.

Practical note on element 14 (standards): As of mid-2026, the AI Act standardisation programme is still in progress. ISO/IEC 42001 (AI management systems) is available and widely referenced. Providers should monitor the European standardisation work under CEN/CENELEC JTC 21 and update this section as harmonised standards are published in the Official Journal.


EU Declaration of Conformity (Art. 47)

The EU Declaration of Conformity (EU DoC) is a separate mandatory document — it is not part of the technical file, but it references it. The EU DoC is the provider's formal statement that the AI system complies with all applicable EU AI Act requirements.

A valid EU DoC must include:

The EU DoC must be kept for 10 years after market placement and produced on request. It accompanies the CE marking (see below).

For AI systems embedded in Annex I products, the EU DoC may be merged with the declaration of conformity required under the relevant sector legislation, provided it contains all the elements required by both legal instruments.


CE Marking (Art. 48)

High-risk AI systems placed on the EU market must bear the CE marking, which signals conformity with the EU AI Act and any other applicable Union harmonised legislation covering the same product.

Exceptions: AI systems in Annex III categories deployed by public authorities for their own internal use are exempt from CE marking requirements. They remain subject to all other obligations — technical documentation, risk management, human oversight, registration — but do not need to affix CE marking.

CE marking must be affixed before the system is placed on the EU market. It must be visible, legible, and indelible. Where the physical nature of the system does not permit affixing the marking directly, it may appear on the packaging or in the instructions for use.

When a high-risk AI system is a component of an Annex I product that already requires CE marking under sector-specific legislation (e.g. medical devices, machinery), the CE marking covers conformity with both the sector legislation and the AI Act. Providers should document clearly which conformity assessment procedures underpin the CE marking.


Practical Checklist: Minimum Viable Technical File

Before any high-risk AI system is placed on the EU market, verify these 10 items are complete and evidenced:

This checklist covers the minimum. A well-prepared technical file will go further — particularly on bias testing methodology, model cards for component models, and evidence of the risk management process being iterative rather than a one-time exercise.


How This Links to the EU AI Act Academy

The EU AI Act Academy Pro tier includes ready-to-use technical documentation templates covering all 14 Annex IV elements, including:

These templates are designed to be adapted to your specific system — they are starting points with substantive content, not blank forms.

Related pages:

Official AI Act Compliance Deadline Calendar

Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.

Obligation Applies to Original date New date Status Countdown Legal basis
Prohibited Practices (Art. 5) All providers and deployers active AI Act Art. 5
GPAI Rules (Chapter 5) GPAI model providers active AI Act Art. 51-56
High-risk AI — Annex III (standalone) Providers of standalone Annex III systems deferred AI Omnibus 2026 Art. 6(2)
High-risk AI — Annex I (embedded) AI embedded in Annex I regulated products deferred AI Omnibus 2026 Art. 6(1)
AI-Generated Content Marking Providers of generative GPAI systems active AI Act Art. 50(2)
Regulatory Sandboxes National competent authorities active AI Act Art. 57

Download JSON · CC BY 4.0

Frequently Asked Questions

The provider of the high-risk AI system is solely responsible for preparing and maintaining technical documentation. Deployers are not required to prepare it, but must keep access logs and may need to provide them to providers for reporting purposes.

Technical documentation must be kept for 10 years after the AI system is placed on the EU market or put into service (Art. 18). For AI systems embedded in products subject to Annex I legislation, the retention period of the product legislation applies if it is longer.

No — technical documentation is not filed centrally. It must be kept by the provider and made available to market surveillance authorities and notified bodies on request. Registration in the EU AI database (Art. 71) is mandatory, but the full technical file stays with the provider.

A formal document signed by the provider stating that the AI system complies with the EU AI Act requirements. It must include the system name, version, provider identity, a list of applicable requirements met, the conformity assessment procedure used, and a reference to relevant harmonised standards. It accompanies the CE marking.

Stay ahead of AI Act changes

Get compliance alerts when deadlines or obligations change.

No spam. One-click unsubscribe.