Article 13 requires high-risk AI systems to be designed and developed so that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. Providers must supply instructions for use in a clear, accessible form, covering intended purpose, accuracy and limitations, oversight measures, input and output conditions, and other matters set out in the article, so that deployers can operate the system in accordance with those instructions.
What is the purpose of Article 13 transparency?
Article 13 transparency is aimed at the deployer, not at the general public. Its purpose is to enable the deployer to understand what the system does, what it cannot do, how it should be overseen, and how its output should be interpreted, so that the deployer can use it correctly and safely. That purpose shapes the writing: instructions must be usable by the people who will operate the system in its real deployment context, not only intelligible to the development team. A provider should test instructions with representative deployer staff, record the feedback, and revise the instructions where the test shows misunderstanding. Transparency that is technically accurate but unusable by its intended reader does not achieve the article's purpose.
What must instructions for use contain?
Instructions for use must contain, in outline, the provider's identity, the system's intended purpose and any known limitations, the accuracy levels and performance measures, the conditions for correct use, the human oversight measures, the input data requirements, the expected output and its interpretation, and information on maintenance, updates and incident reporting. The exact contents should be checked against Article 13(3) in the consolidated text for the system in question. Instructions should be provided in a durable, accessible form, in a language and format the deployer can use, and should be version-matched to the system version supplied. A generic user manual that does not address the specific system, its limitations, or its oversight design will not meet the article, even if it is well written in general terms.
For the broader regulatory framework, see High-risk requirements overview.
How should capabilities and limitations be explained?
Capabilities and limitations should be explained in concrete terms tied to the intended purpose and the testing evidence. That includes the conditions under which the system was tested, the performance achieved, the groups or contexts where performance may differ, and the foreseeable errors or failure modes. Limitations should not be buried in a disclaimer or stated only as a general warning. They should be placed where the deployer will see them before relying on output, and they should be linked to the oversight and monitoring steps the deployer is expected to take. A limitation that is known to the provider but not communicated to the deployer, or communicated only after deployment, leaves the deployer unable to manage the risk the limitation creates.
How does Article 13 relate to human oversight?
Instructions for use must explain the human oversight measures built into the system and the measures the deployer must take, so that oversight staff know what to monitor, when to intervene, and how to override or halt the system. The explanation should cover the tools provided for oversight, the information shown to overseers, the training or competence expected, and the escalation route where an overseer is uncertain. Oversight instructions should be tested with the staff who will perform oversight, in the actual workflow, rather than assumed to be clear from the design. Where oversight depends on interpreting output that is probabilistic or uncertain, the instructions should explain how uncertainty is presented and what action it calls for, in terms the overseer can apply under time pressure.
How should instructions be kept current?
Instructions for use must be kept up to date when the system, its performance, its limitations, or its oversight design changes. The provider should notify deployers of material changes, provide the updated instructions before the changed system is relied on, and record the notification and the version supplied. Deployers should confirm receipt, brief affected staff, and record the date the new instructions took effect in their deployment. A change log for instructions should sit alongside the system version history, so that a question about what a deployer was told and when can be answered from the log. Instructions that describe an earlier version, while a different version is in use, create a gap between the provider's evidence and the deployer's actual operation.
Continue with Article 14 human oversight.
What does this guide not decide?
This guide does not decide whether particular instructions for use meet Article 13, whether a limitation has been adequately explained, or whether a deployer has understood and followed the instructions. It does not write instructions for a specific system or assess a deployer's competence. Those questions depend on the system, the testing evidence, the deployment context, and the consolidated legal text. A provider should test its instructions with representative deployers, have them reviewed by a competent authority or legal adviser where contested, and keep them version-matched and current.
Frequently asked questions
Is Article 13 the same as Article 50 transparency?
No. Article 13 concerns transparency and information to deployers of high-risk systems, so they can interpret output and use the system appropriately. Article 50 concerns transparency duties for certain AI interactions, synthetic content and deepfakes, with duties split between providers and deployers. Both can apply to one product, but they address different audiences and situations.
Must instructions be in a specific language?
Instructions should be provided in a form and language that the deployer and its staff can use in the deployment context. The provider should check any language or format requirements that apply to the system and the Member State of deployment, and should record the language and format supplied for each deployment.
What if a deployer does not follow the instructions?
The deployer has its own duties under Article 26 to use the system in accordance with the instructions for use. A provider should record the instructions supplied and any feedback or incident reported, while the deployer should record how instructions were briefed, monitored and followed in its own operation.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗Commission AI Act Service Desk timeline ↗European Commission AI Act overview ↗