Annex IV of the AI Act: assembling the technical documentation

What the obligation asks for

Art. 11(1) of Regulation (EU) 2024/1689 requires the provider to draw up the technical documentation of a high-risk AI system before the system is placed on the market or put into service, and to keep it up to date. The documentation demonstrates that the system meets the requirements of Chapter III Section 2 and gives national competent authorities and notified bodies the information they need to assess it, in a clear and comprehensive form. Its minimum content is Annex IV: section 1 with sub-points (a) to (h) on the general description, section 2 with sub-points (a) to (h) on the elements and the development process, and sections 3 to 9 on monitoring and control, metric appropriateness, risk management, lifecycle changes, standards applied, the EU declaration of conformity and post-market monitoring. The introductory sentence of Annex IV applies each item as applicable to the relevant AI system. Art. 11(2) requires a single documentation set for a system related to a product under Annex I Section A, holding the Art. 11(1) information and the information the product legislation requires. An SME, including a start-up, or an SMC may provide the Annex IV elements in the simplified form the Commission establishes under Art. 11(1) third subparagraph; the manifest in this guide is for the full form. The Art. 11 obligation page lists every element with its split into testable, documentation and process. The duty applies from the Annex III application date 2027-12-02Deferred for a system classified under Art. 6(2), and from the Annex I date 2028-08-02Deferred for a system under Art. 6(1).

The guide covers five testable elements of the Art. 11 record. The system version and the software or firmware versions in the general description match the deployed artefact and the versions named in the test reports (Annex IV section 1(a) and 1(c)). Every test log and test report carries a date and the signature of a responsible person, and the set covers each pre-determined change (Annex IV section 2(g)). The lifecycle change record matches the version history and the versions the test reports cover (Annex IV section 6). Each entry in the standards and specifications list maps to the requirement it addresses (Annex IV section 7). The copy of the EU declaration of conformity names the same system, version and provider as the general description (Annex IV section 8). The other nineteen elements of the record are documentation: the guide gives each one a manifest row with a status, a location and a source, and the assembly steps draft the sections that test results can supply. The declared values themselves come from the provider's testing under Art. 15; the assembly records the values and leaves their production to the Art. 15 tests.

Inputs

The inputs are the subset of the PR-11-DOC v1.0 input table that the preparation and assembly steps use, plus the tools the examples call. The full table is on the protocol page.

• The technical documentation as it stands, in any format that preserves text, with a version identifier per document.
• The instructions for use as supplied to deployers, and the promotional or sales materials that state the intended purpose.
• The test reports and test logs for accuracy, robustness, cybersecurity and bias, each dated and signed, from PR-15-ROB v1.0, PR-10-BIAS v1.0 or the provider's own testing.
• The deployed artefact identity: build identifier, container digest or package version of the version under review.
• The component inventory and deployed configuration: software bill of materials, architecture diagram, configuration export, external integration list.
• The data pipeline records for the training, validation and testing data sets: manifests, provenance, labelling procedure, cleaning scripts or logs.
• The risk management file, the lifecycle change record and the post-market monitoring plan, each with a version identifier.
• The copy of the EU declaration of conformity, where drawn up.
• For a system related to an Annex I Section A product: the existing technical file under the product legislation and its index.
• A shell with find, sha256sum and python with the PyYAML parser installed.

Procedure

Each step names the protocol step or the clause it derives from and the record it produces. Code blocks follow the step they belong to. Every path, identifier, version, hash and count in the examples is synthetic.

1. Record the system name, the provider, the version under review and the deployed build identifier.

   Record system identity record: name, provider, version under review, deployed build identifier

   [AIAssuranceLabs procedure; PR-11-DOC step 1]

2. Determine the route: full Annex IV, the simplified form, or the Art. 11(2) single set.

   Record route determination record: full Annex IV, simplified form, or single set with the product legislation content named

   [Regulation (EU) 2024/1689, Art. 11(1) third subparagraph and Art. 11(2); PR-11-DOC steps 2 and 3]

3. Collect every document, report, log and record in the inputs list and assign each a version identifier.

   Record input inventory: one line per document with its version identifier

   [AIAssuranceLabs procedure; PR-11-DOC step 5]

4. Build the manifest with one row for each sub-point of Annex IV sections 1 to 9.

   Record section manifest: one row per Annex IV sub-point with status, location, source and reason fields

   [Regulation (EU) 2024/1689, Annex IV sections 1 to 9; PR-11-DOC step 7]

5. Compute a content hash for every file the manifest points to and freeze the set.

   Record frozen input set: path and content hash per file version

   [AIAssuranceLabs procedure; PR-11-DOC step 6]

6. Mark each row present, partial, absent or not-applicable, with a location or a reason.

   Record manifest status per row: present, partial, absent or not-applicable, with location or reason

   [Regulation (EU) 2024/1689, Annex IV introductory sentence; PR-11-DOC step 10]

7. For each absent or partial row, name the test report or record that supplies the content.

   Record source map: absent or partial row to the supplying record, or 'no record'

   [AIAssuranceLabs procedure; PR-11-DOC step 13]

8. Draft sections 2(g) and 3 from the test reports and state each metric in the declaration format.

   Record section 2(g) and section 3 drafts with a source reference on each statement; metric entries with name, value, test set, conditions and version

   [Regulation (EU) 2024/1689, Annex IV section 2(g) and section 3; prEN 18229-2, draft, declaration structure; PR-11-DOC steps 14 to 16]

9. Draft section 7 with each standard, its stage and the requirement it addresses, and the described solution.

   Record standards and specifications list: designation, stage, OJEU citation flag, requirement addressed, described solution

   [Regulation (EU) 2024/1689, Annex IV section 7; PR-11-DOC step 18]

10. Check each test report and test log for a date, a responsible signature and the version it covers.

    Record test report register: report identifier, date, signatory role, version covered, pre-determined change covered

    [Regulation (EU) 2024/1689, Annex IV section 2(g); PR-11-DOC step 33]

11. Reconcile the version in the general description with the build, the test reports, the change record and the declaration.

    Record version reconciliation record: general description, deployed artefact, test reports, change record, declaration of conformity

    [Regulation (EU) 2024/1689, Annex IV section 1(a), 1(c), 6 and 8; PR-11-DOC steps 28, 34 and 35]

12. Record the version, the owner function and the update trigger for each assembled section.

    Record document control record per section: version, owner function, update trigger

    [prEN 18286, published, clauses on document and record control; PR-11-DOC step 42]

13. File the set with an index that names each section, its version and its hash.

    Record documentation index naming each section file, its version, its hash and the frozen input set identifier

    [Regulation (EU) 2024/1689, Art. 11(1) and Art. 18; PR-11-DOC step 45]

Example for steps 4 and 6. The manifest below has one row per Annex IV sub-point; five rows are shown, the full file has twenty-three. A row marked present or partial carries a location inside the documentation; a row marked not-applicable carries the reason, because the introductory sentence of Annex IV applies each item as applicable and a silent omission cannot be told from a gap. The source list names the input inventory entries the section rests on. The system name, the version, the paths and the report identifiers are synthetic.

# Synthetic example: annex-iv-manifest.yaml for demo-system 2.4.0
system: demo-system
version: "2.4.0"
build_id: "sha256:3f9c1a7e0b5d4c2f8a6e9d1b7c3f5a8e2d4b6c8f0a1e3d5b7c9f1a3e5d7b9c1f"
route: annex-iv-full            # annex-iv-full | simplified-form | annex-i-single-set
sections:
  - id: "1(a)"
    title: intended purpose, conditions of use, provider, version and relation to previous versions
    status: present
    location: docs/annex-iv/01-general-description.md#purpose-and-version
    source: [instructions-for-use-2.4.0.pdf, release-notes-2.4.0.md]
  - id: "1(f)"
    title: photographs or illustrations where the system is a component of products
    status: not-applicable
    reason: the system is delivered as an API and is not a component of a physical product
  - id: "2(g)"
    title: validation and testing procedures, data, metrics, test logs and signed test reports
    status: partial
    location: docs/annex-iv/02g-validation-and-testing.md
    source: [evidence/TR-0012-robustness-2.4.0.pdf, evidence/TR-0009-bias-2.3.0.pdf]
    gap: TR-0009 covers version 2.3.0; no bias report exists for 2.4.0
  - id: "6"
    title: relevant changes made to the system through its lifecycle
    status: present
    location: docs/annex-iv/06-lifecycle-changes.md
    source: [evidence/change-record.csv]
  - id: "7"
    title: harmonised standards applied, or the solutions adopted and the other standards applied
    status: absent
    source: []

Example for step 5. The command lists every file under the documentation and evidence folders, sorts the list so that the output is stable between runs, and writes one digest per file. The digest in the manifest index is copied from this file, never recomputed at a later date, so that a later change shows up as a mismatch. The second command runs before filing and fails when any frozen file has changed or disappeared.

# Synthetic example: freeze every file the manifest points to.
find docs/annex-iv evidence -type f \( -name '*.md' -o -name '*.pdf' -o -name '*.csv' \) -print0 \
  | sort -z | xargs -0 sha256sum > frozen-input-set.txt
wc -l frozen-input-set.txt

# Before filing: exit code 1 if any frozen file changed or is missing.
sha256sum --check --quiet frozen-input-set.txt

Example for steps 6 and 7. The script loads the manifest, checks that every one of the twenty-three Annex IV sub-points has a row, that each row's status is one of the four values, that a present or partial row has a location, that a not-applicable row has a reason, and that every source file is in the frozen input set. It prints one line per failing row and exits with code 1 when any row fails, so that it can run as a repository check before the set is filed. It needs the PyYAML parser.

# Synthetic example: check annex-iv-manifest.yaml against the Annex IV sub-point list.
import sys
import yaml

ANNEX_IV = (
    ["1(%s)" % c for c in "abcdefgh"]
    + ["2(%s)" % c for c in "abcdefgh"]
    + ["3", "4", "5", "6", "7", "8", "9"]
)
STATUSES = {"present", "partial", "absent", "not-applicable"}

with open("annex-iv-manifest.yaml", encoding="utf-8") as f:
    manifest = yaml.safe_load(f)

frozen = set()
with open("frozen-input-set.txt", encoding="utf-8") as f:
    for line in f:
        digest, _, path = line.rstrip("\n").partition("  ")
        frozen.add(path)

rows = {r["id"]: r for r in manifest.get("sections", [])}
failures = []

for sid in ANNEX_IV:
    row = rows.get(sid)
    if row is None:
        failures.append((sid, "no row in manifest"))
        continue
    status = row.get("status")
    if status not in STATUSES:
        failures.append((sid, "status %r is not one of %s" % (status, sorted(STATUSES))))
    if status in {"present", "partial"} and not row.get("location"):
        failures.append((sid, "status %s without a location" % status))
    if status == "not-applicable" and not row.get("reason"):
        failures.append((sid, "not-applicable without a reason"))
    if status == "absent":
        failures.append((sid, "absent; source map entry required"))
    for src in row.get("source", []):
        if src not in frozen:
            failures.append((sid, "source %s is not in frozen-input-set.txt" % src))

for sid in rows:
    if sid not in ANNEX_IV:
        failures.append((sid, "row id is not an Annex IV sub-point"))

for sid, reason in failures:
    print("FAIL %-5s %s" % (sid, reason))
print("%d of %d sub-points have a row; %d failures" % (
    sum(1 for s in ANNEX_IV if s in rows), len(ANNEX_IV), len(failures)))
sys.exit(1 if failures else 0)

On the five rows shown above the script reports nineteen failures: row 7 is absent, and the eighteen sub-points not shown have no row. Row 2(g) passes the check as partial with a location; its gap is carried by the source map in step 7, which names the bias report for version 2.4.0 as the supplying record once it exists. Every count is an output of this example, never a requirement of the Act.

Example for step 9. Section 7 has two branches. The first lists harmonised standards whose references are published in the Official Journal; none is cited as of the anchor date, so no presumption of conformity attaches and the first branch is empty for every provider. The second branch lists the other standards and technical specifications applied and describes the solution adopted for each requirement of Chapter III Section 2. The list below carries the stage of each document from the standards page and the requirement each addresses; the designations are the ones the site tracks, the how_applied cell is synthetic.

designation,stage,ojeu_cited,requirement,how_applied
prEN 18229-2,draft,no,Art. 15 accuracy and robustness,declaration structure for the metric entries in sections 2(g) and 3
prEN 18286,published,no,Art. 17 quality management system,document and record control for the Annex IV set
ISO/IEC 42001:2023,published,no,Art. 17 quality management system,management-system structure the QMS documentation maps to
ISO/IEC 23894:2023,published,no,Art. 9 risk management,risk management process described in section 5

Example for step 12. The document control block sits at the end of the manifest. The owner field names a function. The update triggers are the events after which the affected sections are re-drafted and the frozen input set is re-computed; a new system version triggers every section, a new test report triggers sections 2(g), 3 and 4, and a change to the instructions for use triggers section 1(h) and section 3.

# Synthetic example: document control block appended to annex-iv-manifest.yaml
control:
  manifest_version: 3
  system_version: "2.4.0"
  owner: documentation function
  frozen_input_set: frozen-input-set.txt
  update_triggers:
    - new system, software or firmware version
    - new or replaced test report or test log
    - change to the instructions for use or the promotional materials
    - change to the standards and specifications list

A pitfall that vendor documentation omits

Document management and GRC tooling present Annex IV as nine headings and mark the documentation complete when a file is attached to each heading. Annex IV has twenty-three items, because section 1 and section 2 each have eight sub-points, and the introductory sentence applies each item as applicable to the relevant AI system. A file attached to "section 2" says nothing about whether the datasheets under 2(d) describe the labelling procedure, whether the pre-determined changes under 2(f) have a test report under 2(g), or whether the cybersecurity measures under 2(h) are described at all. The Art. 11 record names the resulting findings: the architecture description reflects the design at project start and omits components added later, the test reports carry no date or signature, and the lifecycle change record stops at the first release. A manifest with one row per sub-point, a status per row and a reason on every not-applicable row is the unit at which step 10 of PR-11-DOC v1.0 marks the gap table, and the check in the example above fails on a heading-level manifest because eighteen sub-points have no row.

Section 7 has a second pitfall. Tooling offers a "standards applied" field and accepts a bare designation. Annex IV section 7 asks, where no harmonised standard cited in the Official Journal is applied, for a detailed description of the solutions adopted to meet each requirement of Chapter III Section 2 together with the list of the other standards applied. No harmonised standard is cited in the Official Journal as of the anchor date, so every provider is in that branch, and a list that names prEN 18229-2Draft without its draft stage and without the requirement it addresses is the finding the Art. 11 record names for section 7. A draft standard in the list is evidence of the solution adopted, and the list states its stage because the stage changes as the JTC 21 work moves. For a manufacturer under Art. 11(2), the same manifest serves as the index into the existing technical file under the product legislation: the location column points to the section of that file, and a sub-point the sectoral file already covers is marked present with that location, so that the AI-specific content is added once and the notified body reads one map.

Regulation (EU) 2024/1689 sets no numeric threshold for any check in this guide, and no published document sets a required completeness level for the manifest; the pass criterion of the protocol is binary, present or absent, consistent or not. The hierarchy for the form of each declared value is the one the obligation record states: no harmonised standard is cited in the Official Journal as of the anchor date; the declaration structure comes from prEN 18229-2Draft, at draft stage; the content of the instructions for use in section 1(h) is expected from prEN 18229-3Draft, with no public text at drafting stage; the document control routine comes from prEN 18286Published, published, with ISO/IEC 42001:2023Published as the published management-system structure the Art. 17 documentation maps to; the level of each declared value is the provider's justified choice, recorded in the Annex IV section 4 statement on the appropriateness of the performance metrics.

What the result shows and what it does not

The manifest, the frozen input set and the check show presence and traceability: for each Annex IV sub-point, whether content exists, where it sits, which record it rests on and that the file has not changed since it was frozen. They do not show that a declared value is correct; a value that matches its test report is only as reliable as that report, and a report the provider produced without an independent test is taken as given. They do not show that the documentation is clear and comprehensive to a national competent authority or a notified body, and they do not show that a notified body will accept the simplified form in a given conformity assessment. The set is frozen at step 5, so a change to the system, the documentation or a test report after that step is outside the result until the affected rows are re-frozen, which is why step 12 records the update trigger. The result is evidence for the provider's own technical file under Annex IV; the decision whether the system meets Art. 11 remains with the provider, their notified body where one is required, and their counsel. The technical documentation and evidence-pack preparation service runs the full protocol and delivers the evidence pack with its index and gap list, and its scope limits are on what we cannot do.

Related pages

The obligation, the protocol, the related guide on the traceability matrix that the assembled set feeds, and the hubs for the two roles this guide serves are listed below; every protocol on the site is on the methodology index.

Obligations

• Art. 11

Protocols

• PR-11-DOC v1.0

Related guides

• Building an EU AI Act compliance matrix: traceability from obligation to evidence

ICP hubs

• Annex III providers
• Annex I manufacturers

Questions

+−What is AI Act technical documentation?

Technical documentation is the document set that Art. 11(1) requires for every high-risk AI system. The documentation demonstrates that the system meets the requirements of Chapter III Section 2. The documentation gives competent authorities and notified bodies the information to assess the system. The minimum content is the nine Annex IV sections. The provider draws the documentation up before placing on the market or putting into service and keeps it up to date. Art. 18 requires the provider to keep the documentation at the disposal of the national competent authorities.

+−Which article states what the EU AI Act requires for technical documentation?

Art. 11 of Regulation (EU) 2024/1689 states the duty, and Annex IV states the content. Art. 11(1) requires the documentation before placing on the market or putting into service, and requires the provider to keep it up to date. Art. 11(2) requires a single documentation set for a system related to an Annex I Section A product. Art. 11(1) third subparagraph lets an SME, a start-up or an SMC use the simplified form the Commission establishes. Art. 11(3) lets the Commission amend Annex IV by delegated act under Art. 97.

+−What are the EU AI Act Annex IV technical documentation requirements?

Annex IV lists nine sections with twenty-three items. Section 1 has eight sub-points on the general description. Section 2 has eight sub-points on the elements and the development process, from development methods to testing with dated and signed reports and cybersecurity measures. Sections 3 to 9 cover monitoring and control, metric appropriateness, risk management, lifecycle changes, standards applied, the EU declaration of conformity and post-market monitoring. The introductory sentence applies each item as applicable, so an omitted item carries a recorded reason.

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com