Technical documentation and evidence-pack preparation
We test the technical documentation of a high-risk AI system against every sub-point of Annex IV under Art. 11, and the instructions for use against each item of Art. 13(3), under PR-11-DOC v1.0. Declared values are compared with the dated and signed test reports behind them, and missing sections are drafted from those reports with a source reference on each statement. The client receives a gap analysis, assembled technical file sections, an instructions-for-use consistency check and a traceability matrix, ahead of the Annex III application date Deferred.
Deliverables
The set is designed for the reader named in Art. 11(1): a national competent authority or a notified body that has to assess the system against Chapter III Section 2 from the documentation alone. Each type is specified with a synthetic sample on the deliverables page: the gap analysis follows the findings register specification, the assembled sections follow the evidence pack specification, the consistency check follows the assessment memo specification, and the matrix follows the traceability matrix specification.
| Deliverable | Type | Format | Designed to satisfy |
|---|---|---|---|
| Annex IV technical documentation gap analysis | Findings register | XLSX; CSV; PDF summary | |
| Assembled technical file sections drawn from test results | Evidence pack | Folder with index (PDF, Markdown); ZIP with hash manifest | |
| Consistency check between instructions for use (Article 13) and measured performance (Article 15) | Assessment memo | PDF with Markdown source | |
| Obligation to test to evidence traceability matrix | Traceability matrix | XLSX; CSV; Markdown table for the technical file |
Who this is for
- Annex III providers
- Annex I manufacturers
- Startups
- Non-EU providers
A provider of a standalone Annex III system carries the full Chapter III Section 2 set, and Annex IV is where each of the other requirements has to be shown: the risk management system in section 5, the data governance in the section 2(d) datasheets, the accuracy and robustness results in section 2(g) and section 3, the oversight measures in section 2(e). A manufacturer whose AI is a safety component of an Annex I product already keeps a technical file under the sectoral law, and Art. 11(2) asks for one single set that adds the Annex IV content to it without duplicating what the product legislation covers. A small company answering a procurement questionnaire needs the cheapest defensible path to a file that answers the questionnaire, and the Art. 11(1) simplified form for SMEs and start-ups is part of that path where the Commission has issued it. A company established outside the Union that already documents under NIST AI RMF 1.0Published or ISO/IEC 42001:2023Published has material that maps onto Annex IV sections in part; the gap table records which rows that material fills and which it leaves open.
Two entries set the urgency: the Annex III application date for standalone high-risk systems and the Annex I application date for product-embedded systems, both moved by Regulation (EU) 2026/1744 with the obligations unchanged in content.
- DeferredAnnex III standalone high-risk obligations
- DeferredAnnex I product-embedded high-risk obligations
Scope
The engagement covers the technical documentation of one high-risk AI system under Annex III or Annex I, on the full Annex IV route, the Art. 11(1) simplified form route, or the Art. 11(2) single-set route for a product covered by Annex I Section A; the limits of every result are stated on what we cannot do. PR-11-DOC v1.0 runs three groups of checks. Completeness: every sub-point of Annex IV sections 1 to 9 and every item of Art. 13(3)(a) to (f) is marked present, partial, absent or not applicable, with a location. Assembly: the sections that a test result can supply, which are section 2(g), section 3, section 4 and section 7 and, from the provider's own records, sections 5, 6 and 9, are drafted with a source reference on each statement. Consistency: every declared metric value, version, component, dataset description, oversight measure and cybersecurity measure in the documentation is compared with the record it rests on, and every statement in the instructions for use is compared with the technical documentation and with the measured performance recorded under Art. 15.
The form in which each declared value is stated follows prEN 18229-2Draft, a JTC 21 draft that gives the declaration structure for accuracy and robustness levels and fixes no acceptance criterion. The content of the instructions for use is expected to follow prEN 18229-3Draft, which is at drafting stage with no public text, so the Art. 13 checklist is built from the article text alone and gains rows when a text appears. The document control routine that keeps the assembled set up to date under Art. 11(1) follows prEN 18286Published, a published European standard that is not cited in the Official Journal as of the anchor date. No harmonised standard is cited in the Official Journal for any element in this service, so no presumption of conformity is available; the standards page tracks the count, and the Annex IV section 7 draft lists each standard with its stage.
The engagement does not run accuracy, robustness, cybersecurity or bias tests. The values that the consistency tables compare against come from PR-15-ROB v1.0 under the robustness and adversarial testing service, from PR-10-BIAS v1.0, or from the provider's own dated and signed reports, and a provider report is taken as given. The engagement does not verify the oversight functions themselves, does not judge whether the documentation is clear and comprehensive in the sense of Art. 11(1), which rests with the authority or the notified body, and does not draw up the EU declaration of conformity under Art. 47, of which Annex IV section 8 requires only a copy. Annex XI and Annex XII documentation for a general-purpose AI model runs under the same protocol within the GPAI evaluation support service.
What we test
The table lists the testable elements of the Art. 11 and Art. 13 obligation records, with the protocol that tests each element and the artifacts it produces for the record.
| Obligation | Testable element | Protocol | Artifacts |
|---|---|---|---|
| Art. 11 | The accuracy, robustness and other metric values declared in the documentation match the values in the dated and signed test reports it contains, for the same system version and the same test conditions (Annex IV section 2(g)) | PR-11-DOC v1.0 |
|
| The degrees of accuracy stated for specific persons or groups of persons and the overall expected level of accuracy match the disaggregated and aggregate results in the test reports (Annex IV section 3) | PR-11-DOC v1.0 | ||
| The system version and the software or firmware versions stated in the general description match the deployed artefact and the versions named in the test reports (Annex IV section 1(a) and 1(c)) | PR-11-DOC v1.0 | ||
| The architecture description matches the system as built: the listed components, their interfaces and the integrations with external hardware, software and other AI systems are present and no deployed component is missing from the description (Annex IV section 2(c) and 1(b)) | PR-11-DOC v1.0 | ||
| The intended purpose and the conditions of use in the general description match the instructions for use and the promotional or sales materials (Annex IV section 1(a) and 1(h)) | PR-11-DOC v1.0 | ||
| The datasheets match the data sets actually used: provenance, scope, main characteristics, labelling procedure and cleaning methodology as recorded in the data pipeline (Annex IV section 2(d)) | PR-11-DOC v1.0 | ||
| The human oversight measures and the output interpretation measures described in the documentation are present in the system and in the instructions for use (Annex IV section 2(e) and section 3) | PR-11-DOC v1.0 | ||
| The cybersecurity measures described in the documentation are present in the deployed configuration (Annex IV section 2(h)) | PR-11-DOC v1.0 | ||
| Every test log and test report in the documentation carries a date and the signature of a responsible person, and the set covers each pre-determined change described in section 2(f) (Annex IV section 2(g)) | PR-11-DOC v1.0 | ||
| The lifecycle change record matches the version history in the general description and the versions covered by test reports (Annex IV section 6 with section 1(a) and 1(c)) | PR-11-DOC v1.0 | ||
| Each entry in the standards and specifications list maps to the requirement it addresses, and each Chapter III Section 2 requirement without an applied harmonised standard maps to a described solution (Annex IV section 7) | PR-11-DOC v1.0 | ||
| The copy of the EU declaration of conformity names the same system, version and provider as the general description (Annex IV section 8 with section 1(a)) | PR-11-DOC v1.0 | ||
| Art. 13 | The accuracy level and metrics declared in the instructions for use under Art. 13(3)(b)(ii) match the result of a test on a held-out set under the declared conditions of use. | PR-11-DOC v1.0 |
|
| The robustness and cybersecurity levels declared in the instructions for use under Art. 13(3)(b)(ii) match the result of perturbation and adversarial tests under the declared conditions of use. | PR-11-DOC v1.0 | ||
| The known and foreseeable circumstances declared under Art. 13(3)(b)(ii) and (iii) reproduce the declared change in performance or the declared risk when the system runs under those circumstances. | PR-11-DOC v1.0 | ||
| The performance declared for specific persons or groups under Art. 13(3)(b)(v) matches the disaggregated results recorded in the technical documentation. | PR-11-DOC v1.0 | ||
| Each statement in the instructions for use on intended purpose, input data specifications, pre-determined changes, human oversight measures and log mechanisms (Art. 13(3)(b)(i), (b)(vi), (c), (d) and (f)) matches the corresponding section of the Annex IV technical documentation. | PR-11-DOC v1.0 |
Art. 11, Annex IV and Art. 13 set no numeric threshold; the pass criterion for every check is binary, and a declared value is consistent with its report when the metric name, the test set, the conditions and the system version are identical and the value equals the reported value or lies inside the reported interval, with no tolerance applied because no published source gives one. The level of each declared value is set by the provider under Art. 15, and the source of that level follows a six-level hierarchy: a harmonised standard cited in the Official Journal, of which none exists as of the anchor date; a JTC 21 draft standard named with its stage, which is prEN 18229-2Draft for the declaration structure; an ISO/IEC standard or technical report; a Commission guideline or code of practice; NIST AI RMF or a sector framework; and the provider's justified state of the art. Where no published threshold exists, the justification-location step of PR-11-DOC v1.0 records where in the Annex IV section 4 statement the provider's justification sits and marks each declared value that has none. No figure on this page is attributed to the Act.
Protocols used
One protocol runs the service; its version, derivation and revision history are on its page.
- PR-11-DOC v1.0Annex IV documentation assembly and consistency protocolv1.0
PR-11-DOC v1.0 covers Annex IV completeness, section assembly from test results and records, and consistency between the documentation, the instructions for use and the measured performance. It produces the Annex IV gap and consistency report, the assembled section drafts with a source map, the declared metric to test report consistency table, the instructions-for-use completeness checklist and consistency report, the version and architecture reconciliation record, and the obligation to test to evidence traceability matrix. It shows presence, consistency and traceability; it does not show that a declared value is correct, since a value that matches its report is only as reliable as that report, and it works on a frozen input set, so a change to the system or the documentation after the freeze is outside the result and is handled by repeating the affected steps.
Engagement shape
The service is fixed-scope, scoped per request, and usually follows the classification and readiness assessment, whose obligation register names the documentation route and the articles in scope. The client provides the technical documentation as it stands, the instructions for use as supplied to deployers, the promotional and sales materials that state the intended purpose, the test reports and test logs, the deployed artefact identity with its component inventory and configuration export, the data pipeline records, the risk management file, the lifecycle change record, the post-market monitoring plan and, where drawn up, the copy of the EU declaration of conformity. The work follows the order of the protocol: preparation, in which the route is determined, the inputs are inventoried and each document version is frozen with a content hash, and the three checklists are built; execution, in which each row is marked, each supplying record is named, the sections are drafted and each consistency comparison is run; analysis, in which the findings are classified, the justification locations and the document control data are recorded and the traceability matrix is built; and reporting, in which the gap and consistency report and the section drafts with their source map are delivered for the provider's review and signature.
What we cannot do
- We do not perform conformity assessments where a notified body is required.
- We do not issue CE marking or the EU Declaration of Conformity.
- We are not a notified body.
- We do not give legal opinions on classification or liability.
- We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.
For this service the assembled sections are drafts that the provider reviews, signs and owns; the technical documentation remains the provider's document under Art. 11(1), and the gap and consistency report is not a conformity assessment under Art. 43. The mock conformity assessment service reads the finished set the way a notified body would, and no certificate follows either service.
What the client must have ready
The documentation and process elements below are read and cross-checked during the engagement; the gap table records which are present, partial, absent or not applicable, with the location of each.
Art. 11Technical documentation
- A technical documentation set exists that contains, at a minimum, the elements set out in Annex IV, in a clear and comprehensive form for national competent authorities and notified bodies (Art. 11(1)) documentation
- For an SME, including a start-up, or an SMC that opts for the simplified manner, the documentation uses the Commission's simplified technical documentation form (Art. 11(1) third subparagraph) documentation
- For a system related to an Annex I Section A product, a single documentation set holds the Art. 11(1) information and the information required under the product legislation (Art. 11(2)) documentation
- General description: intended purpose with context and conditions of use, provider name, system version and relation to previous versions, interaction with external hardware, software and other AI systems, software and firmware versions and update requirements, forms of placing on the market, target hardware, product photographs or illustrations where the system is a product component, and a basic description of the deployer user interface (Annex IV section 1(a) to 1(g)) documentation
- Instructions for use for the deployer (Annex IV section 1(h)) documentation
- Development methods and steps, including third-party pre-trained systems or tools and how they were used, integrated or modified (Annex IV section 2(a)) documentation
- Design specifications: general logic, algorithms, key design choices with rationale and assumptions, classification choices, optimisation target and parameter relevance, expected output and output quality, and trade-off decisions taken to meet Chapter III Section 2 (Annex IV section 2(b)) documentation
- Architecture description and the computational resources used to develop, train, test and validate the system (Annex IV section 2(c)) documentation
- Datasheets for the training data sets with training methodologies and techniques, provenance, scope, main characteristics, acquisition and selection, labelling and cleaning (Annex IV section 2(d)) documentation
- Assessment of the human oversight measures under Art. 14 and of the technical measures for output interpretation under Art. 13(3)(d) (Annex IV section 2(e)) documentation
- Detailed description of pre-determined changes and the technical solutions that keep the system within Chapter III Section 2 (Annex IV section 2(f)) documentation
- Description of the validation and testing procedures, the validation and testing data with their main characteristics, and the metrics used for accuracy, robustness, other Chapter III Section 2 requirements and potentially discriminatory impacts (Annex IV section 2(g)) documentation
- Description of the cybersecurity measures put in place (Annex IV section 2(h)) documentation
- Capabilities and limitations in performance, foreseeable unintended outcomes, sources of risk to health and safety, fundamental rights and discrimination, human oversight measures with output interpretation measures, and input data specifications (Annex IV section 3) documentation
- Description of the appropriateness of the performance metrics for the specific system (Annex IV section 4) documentation
- Detailed description of the risk management system under Art. 9 (Annex IV section 5) documentation
- List of the applied harmonised standards cited in the Official Journal, or, where none is applied, a detailed description of the solutions adopted and a list of the other standards and technical specifications applied (Annex IV section 7) documentation
- Copy of the EU declaration of conformity under Art. 47 (Annex IV section 8) documentation
- Detailed description of the post-market monitoring system under Art. 72, including the post-market monitoring plan under Art. 72(3) (Annex IV section 9) documentation
- The technical documentation is drawn up before the system is placed on the market or put into service (Art. 11(1)) process
- The technical documentation is kept up to date over the lifecycle of the system (Art. 11(1)) process
- Test logs and test reports are dated and signed by the responsible persons when they are produced, including for each pre-determined change (Annex IV section 2(g)) process
- Relevant changes made to the system through its lifecycle are recorded as they occur (Annex IV section 6) process
Art. 13Transparency and provision of information to deployers
- Instructions for use exist in an appropriate digital format or otherwise and accompany the system (Art. 13(2)). documentation
- The information in the instructions for use is concise, complete, clear, relevant, accessible and comprehensible to deployers (Art. 13(2)). documentation
- The instructions for use state the identity and contact details of the provider and, where applicable, of its authorised representative (Art. 13(3)(a)). documentation
- The instructions for use state the intended purpose (Art. 13(3)(b)(i)). documentation
- The instructions for use declare the level of accuracy with its metrics, robustness and cybersecurity against which the system was tested and validated, and the known and foreseeable circumstances that affect that level (Art. 13(3)(b)(ii)). documentation
- The instructions for use list the known or foreseeable circumstances under the intended purpose or reasonably foreseeable misuse that may lead to risks to health, safety or fundamental rights (Art. 13(3)(b)(iii)). documentation
- Where applicable, the instructions for use describe the technical capabilities and characteristics that provide information relevant to explain the output (Art. 13(3)(b)(iv)). documentation
- When appropriate, the instructions for use state the performance regarding the specific persons or groups on which the system is intended to be used (Art. 13(3)(b)(v)). documentation
- When appropriate, the instructions for use give specifications for the input data and relevant information on the training, validation and testing data sets (Art. 13(3)(b)(vi)). documentation
- Where applicable, the instructions for use give information that enables deployers to interpret the output and use it appropriately (Art. 13(3)(b)(vii)). documentation
- The instructions for use state the changes to the system and its performance that the provider pre-determined at the initial conformity assessment, if any (Art. 13(3)(c)). documentation
- The instructions for use describe the human oversight measures under Art. 14 and the technical measures that facilitate interpretation of the outputs (Art. 13(3)(d)). documentation
- The instructions for use state the computational and hardware resources needed, the expected lifetime, and the maintenance and care measures with their frequency, including software updates (Art. 13(3)(e)). documentation
- Where relevant, the instructions for use describe the mechanisms that allow deployers to collect, store and interpret the logs under Art. 12 (Art. 13(3)(f)). documentation
- Transparency of operation is a design and development objective carried through the lifecycle of the system, at a type and degree appropriate to the obligations of the provider and the deployer (Art. 13(1)). process
- The maintenance and care measures declared under Art. 13(3)(e), including their frequency and software updates, are carried out over the expected lifetime of the system. process
- The instructions for use are revised when a pre-determined change under Art. 13(3)(c) is applied or when a re-test changes the declared level under Art. 13(3)(b)(ii). process
Inputs take the formats listed on the PR-11-DOC page: documents in any format that preserves text, each with a version identifier; the deployed artefact as a build identifier, container digest or package version; the component inventory as a software bill of materials, an architecture diagram and a configuration export; and the data pipeline records as dataset manifests, provenance records, the labelling procedure and the cleaning scripts or logs.
Questions
What does Annex IV of the EU AI Act require?
Annex IV of Regulation (EU) 2024/1689 lists the minimum content of the technical documentation under Art. 11(1) in nine sections: a general description of the system, a detailed description of its elements and development process with dated and signed test reports, information on monitoring, functioning and control, the appropriateness of the performance metrics, the risk management system, lifecycle changes, the standards and specifications applied, a copy of the EU declaration of conformity, and the post-market monitoring system. PR-11-DOC step 7 builds one checklist row per sub-point.
What is the technical documentation requirement under Article 11 of the EU AI Act?
Art. 11(1) of Regulation (EU) 2024/1689 requires the provider of a high-risk AI system to draw up the technical documentation before placing on the market, to keep it up to date, and to give it content demonstrating the Chapter III Section 2 requirements and holds at least the Annex IV elements. SMEs, start-ups and SMCs may use the Commission simplified form. Art. 11(2) requires a single set for a system related to an Annex I Section A product. The Art. 11 obligation page gives the testable, documentation and process split.
What does Article 111(2) of the EU AI Act change for technical documentation?
Art. 111(2) of Regulation (EU) 2024/1689 applies the Regulation to operators of high-risk AI systems placed on the market before the application date on the regulation page only where those systems undergo significant changes in their design after that date; public-authority systems have a separate later date in the same paragraph. The lifecycle change record under Annex IV section 6 and the version reconciliation in PR-11-DOC steps 28 and 34 show which changes a system has undergone; whether a change is significant is a decision for the provider with counsel.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.