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.
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, addressed to the provider of high-risk systems.
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: packages embedded in 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."
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. Annex IV tells you what it contains, so it tells you what to ask for — in particular the user interface in point 1(g), which is the part described for you.
It isn't your obligation to hold the document. 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.