Skip to content
NEWWhich kind of AI user are you?
Take the two-minute check
AIAC AI ASSURANCE COUNCIL™

EU AI Act

Article 13 — Transparency and provision of information to deployers

Article 13 makes the provider explain the system to whoever will operate it. A high-risk system must be transparent enough that a deployer can interpret its output and use it appropriately, and must be accompanied by instructions for use carrying at least the six categories Article 13(3) lists. The duty is owed to the deployer, not to the person the system is used on.

§ 1 — Who it binds

Whose duty this is, and to whom it is owed

Provider

Every high-risk AI system under either Article 6 gateway. Because the duty runs to the deployer, it also sets the ceiling on what a deployer can rely on when discharging Article 26 — use in accordance with the instructions, competent human oversight, and control of input data are all calibrated against this document. Article 13 is not among the provisions the Digital Omnibus amended.

§ 2 — In practice

A manual for the operator, not a notice for the public

The provision most often confused with this one is Article 50, and the confusion is worth ending early because the two duties have different addressees. Article 50 tells a human being that they are dealing with a machine, or that a piece of content was generated. Article 13 tells a professional organisation how the machine behaves, so that it can discharge obligations of its own. One is a notice at the moment of interaction; the other is a manual handed over at supply. A provider can satisfy either and breach the other, and any assessment that treats transparency as a single subject will find neither gap.

Article 13(1) is easy to skim past and is a design requirement in its own right. Systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the output and use it appropriately — a property of the system, not of the paperwork — with an appropriate type and degree of transparency ensured with a view to achieving compliance with the relevant obligations of the provider and the deployer set out in Section 3. A model whose behaviour cannot be interpreted at all is not rescued by an exhaustive manual explaining that it cannot be interpreted.

Two items in the 13(3) list carry duties that live elsewhere, which is why they are the ones most often left thin. Point (b)(ii) is the destination of Article 15: the level of accuracy including its metrics, and the robustness and cybersecurity against which the system has been tested and validated and which can be expected, together with any known and foreseeable circumstances that may affect those levels. Article 15(3) declares accuracy alone; robustness and cybersecurity reach the deployer through this point, so a file that discusses only accuracy metrics has produced half a declaration. Point (d) is the destination of Article 14: the human oversight measures, including the technical measures put in place to facilitate interpretation of the output. A deployer assigning competent oversight under Article 26 is calibrating against this text, and where it says nothing there is nothing to calibrate against.

Point (c) is the quietest item on the list and the most commercially consequential: the changes to the system and its performance which the provider pre-determined at the moment of the initial conformity assessment. Drafted well, it is what keeps a later retraining inside the original assessment instead of turning it into a substantial modification — which, under the Article 3(23) definition, is a change not foreseen or planned in that assessment. Drafted vaguely, it leaves every subsequent change arguable, and the question of who then carries the provider obligations is answered by Article 25 rather than by the licence. The Digital Omnibus did not amend Article 13, which is worth saying plainly given how much of what surrounds it was amended.

§ 3 — What discharges it

What the instructions for use must actually contain

The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.

  1. 01

    The instructions for use, indexed against Article 13(3)

    Six points, one of them carrying seven sub-headings. An index showing where each is answered turns a product manual into a compliance artefact, and it exposes the sub-headings that were never written at all.

  2. 02

    The statement of pre-determined changes

    Point (c) asks what the provider foresaw at the initial conformity assessment. That sentence later decides whether a modification was substantial, so precision in it repays effort that looks disproportionate at the time of writing.

  3. 03

    Subgroup performance where intended use makes it material

    Point (b)(v) asks, when appropriate, for performance regarding specific persons or groups the system is intended to be used on. Where a system is pointed at people, the qualifier is doing very little work.

  4. 04

    The log-interpretation description under point (f)

    Where relevant, a description of the mechanisms allowing a deployer to collect, store and interpret the logs. A deployer that cannot read them cannot monitor, and its monitoring duty is not qualified by whether anyone explained the format.

  5. 05

    Proof the instructions reached the operating team

    Article 13(2) requires an appropriate digital format or otherwise, and information that is concise, complete, correct, clear, relevant, accessible and comprehensible. A file behind a partner login that operations has never opened fails the last three adjectives.

  6. 06

    The known-circumstances section, written honestly

    Point (b)(iii) covers circumstances, including reasonably foreseeable misuse, which may lead to risks to health, safety or fundamental rights. A section listing none of them is a positive claim rather than an omission, and it will be read as one.

§ 4 — Worked example

Worked example — sixty pages, two unanswered questions

A vendor supplies a high-risk clinical triage system to hospitals. The instructions for use run to sixty pages covering installation, configuration, the API contract, hardware requirements and a support matrix, plus a section headed Performance giving a single aggregate figure. A deployer’s clinical governance committee asks how the system behaves on patients over eighty. The vendor’s account manager replies that the model was validated on a representative cohort.

Which parts of Article 13(3) has the vendor actually satisfied?

Point (e) comprehensively, and the two that matter here barely at all. Computational and hardware resources, expected lifetime and maintenance measures are precisely what point (e) asks for, and sixty pages of it is not padding. But point (b)(v) asks, when appropriate, for performance regarding specific persons or groups on which the system is intended to be used; for a triage system, subgroup behaviour is the paradigm case of appropriate, and one aggregate number answers a question the committee did not ask. Point (b)(ii) asks for the metrics rather than only the score, and for the known and foreseeable circumstances that may affect the expected level. Point (b)(iii) asks for the circumstances of use, including reasonably foreseeable misuse, that may lead to risks to health or fundamental rights. The account manager’s reply is the tell: something that has to be extracted from a salesperson is not something the instructions contain, and a deployer cannot use in accordance with instructions it was never given.

§ 5 — What a weak answer looks like

A datasheet with a compliance label on it

A sales datasheet wearing a compliance label. It is accurate, it is current, and it was written to make a purchase easy — which means it says what the system does well and stays quiet about the conditions under which it does not. Article 13(3) asks for limitations of performance, circumstances that may lead to risk, behaviour under reasonably foreseeable misuse, and results for particular groups of people. None of those helps a sale. The document that discharges this article is the one an operations team needs at three in the morning, and it is rarely the one marketing signed off.

§ 6 — When it applies

When the instructions have to be in the box

  1. 2 December 2027

    Annex III standalone high-risk systems. Moved from 2 August 2026 by the Digital Omnibus — a sixteen-month extension driven by undesignated national authorities and the absence of harmonised standards, not by any relaxation of the Section 2 requirements themselves.

  2. 2 August 2028

    Annex I embedded high-risk systems — medical devices, machinery, vehicles — where AI Act requirements fold into the existing sectoral conformity assessment. Moved from 2 August 2027.

§ 7 — Exposure

Exposure — the provider’s defect, the deployer’s problem

€15 million or 3% of worldwide annual turnover, whichever is higher

Article 99(4)(a), reached through Article 16(a) — Article 13 sits in Chapter III Section 2 and is not itself enumerated in Article 99(4). The consequence worth noticing runs downstream: a deployer handed instructions that omit the oversight measures or the expected accuracy carries its own exposure under Article 99(4)(e) via Article 26, for a defect it did not create and frequently cannot see. Article 99(6) gives an SME the lower of the two figures, and Article 99(6a), inserted by the Digital Omnibus, extends that to small mid-cap companies.

§ 8 — Elsewhere

The same requirement elsewhere

Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.

  • ISO/IEC 42001

    ISO/IEC 42001 Annex A carries controls on the information supplied to those who use an AI system, including its intended use and its limitations. Cited by number and title so the reference stays checkable against the standard.

A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.

Certification

Assessed on the same standard of evidence

Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.