What Article 13 Asks of the AI System Itself

If you’re building a high-risk AI system, Article 13 is probably the obligation you think you’ve already handled — and probably haven’t. The Act doesn’t just ask for instructions. It asks for the system itself to be transparent enough that the people deploying it can understand what it’s doing. The instructions for use are part of that, but only one part. A polished manual sitting on top of an opaque scoring model fails the Article 13 test.

With the Omnibus agreement moving Annex III high-risk obligations to 2 December 2027, you’ve got more time. But Article 13 isn’t a paperwork exercise you can knock out at the end. Retrofitting transparency into a system that wasn’t designed to expose its own reasoning is most of the work, and most of the extra time you’ve been given.

What Article 13 actually requires

The article has three short paragraphs that move from a design principle to a concrete document.

Article 13(1). High-risk AI systems must be “designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret a system’s output and use it appropriately.” Read that carefully. The obligation is on how the system is built, not on what gets written about it later. A system that returns a score with no information about how it got there isn’t sufficiently transparent. It doesn’t matter how thick the manual is.

Article 13(2). Transparency must be enough to let providers and deployers meet their Section 3 obligations — Article 14 oversight, Article 26 use in line with instructions, Article 27 fundamental rights impact assessments, and Article 72 post-market monitoring. The standard is functional. If your deployer can’t do their job with the information you’ve given them, you haven’t satisfied Article 13.

Article 13(3). Systems must be accompanied by instructions for use that are “concise, complete, correct and clear” and “relevant, accessible and comprehensible to deployers.” Points (a) to (f) list what the document must contain. That list is the minimum.

Transparency by design: what the system has to do

Article 13(1) is the part most providers misread. Writing a manual that warns deployers to “treat scores with caution” doesn’t make the system transparent. The information has to be in the system itself — its outputs, its interfaces, its API.

A system that meets the standard gives the deployer four kinds of information at runtime:

• What drove the output. The features that mattered, the confidence the system has in its answer, and the conditions where that answer applies. The Act uses the word “interpret” deliberately. A bare score can’t be interpreted — only obeyed.
• Where the output came from. Model version, training data lineage, runtime configuration in force at inference time. If a deployer can’t reconstruct which version of your model produced which decision, they can’t investigate a complaint.
• How well-calibrated the output is. Probability-style outputs (a “70% match”, an “85% risk score”) need to be calibrated against something. An uncalibrated probability is a number wearing a percentage sign.
• When the system is out of its depth. When an input falls outside the conditions the model was validated on — a different language, a demographic group it wasn’t tested with, a sector it wasn’t trained for — the system should flag that at the moment of inference. A warning buried in chapter 4 of the manual is not the same thing.

Article 13(3) point by point

(a) Identity and contact details. Your name, registered trade name or trademark, address, and contact details. For providers outside the EU, the authorised representative. Give a real compliance contact — a named individual or team mailbox a regulator can actually reach. A generic support email is the wrong address when an inspector writes.

(b) Characteristics, capabilities and limitations. The heart of 13(3). You need to cover:

• Intended purpose
• Accuracy figures with the metric you measured against
• Robustness and cybersecurity claims under Article 15
• Foreseeable circumstances that could harm health, safety, or fundamental rights
• Technical capabilities relevant to explaining outputs
• Performance broken down by specific persons or groups where that matters
• Input data specifications

Two practical tests. Are your performance numbers quantified, or are they adjectives (“highly accurate”, “industry-leading”)? And are the failure modes specific enough that a deployer could recognise one when it happened? “Accuracy may vary” is not a failure mode.

(c) Changes to the system over its lifetime. What updates have you pre-decided will happen — retraining cadence, self-updates, model swaps? Tell the deployer what the system will look like over its expected lifetime, including how often you’ll retrain and the kind of change each release tends to introduce. This connects to Article 43(4) on substantial modification: a change beyond what you pre-disclosed is a new conformity event.

(d) Human oversight measures. Both the technical measures you’ve built in (output explanations, intervention controls, fail-safes) and the operational steps the deployer needs to put in place. Spell out the oversight tasks, the competencies the person doing them needs, and the limits of what they can intervene on. This is the bridge to Article 14.

(e) Compute, hardware, lifetime, maintenance. What it takes to run the system, how long it’s designed to last, how often you update it, and how. Cloud-delivered SaaS providers often skip this on the assumption the deployer doesn’t need to know. They do. They need to know that performance can shift between Tuesday and Thursday because you pushed a new model on Wednesday.

(f) Log collection mechanisms. Where logs exist, how the deployer accesses them, how to store them, and how to read them. Article 26(6) requires deployers to keep logs for at least six months. If you haven’t told them how to retrieve and retain those logs, you’ve broken the chain between Article 12 and Article 26.

(a) to (f) is the minimum. Multimodal systems, foundation-model components, and continually learning systems each add more.

Article 13 versus Annex IV and Article 50

The instructions for use show up in two different places, with two different audiences.

As a 13(3) deliverable, they’re for your deployer in the field. The standard is whether the person operating the system can actually do their job with them. As one item inside the Annex IV technical dossier — specifically §1(h), covered in the Article 11 piece — they’re evidence to a regulator that your deployer was given what they needed. A provider who writes a polished Annex IV submission and a thin help-centre page for the deployer has the relationship backwards. The deployer-facing document is the primary one. The regulator-facing copy is the same document, filed.

Article 13 also runs alongside Article 50, and the two are easy to confuse. Article 50 is what you owe the people interacting with the system: chatbot disclosure, deep-fake labelling, biometric notice. Article 13 is what you owe the company deploying it: the information they need to operate the system responsibly. Telling a customer “you’re talking to an AI” does not also tell their bank’s compliance team how to oversee the model. Both obligations exist. Both have to be discharged.

How Article 13 binds your deployer

Article 26(1) requires deployers to use systems “in accordance with the instructions for use accompanying the systems.” Suppose you provide credit-scoring AI to a bank in Frankfurt. Your Article 13 instructions become the bank’s rulebook. Whatever you write, they have to follow.

Two consequences. If you under-document — leave the deployer guessing about capabilities or failure modes — they can’t meet their Article 26 obligations, and you’ve created the exposure. If you over-promise — claim accuracy figures the system can’t sustain on the bank’s actual loan portfolio — every claim is read against the system’s real behaviour during an audit. The discipline is to write instructions that are true and complete. Enough to use the system properly, no further than the evidence supports.

Documentation expectations

A good Article 13 instructions-for-use document has a few qualities.

One document, dated, versioned, addressed to the deployer. Not three help articles, a sales deck, and a wiki page. The structure should map directly to 13(3)(a)–(f) so an auditor can find each section without hunting.

Performance figures with the conditions attached. “94% accuracy on the LinkedIn-Job-Match benchmark, test set X, measured March 2026” beats “highly accurate.” If your deployer is going to use the system on their data, give them the conditions under which your number actually holds.

Failure modes specific enough to recognise. A named list drawn from your Article 9 risk file and your Article 10 data gap analysis. Where the system is used on people, performance broken down by the groups that matter. If your bias examination was real, this section reflects it.

A pre-disclosed change envelope. What updates you can push without triggering a new conformity assessment, and how you’ll notify the deployer when you push them. Silence here turns every minor change into a fight about substantial modification.

Concrete oversight and log instructions. What the overseer should look at, when, with what tools. How the deployer accesses the logs, what fields they contain, how to keep them for six months. The deployer’s Article 26 work starts at this section — if they can’t act on what you’ve written, you’ve handed them an unbuildable obligation.

Common traps

The brochure-shaped manual. A PDF in marketing voice, full of capabilities and benefits, with no quantified performance, no failure modes, and no oversight detail. Reads well. Fails 13(3) on almost every point.

Transparency pushed onto the deployer. A system whose outputs carry no explanation, paired with instructions that tell deployers to “interpret outputs in context.” You’ve handed your 13(1) design obligation to your customer, who can’t fulfil it.

Two diverging documents. A polished technical dossier for the regulator that disagrees with the thinner help-centre page the deployer actually reads. The auditor will compare both. The differences become the finding.

Aspirational accuracy. A 95% headline figure from a benchmark that doesn’t resemble the deployer’s data. That’s misleading information under 13(3) and an Article 10(4) finding in the same breath.

Silent updates. Imagine a recruitment AI provider pushes a model retrain at 2am on a Tuesday. By Wednesday morning the bank using it is interviewing applicants under a different scoring function — and doesn’t know. With no version pinning, no notification, and no statement of pre-approved changes, the provider has just put the bank’s Article 26 monitoring obligation onto a target it can’t see.

Logs without a reader. Log schemas, retention windows, and access controls the deployer is supposed to operate — but has never been told how. The bridge between Article 12 and Article 26(6) goes unbuilt.

What to do now

If you’re a provider building or shipping a high-risk system:

1. Audit your outputs. For each high-risk decision your system produces, ask whether a competent deployer could investigate that specific decision using only what you expose. If the answer is no, you have an engineering job ahead of you. Documentation can’t fix it.
2. Write the instructions as one document. Map every section to 13(3)(a)–(f). Date it, version it, sign it. Date its updates too.
3. Quantify everything you can. Replace adjectives with numbers. Where you don’t have numbers yet, say so — “no group-conditional performance evaluation has been performed” is uncomfortable, but better than silence.
4. Decide what changes are pre-approved. Write the envelope of pre-disclosed modifications into the instructions. Anything outside it triggers Article 43(4).
5. Walk through Article 26 from the deployer’s seat. Take your instructions and try to discharge a deployer’s obligations using only what you’ve written. The gaps you find are gaps your customer will find six months later, with worse consequences.

Article 13 is the design choice that makes everything else on the deployer side possible. A deployer can’t use a system in line with instructions that don’t say enough. They can’t oversee a system that hides its reasoning. They can’t monitor a system whose logs they can’t read. Get Article 13 right and you make compliance possible for the people using your system. Get it wrong and you’ve shipped them a liability they can’t manage.