EU AI Act Article 13: Transparency Obligations for High-Risk Systems

The word "transparency" appears in more than one place in the EU AI Act, and teams routinely assume Article 13 means the one they've heard about — a chatbot disclosing that it's an AI, an image labeled as AI-generated. That's a real requirement, but it lives in Article 50, a separate provision covering end-user-facing disclosure. Article 13 is a different thing entirely: it requires a high-risk AI system to be designed so its operation is sufficiently transparent for a deployer — the organization using the system, not the person the system is used on — to interpret its output and apply it correctly. The mechanism for that is a specific, substantive document: instructions for use.

Getting this distinction right at the start matters, because it determines who's writing the document and what it needs to contain. This is B2B technical documentation aimed at the organization operating your system, not a consumer-facing notice. It's also worth keeping separate from an entirely different track that runs alongside the risk-tier system: the model-level obligations Articles 51 through 56 put on providers of general-purpose AI models, which apply because of what was trained, not what any specific deployer does with a high-risk system built on top of it.

It's also worth separating from a third document teams sometimes fold it into: the technical documentation required under Article 11 and detailed in Annex IV. That documentation is built for regulators and conformity-assessment bodies — it's the internal evidentiary record proving the system was built and tested correctly. The Article 13 instructions for use are a distinct, deployer-facing deliverable, shorter and more operational, built so a customer can actually run the system correctly rather than prove to an auditor that it was engineered correctly. The two documents draw on overlapping source material — much of the same accuracy testing and risk analysis — but they're not the same artifact serving two audiences; they're two different artifacts with two different jobs.

What the instructions for use actually have to contain

Article 13 doesn't leave the content of this document to interpretation — it specifies categories of information that have to be included, in a form that's concise, complete, correct, and clear.

Identity, intended purpose, and performance metrics

The instructions start with the basics — the provider's identity and contact details — but move quickly into substance: the system's intended purpose, and its level of accuracy, including the actual metrics used to measure it, alongside its robustness and cybersecurity characteristics as referenced under Article 15. This isn't a marketing claim about how well the system performs; it's a documented, testable figure tied to what was actually validated.

Known risks, foreseeable misuse, and performance across groups

The document has to disclose the known and reasonably foreseeable circumstances related to the system's intended use, or to reasonably foreseeable misuse, that could lead to risks to health, safety, or fundamental rights — the same misuse-aware thinking Article 9's risk management process is required to have already worked through. Where relevant, it also has to describe the system's performance with respect to the specific persons or groups of persons on which it's intended to be used, and specify the training, validation, and testing data sets it was built on, in terms of their relevant characteristics.

Human oversight measures and technical resource requirements

The instructions have to describe the human oversight measures built in under Article 14, including the technical measures in place to help the humans assigned to interpret the system's output do so meaningfully — not just a statement that "a human is in the loop." They also need to cover the computational and hardware resources the system needs, its expected lifetime, and the maintenance and care measures required to keep it performing as validated, plus a description of the logging mechanisms required under Article 12. One category teams consistently forget: any changes to the system and its performance that were predetermined by the provider at the time of its initial conformity assessment also belong in this document — deployers need to know in advance which future updates are already anticipated and covered, versus which would require a fresh conformity check.

What this looks like on a real system

Take an AI-driven credit-scoring tool used by a lending platform — the same kind of system that, alongside its own GDPR obligations, also has to satisfy Article 13. A weak instructions-for-use document says the system "assesses creditworthiness with high accuracy" and stops there. A compliant one states the actual validated accuracy figure and the population it was measured against, discloses that performance degrades for applicants with thin credit files because the training data underrepresented that group, specifies that loan officers reviewing borderline scores need to weight the tool's output alongside — not instead of — the standard underwriting checklist, and states plainly that the model wasn't validated for small-business lending even though the interface doesn't technically prevent someone from using it that way. The difference between those two documents isn't length or formatting — it's whether a deployer who reads it actually understands where the system can be trusted and where a human needs to compensate for it.

Why this is a compliance artifact, not marketing collateral

In practice, instructions for use often get delegated to whoever already owns product documentation — and product documentation is optimized for a different job: making a system sound capable and easy to use. Article 13's standard is different. "Concise, complete, correct, clear" is an audit standard, not a style preference, and a document written to sound reassuring rather than to disclose limitations accurately fails it even if it's well-written prose. A deployer reading a compliant instructions-for-use document should come away knowing exactly where the system is validated to perform well and exactly where it isn't — including the uncomfortable parts. If your instructions for use don't mention a single limitation or foreseeable misuse scenario, that's a strong signal the document was written by the wrong team, or reviewed by the wrong one.

That has a practical implication for who owns this document internally. Product marketing or customer success teams are usually the wrong default owners, not because they lack the writing skill, but because their instinct — reasonably, for their actual job — is to make the product sound good. The instructions for use need an owner whose incentive is accuracy under audit, which in most organizations means compliance or legal holding the pen, with engineering supplying the real performance figures and product supplying plain-language context, not the other way around.

How this connects to Articles 12 and 14

Article 13 doesn't generate new content from scratch — it's a synthesis document that pulls together outputs already required elsewhere: the misuse analysis from the Article 9 risk management system, the logging capabilities required under Article 12, and the human oversight design required under Article 14. If those upstream obligations are being handled as one-off checkboxes rather than a connected process, Article 13 is where that gap becomes visible — you can't write a complete, accurate instructions-for-use document from inputs that were never properly worked through in the first place.

For the classification step that determines whether a system needs any of this, see how Article 6 high-risk classification actually works.