Why the instructions for use matter
Most discussion of the EU AI Act’s high-risk regime focuses on what providers must build: risk management, data governance, logging, accuracy, human oversight. Far less attention goes to the single document that carries all of that work across to the company actually using the system. Article 13 of Regulation (EU) 2024/1689 requires every high-risk AI system to be accompanied by instructions for use, and it prescribes what those instructions must contain. It is the hinge between the provider’s compliance file and the deployer’s day-to-day obligations.
For a Swedish business buying an AI system rather than building one, this is the most commercially useful provision in Chapter III: it tells you exactly what you are entitled to receive. Because the deployer’s own central duty under Article 26(1) is to use the system in accordance with those instructions, a thin or evasive set of instructions undermines your ability to comply with a regulation you are independently answerable for. Article 13 was not touched by the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026. What changed is when the requirement bites, not what it says.
Who Article 13 applies to, and when
Article 13 sits in Chapter III, Section 2 of the AI Act — the requirements for high-risk AI systems. It binds providers: whoever develops a high-risk system and places it on the market or puts it into service under their own name or trade mark. Article 16(a) converts the Section 2 requirements into an enforceable provider obligation, and Article 16(k) obliges providers, on a reasoned request from a national competent authority, to demonstrate that conformity.
Deployers are not directly bound by Article 13, but they are its intended beneficiaries, and the provision is written from their perspective throughout. Following the Digital Omnibus, the obligations in Sections 1, 2 and 3 of Chapter III apply from 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those high-risk under Article 6(1) and Annex I — AI embedded in regulated physical products.
One confusion is worth clearing immediately. Article 13 is not Article 50. Article 50 is the transparency regime requiring chatbots to disclose that they are machines and synthetic content to be marked, and it has applied since 2 August 2026. Article 13 is a design and documentation requirement for high-risk systems, owed to professional deployers rather than to the public. Commentary treating the Commission’s transparency guidelines as covering Article 13 is simply wrong.
What Article 13 actually requires
The article has three paragraphs, and each does distinct work: a design duty, a delivery duty and a content duty.
The design duty in paragraph 1
Article 13(1) requires that high-risk AI systems “shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret a system’s output and use it appropriately”. It then adds that “an appropriate type and degree of transparency shall be ensured with a view to achieving compliance with the relevant obligations of the provider and deployer set out in Section 3”.
Two things follow. First, this is an obligation about the system itself, not only about paperwork: transparency has to be engineered in, and a system that cannot be explained to its users is non-compliant however well the manual is written. Second, the calibration standard is external. How transparent is transparent enough is measured against what provider and deployer each have to do under Section 3, Articles 16 to 27.
The delivery duty in paragraph 2
Article 13(2) requires that high-risk AI systems “shall be accompanied by instructions for use in an appropriate digital format or otherwise that include concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers”. Digital delivery is permitted, not mandated. The quality test is demanding: seven adjectives, four describing the information and three describing it relative to the reader. Complete and concise pull against each other on purpose. A 300-page reference document is not concise; a four-page summary is not complete.
The content duty in paragraph 3
Article 13(3) says the instructions “shall contain at least the following information”, then lists six points, (a) to (f). Point (a) is the identity and contact details of the provider and, where applicable, its authorised representative. Point (c) covers changes to the system and its performance that the provider pre-determined at the moment of the initial conformity assessment. Point (d) covers the human oversight measures required by Article 14, including the technical measures put in place to help deployers interpret outputs. Point (e) covers computational and hardware resources needed, the expected lifetime of the system, and any necessary maintenance and care measures including their frequency and software updates. Point (f) requires, where relevant, a description of the mechanisms that allow deployers to collect, store and interpret the logs in accordance with Article 12.
The seven sub-points that carry the weight
Point (b) is the substantial one, and it is the only point with sub-points — seven of them, running from (i) to (vii). It requires the characteristics, capabilities and limitations of performance of the system, including its intended purpose; the level of accuracy including its metrics, robustness and cybersecurity referred to in Article 15 against which the system has been tested and validated and which can be expected, together with any known and foreseeable circumstances that may affect that expected level; any known or foreseeable circumstance related to use in accordance with the intended purpose or under conditions of reasonably foreseeable misuse which may lead to risks to health and safety or fundamental rights; where applicable, the technical capabilities to provide information relevant to explaining the output; when appropriate, performance regarding specific persons or groups of persons the system is intended to be used on; when appropriate, specifications for input data or other relevant information about the training, validation and testing data sets; and, where applicable, information enabling deployers to interpret the output and use it appropriately.
Sub-point (ii) is reinforced elsewhere. Article 15(3) independently provides that the levels of accuracy and the relevant accuracy metrics “shall be declared in the accompanying instructions of use”. A provider that ships a high-risk system without stated accuracy figures breaches both.
How this connects to the deployer’s own duties
Article 26(1) requires deployers to “take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems”. That is a duty of means rather than a bare duty to comply, but it makes the deployer’s operating posture legally referable to a document it did not write and cannot amend.
The consequence is that instructions for use are not vendor collateral. They are the deployer’s compliance baseline. Without stated accuracy metrics, the deployer cannot know whether the system is performing as expected. Without a description of the log mechanisms, it cannot discharge its own record-keeping duty. Without the circumstances of reasonably foreseeable misuse, it cannot train staff to avoid them. None of these gaps can be cured downstream, which is why they belong in the procurement conversation rather than the implementation one.
It is also worth separating the instructions for use from the technical documentation under Article 11 and Annex IV. The Annex IV file is authority-facing and stays with the provider; the Article 13 instructions are deployer-facing and travel with the product. The Digital Omnibus amended the second subparagraph of Article 11(1) but left Article 13 untouched. Commentary treating the two documents as one will carry that change across incorrectly.
Practical example
A Stockholm software company sells a creditworthiness assessment module to lenders across the Nordics. Systems intended to evaluate creditworthiness or establish credit scores fall within Annex III, so the company is a provider of a high-risk AI system. It has good engineering documentation, and it assumes its existing product manual will serve.
It will not. The manual describes features. Article 13(3) requires performance limits: the accuracy figures the model was validated against, the circumstances in which those figures degrade, how it behaves for particular groups of applicants where that is appropriate, the input data specifications, the pre-determined changes planned after conformity assessment, and how the lender extracts and reads the logs. A Swedish lender holding only the current manual cannot answer a supervisory question about using the system in accordance with the instructions, because the instructions do not contain the material the question is about. The commercial point is that procurement teams are increasingly likely to notice, and to buy from a competitor whose documentation holds up.
Common mistakes companies make
The first is treating the instructions for use as marketing material. The document is a regulatory instrument with prescribed minimum content, and it will be read by a supervisory authority alongside the deployer’s account of how it operated the system. Sales language about capabilities, unaccompanied by stated limitations, is the opposite of what Article 13(3)(b) asks for.
The second is omitting accuracy figures because they are unflattering. Article 13(3)(b)(ii) and Article 15(3) both require them, and the disclosure runs to deployers rather than to the world, so the competitive concern is manageable through contract rather than through silence.
The third is on the buyer’s side: accepting whatever documentation arrives, then discovering the gaps at the moment the material is needed. The fourth is assuming a harmonised standard will settle the format. No CEN or CENELEC deliverable has been publicly identified as supporting Article 13, and no AI Act standard has yet been cited in the Official Journal, so no presumption of conformity is available to anyone.
Recommended actions
If you are a provider, start from the six points and seven sub-points rather than from your existing manual, and build the instructions as a controlled document with an owner, a version history and a review trigger tied to substantial modification. Much of the content already sits inside your Article 9 risk management file and your Article 15 testing records; the work is selection and translation rather than new analysis. Write for the deployer’s competence level, not your engineers’.
If you are a deployer, make the instructions for use a procurement deliverable with a defined acceptance test. Ask for the document before signing, check it against Article 13(3), and record in the contract that the provider will maintain and update it. Where the system is delivered as a service and the provider controls the logs, address access expressly rather than relying on the statutory formula. Keep the version you received: your Article 26(1) obligation is measured against the instructions that accompanied the system.
Frequently asked questions
Does Article 13 apply to us if we only use AI, and do not build it?
Not directly. Article 13 binds providers. But it is the provision that determines what you are entitled to receive, and Article 26(1) makes your own compliance depend on the document it produces, so it is the article a deployer should read most closely before signing a contract.
Did the Digital Omnibus change Article 13?
No. Article 13 stands in its original 2024 form, confirmed both by the consolidation markers in the amended Act and by the list of amendments in Article 1 of Regulation (EU) 2026/1744. What changed is timing: the high-risk requirements now apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
Is there a template we can use for the instructions for use?
There is no official template and no harmonised standard yet cited for Article 13. The six points of Article 13(3) are themselves a serviceable structure, and building the document around them makes it straightforward for a deployer or an authority to check that nothing is missing.
Conclusion
Article 13 is short, unchanged and easy to overlook, and it decides whether the rest of a provider’s compliance work is usable by anyone else. For providers, it makes the compliance file legible to the market. For deployers, it is the checklist that shows whether a supplier has done the work or merely says it has. With the high-risk obligations applying from December 2027 and August 2028, there is time to get this right, and a clear commercial advantage in being the supplier whose documentation survives a customer’s review.
Lawgent helps businesses draft and review AI Act instructions for use, and assess supplier documentation before high-risk AI systems are bought or deployed.
