Annex IV of the EU AI Act contains nine numbered points, of which points 1 and 2 are each subdivided (a) to (h), giving seven unsubdivided points plus sixteen lettered sub-points. On an open-weight model you downloaded, only two of those rows touch the third-party model at all: 2(a), which asks what you did with the pre-trained system, and 2(d), which asks for datasheets on the training data sets, opening with the qualifier 'where relevant'. 2(a) is a fact you hold, so 2(d) is the single row whose underlying information may sit in someone else's building. The Llama 3.3 70B model card devotes two lines to training data, which is a proper model card and a poor datasheet, because the two artefacts document different objects. Everything else is evidence you manufacture, and two rows cannot be filled honestly from behind a vendor endpoint: 1(e) asks for the hardware the system is intended to run on and 1(c) asks for software and firmware versions. On the Annex III route there is no notified body, so under Annex VI point 3 you examine your own technical documentation, and Article 18 makes you hold it for 10 years. Start by counting how many of the sixteen lettered sub-points have a named artefact behind them, then close 1(c) and 1(e) from a running host today.
Annex IV opens with one sentence that decides how much of the work is anyone else's: "The technical documentation referred to in Article 11(1) shall contain at least the following information, as applicable to the relevant AI system". If you are building a high-risk system on an open-weight model you downloaded, the first question to ask about EU AI Act Annex IV technical documentation is what the model publisher owes you. The annex answers it in two rows.
Point 2(a) asks for the methods and steps performed for development, "including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider". That is a description of what you did, and you hold every fact in it. Point 2(d) asks, "where relevant", for datasheets on the training data sets. Those two are the only rows in the annex that touch a third-party model at all, and only the second can put a required fact in someone else's building. Everything else describes the system you built, on the hardware you chose, with the evidence you generated.
This post is the Annex III route: a standalone high-risk system with no pre-existing sectoral technical file to fold the records into. Where the system is a product or a safety component under the Union harmonisation legislation in Section A of Annex I, Article 11(2) requires a single set of technical documentation covering both regimes, which we have worked through for medical device teams facing the MDR and the AI Act at once. A sectoral conformity assessment that already runs through a notified body changes the problem again, as it does for machinery safety components. Whether fine-tuning makes you the provider at all is the prior question, settled by the compute test for provider status, and the surrounding regulatory work sits in the AI for business pillar. Every legal fact below is read off the Commission's own pages: the AI Act Service Desk entry for the article or annex named, and the digital-strategy site for the dates.
Nine numbered points, and the sixteen lettered sub-points under points 1 and 2
Annex IV contains nine numbered points. Points 1 and 2 are each subdivided into lettered sub-points (a) to (h). Points 3 through 9 carry no sub-points. That is seven unsubdivided points plus sixteen lettered sub-points, eight under each of the two subdivided ones.
Point 1 opens "A general description of the AI system including:" and runs through its intended purpose with the provider name and version, how the system interacts with hardware or software that is not part of it, software and firmware versions, the forms it is placed on the market in, the hardware it runs on, product photographs where it is a component, the user interface, and instructions for use.
Point 2 opens "A detailed description of the elements of the AI system and of the process for its development, including:" and is the heaviest of the nine, because 2(b) alone asks for the design specifications, the general logic of the system and of the algorithms, the key design choices with their rationale and assumptions, the main classification choices, what the system is designed to optimise for, expected output and output quality, and the trade-offs made to comply with Chapter III, Section 2.
Points 3 through 9 read, verbatim and in compressed form:
Points 4 and 8 are one line each. The mass of the file sits in points 1, 2 and 3. Point 3 and all eight sub-points of point 1 describe your system alone, and of point 2's eight sub-points, exactly two touch anything outside your own organisation.
The two rows that touch the model you downloaded: 2(a) and 2(d)
Read 2(a) slowly, because it names third parties and asks nothing of them. It asks for "the methods and steps performed for the development of the AI system, including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider". The object of the sentence is the provider's own conduct. Which checkpoint you pulled, at which revision, what you froze, what you fine-tuned, what adapter you merged, what you quantised and at what precision: all of that is yours to state, and none of it requires a document from the publisher. On an open-weight base this row is closed by a run record and a weight checksum, not by procurement.
Point 2(d) is the one row that can put a required fact outside your control:
where relevant, the data requirements in terms of datasheets describing the training methodologies and techniques and the training data sets used, including a general description of these data sets, information about their provenance, scope and main characteristics; how the data was obtained and selected; labelling procedures (e.g. for supervised learning), data cleaning methodologies (e.g. outliers detection);
Five limbs, and a qualifier that carries most of the weight. "Where relevant" is the opening of the provision, and dropping it turns an argued scope question into a flat obligation. There are two honest readings on a downloaded base. The narrow one: "the training data sets used" means the data sets used in the development of this AI system, which on a frozen base plus a fine-tune is your fine-tuning corpus, and the base model's pretraining corpus is upstream fact you are not in a position to characterise. The broad one: the system's behaviour is inherited from pretraining, so a datasheet that stops at the fine-tune describes a fraction of what determines the output.
We would write the narrow reading, and we would write it down. Record the scoping decision as a dated entry in the 2(d) row with the reasoning, name what you could not obtain and what you asked for, and produce complete datasheets at all five limbs for every corpus you did assemble. The dataset datasheet keyed to the AI Act's data-governance records is the template for those rows. What loses an argument with a market surveillance authority is not a defended narrow scope; it is a row with nothing in it.
What an open-weight model card states against what 2(d) names
Take a specific card rather than an impression of cards. The Llama 3.3 model card in the meta-llama/llama-models repository, at tag v0.2.0, path models/llama3_3/MODEL_CARD.md, gives a Training Data section of two lines. The Overview line: "Llama 3.3 was pretrained on ~15 trillion tokens of data from publicly available sources. The fine-tuning data includes publicly available instruction datasets, as well as over 25M synthetically generated examples." The Data Freshness line: "The pretraining data has a cutoff of December 2023." The summary table adds one cell, "A new mix of publicly available online data.", alongside 70B parameters, 128k context, 15T+ tokens and a December 2023 knowledge cutoff.
Set that against the five limbs.
That card is a good card of its kind. The mismatch is categorical: a model card documents a model, and point 2(d) names datasheets that document data sets. Asking one artefact to be the other is the error, and the same card shows how easily an upstream figure gets misread. Its Hardware and Software prose gives a cumulative 39.3M GPU hours on H100-80GB and 11,390 tons CO2eq, while the table those figures point at holds one row, Llama 3.3 70B, at 7.0M GPU hours and 12.9 metric tons location-based CO2eq. Copy the prose number into your point 2(c) row and you have filed a wrong fact about your own system.
| Point 2(d) limb | The verbatim ask | What the Llama 3.3 70B card states | What you would still have to write |
|---|---|---|---|
| General description | "a general description of these data sets" | "~15 trillion tokens of data from publicly available sources"; "A new mix of publicly available online data." | Per-corpus description for every data set you assembled, at the granularity a reviewer can act on |
| Provenance, scope, characteristics | "information about their provenance, scope and main characteristics" | Scope stated as 15T+ pretraining tokens with a December 2023 cutoff; provenance stated as publicly available sources; no per-source characteristics | Provenance chain per corpus: source, licence basis, collection window, language and domain mix |
| How obtained and selected | "how the data was obtained and selected" | Not stated | Collection method, inclusion and exclusion criteria, sampling and de-duplication decisions |
| Labelling procedures | "labelling procedures (e.g. for supervised learning)" | Fine-tuning data described as public instruction datasets plus over 25M synthetically generated examples; no labelling procedure stated | Annotation guidelines, annotator instructions, adjudication rules, inter-annotator agreement where measured |
| Data cleaning methodologies | "data cleaning methodologies (e.g. outliers detection)" | Not stated | Filtering, de-duplication, outlier and toxicity handling, and what each step removed |
Points 1, 3, 4, 5, 6, 7 and 8: the rows you manufacture
Seven points, no upstream dependency in any of them, nor in point 9 below. One of the seven, point 1, holds two rows that change character entirely depending on where the model runs.
Point 1 is where deployment location becomes a documentation question rather than an architecture preference. Sub-point 1(e) asks for "the description of the hardware on which the AI system is intended to run". Behind a vendor endpoint there is no honest answer beyond naming someone else's estate. Sub-point 1(c) asks for "the versions of relevant software or firmware, and any requirements related to version updates", and on a hosted endpoint that value can change without a version identifier you control and without notice you received. On your own hardware both rows close in an afternoon: 1(e) is a bill of materials, and 1(c) is a pinned image digest, a driver version and a checksum over the weight files. Sub-point 1(d) then asks for "the description of all the forms in which the AI system is placed on the market or put into service, such as software packages embedded into hardware, downloads, or APIs", which names downloads and APIs in the text, so a self-hosted distribution sits squarely inside the row.
Point 1(c), and the compute half of point 2(c) where the same host ran the fine-tune and the evaluations, come off the machine that serves the model; point 1(e) is a bill of materials you already hold. The capture below is a house convention, not a prescribed format:
# Annex IV point 1(c): versions of relevant software or firmware
# Annex IV point 2(c): the computational resources used
out=annex-iv/01-general-description/c-evidence/host-$(date -u +%Y%m%dT%H%M%SZ).txt
mkdir -p "$(dirname "$out")"
{
date -u +%Y-%m-%dT%H:%M:%SZ
uname -a
nvidia-smi --query-gpu=name,driver_version,memory.total --format=csv
docker image inspect --format '{{.Id}}' "$SERVING_IMAGE"
python -c 'import torch, vllm; print(torch.__version__, vllm.__version__)'
sha256sum "$WEIGHTS_DIR"/*.safetensors
} | tee "$out"Point 3 is measurement rather than prose, because the degrees of accuracy for specific persons or groups is something you have to measure. Point 4, one line, asks whether your metrics were the right metrics for this system, which catches an accuracy number reported on a distribution nobody deploys against. Point 5 points at Article 9, whose service desk page carries no amendment banner, and whose paragraph 2 defines the risk management system as "a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating".
Point 6 covers changes actually made through the lifecycle, distinct from 2(f), which covers changes pre-determined at design time and belongs with the pre-determined change control that medical device teams already run. Point 7 has two branches, and which one you are on depends on the state of the Official Journal on the day you sign, so record the branch and the date rather than a standing claim; the Article 40 presumption of conformity route is worked through in our comparison of ISO 42001 against the AI Act. Point 8 is a copy of the declaration under Article 47, whose contents are Annex V's eight items: system name and type with a reference allowing traceability, provider or authorised representative name and address, a statement that the declaration is issued under the provider's sole responsibility, a statement of conformity with the Regulation and other applicable Union law, a data protection compliance statement where personal data is processed, references to harmonised standards or common specifications used, notified body details where applicable, and the place and date of issue with the signatory's name and function.
The retention clock is the second reason the host matters. Article 18 puts the technical documentation at the disposal of national competent authorities for 10 years, a clock this blog has already walked for the MDR technical file. Points 3, 4 and 6 are claims about behaviour, and such a claim is only defensible while the behaviour can be reproduced. A checkpoint on storage you control is byte-identical in year eight; a retired hosted model version is not, and the file then documents a system nobody can re-run. What an EU region does and does not buy you is covered separately.
What to ask a commercial model provider that will sign
Article 25(4) is the provision that turns documentation gaps into contract terms. Its first subparagraph requires the provider of a high-risk AI system and the third party supplying an AI system, tools, services, components or processes used or integrated in it to "by written agreement, specify the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation". Its second subparagraph opens with a sentence worth reading for what it does not say: "The AI Office may develop and recommend voluntary model terms for contracts between providers of high-risk AI systems and third parties that supply tools, services, components or processes that are used for or integrated into high-risk AI systems." The verb is "may", and no such published model terms were confirmed for this post. You are drafting the schedule yourself.
The schedule below is a drafting aid for your legal team, not legal advice. It has seven items: the six Annex IV rows in the table plus a survivability clause that has no Annex IV row of its own.
Supplier information schedule, referenced from the written agreement under Article 25(4) of Regulation (EU) 2024/1689. 1. Training data sets, feeding Annex IV point 2(d) Supplier provides, per data set: a general description; provenance, scope and main characteristics; how the data was obtained and selected; labelling procedures; data cleaning methodologies. 2. Architecture and compute, feeding Annex IV point 2(c) Supplier provides the system architecture and the computational resources used to develop, train, test and validate anything the supplier develops or trains for us. 3. Version identity and notice, feeding Annex IV point 1(c) Supplier provides an immutable version identifier per model build and written notice before any change to that identifier. 4. Execution environment, feeding Annex IV point 1(e) Supplier states the hardware the model is intended to run on. 5. Testing evidence, feeding Annex IV point 2(g) Supplier provides validation and testing procedures, the metrics used, and test logs and test reports dated and signed by the responsible persons, for testing the supplier performed. 6. Cybersecurity, feeding Annex IV point 2(h) Supplier states the cybersecurity measures put in place. 7. Survivability, feeding Article 18 Supplier's obligations under 1 to 6 survive termination for the 10 year period during which we must keep the technical documentation at the disposal of national competent authorities.
A publisher whose weights you downloaded is party to none of this, which is the trade. What it does owe the public is the Article 53(1)(d) summary about the content used for training, on an AI Office template, and which Chapter V duties survive the open-source relief is already worked out.
| Annex IV row | What you produce yourself on an open-weight base | What you obtain from a commercial provider | The schedule item that carries it |
|---|---|---|---|
| 1(c) software and firmware versions | Image digest, driver version, weight checksum, captured from the host | An immutable version identifier per build plus advance written notice of change | Item 3 |
| 1(e) hardware intended to run on | Bill of materials for the serving nodes | A statement of the hardware the model is intended to run on | Item 4 |
| 2(c) architecture and computational resources | Your own architecture diagram and accelerator hours for training and evaluation | The same, for anything the supplier develops or trains on your behalf | Item 2 |
| 2(d) training data datasheets | Full datasheets at all five limbs for every corpus you assembled | Data set information at the five limbs the provision names | Item 1 |
| 2(g) validation and testing | Your evaluation harness, metrics and dated signed test reports | The supplier's procedures, metrics and dated signed logs for testing it performed | Item 5 |
| 2(h) cybersecurity measures | Controls on the serving path, the weights at rest and the retrieval layer | A statement of the measures put in place in the supplied component | Item 6 |
Which provisions around Annex IV the Commission flags as amended
This post is anchored on the annex rather than on the articles around it for a reason. The Commission's own pages flag the provisions the Digital Omnibus on AI has changed:
This provision has been amended by the Digital Omnibus on AI. The text displayed on this page has not yet been updated to reflect those amendments.
Three of the eight are clean and five are flagged, and the clean three carry the rows this post spends its evidence on.
The Article 25 page carries the banner, so its displayed carve-out for free and open-source suppliers, "This paragraph shall not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence", is text the issuing authority itself marks as not reflecting current amendments. The banner on that page links to the Digital Omnibus on AI Regulation Proposal library page, dated 19 November 2025 and hosting a Commission proposal under the EUR-Lex reference CELEX:52025PC0836, rather than to an adopted text. The adopted AI Omnibus Regulation entered into force on 27 July 2026 with its final text at OJ:L_202601744, and its amended wording could not be retrieved for this post, so nothing here is built on it. Note also Article 11(3): the Commission may amend Annex IV by delegated act, which is reason enough to record the annex version you filed against.
The dates that bind the filing are not the Act's application date. The AI Act entered into force on 1 August 2024 and became applicable on 2 August 2026, but the Commission states that rules for systems in certain high-risk areas will apply from 2 December 2027, and that systems integrated into products such as lifts or toys follow from 2 August 2028.
| Provision | Digital Omnibus banner on the Commission page | What this post uses it for |
|---|---|---|
| Annex IV | No banner. Cites the official version of 13 June 2024 | Every row of the file, and the two upstream rows |
| Article 9 | No banner | The risk management system behind point 5 |
| Article 47 | No banner | The declaration of conformity behind point 8, and Annex V's eight items |
| Article 10 | Banner present | Data governance context for 2(d), used only as background |
| Article 11 | Banner present | The obligation to draw the file up before placing on the market |
| Article 25 | Banner present | The written agreement and the supplier schedule |
| Article 43 | Banner present | The routing of Annex III points 2 to 8 to internal control |
| Article 72 | Banner present | The post-market evaluation system behind point 9 |
The worksheet, and the file nobody outside your company reads until they do
One row per numbered point, with the artefact that closes it and the role that signs it.
On disk it is simpler than a register. One directory per numbered point, one file per lettered sub-point, evidence attachments beside the row they support:
annex-iv/
01-general-description/
a-intended-purpose-provider-and-version.md
b-interaction-with-other-hardware-and-software.md
c-software-and-firmware-versions.md # image digest, driver, runtime
c-evidence/ # one host capture per release
d-forms-placed-on-the-market.md # download, embedded, API
e-hardware-intended-to-run-on.md # bill of materials
f-photographs-where-a-product-component.md
g-user-interface-description.md
h-instructions-for-use.md
02-elements-and-development/
a-development-methods-and-pre-trained-systems.md
b-design-specifications-and-logic.md
c-architecture-and-computational-resources.md
d-training-data-datasheets/ # where relevant
e-human-oversight-assessment.md
f-pre-determined-changes.md # where applicable
g-validation-and-testing/ # dated, signed test logs
h-cybersecurity-measures.md
03-monitoring-functioning-control.md
04-appropriateness-of-performance-metrics.md
05-risk-management-system.md # Article 9
06-relevant-lifecycle-changes.md
07-harmonised-standards-or-solutions-adopted.md
08-eu-declaration-of-conformity.pdf # Article 47, Annex V
09-post-market-evaluation-system.md # Article 72Article 43(2) routes Annex III points 2 to 8 to conformity assessment based on internal control under Annex VI with no notified body, as the ISO 42001 comparison sets out. Read what Annex VI then asks of you. Point 2 has the provider verify that the established quality management system complies with Article 17. Point 3 has the provider examine the information contained in the technical documentation "to assess the compliance of the AI system with the relevant essential requirements set out in Chapter III, Section 2". Point 4 has the provider verify that the design and development process and the post-market monitoring under Article 72 are consistent with that documentation. You grade your own file, against itself. Annex III point 1, biometrics, is the exception, because Article 43(1) offers it the notified-body route.
The quality management system Annex VI point 2 grades is walked in the thirteen points of Article 17, and on the deployer side the same system generates a fundamental rights impact assessment somebody else files. For a bank or insurer the Annex IV file lands inside the records held under financial services record-keeping rather than in a new cabinet beside them.
This week, open whatever file you have and count how many of the sixteen lettered sub-points have a named artefact behind them rather than a paragraph of intent. Then close 1(c) and 1(e) first, because those two are a shell session away on a host you control, and they are the two rows a hosted endpoint cannot honestly fill at all.
| Annex IV point | What the text asks for | Upstream or in-house | Evidence artefact | Who signs |
|---|---|---|---|---|
| 1. General description | Purpose, provider and version, interaction with other hardware and software, software and firmware versions, forms placed on the market, hardware it runs on, photographs, user interface, instructions for use | In-house | Product specification, pinned image digest, host bill of materials, deployer manual | Product owner |
| 2. Elements and development | Development methods including recourse to pre-trained systems, design specifications, architecture and computational resources, training data datasheets, oversight assessment, pre-determined changes, validation and testing, cybersecurity | In-house, with two upstream rows: 2(a) and 2(d) | Fine-tune run records, corpus datasheets, dated and signed test logs, threat model | ML lead |
| 3. Monitoring, functioning, control | Capabilities and limitations, degrees of accuracy for specific persons or groups, foreseeable unintended outcomes, oversight measures, input data specifications | In-house | Evaluation report with subgroup breakdowns, oversight design note | ML lead and risk owner |
| 4. Appropriateness of metrics | Whether the performance metrics suit this system | In-house | Metric justification memo tied to the intended purpose | ML lead |
| 5. Risk management system | The Article 9 system, run as a continuous iterative process | In-house | Article 9 risk file with review dates | Risk owner |
| 6. Lifecycle changes | Relevant changes made by the provider through the lifecycle | In-house | Change log keyed to the 1(c) version identifiers | Release manager |
| 7. Standards or solutions | Harmonised standards applied, or the solutions adopted where none were | In-house | Standards list, or the solutions description, dated | Quality lead |
| 8. Declaration of conformity | A copy of the Article 47 declaration | In-house | Signed declaration carrying Annex V's eight items | Authorised signatory |
| 9. Post-market evaluation | The Article 72 system, including the monitoring plan | In-house | Post-market monitoring plan and its reporting route | Post-market owner |
FAQ
Quick answers to the questions this post tends to raise.
