EU AI Act Article 11: Technical Documentation for High-Risk AI Systems

Before a high-risk AI system reaches the market — or is put into service — its provider must have a complete technical file in place. That obligation comes from Article 11 of Regulation (EU) 2024/1689. The documentation must demonstrate that the system satisfies every requirement in Chapter III, Section 2 (Articles 9–15), and it must give national competent authorities enough detail to assess compliance without guesswork. The contents are specified in Annex IV.

This is not a bureaucratic afterthought. The technical file is the primary evidence base for conformity assessment under Article 43, the document a notified body reviews when it evaluates whether your system can lawfully enter the EU market. If it is incomplete, the conformity assessment fails. If it is missing, you cannot legally deploy. If it is misleading, the fine ceiling under Article 99 is €15,000,000 or 3% of worldwide annual turnover — whichever is higher.

Under the Digital Omnibus agreed in May 2026, the deadline for stand-alone high-risk AI systems (Annex III) is 2 December 2027. For high-risk AI embedded as safety components in regulated products (Annex I), it is 2 August 2028. The original August 2026 date has been pushed back. That additional time does not make the documentation task smaller — Annex IV is specific, and assembling a complete file for a non-trivial system typically takes several months.

Who Must Draw Up Article 11 Documentation

The obligation falls on the provider — the entity that develops a high-risk AI system and places it on the market or puts it into service under its own name or trademark (Article 3(3)). A SaaS company that builds and sells a recruitment screening tool, a fintech that deploys its own credit-scoring model, a health-tech startup that ships a medical-triage system: each is a provider and must produce the Annex IV file.

Deployers — organisations that use a high-risk system built by someone else — do not bear the Article 11 obligation directly. But Article 25 creates a trap: if a deployer substantially modifies a high-risk system, or extends its intended purpose beyond the original scope, it becomes a provider and the documentation obligation transfers.

The documentation must be drawn up before the system is placed on the market or put into service, not retrospectively. That timing matters: teams that treat compliance documentation as a post-launch task find themselves unable to pass Article 43 conformity assessment and legally blocked from deploying.

What Annex IV Requires: Nine Documentation Sections

Annex IV specifies nine categories of content. The Act gives SMEs (including start-ups) the option to provide these elements in a simplified manner; the Commission is empowered to adopt the simplified form. Even so, the substance must cover all nine sections — simplified means condensed presentation, not fewer elements.

1. General Description of the System

The first section establishes what the system is and what it is supposed to do. Required elements include:

• The intended purpose stated with enough precision for a regulator unfamiliar with your business to assess deployment scope (e.g., "scores creditworthiness for unsecured personal loans of €5,000–€50,000 to individual consumers in Germany and Austria")
• The identity of the provider, including name, registered address, and any authorised representative (Article 22) if the provider is established outside the EU
• The version identifier and a description of how the system differs from previous versions — algorithm changes, retraining on new data, revised decision thresholds
• How the system interacts with hardware and software it is intended to be used with, including any dependencies on third-party APIs or infrastructure
• The forms in which it is placed on the market or put into service — on-premises deployment, cloud SaaS, API, embedded module
• Any hardware the system is intended to run on, including minimum specifications
• Photographs or illustrations where they aid understanding of the system architecture or physical deployment
• Instructions for use for deployers, covering the system's intended purpose, contraindications (use cases the system is not designed for), and the level of accuracy users should expect

2. Detailed Description of the Development Process

This is the largest section and the one that most often has gaps. It covers how the system was built.

Design specifications and architecture: Document the system architecture — whether it uses decision trees, ensemble methods, neural networks, or rule-based logic — and the rationale for design choices that affect accuracy, fairness, or failure modes. A high-level architecture diagram is standard.

Data governance and datasheets: For each dataset used in training, validation, and testing, Annex IV requires a datasheet: origin of the data, collection methodology, demographic composition (age, gender, geography, other relevant characteristics), preprocessing steps, quality-assurance procedures, and known limitations. Article 10 sets out the data governance obligations that underpin this documentation; what Annex IV section 2 requires is the evidentiary record that Article 10 was followed.

Human oversight assessment per Article 14: The development section must show how the design supports the human oversight mechanisms required by Article 14. That means documenting what a human operator can observe, what they can intervene on, what the system's outputs mean in practice, and how the interface makes limitations visible. This is not an operational procedure note (that goes in section 3); this is a design-phase assessment of whether the architecture enables meaningful oversight.

Predetermined changes and continuous learning: If the system is designed to update its parameters automatically after deployment — a continuously-learning model — the documentation must describe the bounds of that learning, the conditions that trigger updates, and how the provider controls model drift. Systems with fixed post-deployment parameters are simpler to document here, but the section must still confirm that the parameters are frozen and explain the governance around retraining cycles.

Validation and testing procedures: Document the full testing programme: cross-validation methodology, hold-out test set composition (including demographic breakdowns), temporal validation against data reflecting current conditions, adversarial testing, and edge-case coverage. For every metric reported — accuracy, precision, recall, F1, AUC-ROC — the documentation must show how it was computed and on what data. Subgroup analysis is mandatory: performance disaggregated by protected characteristics (gender, age, ethnicity, disability) is what Article 10(3) requires, and Annex IV section 2 is where the results are recorded.

Logs: Document the logging architecture — what the system records at inference time, how long logs are retained, who can access them, and how logs support post-incident review. Article 12 addresses record-keeping obligations separately; section 2 of Annex IV documents the technical design that makes Article 12 compliance possible.

Practical SMB example: A 35-person HR-tech company in the Netherlands provides a CV-screening tool to mid-market employers across the EU. Under Annex III Category 4 (employment and worker management), it is a high-risk provider. For section 2, the company must document that its training set comprises 1.2 million job applications collected 2019–2024, with demographic breakdowns across gender (54% male, 46% female applicants), age band, and country of origin. It must record that it ran fairness testing using demographic parity and equalized odds metrics, identifying a 4.2 percentage-point disparity for applicants over 55, and documenting the threshold adjustment it applied to bring the disparity within acceptable bounds.

3. Detailed Information on Monitoring, Functioning, and Control

Section 3 moves from build-time to runtime. It covers how the system operates once deployed: the monitoring architecture, the conditions under which the system should and should not be used, the controls in place when it produces unexpected outputs, and the procedures for safe shutdown or suspension.

This section should be read alongside the Article 14 human oversight obligations. The documentation must show that a human operator — not just technically capable, but given the tools and information — can understand the system's outputs and intervene meaningfully. Concrete elements: the interface the operator uses, the information displayed at inference time, the override path, what happens to a decision when a human overrides, and whether and how overrides are logged.

4. Appropriateness of Performance Metrics

Section 4 asks providers to justify the choice of performance metrics, not merely report them. If you selected AUC-ROC as your primary metric for a credit-scoring system, you need to explain why that metric is appropriate for a binary lending decision — and acknowledge that a metric capturing aggregate discrimination does not automatically capture disparate impact on a specific demographic subgroup.

This is the section where regulators look to see whether providers understand their system or are cargo-culting standard ML evaluation. A well-written section 4 shows that the provider considered the downstream harm the system could cause, chose metrics sensitive to those harms, and accepted the trade-offs explicitly.

5. The Risk Management System

Article 9 requires providers to establish and maintain a risk management system covering the full lifecycle of the high-risk AI system. Section 5 of Annex IV is the documentary record of that system. It must describe the risk identification methodology, the probability and severity assessment for each identified risk, the mitigations applied, the residual risk accepted, and the monitoring procedures that will detect emerging risks post-deployment.

The risks Article 9 has in mind are risks to health, safety, and fundamental rights — not generic business risk. For a recruitment screening tool, that means documenting the risk of discriminatory shortlisting for protected groups, the probability of that harm occurring given the training data, the mitigations applied (fairness testing, threshold adjustment, mandatory human review for borderline scores), and the residual disparity still present. For a credit-scoring model, it means documenting the risk of systematically denying credit to particular demographic groups and the chain of mitigations that keeps that risk within the provider's stated tolerance.

6. Lifecycle Changes

Section 6 is the change log. Any modification that could affect the system's compliance — model retraining on new data, revision of decision thresholds, extension to a new use case, changes to the hardware it runs on — must be recorded here, with the date, the nature of the change, and the compliance assessment that determined whether the change triggered a new conformity assessment under Article 43.

Not every change requires a fresh Article 43 assessment. But providers must have a documented process for making that determination, and section 6 is where the outputs of that process live.

7. Standards Applied

List every harmonised standard, technical specification, or common specification applied during development and testing. Where a harmonised standard under Article 40 was used, note the presumption of conformity it affords for the requirements it covers. Where no harmonised standard existed for a particular requirement, document the alternative method used to demonstrate conformity and why it is adequate.

At the time of writing, harmonised standards under the EU AI Act are still being finalised by CEN-CENELEC. Providers developing ahead of 2 December 2027 should document any applicable ISO/IEC standards they have applied — ISO/IEC 42001 (AI management systems), ISO/IEC 23894 (AI risk management), ISO/IEC 25059 (software quality for AI) — along with any NIST AI RMF alignment, while noting that these do not yet carry a formal presumption of conformity under the Act.

8. EU Declaration of Conformity

Section 8 of Annex IV requires the technical file to include a copy of the EU declaration of conformity drawn up under Article 47. The declaration confirms that the provider has completed conformity assessment under Article 43, that the system meets the requirements in Chapter III, Section 2, and that the provider takes responsibility for that conformity. It must be signed by a person authorised to represent the provider and must contain the particulars specified in Annex V.

One common error: providers treat the declaration as a standalone document and fail to include it in the technical file. It belongs in both places.

9. Post-Market Monitoring Plan

Section 9 of Annex IV requires a description of the post-market monitoring system the provider is required to establish under Article 72. The monitoring plan must specify how the provider will actively collect data on the system's performance in real-world deployment, the metrics it will track, the thresholds that will trigger corrective action, and the procedures for reporting serious incidents under Article 73.

For most stand-alone high-risk systems, the monitoring plan should address: how inference logs are collected and aggregated, how accuracy and fairness metrics are tracked over time, what level of performance degradation triggers a review, how the provider will detect distributional shift (training data that no longer reflects current users), and how customer feedback or incident reports feed into the review cycle.

Retention: 10 Years Under Article 18

Article 18 requires providers to keep the technical documentation at the disposal of national competent authorities for 10 years after the system is placed on the market or put into service. For high-risk AI embedded in products covered by harmonisation legislation (Annex I), the retention obligation mirrors the relevant product-safety regulation, which may specify a different period.

Ten years is a long time in software. Providers need to think now about documentation management: version-controlled storage, access controls, a retention policy that survives staff turnover, and a process for keeping the file current as the system evolves. Competent authorities can request the technical file at any point during the retention period.

The Conformity Assessment Connection

The technical file is the input to conformity assessment under Article 43. For most Annex III high-risk systems, Article 43(2) allows self-assessment by the provider — the provider reviews its own documentation, concludes it demonstrates compliance, draws up the EU declaration of conformity under Article 47, and affixes CE marking under Article 48. Registration in the EU database under Article 49 follows.

For a narrower set of systems — certain biometric identification systems and systems in sensitive domains where Annex VII applies — conformity assessment requires a notified body. The notified body reviews the technical file under the procedures in Annex VI or VII. Without a complete Annex IV file, the notified body cannot proceed.

Either way, the technical file is what the conformity assessment reviews. Gaps in the file are gaps in the assessment. Providers who delay documentation until after development will find themselves rebuilding large sections from memory, which is both time-consuming and less credible than contemporaneous records.

SME and Start-Up Provisions

Article 11(3) provides that SMEs, including start-ups, may provide the elements in Annex IV in a simplified manner. The Commission is to establish the format of the simplified form. This is a genuine proportionality measure: a 12-person company building its first high-risk system should not need a 200-page file in the same format as a large enterprise.

What simplified means in practice is presentation, not substance. The simplified form will still need to cover all nine Annex IV sections; it will be structured to guide smaller providers through them efficiently. Providers who want to use the simplified form should monitor Commission implementing acts as they are adopted ahead of 2 December 2027.

One point on penalties that matters for SMEs: under Article 99(6), fines for SMEs and start-ups are capped at the lower of the fixed-sum figure and the percentage-of-turnover figure. A start-up with €2 million annual revenue faces a ceiling well below €15 million for an Article 11 breach — but the percentage of turnover cap (3%) can still be material, and the operational consequences of a compliance order or market suspension are severe regardless of company size.

A Worked Example: Mid-Market HR-Tech Provider

Consider a 40-person company in Vienna that offers a CV-ranking API to corporate HR departments across the DACH region. The system scores job applications and ranks candidates for human review. It falls under Annex III Category 4 and the company is the provider under Article 3(3).

Their Article 43 conformity assessment is self-assessment — no notified body required for this category. But the technical file must still cover all nine Annex IV sections, signed off before the API is made available to customers.

For section 1, they document the intended purpose (ranking, not selecting — outputs are rankings for human reviewers, not autonomous hiring decisions), the API deployment architecture, and the instructions for use they provide to deployer customers, including explicit contraindications (the API should not be used as the sole determinant of any hiring decision).

For section 2, they produce datasheets for three datasets used in training and validation, include the fairness testing results, and document the design of the ranking algorithm and the reasoning behind the selected performance metrics. Human oversight at the deployer level is supported by a confidence score displayed with each ranking and a design constraint preventing any candidate from being screened out without the ranking being visible to the human reviewer.

For section 5, the risk register covers discriminatory ranking of candidates over 55 (identified in testing), the threshold calibration applied to reduce the disparity to below 2 percentage points, and the residual risk accepted.

For section 9, the post-market monitoring plan requires monthly accuracy checks against a rolling hold-out set and a quarterly subgroup fairness review, with a customer incident-reporting channel that feeds into the review cycle.

The full file runs approximately 80 pages. It is version-controlled in their compliance repository and kept at the disposal of the Austrian market surveillance authority for 10 years from the date the API first went live.

How Confir Helps

Confir's AITR compliance area (Data and Technical Robustness, covering Articles 10, 11, and 15) generates the Annex IV technical documentation pack through a structured intake process. Providers work through the nine Annex IV sections via plain-English prompts; the rule-based engine derives the required output — a print-ready Conformity Package — without requiring providers to interpret the Annex directly.

The AITR workflow also connects to the Article 47 EU Declaration of Conformity generated in the AIRC area, so the declaration is available to include in the technical file (section 8) from the start. The documentation pack is retained in Confir's audit-log system and can be exported in full for submission to competent authorities or notified bodies.

Pricing starts at €600 per year.

What Documentation Failures Look Like in Practice

Three patterns appear repeatedly in enforcement contexts.

Vague intended purpose. "The system assesses candidate suitability" is insufficient. Competent authorities need to understand what decisions the system informs, what the output looks like, what the score thresholds mean, and whether those thresholds have been calibrated. A vague statement prevents both conformity assessment and meaningful human oversight review.

Subgroup testing absent. Overall accuracy numbers that mask demographic disparities are a common and serious gap. Article 10(3) requires testing for bias; Annex IV section 2 is where the results live. A provider that cannot produce subgroup performance metrics has likely not done the testing.

Stale documentation. A system retrained on new data with no corresponding update to the technical file is non-compliant. Section 6 must record every material change and section 2 must be current. Competent authorities inspecting two years after market launch expect to see a file that reflects the system as deployed today, not as designed in 2024.

What to Do Now

The 2 December 2027 deadline creates a planning window, not a gap to ignore. Assembling a complete Annex IV file for a non-trivial system typically takes three to five months the first time: data governance procedures must be documented contemporaneously, fairness testing must be designed and run, the risk management system must produce records, and the human oversight design must be assessed before the architecture is locked.

Providers who start documenting in mid-2027 will find the deadline uncomfortably close. Those who begin now — building the documentation practice into their development workflow — will have a file that is both more complete and more credible when competent authorities ask for it.

Related guides

• AI system inventory management tools
• EU AI Act compliance overview
• EU AI Act compliance software solutions
• AI governance platform for compliance
• high-risk AI classification requirements
• governance software solutions