The Spanish Agency for the Supervision of Artificial Intelligence (AESIA) has published the eighth guide of its AI regulatory sandbox, dedicated to Article 13 of the AI Act on transparency and provision of information to deployers. It follows Guide No. 7 on data and data governance. The Guide is non-binding and offers practical implementation measures for providers and deployers of high-risk AI systems.

Under the Digital Omnibus, the requirements of Article 13 apply from 2 December 2027 for high-risk systems listed in Annex III and from 2 August 2028 for those covered by Annex I.

Two kinds of transparency

The AI Act contains two different transparency regimes, and they are often confused.

Article 13 concerns high-risk systems. It governs the information that the provider must give the deployer, so that the deployer can understand and use the system correctly.

Article 50 concerns the information given to people who interact with AI or are exposed to its outputs: telling them they are talking to a chatbot, marking synthetic content, disclosing deepfakes. These obligations have applied since 2 August 2026. However, for generative AI systems already on the market before that date, the obligation to mark synthetic content in a machine-readable format (Article 50(2)) applies from 2 December 2026.

Guide No. 8 deals with the first.

What Article 13 requires

Providers must design and develop high-risk systems so that their operation is sufficiently transparent for deployers to interpret their outputs and use them appropriately. AESIA presents this as a functional requirement, not a disclosure exercise: the information must let the deployer understand what the system can do, where its limits lie and how its outputs should be read in the context of use.

Two consequences follow. First, transparency has to be built in from the design stage. The provider must decide early what information deployers will need to operate the system, monitor it and understand its results, and design the system and its interfaces accordingly. Second, it matters directly to deployers. Under Article 26, deployers must use high-risk systems in accordance with the instructions for use. The information required by Article 13 therefore also defines what the deployer has to do to comply.

What the instructions for use must contain

The instructions must be concise, complete, correct and clear, and relevant, accessible and understandable to deployers. Article 13(3) sets out what they must include:

1. The provider’s identity and contact details, and those of its authorised representative where applicable, so that the deployer knows whom to contact about questions, problems and incidents.
2. The intended purpose of the system. Outputs cannot be interpreted without knowing the context the system was designed for. The deployer must be able to distinguish appropriate use from use outside the validated conditions.
3. The levels of accuracy, robustness and cybersecurity against which the system has been tested and validated, and the known or foreseeable circumstances that may affect them.
4. Known or foreseeable circumstances that may lead to risks to health, safety or fundamental rights, whether in use according to the intended purpose or under reasonably foreseeable misuse. This links transparency to risk management: the deployer must be able to recognise when extra safeguards, human intervention or restrictions are needed.
5. Technical capabilities that help explain outputs, where applicable. People overseeing the system need to understand and critically assess what it produces.
6. Performance for specific persons or groups, where relevant, for the populations on which the system is intended to be used. Differences in data quality or representativeness, discussed in Guide No. 7, can affect results across groups.
7. Specifications for input data and, where appropriate, information on the training, validation and testing datasets, so that deployers know what inputs the system expects and when they are appropriate.
8. Information to interpret outputs and use them appropriately: what a recommendation, prediction or classification means, what it does not mean, and how it fits into human decision-making. This is the main defence against automation bias.
9. Changes predetermined by the provider at the time of the initial conformity assessment, so that deployers can understand how the system may evolve and whether changes affect its performance or safe use.
10. The human oversight measures required by Article 14, including technical measures that help interpret outputs.
11. The computational and hardware resources needed, the expected lifetime of the system, and the maintenance and care measures required, including the frequency and nature of software updates.
12. The mechanisms for collecting, storing and interpreting logs in line with Article 12, so that deployers can keep and use the records the system generates.

Transparency within the wider framework

AESIA places Article 13 within the broader governance of high-risk systems. Information on datasets connects to Article 10; output interpretation supports human oversight under Article 14; performance information is linked to accuracy, robustness and cybersecurity under Article 15; and logging and technical documentation provide the evidence behind what the instructions state.

The practical consequence is that transparency cannot be delegated to a communication or compliance team writing a manual at the end. The instructions must reflect real technical decisions, so engineers, product teams, legal and compliance functions all have a role in making them accurate, complete and usable. They must also stay consistent with the system as it actually is. When relevant changes occur, the information available to deployers has to be updated.

The Guide translates these requirements into concrete measures. For each one it identifies whether the measure concerns the provider or the deployer, illustrates it with examples and links it to the relevant provisions of the AI Act. Dedicated sections on technical documentation and self-assessment reinforce a central idea: transparency must be demonstrable, not merely asserted.

Where to start

For providers and deployers working through Article 13, the Guide suggests a clear sequence:

1. Define what the deployer needs to understand in order to use the system appropriately.
2. Design the system and its interfaces with transparency in mind.
3. Identify the intended purpose, capabilities and limitations.
4. Document the expected levels of accuracy, robustness and cybersecurity.
5. Identify foreseeable risks, including reasonably foreseeable misuse.
6. Explain the expected input data and how outputs should be interpreted.
7. Describe human oversight measures, logging mechanisms, maintenance and updates.
8. Communicate predetermined changes affecting the system.
9. Prepare clear, accessible instructions for use.
10. Keep the information consistent with the technical documentation and the system throughout its lifecycle.

The central question under Article 13 is not whether information has been provided. It is whether that information allows the deployer to use the system appropriately, interpret its outputs, recognise its limits and exercise effective human oversight. Transparency becomes meaningful when it is technically accurate, operationally useful and adapted to the context in which the system is actually used.

‍

‍