Article 11 Technical documentation

It describes what the system is, who it is for and how it is meant to be used, and it is the first section an assessor reads to understand the scope of everything else. Product, compliance and engineering staff usually write it together. It typically records the provider's name, the system version, the intended purpose, the deployment context, the categories of users and affected people, the hardware and software the system runs on, and the forms in which it reaches the market, such as an API, an embedded module or a downloadable package. Useful source documents include the product requirements, the marketing claims reviewed by legal, architecture diagrams and the instructions for use. Keep the stated intended purpose identical to the one used in the Article 9 risk assessment, because a mismatch between the two is an early finding. Every later section depends on this description.

It explains how the system was built and which design choices were made, with enough detail to show that the Section 2 requirements were considered during development. Engineering leads usually document the development methods, design specifications and system architecture, the data sources and data governance steps for training, validation and testing data, any pre-trained or third-party components, the computational resources used, and the validation and testing procedures with their results. Sources include design records, architecture decision records, data lineage records from the Article 10 work, model documentation, training logs and test reports. Link it to Article 10 for data governance and to Article 15 for accuracy and robustness claims, since those claims must trace back to the tests recorded here. For components supplied by an outside party, record what the supplier provided and what you verified yourself. Confirm the expected depth with your assessor or notified body before you start writing, because it varies with the system.

It describes how the system behaves in operation and which human oversight and control measures are built in, so an assessor can see how people can intervene. Typical content includes the system's capabilities and limitations, the persons or groups it is intended for, the expected accuracy for those groups, known risks to health, safety and fundamental rights, the oversight measures and how they are designed, and the technical means used to help people interpret outputs. Sources include the human oversight design, interpretability documentation, the instructions for use and the logging design. This section links directly to Article 12 (record-keeping), Article 13 (transparency toward deployers) and Article 14 (human oversight), so draw it from those articles and keep the two in step. Confirm with your compliance lead which oversight measures sit in the product and which are assigned to deployers.

Document the metrics you chose, why each one suits the intended purpose, the levels you measured, and the limits those measurements reveal, so a reader can judge whether each metric is appropriate. Typical content includes metric definitions, test datasets and test conditions, results broken down by relevant subgroups, the thresholds that trigger action, and a statement of which metrics were considered and set aside, with reasons. Source material includes evaluation reports, test plans, validation records and the accuracy declarations that appear in the instructions for use. Connect each metric to the Article 9 risk management system and to the accuracy requirements in Article 15, so a reader can follow a risk from identification through to the test that measured it. Metric selection is a judgment that domain experts should make, and the file should record who made it and on what basis. Ask your assessor which level of subgroup analysis they expect before testing begins.

It summarizes the risk management system required by Article 9, showing how risks were identified, estimated, mitigated and reviewed across the system's lifecycle. Risk owners usually document the risk register, the hazard and harm analysis, the decisions on acceptable residual risk, the testing against predefined metrics, the review schedule and the approval history. Sources include the risk register, threat models, incident and feedback records, post-deployment monitoring data and the security test results covering AI-specific attacks. This section is the spine of the file, because almost every other heading points back to it. Keep risk identifiers stable and cross-reference them throughout. Write the summary as an index into the full risk records, and keep those records complete. If the organization manages the process in an internal wiki or document system, confirm that the version history can show who approved which residual risk and when.

The lifecycle changes section describes every modification made after the system was first placed on the market. The harmonised standards section lists the standards applied, or explains the alternative solutions used where none were applied. Engineering and quality staff usually maintain the change log, recording version numbers, the reason for each change, its assessed effect on compliance and whether a new conformity assessment was needed. For standards, record the identifiers and versions you applied, the parts you applied, and the justification for any gaps. The first harmonised standard, EN 18286:2026 on quality management, was cited in the Official Journal on 14 October 2026. Check its applicability to your system against the Commission Implementing Decision (EU) 2026/2274 before you rely on it, and keep a dated record of that check.

Yes. The file must include a copy of the EU declaration of conformity, and the post-market monitoring system and plan form part of the Annex IV documentation under the amended Article 72(3). The provider issues the declaration, which states that the system meets the Section 2 requirements, and compliance staff keep a signed copy with a record of the conformity assessment route used. For most Annex III systems that route is internal control under Annex VI. The post-market plan describes how performance data is collected from deployed systems, how incidents and corrective actions are handled, and who reviews the findings. Sources include field monitoring data, complaint and incident records and the plan itself. Keep the file current, since Article 11 requires it, and retain it for 10 years after placing on the market under Article 18(1). Confirm with your legal advisers how signatures and version history will be managed.

The file takes as much effort as the system's documentation gap, and no supplied figure gives a fixed duration. The main drivers are the number of high-risk systems, how many Annex IV headings already have evidence, how complex the development process is, and how many versions and lifecycle changes must be recorded. Quantity of material matters less than whether each claim traces to a real test, decision or record. Ask any adviser for a written scope that lists the systems, the Annex IV headings covered, the evidence to be collected and the review cycle before agreeing to effort.

Yes, if the organization is an SME, start-up or small mid-cap enterprise, because the 2026 amendment to Article 11(1) lets it provide the Annex IV elements in a simplified manner using a Commission form. The amendment also requires notified bodies to accept that form. Confirm your eligibility against the enterprise size definitions that apply to you, check the current form on EUR-Lex, and confirm with your notified body or national authority how it expects the form to be submitted. The simplified route changes presentation, not the substance: the underlying risk management, data and testing evidence still has to exist.

Providers must keep the technical documentation for 10 years after the system is placed on the market or put into service, under Article 18(1). National competent authorities can ask to see it during that period, so the file must remain available in a form they can read. Confirm with your legal team whether other retention rules, such as sectoral regulations or contracts, extend the period, and plan storage, access rights and migration of the file so it stays retrievable for the whole retention window.

Yes, open-source tools can hold and version most of the file, but none of them writes the Annex IV content for you. A wiki or documentation platform such as XWiki keeps every change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack lets you set role-based permissions at shelf, book, chapter or page level, which helps separate drafting from approval. Evidence from testing can come from tools such as garak, which writes a JSONL report of every attempt, and Langfuse, which captures traces with inputs, outputs and metadata. Confirm each tool's fit with your own requirements before relying on it.

The provider's own team owns the technical file, the system design decisions and the evidence behind each claim. Engineers must supply architecture, data lineage, test results and change records. Risk and compliance staff must approve the risk management content, and product owners must confirm the intended purpose and instructions. An implementation partner can structure the file, set up the document system and organize evidence, but it cannot make these decisions. Agree the named owner for each Annex IV heading and the review cadence in writing before work begins.

An outside partner can prepare the structure, templates, document system and supporting evidence for the file, and can help your team complete it. The partner cannot own the conformity claims or issue any report or certificate, because only an independent auditor, assessor or notified body does that. DeployOpen plans and implements self-hosted open-source platforms inside the client's infrastructure and prepares evidence for assessments, but it does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, so ask for the deliverables, the Annex IV headings covered and the handover conditions in writing.