The provider of a high-risk AI system must explain it to the business that deploys it: that is Article 13 of the EU AI Act. The system must be interpretable and come with instructions for use. For an AI agent, those instructions must cover what it can do, not only what it says.
What does Article 13 require?
Article 13 has two parts. The first is a design duty: a high-risk system must be built so that its operation is sufficiently transparent for deployers to understand its output and use it appropriately. The second is a documentation duty: the system must ship with instructions for use that are concise, complete, correct, clear and accessible.
In substance, the instructions must cover:
- who the provider is and how to contact them;
- the intended purpose and the conditions it was designed for;
- the levels of accuracy, robustness and cybersecurity it was tested against, and the metrics used;
- known or foreseeable circumstances that could lead to risks to health, safety or fundamental rights;
- any technical means it has to explain its output;
- its performance for specific groups of people, where relevant;
- the input data it expects;
- changes the provider has planned in advance;
- the human oversight measures, including features that help people interpret its output;
- resources needed, expected lifetime and maintenance;
- how to collect, store and read its logs.
This is different from the disclosure to the public in Article 50, which tells people they are dealing with AI. Article 13 is business to business. Our piece on Article 50 transparency for AI agents covers the other side.
Who gives and who receives?
The provider gives. The deployer receives and must act on what it receives: Article 26 requires deployers to use high-risk systems in line with the instructions for use, and the deployer can use the same information to complete its data protection impact assessment. The full list of deployer duties is set out in what the EU AI Act requires deployers of AI agents to do.
That creates a dependency worth noticing. If the instructions are vague, the deployer cannot show it used the system as intended, because "as intended" was never defined. Thin instructions are a deployer risk, not just a provider failing.
Why are agent instructions harder to write?
A credit scoring model has one output: a score. Its instructions describe the score, its accuracy and its limits. An agent has capabilities: read a ledger, draft a letter, set up a payment, update a record. Each has its own risk, and its behaviour depends on the sources and connections the deployer adds.
So the instructions for an agent should be organised by capability. For each one, a deployer needs to know:
- what the capability does and through which connection;
- how far it may act, from read-only to irreversible;
- which actions the provider has blocked entirely, whatever the deployer configures;
- what evidence the provider has that it works, tested on what kind of cases;
- the conditions under which it should refuse or escalate;
- how to stop it.
Expected behaviour also matters more for agents, because their output varies with wording and context. A statement such as "accurate on the provider's test set" tells a deployer little. A statement of the test conditions, the failure modes seen and the escalation behaviour tells them a lot.
How do you meet Article 13, from either side?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Intended purpose stated | Purpose written per capability, with out-of-scope uses named | Instructions document, versioned |
| Accuracy and metrics declared | Test results per capability, with the test conditions described | Evaluation report attached to the instructions |
| Known risk circumstances | Failure modes from testing and production listed with mitigations | Risk section updated after each release |
| Means to explain output | Each action carries the sources used and the reason it was allowed or held | Sample records showing reasons and sources |
| Human oversight measures | Hold points, approval roles and a stop control described | Oversight section mapped to the deployer's roles |
| Log handling | Format, access method and retention guidance for records | Log specification and a test export |
| Pre-planned changes | Change notice process with advance description of updates | Change log shared with the deployer |
A deployer should check each row on receipt, not on audit. File the instructions version with the deployment record so that you can show which instructions applied on which date.
What will a supervisor or auditor ask?
- Show us the instructions for use for this agent. Which version applied when this case happened?
- Where do the instructions say this capability may be used for this purpose?
- What did the provider say about accuracy, and does your monitoring agree?
- How did you use the instructions to set up oversight?
- What did you do when the provider changed the system?
The timing of these duties matters for planning. Our EU AI Act timeline for AI agent deployers explains what applies already and what is still phasing in.
What does Article 13 not cover?
It does not require the provider to disclose model weights, source code or trade secrets. It does not apply as a legal duty to agents that are not high-risk, though asking for the same information is sensible in any procurement. It does not tell end customers anything; that is Article 50 and, for personal data, GDPR's transparency rules. And it does not make the deployer's oversight design for it: instructions describe the means, the deployer still has to assign people and use them. For background on the concept itself, see what AI transparency means, and for the full map of duties, AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
What should we do if a vendor's instructions are too thin?
Put specific questions in writing: purpose per capability, test conditions, failure modes, blocked actions and log access. Record the answers as part of the instructions. If the provider will not answer, record that too and weigh it in your risk assessment.
Do instructions for use need to be in our language?
The Act expects the information to be accessible and comprehensible to deployers, and member states can set language requirements. Assume you need it in a language your overseers read fluently.
Are instructions enough to show our staff understand the agent?
No. They are an input. Staff competence is a separate duty under the AI literacy rule, and supervisors will test it by asking overseers directly how the agent behaves.