EU AI Act technical documentation guide: the simplified form for SMEs

This guide builds the technical documentation of a high-risk AI system in the simplified manner that Art. 11(1) third subparagraph opens to an SME, including a start-up, and to an SMC, with the route and assembly steps of PR-11-DOC v1.0. Each declared metric keeps the declaration structure of prEN 18229-2Draft, at draft stage. At the end the reader holds a size-and-eligibility record, a reduced manifest that still carries every Annex IV sub-point, a check that fails on a missing row, and the set an authorised representative holds under Art. 22(3).

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 it is placed on the market or put into service, to keep it up to date, and to give it a content that demonstrates the requirements of Chapter III Section 2 and contains at least the elements of Annex IV. The third subparagraph lets an SME, including a start-up, and an SMC provide the Annex IV elements in a simplified manner; the Commission establishes a simplified technical documentation form targeted at their needs; an eligible provider that opts for the simplified manner uses that form; and notified bodies accept the form for the purposes of the conformity assessment. Art. 3(14a) defines an SME through Article 2 of the Annex to Recommendation 2003/361/EC, and Art. 3(14b) defines an SMC through point (2) of the Annex to Recommendation (EU) 2025/1099; both definitions and the SMC category in Art. 11(1) entered the Regulation with Regulation (EU) 2026/1744, which moved the Annex III application date 2027-12-02Deferred and left the content of Annex IV unchanged, as the regulation entry records. The Art. 11 obligation page lists every Annex IV element with its split into testable, documentation and process; the simplified form is one of its documentation elements and one of its artifacts. The Art. 11 record and the protocol page name the form as one the Commission establishes and record no published version of it; this guide therefore describes the Art. 11(1) rule and the manifest an eligible provider keeps, and adds nothing about the content of a form the data does not hold.

The simplified manner changes the form in which the Annex IV elements are provided and removes no element from the list, because the second subparagraph of Art. 11(1) keeps Annex IV as the minimum content for every provider and the introductory sentence of Annex IV applies each item as applicable to the relevant AI system. The guide covers the testable elements of the Art. 11 record that survive any reduction in form: the system version and the software or firmware versions in the general description match the deployed artefact and the test reports (Annex IV section 1(a) and 1(c)); every test log and test report carries a date and a responsible signature (Annex IV section 2(g)); the lifecycle change record matches the version history (Annex IV section 6); each entry in the standards list maps to the requirement it addresses (Annex IV section 7); and the copy of the EU declaration of conformity names the same system, version and provider as the general description (Annex IV section 8). A provider established outside the Union hands the resulting set to its authorised representative, because Art. 22(3)(a) requires the representative to verify that the technical documentation has been drawn up, Art. 22(3)(b) requires it to keep the technical documentation at the disposal of the competent authorities for ten years after the system is placed on the market, and Art. 22(3)(c) requires it to provide that documentation on a reasoned request; the hub for providers outside the Union gives the full Art. 22 mandate content. The full-form section manifest, the freeze commands and the completeness script are in the related guide on assembling the Annex IV technical documentation and are not repeated here.

Inputs

The inputs are the subset of the PR-11-DOC v1.0 input table that the route determination and assembly steps use, plus the size data the eligibility record needs. The full table is on the protocol page.

The headcount in annual work units, the annual turnover and the annual balance-sheet total of the last approved accounting period, for the provider and for every partner and linked enterprise within the meaning of Article 3 of the Annex to Recommendation 2003/361/EC.
The capital and voting-rights structure of the provider: each holder at or above the partner threshold, with its own size data and whether it falls under an investor exception in Article 3(2) of that Annex.
The technical documentation as it stands, in any format that preserves text, with a version identifier per document, and any draft of the Commission simplified form the provider holds.
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, with the system version each covers.
The deployed artefact identity: build identifier, container digest or package version of the version under review.
The quality management system records under Art. 17 that a reduced section can point to: the risk management record, the change record and the post-market monitoring procedure, each with a version identifier.
The copy of the EU declaration of conformity, where drawn up, and, for a provider outside the Union, the written mandate of the authorised representative under Art. 22(1).
A shell with 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 enterprise name, figure, path, identifier, version and hash in the examples is synthetic.

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]
Compute the size category from the last approved accounting period with partner and linked enterprises aggregated.
Record size-and-eligibility record: own and aggregated headcount, turnover and balance-sheet total, partner and linked enterprise list, category, eligibility outcome per provision
[Regulation (EU) 2024/1689, Art. 3(14a) and Art. 3(14b); Annex to Recommendation 2003/361/EC, Articles 2, 3, 4 and 6; Annex to Recommendation (EU) 2025/1099, point (2)]
Determine the route and record the Commission form version the documentation follows, or its absence.
Record route determination record: full Annex IV or simplified form, with the Commission form version or 'none held in the data'
[Regulation (EU) 2024/1689, Art. 11(1) third subparagraph; PR-11-DOC step 2]
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]
Build the reduced manifest with one row per Annex IV sub-point and a form value on each row.
Record reduced section manifest: one row per Annex IV sub-point with form, reason, status, location and source fields
[Regulation (EU) 2024/1689, Annex IV sections 1 to 9 and Art. 11(1) third subparagraph; PR-11-DOC step 7]
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]
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]
Run the completeness check and confirm that no Annex IV sub-point lacks a row.
Record manifest check output: sub-points with a row, rows failing a field rule, exit code
[Regulation (EU) 2024/1689, Annex IV introductory sentence and Art. 11(1) second subparagraph; AIAssuranceLabs procedure]
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]
Draft each simplified row in one paragraph and each qms-record row as a reference to the named record.
Record reduced section drafts: one paragraph per simplified row, and one record reference with version and hash per qms-record row
[Regulation (EU) 2024/1689, Art. 17(1)(a), (g) and (h); prEN 18286, published, clauses on records; PR-11-DOC step 14]
For a provider outside the Union, assemble the set the authorised representative keeps and index it.
Record representative hand-over index: mandate copy, provider contact details, declaration of conformity copy, technical documentation index with hashes, certificate where one exists
[Regulation (EU) 2024/1689, Art. 22(1) and Art. 22(3)(a) to (c); AIAssuranceLabs procedure]
Record the owner function and update trigger per section and file the set with an index.
Record document control record per section and documentation index naming each section file, its version, its hash and the frozen input set identifier
[prEN 18286, published, clauses on document and record control; Regulation (EU) 2024/1689, Art. 11(1) and Art. 18; PR-11-DOC steps 42 and 45]

Example for step 2. The record below holds the provider's own figures, one partner enterprise and no linked enterprise. Article 6(2) of the Annex to Recommendation 2003/361/EC adds the data of a partner enterprise in proportion to the share of capital or voting rights, and adds the data of a linked enterprise in full; Article 4(1) takes the figures of the last approved accounting period; Article 4(2) changes the status only when the thresholds are crossed over two consecutive accounting periods; Article 3(4) removes SME status where public bodies control a quarter or more of the capital or voting rights, subject to the exceptions in Article 3(2). The thresholds the outcome is tested against are the ones in Article 2 of that Annex for an SME and in point (2) of the Annex to Recommendation (EU) 2025/1099 for an SMC. The enterprise names and every figure are synthetic.

# Synthetic example: size-and-eligibility.yaml for the provider of demo-system 2.4.0
enterprise: demo-provider              # synthetic name
accounting_period: last-approved       # Annex to Recommendation 2003/361/EC, Article 4(1)
own_figures:
  headcount_awu: 38                    # annual work units, Annex Article 5
  turnover_eur_million: 6.4
  balance_sheet_eur_million: 4.9
partner_enterprises:                   # 25 % to 50 % of capital or voting rights, Annex Article 3(2)
  - name: demo-holding                 # synthetic name
    share: 0.30
    investor_exception: false          # Annex Article 3(2)(a) to (d) not claimed
    headcount_awu: 120
    turnover_eur_million: 31.0
    balance_sheet_eur_million: 27.5
linked_enterprises: []                 # Annex Article 3(3); data added in full when present
public_body_control_quarter_or_more: false   # Annex Article 3(4)
aggregated:                            # own figures plus 0.30 of the partner, Annex Article 6(2)
  headcount_awu: 74
  turnover_eur_million: 15.7
  balance_sheet_eur_million: 13.15
previous_period_category: sme          # Annex Article 4(2): two consecutive periods change a status
outcome:
  category: sme                        # sme | smc | none
  basis: "Art. 3(14a); Annex to Recommendation 2003/361/EC, Article 2(1)"
  art_11_1_simplified_form: eligible   # SME, start-up or SMC status is the only condition
  art_63_1_qms_simplified: not-eligible   # a partner enterprise is present

Example for step 5. The reduced manifest keeps one row per Annex IV sub-point, twenty-three in the full file, and adds a form field with three values: full, where the content is written out as in the full form; simplified, where the content is given in a shorter form under the third subparagraph; and qms-record, where the row points to a record the quality management system already holds under Art. 17(1), with the record's version and hash. Every row that is not full carries a reason, because a notified body reading the form under Art. 11(1) third subparagraph and a market surveillance authority reading it on a reasoned request under Art. 22(3)(c) see the same file and cannot tell a deliberate reduction from a gap without one. Seven rows are shown.

# Synthetic example: annex-iv-reduced-manifest.yaml for demo-system 2.4.0
system: demo-system
version: "2.4.0"
build_id: "sha256:3f9c1a7e0b5d4c2f8a6e9d1b7c3f5a8e2d4b6c8f0a1e3d5b7c9f1a3e5d7b9c1f"
route: simplified-form                 # annex-iv-full | simplified-form
commission_form_version: none-held-in-data   # PR-11-DOC step 2 record
eligibility_record: size-and-eligibility.yaml
sections:
  - id: "1(a)"
    title: intended purpose, conditions of use, provider, version and relation to previous versions
    form: full
    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
    form: full
    status: not-applicable
    reason: the system is delivered as an API and is not a component of a physical product
  - id: "2(b)"
    title: design specifications, key design choices, optimisation target, trade-offs
    form: simplified
    reason: one architecture and one optimisation target; the rationale fits one paragraph with the model card as source
    status: present
    location: docs/annex-iv/02b-design-specifications.md
    source: [model-card-2.4.0.md]
  - id: "2(g)"
    title: validation and testing procedures, data, metrics, test logs and signed test reports
    form: full
    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: "5"
    title: detailed description of the risk management system under Art. 9
    form: qms-record
    reason: the risk management record under Art. 17(1)(g) is the same document; the row references it by version and hash
    status: present
    qms_record: { id: QMS-RM-2.4.0, version: "3", hash: "sha256:9b1e5c7a2d4f6081a3c5e7f9b1d3f5a7c9e1b3d5f7a9c1e3b5d7f9a1c3e5b7d9" }
    source: [qms/risk-management-record-3.md]
  - id: "6"
    title: relevant changes made to the system through its lifecycle
    form: qms-record
    reason: the modification record under Art. 17(1)(a) holds the version history; the row references it
    status: present
    qms_record: { id: QMS-CHG-2.4.0, version: "7", hash: "sha256:4d6f8a0c2e4b6d8f0a2c4e6b8d0f2a4c6e8b0d2f4a6c8e0b2d4f6a8c0e2b4d6f" }
    source: [qms/change-record.csv]
  - id: "9"
    title: post-market monitoring system and plan under Art. 72
    form: qms-record
    reason: the post-market monitoring procedure under Art. 17(1)(h) holds the plan; the row references it
    status: absent
    source: []

Example for step 8. The script loads the manifest and the eligibility record, checks that every one of the twenty-three Annex IV sub-points has a row, that the form value is one of the three, that a row not marked full carries a reason, that a qms-record row names a record with a version and a hash, that a present or partial row has a location or a record, that a not-applicable row has a reason, and that a simplified-form route rests on an eligibility record whose outcome is eligible under Art. 11(1). It prints one line per failing row and exits with code 1 on any failure, so that it can run as a repository check before the set is filed. It needs the PyYAML parser.

# Synthetic example: check annex-iv-reduced-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"]
)
FORMS = {"full", "simplified", "qms-record"}
STATUSES = {"present", "partial", "absent", "not-applicable"}

with open("annex-iv-reduced-manifest.yaml", encoding="utf-8") as f:
    manifest = yaml.safe_load(f)
with open(manifest.get("eligibility_record", "size-and-eligibility.yaml"), encoding="utf-8") as f:
    eligibility = yaml.safe_load(f)

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

if manifest.get("route") == "simplified-form":
    outcome = eligibility.get("outcome", {}).get("art_11_1_simplified_form")
    if outcome != "eligible":
        failures.append(("route", "simplified-form without an eligible Art. 11(1) outcome: %r" % outcome))

for sid in ANNEX_IV:
    row = rows.get(sid)
    if row is None:
        failures.append((sid, "no row in manifest; the simplified form removes no Annex IV sub-point"))
        continue
    form = row.get("form")
    status = row.get("status")
    if form not in FORMS:
        failures.append((sid, "form %r is not one of %s" % (form, sorted(FORMS))))
    if form != "full" and not row.get("reason"):
        failures.append((sid, "form %s without a reason" % form))
    if form == "qms-record":
        rec = row.get("qms_record") or {}
        if not all(rec.get(k) for k in ("id", "version", "hash")):
            failures.append((sid, "qms-record without id, version and hash"))
    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") or row.get("qms_record")):
        failures.append((sid, "status %s without a location or a record" % 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 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 seven rows shown above the script reports eighteen failures: row 9 is absent and names no record yet, which fails twice, and the sixteen sub-points not shown have no row. Rows 5 and 6 pass as qms-record because each names a record with an identifier, a version and a hash; row 2(b) passes as simplified because it carries a reason. Every count is an output of this example, never a requirement of the Act.

Example for step 11. The index below is what a provider outside the Union hands its authorised representative, ordered by the points of Art. 22(3). The mandate copy sits first because Art. 22(3) requires the representative to provide a copy of the mandate to a market surveillance authority on request; the technical documentation entry points to the reduced manifest and the frozen input set rather than to a single file, so that the representative can produce the set as filed and a later change shows up as a hash mismatch. Names, paths and hashes are synthetic.

# Synthetic example: representative-handover-index.yaml for demo-system 2.4.0
provider: demo-provider                # synthetic name, established outside the Union
authorised_representative: demo-rep    # synthetic name, established in the Union
items:
  - point: "Art. 22(1) and 22(3)"
    item: written mandate, copy in an official language of the Member State of the representative
    path: handover/mandate-signed.pdf
    hash: "sha256:7c9e1b3d5f7a9c1e3b5d7f9a1c3e5b7d9f1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e"
  - point: "Art. 22(3)(b)"
    item: provider contact details
    path: handover/provider-contact.md
    hash: "sha256:2a4c6e8b0d2f4a6c8e0b2d4f6a8c0e2b4d6f8a0c2e4b6d8f0a2c4e6b8d0f2a4c"
  - point: "Art. 22(3)(b)"
    item: copy of the EU declaration of conformity under Art. 47
    path: handover/eu-doc-2.4.0.pdf
    hash: "sha256:5b7d9f1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3b5d7f9a1c3e5b7d"
  - point: "Art. 22(3)(a) and 22(3)(b)"
    item: technical documentation in the simplified form, as filed
    path: docs/annex-iv/index.md
    manifest: annex-iv-reduced-manifest.yaml
    frozen_input_set: frozen-input-set.txt
    hash: "sha256:8d0f2a4c6e8b0d2f4a6c8e0b2d4f6a8c0e2b4d6f8a0c2e4b6d8f0a2c4e6b8d0f"
  - point: "Art. 22(3)(b)"
    item: certificate, where a notified body issued one
    path: none
    reason: conformity assessment by internal control under Annex VI; no certificate exists
  - point: "Art. 22(3)(c)"
    item: log access statement naming the logs under the provider's control and how the representative obtains them
    path: handover/log-access-statement.md
    hash: "sha256:1e3b5d7f9a1c3e5b7d9f1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3b"

A pitfall that vendor documentation omits

The Regulation carries two SME simplifications with two different eligibility tests, and a provider that passes one does not always pass the other. Art. 11(1) third subparagraph opens the simplified technical documentation form to any SME, including a start-up, and any SMC, with status under Art. 3(14a) or Art. 3(14b) as the only condition. Art. 63(1), as the Art. 17 record states, lets an SME, including a start-up, meet certain elements of the quality management system in a simplified manner only where it has no partner enterprises or linked enterprises within the meaning of Recommendation 2003/361/EC, and Art. 63(2) keeps every other requirement in force for the same provider. The size record in step 2 therefore carries one outcome per provision. The status itself is computed, not declared: Article 6 of the Annex to Recommendation 2003/361/EC aggregates the headcount and financial data of partner enterprises in proportion to the holding and of linked enterprises in full, so a start-up whose own figures sit under the thresholds can exceed them once a majority shareholder's group is added, while Article 3(2) of that Annex leaves an enterprise autonomous where the holder at or above a quarter of the capital is a venture capital company, a business angel within the limit the Annex states, a university, a non-profit research centre or an institutional investor that is not linked to it. Article 4(2) adds a time condition: a status changes only when the thresholds are crossed over two consecutive accounting periods, so a provider that grew past the SME ceiling in the last period keeps its status for that period and records the previous one in the eligibility record. The simplified form itself is no lighter element list: Art. 11(1) second subparagraph keeps Annex IV as the minimum content, and a qms-record row that points to a record the representative cannot produce fails the same Art. 22(3)(c) request as a missing section.

Regulation (EU) 2024/1689 sets no numeric threshold for any check in this guide, and no published document sets a required proportion of full, simplified and qms-record rows; the pass criterion of the protocol is binary, present or absent, consistent or not, and the form value on each row is the provider's justified choice recorded in the reason field. 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, so no presumption of conformity is available; the declaration structure comes from prEN 18229-2Draft, at draft stage, whose stage is on the standards page; the record and document control routine that a qms-record row rests on comes from prEN 18286Published, published and not cited in the Official Journal; and 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, in the simplified form as in the full one.

What the result shows and what it does not

The eligibility record, the reduced manifest, the frozen input set and the check output show, for one version at one point in the lifecycle, which size category the aggregated figures give under the two Recommendations, that every Annex IV sub-point has a row with a form value and a reason where the form is reduced, where each row's content or record sits, and that the set has not changed since it was frozen. They do not show that the size category is correct in law; the category rests on the accounting figures and the shareholding structure the provider supplied, and the SME, start-up or SMC status is the provider's decision, which the record documents and does not decide. 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 Commission simplified form in a given conformity assessment, which is the limit the protocol states. The set is frozen at step 7, so a change to the system, the documentation or a record 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 Art. 11 and for the set its authorised representative holds under Art. 22(3); 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 its scope limits are on what we cannot do.

The obligation, the protocol, the related guides on the full Annex IV assembly and on the Art. 17 documentation that a qms-record row points to, and the hubs for the two situations this guide serves are listed below.

Obligations: Art. 11
Protocols: PR-11-DOC v1.0
Related guides: Annex IV of the AI Act: assembling the technical documentation
EU AI Act Article 17 quality management system: building the QMS documentation
ICP hubs: Startups
Non-EU providers

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

Ask about scope hello@aiassurancelabs.com