If your company deploys a high-risk AI system that someone else has developed, the two previous articles in this series don't apply to deployers, each for a different reason: Article 17, because they don't build the system, and Article 18, because they don't hold what has to be retained.
With Annex IV the question is of a different order, which is why it's worth two minutes: it isn't that the obligation belongs to someone else. It's that it isn't an obligation at all.
The figure divides the AI Act's obligations between the provider and the deployer, one per row. The highlighted row is technical documentation, the quality management system and conformity (Articles 11, 17, 18 and 43 and Annex IV): the provider's column says draw it up, keep it and put the system through conformity assessment; the deployer's column is empty.
What it actually is
Its heading says it all: "Technical documentation referred to in Article 11(1)". And its opening line: "The technical documentation referred to in Article 11(1) shall contain at least the following information…"
Annex IV doesn't require anyone to do anything. It specifies the content of a document whose obligation to produce sits elsewhere — in Article 11, which requires the technical documentation of a high-risk system to be drawn up before it is placed on the market or put into service, and in Article 16, point (a), which requires the provider to ensure that its system complies with the requirements of Section 2, that one among them.
It is, literally, a table of contents. And the table of contents of a document can't be a task for whoever doesn't write the document.
The content confirms it in three lines
The first point on the list is enough to see whose document this is. The general description of the system must include:
- the relevant software or firmware versions and update requirements;
- the description of the hardware on which it is intended to run;
- if it's a component of a product, photographs or illustrations of the external features, marking and internal layout;
- the forms in which the system is placed on the market or put into service, such as software packages embedded into hardware, downloads or APIs.
Internal layout. Product photographs. Firmware versions. Distribution channels. None of that is known — nor should it be — by whoever buys a tool and uses it.
Why it ends up on the wrong lists
There's a specific reason for this, and it's more interesting than carelessness.
The deployer is mentioned in Annex IV. Point 1(g) requires "a basic description of the user-interface provided to the deployer", and point 1(h) "instructions for use for the deployer".
It's named there. Anyone searching for their obligations with a text search finds it and assumes something is owed. But it appears as the recipient of what the provider must describe, not as the author of the description. That's the difference between being mentioned in a document and having to write it.
It's the same root cause we saw with Article 50 —where the heading names both subjects— applied to an annex: the text mentions you, and the mention gets mistaken for an attribution.
What to do with Annex IV if you're a deployer
Use it for what it is: a checklist of what you can ask for.
If you're going to deploy a high-risk system, its provider must have that technical documentation once the Chapter III requirements apply to it — from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems — and, if it is an SME or a small mid-cap, it may provide those elements in a simplified manner using the form the Commission is to establish. Annex IV tells you what it contains, so it tells you what to ask for — in particular the user interface and the instructions for use in points 1(g) and 1(h), which are the parts described for you.
It isn't your obligation to hold the document, unless Article 25(1) makes you the provider: if you put your name or trademark on a high-risk system already placed on the market or put into service (without prejudice to contractual arrangements allocating the obligations otherwise), if you make a substantial modification to it such that it remains high-risk, or if you modify the intended purpose of a system that was not high-risk so that it becomes high-risk. It's the best available guide to what whoever sells it to you should be able to show you, and it fits with the rest of what's worth resolving before signing.
What this case adds to the series
Three articles, three reasons, and the third changes in nature: you don't build it, you don't hold what has to be retained, and this one doesn't even command anything.
Needing three separate readings to rule out three texts is exactly what makes solving this from memory unworkable — and why a checklist inherited from a generic article ends up containing someone else's tasks. The check isn't hard; it's that it has to be done once per article, with the result written down and dated so it doesn't have to be repeated every time someone asks.
Content in accordance with Annex IV and Article 11 of Regulation (EU) 2024/1689.
This article is for informational purposes only and does not constitute legal advice.