EU AI Act Article 11. The technical documentation obligation that underpins every high-risk AI deployment.

Article 11 sits within Chapter III, Section 2 of Regulation (EU) 2024/1689, alongside the other high-risk AI obligations for providers. It is often grouped in compliance discussions with Article 17 (quality management systems) and Article 12 (record-keeping), but its function is distinct. Article 11 is the documentary record that a system was designed, developed, and assessed to a defined standard. It is the evidence base that national market surveillance authorities can inspect, that notified bodies rely on during conformity assessment, and that deployers can use to verify what the system they are purchasing was actually built to do.

What Article 11 requires

Article 11(1) states that providers of high-risk AI systems shall draw up technical documentation in accordance with Annex IV before placing the system on the market or putting it into service, and shall keep it updated. Two elements of this formulation carry operational weight. First, the pre-market timing: the documentation is not a post-deployment reflection on what was built, but a formal record that must exist before any deployment begins. Second, the maintenance obligation: the documentation is not a one-time exercise but a living record that must track changes to the system throughout its operational life.

Article 11(2) establishes the accessibility requirement. Providers must keep the technical documentation available to national competent authorities for a period of ten years after the system has been placed on the market or put into service, or for a longer period if specified by Union or national law for the sector in which the system operates. Financial services, healthcare, and public sector deployments in particular may face sector-specific retention requirements that extend this period.

Article 11(3) addresses the scenario where a high-risk AI system incorporates a general-purpose AI model. In this case, the provider of the high-risk system may rely on the technical documentation produced by the GPAI model provider, provided that documentation is adapted to be specific to the high-risk system. This is commercially significant because most enterprise AI deployments in 2026 are built on foundation models from major providers. The adaptation requirement means that simply attaching a foundation model provider's model card is not sufficient: the documentation must address the combined system as deployed in the specific high-risk context.

Annex IV: the eight-section specification

Annex IV to Regulation (EU) 2024/1689 specifies the minimum content of technical documentation in eight sections. Understanding these sections is important for deployers even though they do not hold the documentation, because the sections define what a competent provider should be able to evidence and what a deployer can reasonably request a summary of.

Section 1: General description of the AI system. This covers the intended purpose, the name, type, and version of the system, the intended deployers and users, any interaction with hardware or software not part of the system itself, and a general description of the system's inputs and outputs. For deployers, section 1 is the starting point for verifying that the system they are deploying matches what the provider documented. Version discrepancies between what is documented and what is supplied are a compliance risk that affects both Article 11 conformity and insurance coverage.

Section 2: Description of elements and development process. This is the most technically substantive section. It covers the design specifications and choices made in the system's development, the training methodologies and techniques, the training, validation, and testing datasets including their provenance, the measures taken to examine and address potential bias, information about any pre-trained models or third-party components incorporated, and a summary of reasonably foreseeable risks to health, safety, and fundamental rights that the development process identified. For deployers assessing the adequacy of a provider's documentation, the bias examination and foreseeable risk summary are the two components most directly relevant to their Article 26(1) obligations.

Section 3: Information on monitoring, functioning, and control. This section addresses how the system performs in operation: its capabilities and limitations, the expected levels of accuracy, robustness, and cybersecurity, the specifications of input data, and the reasonably foreseeable misuse scenarios that the system could be put to. The misuse scenarios documented in section 3 are the provider's assessment of how a deployer could operate the system in ways that generate harms the provider anticipated. Deployers should review this section in the instructions for use they receive, because operating in a documented misuse scenario exposes the deployer to liability arguments that the harmful use was foreseeable.

Section 4: Description of appropriateness of performance metrics. This section explains why the performance metrics chosen for the system are appropriate for its purpose. It is less commonly reviewed by deployers but is relevant when a deployer is evaluating whether a system's accuracy claims are meaningful for the specific use case they intend. An accuracy metric that is appropriate for a general-purpose classification task may not be appropriate for a high-stakes employment screening application.

Section 5: Risk management system. This section documents the risk management system required by Article 9, including the identified risks, the mitigations adopted, the residual risks after mitigation, and the testing that validated the mitigations. This is the section most directly relevant to deployers, because the residual risks it identifies are the risks that deployers must manage at the deployment level through Article 26(1). Deployers should request a summary of section 5 content, at minimum the residual risk classification for their intended use case.

Section 6: Changes made throughout the lifecycle. This section records material changes to the system since its initial documentation. For deployers relying on a system that has been updated, section 6 is the evidence that material changes were documented and assessed. The update obligation in Article 11(1) means that a provider who releases a new version without updating the technical documentation is in breach of their Article 11 obligation. Deployers should contractually require notification when section 6 is updated with a material change.

Section 7: EU declaration of conformity. This section incorporates the declaration required under Article 48 and Annex V, which formally attests that the system complies with the requirements of the EU AI Act. The declaration must be signed by the provider or their authorised representative and must reference the conformity assessment procedure applied. For deployers, the declaration of conformity is the formal document attesting that the system they are deploying was assessed against the EU AI Act requirements.

Section 8: Post-market monitoring plan. This section describes the post-market monitoring system the provider has established under Article 72, including the procedures for collecting and reviewing data from deployed systems, the frequency of review, and the process for identifying and reporting serious incidents. The monitoring plan is the link between ongoing operation and the iterative risk management required by Article 9. Deployers should verify that the provider's post-market monitoring plan covers the type of deployment they are making.

What deployers actually receive: instructions for use

The full Annex IV documentation is not transmitted to deployers. It remains with the provider and is available to national competent authorities on request. What deployers receive is the instructions for use, required under Article 13 and specified in Annex XIII.

The instructions for use are the deployer-facing extract of the technical documentation. They must cover the identity and contact details of the provider, the system's capabilities and limitations, the performance levels in terms of accuracy and robustness, known or foreseeable circumstances that may affect the system's performance, the changes made to the system after initial conformity assessment, the human oversight measures that deployers must implement, the data inputs the system requires, and any post-deployment monitoring measures the deployer must establish.

The instructions for use are, in effect, the deployer's operating manual for compliance. They translate the technical documentation into operational obligations at the deployment level. A deployer who follows the instructions for use is operating within the risk parameters the provider assessed. A deployer who operates outside those parameters is not covered by the provider's Article 11 documentation for that use, and may have triggered the substantial modification analysis under Article 25(1)(d).

The adequacy of the instructions for use varies significantly across providers. A provider whose instructions for use contain only generic guidance about system limitations without use-case-specific risk information has not discharged their obligations adequately. Deployers who receive inadequate instructions for use should press providers in writing for the missing information and should treat an inability to supply it as a material procurement concern.

What deployers should request from providers

Beyond the instructions for use, deployers should request, and ideally contractually require, several additional items from providers in connection with the Article 11 technical documentation.

First, a written confirmation that Annex IV documentation exists, is current, and covers the version of the system being supplied. This request should be made in writing and the response retained. Providers who cannot confirm this are either non-compliant with Article 11 or are supplying a version whose documentation has not been kept current.

Second, a risk management summary from section 5 of the technical documentation. This should identify the residual risks for the specific use case the deployer intends and the risk management measures the provider has adopted. Providers may redact commercially sensitive development details while supplying the risk summary, but a complete refusal to provide any residual risk information should be treated as a red flag.

Third, confirmation that pre-market testing covered the deployer's specific intended context. A system tested for one industry and deployment scenario may not have been tested for another. The testing scope is documented in section 2 and section 8 of the technical documentation, and a summary relevant to the deployer's use case should be obtainable on request.

Fourth, a notification mechanism for material changes to the technical documentation. Article 11(1) requires providers to keep documentation updated. When that update reflects a change that affects the deployer's risk profile or operating conditions, the deployer needs to know. This notification obligation should be written into the supply contract.

For the full framework of deployer obligations that this documentation sits within, see the operator obligations compliance guide. For how to structure the deployer's own documentation file, see documenting AI agent risk management for compliance.

When deployers become Article 11 subjects

Article 25(1)(d) of Regulation (EU) 2024/1689 provides that a deployer who substantially modifies a high-risk AI system is treated as the provider of the modified system for the purposes of the Act. The substantial modification definition in Article 3(23) covers modifications that change the system's performance in relation to its essential requirements, or that change its intended purpose. When a deployer becomes a provider under Article 25(1)(d), all provider obligations apply, including Article 11. The deployer must draw up Annex IV documentation, conduct conformity assessment, and register the system in the EU database.

The modifications most likely to trigger Article 25(1)(d) for enterprise deployers are: fine-tuning the foundation model on proprietary data in ways that materially change its accuracy or behaviour characteristics; integrating the system with other automated decision-making tools in ways that change the combined system's outputs; extending the system's use to a purpose or population not covered by the provider's conformity assessment; and making configuration changes that take the system outside the operational parameters documented in the technical documentation.

The compliance gap here is substantial. Enterprise AI deployments in 2026 routinely involve customisation, integration, and contextual adaptation that collectively may constitute substantial modification without being labelled as such. Organisations that have customised their AI deployments should seek legal advice on whether their customisations cross the Article 25(1)(d) threshold before the August 2026 enforcement date.

For a detailed treatment of when deployers acquire provider obligations, see the liability chain analysis covering provider and deployer responsibilities.

Article 11 documentation and insurance underwriting

The Article 11 technical documentation is the foundational underwriting document for AI agent insurance. Insurers writing AI liability policies cannot price risk without understanding how the system was designed, what risks were identified and mitigated, what residual risks remain, and what governance processes exist around the deployment. These are precisely the questions that Annex IV documentation is designed to answer.

Products from Munich Re aiSure, Armilla, and AIUC-1 licensees all require applicants to present governance and technical evidence that maps closely to the Annex IV categories. The risk management system summary from section 5 maps directly to what Munich Re and Armilla require as evidence of a documented risk process. The development and testing information from sections 2 and 3 maps to the system documentation requirements in the AIUC-1 standard.

A deployer who has obtained adequate documentation from their provider, built a deployment-specific risk supplement, and established a monitoring process is carrying most of what an insurer needs to underwrite a policy. The insurer's underwriting process becomes a verification exercise rather than a documentation-building exercise. For more on the connection between compliance documentation and coverage eligibility, see the insurance evidence chain analysis on agentinsured.eu.