Article 13 sits between the prohibitions everybody writes about and the human oversight rules everybody quotes, and it is skipped accordingly. It is the provision that makes the rest of the high-risk regime operable, because the deployer’s obligations are written on the assumption that this document exists.
Transparency to whom
Article 13 of Regulation (EU) 2024/1689 is headed transparency and provision of information to deployers. That is the whole orientation of it: the audience is the organisation deploying the system, not the person affected by it.
Transparency to affected persons is elsewhere. Article 50 carries the user-facing duties — telling people they are interacting with an AI system, marking synthetic content, notifying subjects of emotion recognition and biometric categorisation. Article 86 gives affected persons a right to an explanation of individual decision-making in certain cases. Article 13 is upstream of both, and confusing the two produces the common error of assessing Article 13 compliance by looking at a product’s user interface.
Article 13(1) states the objective: the system must be designed and developed so that its operation is sufficiently transparent to enable deployers to interpret its output and use it appropriately, with an appropriate type and degree of transparency to achieve compliance with the relevant provider and deployer obligations in Section 3. Note that this is a design obligation, not only a documentation one — the system itself has to be interpretable enough, not merely described.
Not legal advice. Whether a particular instruction set satisfies Article 13 is a judgment about a specific system and a specific deployer, and it is also the document a market surveillance authority will read first. Have it reviewed against your facts.
The standard the document must meet
Article 13(2) requires high-risk systems to 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.
Seven adjectives, and two of them are in tension. “Concise” and “complete” pull against each other, and the resolution the wording implies is structural rather than editorial: a document organised so that each required item is findable, rather than either a summary that omits or an undifferentiated dump. “Comprehensible to deployers” also fixes the reading level at the deployer’s expertise, which connects back to Article 9(5)’s requirement to take account of the technical knowledge, experience, education and training to be expected of the deployer.
What Article 13(3) requires
The instructions shall contain at least the following. The list is a minimum and each item is a section.
- (a) Identity and contact details of the provider and, where applicable, its authorised representative.
- (b) Characteristics, capabilities and limitations of performance, comprising seven sub-items: the intended purpose; the level of accuracy including its metrics, robustness and cybersecurity under 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 reasonably foreseeable misuse which may lead to risks to health, safety or fundamental rights under Article 9(2); where applicable, the technical capabilities to provide information relevant to explaining the output; where appropriate, performance regarding specific persons or groups the system is intended to be used on; where appropriate, specifications for the input data or other relevant information about the training, validation and testing data sets used; and, where applicable, information enabling deployers to interpret the output and use it appropriately.
- (c) Pre-determined changes to the system and its performance determined by the provider at the moment of the initial conformity assessment, if any.
- (d) Human oversight measures under Article 14, including the technical measures put in place to facilitate the interpretation of outputs by deployers.
- (e) Computational and hardware resources needed, the expected lifetime of the system, and any necessary maintenance and care measures including their frequency, covering software updates.
- (f) Log mechanisms — where relevant, a description of the mechanisms included in the system allowing deployers to properly collect, store and interpret the logs under Article 12.
Item (b)(ii) is the demanding one. It requires not a headline accuracy number but the metrics, the conditions of testing, the level that can be expected in use, and the circumstances that degrade it. A provider who has not documented the conditions under which performance falls away cannot write that section, which is why it is effectively an obligation to have characterised the system’s failure modes before shipping.
Item (c) is quietly important for anyone who intends to keep improving a system after conformity assessment. Pre-determined changes have to be declared at assessment time and described here; changes outside that envelope raise the substantial modification question, which restarts obligations.
What breaks when an item is missing
The clearest way to see why Article 13 matters is to read Article 26, the deployer’s obligations, and note how many of them are expressly performable only in accordance with the instructions for use.
- Article 26(1) requires deployers to take appropriate technical and organisational measures to ensure they use the system in accordance with the instructions for use. Without item (b)(i) and (e), they cannot.
- Article 26(4) requires deployers, to the extent they exercise control over the input data, to ensure that input data is relevant and sufficiently representative in view of the intended purpose. That duty is defined by reference to the intended purpose and to the input specifications under item (b)(vi).
- Article 26(2) requires assignment of human oversight to natural persons with the necessary competence, training and authority. What competence is necessary is determined by the item (d) oversight measures.
- Article 26(5) requires monitoring of operation on the basis of the instructions for use and informing the provider where use may present an Article 79(1) risk. Without item (b)(ii) the deployer has no baseline against which to notice a problem.
- Article 27 fundamental rights impact assessments, where required, draw directly on the intended purpose, the affected categories of persons and the specific risks — all of which come from this document. See the full deployer obligation set.
The consequence for a deployer procuring a high-risk system is practical: the instructions for use are the artefact to demand and review during diligence, because a deficiency in them converts directly into an obligation you cannot discharge.
The problem of a system that changes underneath
Article 13(3)(b)(ii) requires the instructions to state the accuracy level against which the system has been tested and validated and which can be expected. That statement is about a specific system as assessed. It has an uncomfortable interaction with any architecture whose behaviour depends on a component that can change without the provider’s involvement.
If a high-risk system’s outputs come from a hosted general-purpose model, and the vendor updates the checkpoint behind an unchanged identifier, the tested-and-validated statement in the instructions may no longer describe the system in the field. Nothing in Article 13 contemplates that: the drafting assumes the provider controls what changes, and Article 13(3)(c) offers only the narrow route of pre-determined changes declared at conformity assessment. Whether such an update amounts to a substantial modification under Article 3(23), and whose obligation it is when the change originates upstream, is not settled.
The mitigation is unglamorous: make the model a pinned, recorded dependency rather than an ambient one, so that the version the instructions describe is the version that answers. That means requesting a dated model identifier rather than a floating alias, recording the resolved version and provider per call, and treating a routing change or fallback to a different model as a change to the system rather than an operational detail — because under Article 13(3)(b)(ii) it is one. A gateway is a reasonable place to enforce and record that; Multigrid does it per request, and so would any equivalent layer you built yourself.
The accuracy and robustness requirements the instructions report against are set by Article 15, and the oversight measures described under item (d) are specified in Article 14.
The application date for the high-risk obligations, Article 13 among them, has moved. Article 113 as adopted set it at 2 August 2026; Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, postponed it to 2 December 2027 for stand-alone Annex III systems and to 2 August 2028 for high-risk systems embedded in products regulated under Annex I. The Article 50 transparency obligations — the user-facing duties distinguished at the top of this page — were not postponed and applied from 2 August 2026, so the two halves of “AI Act transparency” now fall due more than a year apart. This page states the timing changes only; for any amendment 2026/1744 made to the content of Article 13 itself, read the consolidated text on EUR-Lex, which is outside what can be confirmed here.
Top comments (0)