Annex IV section-by-section: what hiring AI deployers must actually document
Annex IV of the EU AI Act lists nine sections of required documentation. Most published guidance treats it as a vendor obligation. This post walks through it from the deployer's perspective, section by section, and is the closest thing we have to a public answer key.
- EU AI Act
- Annex IV
- Deployer obligations
A friend who runs People at a 1,200-person company in Berlin recently sent me a screenshot of her general counsel’s email. The email was three sentences long. The third sentence was: "Annex IV." Just like that, with no question mark.
She is in good company. Annex IV of the EU AI Act enumerates the technical documentation a high-risk system must accompany. It is written from the provider’s perspective. But once the deployer has the provider’s file in hand, the deployer is on the hook for using the system in conformity with that documentation, logging deviations, and producing a parallel deployer-side file that demonstrates conformity. Reading Annex IV like a provider is reading a maintenance manual you will never use. Reading it like a deployer is reading a list of evidence you will be asked to produce.
Here is the deployer-side reading.
§1. General description of the AI system
For the deployer, this is straightforward but easy to get wrong: do not copy the vendor’s general description verbatim. Write your own, focused on how you use it. If the vendor sells a general "screening" product but you use it only for resume parsing and never for ranking, your §1 says that. The deployer’s §1 is shorter than the vendor’s.
§2. Detailed description of the system’s elements and development process
This is the vendor’s section. The deployer obtains it under the Article 13 transparency obligation that the provider has to the deployer. If you cannot get it, you document the request, the response or refusal, and the remediation plan.
§3. Information about the training, validation, and test data
Vendor’s section. Same procedure as §2.
§4. Detailed information about the monitoring, functioning, and control of the system
The provider’s file describes their built-in monitoring. The deployer’s parallel obligation is the Article 26 instructions of use: are you using the system inside the provider’s documented operating envelope? Are you logging deviations? §4 is the section where the provider’s instructions meet the deployer’s reality.
§5. Description of the appropriate risk management system
Provider produces theirs (Article 9); deployer maintains a parallel risk management posture for deployment-side risks that the provider cannot foresee — the role mix you hire for, the workforce you screen against, the local labor market dynamics.
§6. Description of changes made to the system through its life cycle
Vendor side. Deployer side: a change log of when the deployer materially changed how the system is used. New job families. New populations. New integrations.
§7. List of harmonised standards or common specifications applied
Largely provider side, although the deployer may want to reference any internal frameworks (NIST AI RMF, ISO 42001) the deployer is mapping to.
§8. Copy of the EU declaration of conformity
The provider’s declaration. The deployer keeps it.
§9. Detailed description of the system for evaluation of the AI system’s performance in the post-market phase
This is where the deployer does substantive work. Article 72 places post-market monitoring obligations on the provider, but the deployer is the party closest to the system’s in-the-field performance. The deployer’s §9 covers: how you measure performance, what drift signals you watch for, what the incident-reporting workflow looks like, what the customer-notification protocol is.
The Casework conformity file is structured against these nine section numbers, with deployer-specific content in §1, §4, §5, §6, §7, and §9 and cross-references to provider materials in §2, §3, and §8. If you want to see the table of contents, it’s on the Pack page.