Article 13 is the bridge between the provider who builds a high-risk system and the organisation that uses it. It defines exactly what information has to travel with the system — and it is more than a manual.
Most high-risk AI is bought, not built. Article 13 governs the handover: it obliges the provider to make a high-risk system transparent enough, and documented enough, that a deployer can use it correctly and meet its own obligations. If you procure AI, this article tells you what you are entitled to receive — and what to ask for before you sign.
The opening requirement of Article 13 of Regulation (EU) 2024/1689:
“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.”
Regulation (EU) 2024/1689, Article 13(1)Transparency here is functional, not cosmetic: the goal is that a deployer can interpret the output and use the system appropriately, and thereby comply with the obligations that fall on both provider and deployer.
Article 13(2) requires that high-risk systems be accompanied by instructions for use, in an appropriate digital or other format, containing “concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers.” Four adjectives do a lot of work here: concise and complete, correct and clear. A 200-page PDF that buries the limitations is not compliant just because it is technically complete.
Article 13(3) sets out the required contents. In practice they group into a handful of themes:
| Theme | What providers must disclose |
|---|---|
| Who built it | Identity and contact details of the provider (and any authorised representative) |
| What it does — and doesn’t | Intended purpose; characteristics, capabilities and limitations of performance; the level of accuracy (including its metrics), robustness and cybersecurity; and known or foreseeable risks to health, safety or fundamental rights |
| How it performs across groups | Performance regarding specific persons or groups, plus specifications of the input data and any relevant training, validation and testing data |
| Predetermined changes | Any changes to the system and its performance that the provider predetermined at the conformity-assessment stage |
| Human oversight | The oversight measures under Article 14, including the technical measures that help deployers interpret outputs |
| Resources & lifecycle | Computational and hardware resources needed, the expected lifetime, and the maintenance and care measures (including software updates) required to keep the system working as intended |
| Logging | Where relevant, the mechanisms that let deployers properly collect, store and interpret the system’s logs |
A procurement checklist in disguise. Read in reverse, Article 13(3) is the list of questions to put to any AI vendor: what are the accuracy metrics? What are the known limitations and risks? What oversight does the system support? What is its expected lifetime and maintenance burden? If a provider cannot answer these, the system is not deployment-ready.
Article 13 sits on the provider, but it exists for the deployer’s benefit — and a deployer’s own duties under the Act assume this information is in hand. You cannot exercise human oversight (Article 14) over a system whose limitations you do not understand, and you cannot judge appropriate use without the accuracy and risk information Article 13 requires the provider to give you. For deployers, Article 13 documentation is an input you must collect, store and act on — per system.
For every high-risk system you deploy, the Article 13 instructions are evidence you need to keep and link — provider details, accuracy and limitations, oversight measures, expected lifetime. When a regulator or an internal auditor asks “what did the vendor tell you, and where is it?”, the answer should be one click from the system’s inventory record, not a hunt through email and shared drives.
Model Inventory for Jira makes each AI system a Jira work item, so the provider’s instructions, accuracy figures and oversight notes live against the system they describe — with Confluence-linked documentation and an immutable change history, inside your existing Jira. When the question is “where is the Article 13 information for this model?”, the record answers it. The instructions themselves come from your providers; the inventory is where you keep and govern them.
See how it worksThis page is a practical explanation, not legal advice. Always confirm requirements against the official text of Regulation (EU) 2024/1689.