How to Write Instructions for Use That Actually Comply With Annex IV
If you provide a high-risk AI system, you must supply instructions for use to your deployers. This isn’t a suggestion, and a standard product manual won’t meet the requirements. The EU AI Act specifies exactly what these instructions must contain, and the requirements go well beyond what most AI providers currently document.
Annex IV, section 9 and Article 13 define the requirements. Here’s what your instructions for use need to cover and how to write documentation that actually complies.
Why instructions for use matter
Under Article 26, deployers are required to use high-risk AI systems “in accordance with the instructions for use.” This creates a direct compliance dependency: deployers can’t meet their obligations if you haven’t given them adequate instructions.
If your instructions are incomplete, vague, or missing, your deployers are in a difficult position — they can’t comply with their own obligations, and you’ve failed yours. The liability flows both ways.
Instructions for use are also a key part of the conformity assessment. When your system is assessed for compliance (whether through internal assessment or by a notified body), the adequacy of your instructions is evaluated.
What Annex IV requires
Annex IV, section 9 specifies that instructions for use must include “at a minimum” the following information:
Provider identity and contact details
Your name, registered trade name or trademark, postal address, email address, and any other contact details for reaching you. If you’ve appointed an authorised representative in the EU, their details as well.
This is straightforward but often incomplete. Ensure your documentation includes a specific compliance contact, not just a generic support email.
System capabilities and limitations
A description of the AI system’s capabilities and limitations of performance, including:
Levels of accuracy, robustness, and cybersecurity. Provide quantified performance metrics where possible. “The system achieves 94% accuracy on the validation dataset” is useful. “The system is highly accurate” is not.
Known or foreseeable circumstances that may lead to risks. If the system performs poorly on certain input types, demographic groups, or edge cases, say so explicitly. If accuracy degrades in certain conditions (low data quality, unusual input distributions, adversarial inputs), document those conditions.
Foreseeable misuse. Describe uses that fall outside the system’s intended purpose but that a deployer might reasonably attempt. If your hiring tool was validated for screening technical roles but someone might use it for executive recruitment, flag that as outside the validated use case.
Intended purpose
A clear, specific description of what the AI system is designed to do. This isn’t a marketing description — it’s a precise statement of the system’s function that defines the boundaries of compliant use.
Good: “The system evaluates structured applicant profiles for entry-level software engineering roles, generating a suitability score between 0 and 100 based on qualifications, experience indicators, and skills match.”
Bad: “The system uses advanced AI to help you find the best candidates.”
Input specifications
What data the system requires as input, what format it should be in, and any quality requirements. If the system expects specific data fields, document them. If it can’t handle missing values or certain data types, say so.
Output interpretation
How to interpret the system’s outputs correctly. A numerical score, a classification label, a probability estimate — each requires different interpretation. If a score of 70 means “proceed to interview” in your intended use case but not “guaranteed good hire,” explain the distinction.
Document what actions should and shouldn’t be taken based on different output values. If certain output ranges require human review, specify that.
Human oversight measures
Describe the technical measures built into the system to facilitate human oversight, as required by Article 14. This includes:
- How users can monitor the system’s operation
- How they can interpret outputs
- How they can override or disregard outputs
- How they can intervene in or stop the system’s operation
- What training or competence is required for effective oversight
Changes and modifications
The system’s version, any relevant updates, and how the deployer will be informed of changes. If the system is updated automatically (as many cloud-based AI services are), describe the update process and how deployers can assess the impact of changes.
Log generation
What logs the system automatically generates, what information they contain, how the deployer can access them, and for how long they should be retained. Since deployers must keep logs for at least six months under Article 26(6), your documentation should enable them to do so.
Computational resources
The computational and hardware resources needed to operate the system, including any processing, storage, or connectivity requirements. If performance varies with available resources, document the minimum and recommended specifications.
Expected lifetime and maintenance
The expected lifetime of the system, any maintenance requirements, and the frequency of updates or recalibration needed to maintain performance.
Common gaps in existing documentation
Having reviewed AI product documentation across many providers, the most common gaps are:
Quantified performance is missing. Most AI providers describe their system as “accurate” or “state-of-the-art” without providing specific metrics, test conditions, or benchmark datasets. The Act requires quantified performance levels.
Limitations are underdocumented. Providers are understandably reluctant to highlight where their systems fail. But Annex IV specifically requires documentation of “known or foreseeable circumstances that may lead to risks.” If your system performs worse on certain demographics, in certain languages, or with certain input characteristics, that must be documented.
Misuse scenarios are absent. Few providers document foreseeable misuse. This requires thinking about how a deployer might use the system incorrectly — not maliciously, but beyond its validated scope. Anticipating and documenting these scenarios is a specific requirement.
Human oversight guidance is generic. Providers often state that “human review is recommended” without specifying what that review should consist of, what competencies are needed, or how the system’s design supports it. The Act requires concrete technical measures for human oversight.
Log documentation is insufficient. Many providers generate logs but don’t adequately document what those logs contain, how to access them, or how to use them for the monitoring and retention obligations deployers face.
Writing effective instructions for use
Be specific, not aspirational
Every claim in your instructions should be verifiable. If you state accuracy figures, reference the test conditions. If you describe capabilities, define their boundaries. If you recommend human oversight, describe what it looks like in practice.
Structure for compliance
Organise your documentation to map directly to the Annex IV requirements. A deployer’s compliance team should be able to locate each required element without searching through unstructured product documentation.
Consider including a compliance-specific section or appendix that addresses each Annex IV requirement in sequence, with cross-references to more detailed technical documentation where appropriate.
Write for the deployer’s compliance team
Your primary audience isn’t the technical user who integrates your API. It’s the deployer’s compliance, legal, and governance teams who need to demonstrate that their use of your system meets the Act’s requirements. Write accordingly: clear, precise, and complete enough to support a compliance assessment.
Update when the system changes
Instructions for use must remain accurate. If you update your model, change your training data, or modify the system’s behaviour, your instructions must be updated to reflect those changes. Establish a process for keeping documentation in sync with the system.
Test with deployers
Before finalising your instructions, test them with actual deployers. Can they find the information they need? Do they understand the limitations you’ve documented? Can they use the instructions to configure their human oversight, monitoring, and logging processes? If your documentation doesn’t support these practical needs, it’s not adequate.
The commercial case
Adequate instructions for use aren’t just a compliance requirement. They’re a commercial differentiator. As the August 2026 deadline approaches, deployers are evaluating their AI providers against the Act’s requirements. A provider who can supply comprehensive, compliant documentation makes the deployer’s job easier and reduces their compliance risk.
Conversely, a provider whose documentation is insufficient forces the deployer to either fill the gaps themselves (creating friction and risk) or switch to a provider who can supply what they need. In a market where compliance is a new procurement criterion, documentation quality becomes a competitive factor.
The instructions for use are the interface between provider and deployer compliance. Getting them right serves both parties.