EU AI Act Instructions for Use: What High-Risk AI Documentation Actually Needs to Say

If you are building a high-risk AI system under the EU AI Act, you need to ship "instructions for use" with it. Most teams hear that and think: user manual. Help docs. Maybe a README.

That is not what this is. Instructions for use under Article 13 are a structured compliance document with 12 mandatory elements. They tell deployers how to use your system lawfully, what it can and cannot do, what risks to watch for, and how to maintain human oversight. If your instructions are missing any of the required content, your system fails its conformity assessment — even if the AI itself works perfectly.

This is not a user manual

The distinction matters because it changes who you are writing for and what you need to include.

A user manual tells someone how to operate your product. Click here, enter this, expect that. Instructions for use under the EU AI Act tell a deployer how to use your AI system in a way that complies with the regulation. That includes things most product documentation never covers:

• The specific purpose the AI system was designed for — and what it was explicitly not designed for
• Known limitations, foreseeable misuse scenarios, and residual risks that could not be eliminated
• What level of human oversight is needed and what the human overseer should be looking for
• Performance metrics broken down by the specific groups of people the system affects
• Technical specifications of input data — what format, quality, and characteristics the system expects

Think of it this way: a user manual tells you how to drive the car. Instructions for use tell you what roads it is certified for, what weather conditions it cannot handle, how fast you can go before the safety features stop working, and what the driver needs to monitor at all times.

The 12 required elements

Article 13(3) lists exactly what instructions for use must contain. This is not a suggestion — each item is a conformity requirement. Missing one is a finding.

1. Provider identity and contact details. Name, address, and a way to reach you. Simple but often buried in terms of service instead of the instructions themselves.

2. The AI system's characteristics, capabilities, and limitations. This is the core of the document. What does the system do? What was it designed for? What is it explicitly not designed for? What are the known accuracy limits? Where does performance degrade?

3. Intended purpose.The specific, defined use case. Not "general-purpose AI assistant" — a concrete description like "automated screening of job applications for junior software engineering roles based on CV parsing and skill matching."

4. Level of accuracy, robustness, and cybersecurity. Measured performance metrics. Not marketing claims — actual test results against defined benchmarks, including the metrics used and the test conditions.

5. Known or foreseeable circumstances that may lead to risks. What could go wrong? Biased training data, adversarial inputs, edge cases, demographic disparities in performance. You must disclose these even if you have mitigations in place.

6. Performance with respect to specific groups of persons or populations.If your AI system affects different groups differently — and it probably does — you need to document it. This is where most teams fall short. "Performs well on our test set" is not sufficient if your test set does not represent the groups the system will actually affect.

7. Input data specifications. What data does the system need? What format, quality, and characteristics? What happens when input data does not meet specifications?

8. Interpretability of output.How should deployers interpret the system's outputs? What do confidence scores mean? What does a "recommendation" actually represent? When should a human override the output?

9. Human oversight measures. Specific instructions on how humans should oversee the system. What to monitor, when to intervene, how to override decisions, and what training the human overseer needs. See our Article 14 human oversight guide for the full breakdown.

10. Expected lifetime and maintenance. How long is the system intended to operate? What maintenance does it need? When do model updates happen and how are deployers notified?

11. Changes and modifications. What has changed since the last version? How do updates affect performance, accuracy, or risk profile? This is a versioning and changelog requirement built into the document itself.

12. Logging capabilities.What does the system log automatically? How can deployers access logs? How long are they retained? What format are they in? This connects directly to Article 12's automatic logging requirements.

Who you're writing for

This is where most technical teams go wrong. Instructions for use are written for deployers, not for your engineering team. The deployer is the company or person who puts your AI system to use in their business.

In practice, the person reading your instructions for use is likely a compliance officer, a DPO, a risk manager, or a procurement lead. They need to understand:

• What the system does in plain language
• Whether it is appropriate for their intended use
• What internal processes they need to have in place
• What to monitor and what to escalate
• What they are responsible for versus what the provider handles

If you write your instructions for use in the same style as your API documentation, you have failed. Article 13(2) specifically says instructions must be in "an appropriate digital format or otherwise" and must be "concise, complete, correct and clear" and "relevant, accessible and comprehensible to deployers."

Common mistakes

From reviewing how teams approach this, here are the patterns that will get flagged:

• Burying it in marketing docs. Your product landing page is not instructions for use. It needs to be a standalone document that a deployer can reference independently.
• Vague limitations."The system may produce inaccurate results in some cases" is not a known limitation. "Accuracy drops to 72% for inputs in languages other than English and German" is.
• Missing the negative scope. You defined what the system is for — but did you define what it is not for? Foreseeable misuse needs to be explicitly addressed.
• No group-specific performance data. This is the most commonly missing element. If your hiring AI performs differently across age groups, genders, or ethnicities, that must be documented — even if the differences are within acceptable bounds.
• One-and-done. Instructions for use are a living document. When you update your model, change training data, or discover new limitations, the instructions must be updated too. Version them.

A practical structure

There is no official template from the EU yet, though one may come via harmonised standards. In the meantime, here is a structure that covers all 12 required elements:

• Section 1: Provider information — company name, address, contact, registration numbers (covers item 1)
• Section 2: System description — what it does, how it works at a functional level, what technology it uses (covers items 2, 3)
• Section 3: Performance and accuracy — test results, benchmarks, metrics used, test conditions (covers items 4, 6)
• Section 4: Known risks and limitations — foreseeable risks, edge cases, demographic disparities, conditions where performance degrades (covers items 5, 6)
• Section 5: Input specifications — data format, quality requirements, what happens with out-of-spec inputs (covers item 7)
• Section 6: Output interpretation — what outputs mean, confidence scores, when to trust or question results (covers item 8)
• Section 7: Human oversight — monitoring requirements, intervention procedures, overseer qualifications, override mechanisms (covers item 9)
• Section 8: Deployment and maintenance — expected lifetime, update schedule, notification process, end-of-life (covers items 10, 11)
• Section 9: Logging and traceability — what is logged, access methods, retention periods, format (covers item 12)
• Section 10: Version history — changelog of material changes to the system and this document

That is 10 sections covering 12 mandatory items. It is not short — for a complex system, this could be 20-40 pages. But it is structured, reviewable, and auditable. Which is exactly what a conformity assessment requires.

Keeping instructions current

Article 13 does not say "write it once and ship it." The instructions must remain accurate throughout the system's lifecycle. That means:

• Model updates trigger document updates. If you retrain, fine-tune, or swap models, review every section. Performance metrics may change, limitations may shift, risk profile may be different.
• Post-market monitoring feeds back in. If you discover a new limitation or risk after deployment — through user reports, incident analysis, or monitoring — it goes into the instructions.
• Version and date everything. Each version should have a clear date, version number, and a summary of what changed from the previous version.
• Notify deployers of material changes. If the instructions change in a way that affects how deployers should use or oversee the system, they must be told. A changelog on your docs site is not sufficient — active notification is expected.

The bottom line: instructions for use are not a paperwork exercise. They are the primary document through which deployers understand their obligations. If your instructions are vague, incomplete, or stale, you are effectively asking deployers to use your high-risk AI system blind — and both of you are liable for what happens.

Start with Annex IV technical documentation to understand the broader documentation picture, then build your instructions for use as the deployer-facing layer on top.