EU AI Act Article 13: How to Write Instructions for Use That Actually Comply
Article 13 of the EU AI Act requires providers of high-risk AI systems to supply deployers with precise, structured instructions for use. Discover the eight mandatory content elements, the most common drafting mistakes, and a section-by-section template you can adapt today.
Most AI providers write their instructions for use last, quickly, and as an afterthought. Under the EU AI Act, that approach is not merely inadequate — it is non-compliant. Article 13 imposes a specific, mandatory content structure on the instructions that providers of high-risk AI systems must supply to deployers. This article shows you exactly what to include, what to avoid, and how to structure a document that will withstand scrutiny from a market surveillance authority.
The Legal Basis: Article 13 in Context
Article 13 is titled "Transparency and provision of information to deployers." It is one of the core obligations for high-risk AI systems listed in Annex III, alongside the requirements for technical documentation (Article 11), logging (Article 12), human oversight (Article 14), accuracy and robustness (Article 15), and the quality management system (Article 9).
The underlying logic is accountability by information: deployers cannot exercise meaningful human oversight — as required by Article 14 — unless they receive the information they need to understand the system, its limitations, and how to intervene. Article 13(1) states this directly: the instructions must enable deployers to implement the human oversight measures specified in Article 14.
The Eight Mandatory Content Elements
Article 13(3) sets out the specific information that instructions for use must contain. This is not a non-exhaustive list of suggestions — it is a mandatory checklist:
| # | Element | What it means in practice |
|---|---|---|
| 1 | Identity and contact details of the provider | Legal name, address, Article 22 point-of-contact for the EU |
| 2 | Characteristics, capabilities, and limitations of the system | Intended purpose, performance metrics, known failure modes |
| 3 | Changes to the system affecting Annex IV documentation | Versioning policy, notification procedure for material changes |
| 4 | Human oversight measures | Specific interventions available to the deployer, escalation paths |
| 5 | Computational and hardware requirements | Minimum specs for reliable operation |
| 6 | Expected lifetime and maintenance measures | Update schedule, end-of-support dates, retraining cadence |
| 7 | Logging capabilities | What is logged, retention period, how to access logs |
| 8 | Accuracy, robustness, and cybersecurity performance levels | Metrics, testing conditions, known degradation scenarios |
Each of these elements has sub-requirements. "Characteristics, capabilities, and limitations," for example, must describe the specific purpose for which the system was tested and validated — it is not sufficient to list generic use-cases. You must specify the populations on which the system was validated, the conditions under which performance metrics were measured, and the scenarios in which performance is known to degrade.
How to Write Each Section: Practical Guidance
Section 1 — Provider Identity
This is not a marketing header. Include the legal entity name as it appears in the EU database (Article 71), the registration number, and a dedicated compliance contact email that will be monitored after the product is deployed. Many providers list a generic support address; MSAs and deployers need to reach the person responsible for compliance, not a help desk.
Section 2 — Characteristics, Capabilities, and Limitations
This is the section that most frequently fails in audits. The three most common errors:
Too vague: "The system may produce errors in some cases." This tells the deployer nothing actionable. The correct formulation specifies which cases, at what frequency, and what the deployer should do when they occur.
Too technical: Dumping a model card written for ML engineers into a compliance document is not compliant. The deployer may be an HR department, a hospital procurement team, or a public authority. Write for the intended audience.
No usage limits: Article 13(3)(b) requires you to describe not just what the system does, but what it should not be used for. If the system was validated on adults aged 18-65 in a Western European context, that must be stated explicitly. Deploying outside those parameters is the deployer's risk — but only if you told them.
Section 3 — Changes and Versioning
Providers routinely update models after deployment. Article 13(3)(c) requires you to describe the types of changes that will affect the documentation listed in Annex IV. Practically, this means defining in your instructions what constitutes a "material change" (triggering a new conformity assessment) versus a routine update, and how you will communicate either category to deployers.
Section 4 — Human Oversight Measures
This section connects Article 13 directly to Article 14. You must describe the specific technical and organizational measures that allow a deployer to:
- Monitor system operation during use
- Detect situations where the system may be unreliable
- Override or interrupt the system
- Interpret system outputs correctly
Generic statements ("users should review all outputs") do not meet the standard. You need to specify the interface elements, the log formats, or the threshold indicators that a competent deployer can act on.
Sections 5-8 — Technical and Performance Information
These sections are often populated with marketing-grade claims ("industry-leading accuracy") rather than auditable specifications. The law requires performance levels measured under defined test conditions, cybersecurity specifications aligned with harmonized standards (where available), and honest disclosure of degradation scenarios — for example, performance drops in low-bandwidth environments or with non-native language inputs.
Article 13 vs. Article 50: Two Different Audiences
A critical distinction that providers frequently miss: Article 13 governs information to deployers — the organizations that integrate and operate your system within their own products or processes. Article 50 governs transparency obligations toward end-users — the individuals who interact with the AI output.
The two documents serve different purposes and have different audiences:
| Article 13 | Article 50 | |
|---|---|---|
| Audience | Deployer (business/organization) | End-user (natural person) |
| Format | Technical instructions document | Interaction-level disclosure |
| Timing | Before/at time of provision | At time of interaction |
| Key content | Technical specs, oversight measures, limits | Fact of AI interaction, specific obligations per context |
| Tone | Professional/technical | Clear, accessible |
Merging these two documents is a compliance error. Article 13 instructions are part of the technical documentation; they should be formal, complete, and versioned. Article 50 disclosures are operational; they should be brief, contextual, and human-readable.
Annotated Template Structure
The following section headers satisfy the Article 13(3) checklist. Each section is annotated with the minimum content requirement:
INSTRUCTIONS FOR USE
[System Name] — Version [X.X]
Provider: [Legal name] | EU Registration: [DB number]
Revision date: [date] | Replaces version: [X.X]
1. PROVIDER IDENTIFICATION
[Legal name, address, EU compliance contact, authorized representative if applicable]
2. SYSTEM DESCRIPTION
2.1 Intended purpose [exact Annex III category and use-case]
2.2 Capabilities [what it does, in measurable terms]
2.3 Limitations [what it does not do; populations/contexts not validated]
2.4 Prohibited uses [explicit list of out-of-scope applications]
3. VERSION AND CHANGE MANAGEMENT
3.1 Current version scope
3.2 Material change definition and notification procedure
3.3 Deployer obligations upon receiving a change notification
4. HUMAN OVERSIGHT
4.1 Available oversight mechanisms [list with interface references]
4.2 Override and interruption procedure
4.3 Output interpretation guidance [what each output type means and how to act]
4.4 Escalation contacts
5. TECHNICAL REQUIREMENTS
5.1 Hardware and infrastructure minimums
5.2 Integration prerequisites
5.3 Data input specifications and quality requirements
6. LIFETIME AND MAINTENANCE
6.1 Supported lifetime and end-of-support date
6.2 Update schedule and procedure
6.3 Retraining or recalibration triggers
7. LOGGING AND AUDIT
7.1 Logged events [complete list]
7.2 Log retention period and format
7.3 Deployer access procedure
8. PERFORMANCE AND SECURITY
8.1 Accuracy metrics [with test conditions]
8.2 Robustness specifications [degradation scenarios]
8.3 Cybersecurity standards compliance
8.4 Known vulnerabilities and mitigations
Common Drafting Mistakes — Summary
- Writing instructions for an idealized use-case rather than the actual deployed context
- Omitting known failure modes to avoid appearing weak — this creates liability, not protection
- Using performance claims that cannot be reproduced under auditable test conditions
- Providing a single document when the deployer operates in multiple regulatory contexts (e.g., healthcare + general business) requiring differentiated guidance
- Not versioning the document — MSAs expect to be able to match the instructions to the system version deployed at the time of any incident
DILAIG's compliance platform includes a structured Article 13 template with inline guidance for each mandatory section, and a conformity checker that flags incomplete or non-specific content before you finalize your technical documentation package. Start your compliance assessment at dilaig.com.