EU AI Act Article 13 in Practice: What Transparency Documentation Actually Requires

Article 13 requires high-risk AI systems to be transparent enough for deployers to use them responsibly. This guide explains what that means in practice, what documentation you need to write, and what deployers actually need to know.

This article is educational guidance for practitioners, not legal advice. For specific compliance decisions, consult qualified legal counsel.

What Article 13 Requires

Article 13 of the EU AI Act requires high-risk AI systems to be designed and developed in such a way that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately.

This is distinct from the broader transparency principles you might be familiar with from AI ethics guidelines. Article 13 transparency is specifically about enabling deployers (the organisations using your high-risk AI system) to understand what the system does, where it works well, where it does not, and how to use it responsibly.

The deployer here is the business that buys or uses your AI system — not the end user. Article 13 documentation is primarily B2B documentation. End-user transparency rights come from Article 50 (limited-risk transparency) and the rights to explanation under GDPR.

The Four Elements of Article 13 Documentation

Article 13 paragraph 3 specifies what the instructions of use must contain as a minimum:

Element	What it means in practice
Identity and contact details of provider	Your company name, registered address, and contact for compliance enquiries. If you use an EU authorised representative (non-EU provider), their details too.
Characteristics, capabilities, and limitations of the AI system	Plain English description of what the system does, the input data types it requires, the output types it produces, the performance specifications it meets, and — critically — the conditions under which performance may be degraded.
Intended purpose	The specific use cases the system is designed and validated for. Any uses outside this scope are the deployer's responsibility. Be specific: 'screening CVs for software engineering roles in European labour markets' is better than 'recruitment AI.'
Level of accuracy, robustness, and cybersecurity	The metrics the system was validated against. Accuracy on your validation set, breakdown by relevant demographic groups, robustness test results. Must include the conditions these metrics were measured under.
Any known or foreseeable circumstances that may lead to risks	The failure modes you know about. Input types that produce unreliable outputs. Edge cases that produce biased or incorrect results. The system's behaviour outside its validated use context.
Performance on specific groups of persons	Performance data disaggregated by demographic groups where relevant to the use case. A hiring tool must show performance across gender, ethnicity, and age groups.
Human oversight measures	Who needs to be in the loop, at what points, and what qualifications they need. What decisions the system should and should not make without human review.
Maintenance and data management expectations	What monitoring the deployer needs to run. How to detect that the system is no longer performing as expected. Data quality requirements for inputs.

Who Reads It and What They Need

Article 13 documentation has two distinct readerships with different needs:

The compliance or procurement reader

Before purchase or deployment, a compliance officer or procurement team will evaluate whether the AI system is appropriate for their use case and compliant with their regulatory obligations. They need:

Clear scope of the intended use and any uses that are explicitly out of scope.
Performance evidence they can assess against their risk tolerance.
Information about what regulatory compliance the provider has completed (conformity assessment, database registration).
The contact details for escalating compliance questions.

The operational reader

After deployment, the person actually using or overseeing the AI system needs operational guidance. They need:

How to interpret the system's output (what does a high confidence score actually mean?).
The warning signs that should trigger human review rather than automated action.
What input conditions produce unreliable outputs.
How to escalate edge cases or unusual outputs.

Write Article 13 documentation in two parts: a short summary document for compliance evaluation (two to four pages), and a detailed operational guide for users and operators. A single dense technical document serves neither reader well.

Performance Disclosure: What Level of Detail

Article 13 requires disclosure of accuracy, robustness, and cybersecurity metrics — but does not specify format or granularity. In practice, the acceptable minimum is:

Overall performance metrics on a representative held-out test set.
Performance metrics disaggregated by the demographic groups most relevant to the use case (gender, age group, ethnicity for employment AI; geographic region for critical infrastructure AI).
The conditions under which metrics were measured (evaluation dataset characteristics, test conditions).
Known performance degradation conditions (what inputs make the model perform worse than the headline metric).

Disclosing only aggregate accuracy metrics without group-level disaggregation is insufficient under Article 13 for most high-risk use cases. A system that achieves 92% accuracy overall but 78% accuracy for one demographic group is not performing equally. The disaggregated figures must be disclosed.

The Limitations Disclosure: What to Include

The hardest part of Article 13 compliance for most providers is the limitations disclosure. This requires you to document failure modes — something most product teams are reluctant to publish in a customer-facing document.

The standard for limitations disclosure is: anything a deployer would reasonably want to know before deciding to use the system. In practice:

Input data quality thresholds: the system performs as specified when inputs meet criteria X. Below these criteria, outputs are unreliable.
Out-of-distribution behaviour: performance metrics were measured on a dataset drawn from population Y. If the deployer's population differs materially, they should conduct additional validation.
Temporal limitations: the system was trained on data from period Z. Performance may degrade as the world changes. Indicate the recommended revalidation interval.
Edge case failures: specific input types or conditions that produce unreliable outputs, even if rare.

The limitations disclosure is a legal document, but it is also a trust-building document. Deployers who understand a system's limitations are less likely to deploy it inappropriately, less likely to have an incident, and more likely to maintain a productive vendor relationship. Write it to genuinely inform, not to minimise.

Human Oversight Documentation: The Most Neglected Element

Article 14 requires human oversight mechanisms to be built into the system. Article 13 requires you to document what human oversight the deployer needs to implement. These are often confused.

Your Article 13 documentation must tell the deployer:

Which outputs are suitable for autonomous action (no human review required) and which require human review before action.
The qualifications or training a human reviewer needs to meaningfully evaluate the system's output. A non-specialist cannot meaningfully review outputs from a medical diagnostic AI.
How to configure the system's human-in-the-loop settings where configurable.
The indicators that a specific output should be escalated for expert review regardless of the system's confidence score.

A Documentation Structure That Works

Cover page: System name, provider identity, version number, applicable regulatory framework (EU AI Act Regulation 2024/1689), date of this documentation, contact for compliance enquiries.
Intended purpose and scope (one page): What the system does, the specific use cases it is validated for, and explicitly: what it is not designed for.
Technical specifications (one to two pages): Input requirements, output format, model architecture summary (at a conceptual level), and infrastructure requirements.
Performance specifications (one to two pages): Accuracy metrics, disaggregated performance by relevant groups, conditions of measurement, benchmarks against relevant standards.
Known limitations and risks (one page): Input conditions that degrade performance, out-of-distribution behaviour, temporal validity, identified failure modes.
Human oversight requirements (one page): Required oversight by output type, qualifications of reviewers, escalation criteria, configuration options.
Data requirements and maintenance (one page): Input data quality requirements, recommended monitoring frequency, revalidation triggers, deployer responsibilities.
Regulatory compliance status (one page): Conformity assessment status, EU AI database registration number, applicable national market authority contact.