EU AI Act Article 13: Transparency and Instructions for Use

Article 13 of the EU AI Act makes the provider of a high-risk AI system responsible for telling deployers enough to use it safely, yet most "instructions for use" today are product manuals or marketing sheets that leave out accuracy figures, known failure conditions and the logging the deployer needs. The article requires high-risk systems to be transparent enough for deployers to interpret their outputs, and to ship with instructions that meet a minimum content list. Those instructions then become the yardstick for the deployer's own duties: using the system as instructed, monitoring it, staffing oversight and carrying out data protection and fundamental rights impact assessments. This guide walks through Article 13 point by point, shows how each point feeds deployer obligations, and sets out how to write, test, version and evidence the instructions. It is written for providers of high-risk systems, deployers who must rely on what they receive, and procurement, risk and security teams evaluating AI suppliers. Transparency towards people interacting with AI is a different duty, covered in the EU AI Act Article 50 Transparency Obligations Guide.

Source note: provisions are paraphrased from the consolidated text of Regulation (EU) 2024/1689 shown on the European Commission's AI Act Service Desk (EUR-Lex consolidated version as at 27 July 2026, including Digital Omnibus amendments), checked on 11 November 2026. Confirm against the official text before relying on it.

Key takeaways

Article 13 is transparency to deployers, not to the public. Its audience is the organisation operating the high-risk system; disclosures to people affected by AI sit mainly in Articles 26(11), 50 and 86.
The content list is a minimum. Article 13(3) sets six headings, (a) to (f), and seven sub-points on characteristics and performance under (b); good instructions add illustrative examples, as recital 72 suggests.
Accuracy must come with metrics and conditions. Point (b)(ii) requires the expected level of accuracy, including its metrics, robustness and cybersecurity under Article 15, plus the circumstances that may affect them.
The instructions set the deployer's duties. Article 26(1) and 26(5) tie use and monitoring to the instructions, and Articles 26(9) and 27(1)(d) and (e) make deployers use the Article 13 information in DPIAs and fundamental rights impact assessments.
Logging and identity details belong in them. Point (f) requires a description of how deployers collect, store and interpret Article 12 logs, which is where access, retention and integration credentials have to be explained.

What Article 13 requires

The table paraphrases Article 13 of Regulation (EU) 2024/1689 as shown on the European Commission's AI Act Service Desk, which presents the consolidated text as at 27 July 2026 and marks changes made by the Digital Omnibus on AI, Regulation (EU) 2026/1744. No such marks appeared on Article 13 when checked on 11 November 2026.

Provision	Requirement (paraphrased)	What it means in practice
13(1)	Design and develop the system so its operation is sufficiently transparent for deployers to interpret output and use it appropriately; the type and degree of transparency should support provider and deployer compliance with Section 3	Transparency is a design property: confidence indicators, explanation features and exposed logs, not only a document
13(2)	Accompany the system with instructions for use in an appropriate digital or other format, with concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers	A versioned, searchable document or portal written for the deployer's operators and risk teams
13(3)(a)	Identity and contact details of the provider and, where applicable, its authorised representative	A working route for incident reports and Article 26(5) notifications
13(3)(b)	Characteristics, capabilities and limitations of performance, points (i) to (vii) below	The core of the document; see the next section
13(3)(c)	Changes to the system and its performance pre-determined by the provider at the initial conformity assessment, if any	Planned retraining, threshold updates or model refresh cycles that do not count as substantial modification
13(3)(d)	Human oversight measures under Article 14, including technical measures to help deployers interpret outputs	Override and stop procedures, safe state, overseer competence. See the EU AI Act Article 14 Guide.
13(3)(e)	Computational and hardware resources needed, expected lifetime, and maintenance and care measures, including their frequency, to ensure proper functioning, including software updates	Supported platforms, update cadence, end-of-support date, deployer patching duties
13(3)(f)	Where relevant, mechanisms that allow deployers to properly collect, store and interpret logs under Article 12	Log schema, export interfaces, retention settings, access model

Point (b): characteristics, capabilities and limitations

Point (b) carries most of the substance. Each sub-point below is paraphrased from the Service Desk text, with the content a deployer should expect to find and the question to ask if it is missing.

Sub-point	Required content	Good content looks like	Ask the provider
(i)	Intended purpose	Specific tasks, users, settings and populations, plus explicit out-of-scope uses	Which uses would make us a provider under Article 25?
(ii)	Level of accuracy, including its metrics, robustness and cybersecurity under Article 15 against which the system was tested and validated, and circumstances that may affect them	Named metrics (for example precision, recall, false positive rate) on stated test sets, known attack and degradation conditions	How do these figures change on our population and data quality?
(iii)	Known or foreseeable circumstances, including reasonably foreseeable misuse, that may lead to risks to health, safety or fundamental rights	Concrete misuse scenarios drawn from the Article 9 risk register	What did the risk assessment find that you did not fully mitigate?
(iv)	Where applicable, technical capabilities to provide information relevant to explaining output	Which explanation features exist, what they show and their limits	Can we produce an explanation for an individual decision on request?
(v)	When appropriate, performance regarding specific persons or groups on which it is intended to be used	Disaggregated performance by relevant groups	Where does performance drop, and by how much?
(vi)	When appropriate, input data specifications and relevant information on training, validation and testing data	Required input formats, ranges and quality thresholds; dataset provenance summary	What input conditions put the system outside its validated envelope?
(vii)	Where applicable, information enabling deployers to interpret output and use it appropriately	Meaning of scores and thresholds, worked examples, recommended decision rules	What score should never be acted on without review?

Recital 72 adds that the instructions should, where appropriate, include illustrative examples of limitations and of intended and precluded uses, that documentation should be meaningful, comprehensive, accessible and understandable, and that the language should be easily understood by target deployers as determined by the Member State concerned.

How the instructions drive deployer obligations

Article 13 is a provider duty, but its output is consumed by the deployer. Weak instructions leave the deployer unable to show compliance with obligations that reference them directly.

Deployer duty	How it uses Article 13 content	Gap if the instructions are weak
Article 26(1): use in accordance with the instructions for use	Defines the boundary of compliant use	No clear boundary, so drift into unintended use goes unnoticed
Article 26(2): assign competent overseers	13(3)(d) oversight measures define the skills needed	Overseers trained on a generic course rather than this system
Article 26(4): relevant and representative input data	13(3)(b)(vi) input specifications	Deployer cannot test its own data against the validated envelope
Article 26(5): monitor on the basis of the instructions, inform providers, suspend where risk	Performance figures and known failure conditions set the monitoring baseline	No baseline to detect degradation, so post-market monitoring receives no useful signal
Article 26(6): keep logs for at least six months	13(3)(f) logging mechanisms	Logs exist only in the provider's environment
Article 26(9): DPIA under GDPR Article 35	Deployers use the Article 13 information	DPIA relies on assumptions rather than provider evidence
Article 27(1)(d) and (e): fundamental rights impact assessment	Specific risks of harm take account of Article 13 information; oversight follows the instructions for use	FRIA cannot be completed credibly

For the full split of duties see the EU AI Act Provider vs Deployer Obligations Guide and the EU AI Act Fundamental Rights Impact Assessment guide.

Where the instructions sit in the compliance file

Technical documentation: Annex IV point 1 requires the instructions for use for the deployer, and a basic description of the user interface provided to the deployer, in the provider's technical documentation. Point 3 holds the detailed monitoring, functioning and control information that the instructions summarise for deployers.
Provider obligations: Article 13 sits in Chapter III Section 2, so the provider's general duty to ensure its high-risk systems meet the Section 2 requirements (Article 16) covers it, and the conformity assessment checks it. See the EU AI Act Conformity Assessment and Harmonised Standards Guide.
Pre-determined changes: 13(3)(c) connects to substantial modification. Changes the provider declared at the initial conformity assessment can happen without a new assessment; undeclared ones may not. Listing planned update types precisely protects both parties.
Role change: a deployer that uses the system outside the intended purpose in 13(3)(b)(i) in a way that makes it high-risk, or substantially modifies it, can become a provider under Article 25 and inherit the Article 13 duty itself.

Timeline and enforcement

Article 113, as shown in the Service Desk consolidated text and amended by the Digital Omnibus, applies the Chapter III Sections 1 to 3 high-risk requirements, which include Article 13, from 2 December 2027 for systems under Article 6(2) and Annex III, and from 2 August 2028 for systems under Article 6(1) and Annex I. These dates were changed once already; confirm them in the EU AI Act Implementation Timeline Tracker before planning against them. Non-compliance with provider obligations falls under Article 99(4), with fines up to EUR 15 million or 3 percent of total worldwide annual turnover, whichever is higher, and the lower of the two for SMEs under Article 99(6). Market surveillance authorities assess the instructions as part of the system they inspect.

Writing and maintaining the instructions: a phased approach

Start from the risk register and test results: draft (b)(ii), (iii) and (v) directly from the Article 9 risk assessment and the Article 15 validation results so the figures match the technical documentation.
Define the envelope: state intended purpose, populations, input ranges and quality thresholds, and out-of-scope uses with illustrative examples of precluded use.
Write for two readers: an operator section (how to read outputs, when to override, how to stop) and a governance section (metrics, data, logging, update policy) for risk, privacy and security teams.
Usability test with a real deployer: ask a pilot customer to complete a DPIA and FRIA draft and a monitoring plan using only the instructions; every question they raise is a gap.
Version and link to the model: each instructions version references the system version (Annex IV 1(a)), and deployers are notified of changes that alter metrics, envelope or oversight measures.
Feed back from the field: post-market monitoring findings and deployer reports update the known limitations and performance sections. See the EU AI Act Post-Market Monitoring Guide (Article 72).
Rollback: keep previous versions available; if a release changes behaviour outside the declared pre-determined changes, revert the system to the version matching the current instructions while the assessment is reviewed.

Decision guidance

Document or portal: a static PDF suits a stable system with few deployers; a versioned portal with change notices suits frequently updated systems and large customer bases. Article 13(2) allows digital formats.
Small provider: one structured document mapped heading by heading to 13(3), with a changelog, is enough to start. The Model Card and System Card Template covers much of point (b).
Large deployer buying many systems: make an Article 13 content checklist part of procurement, and refuse go-live where (b)(ii), (d) or (f) is missing.
General-purpose model inside a high-risk system: the high-risk system provider still owns Article 13 for the system, and will need upstream information from the model provider to write (b)(ii) and (vi) credibly.

Where identity fits

Point (f) logging and point (e) maintenance usually involve access the deployer must grant or manage, and both are often left vague.

Log access: the instructions should say who can read and export logs, how access is authenticated and whether the provider retains a copy. See the AI Agent Audit Trails for Regulators Guide.
Integration credentials: describe the service accounts, API keys or OAuth clients the system uses to read inputs and write outputs, their minimum scopes and how to rotate them, so deployers can treat them as managed non-human identities.
Provider maintenance access: remote support or update channels named under 13(3)(e) should state the access method and how the deployer approves, logs and revokes it.
Overseer roles: the 13(3)(d) section should name the permissions needed to override and stop so deployers can assign them to named people.

Detection and measurement

Coverage: percentage of in-scope high-risk systems with instructions that address every 13(3) heading.
Metric completeness: share of systems whose instructions give named accuracy metrics, test conditions and group-level performance where relevant.
Deployer query rate: questions per deployer onboarding that the instructions should have answered; a falling rate shows improving quality.
Change notice lag: time between a system release and updated instructions reaching deployers.
Observed versus declared performance: gap between deployer-measured and declared (b)(ii) figures; a persistent gap means the instructions or the system need revisiting.

Framework mapping

Article 13 element	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other references
Instructions and documentation	SA-5 System Documentation	GV.OC-03	ISO/IEC 42001:2023 Annex A (information for interested parties)
Supplier transparency in procurement	SA-4 Acquisition Process	GV.SC-05	AI Act Articles 25 and 26
Pre-determined changes and versioning	CM-3 Configuration Change Control	ID.AM-08	Annex IV point 1(a) and (c)
Logging mechanisms	AU-2 Event Logging; AU-11 Audit Record Retention	PR.PS-04	AI Act Articles 12 and 26(6)
Operator training on instructions	AT-3 Role-based Training	PR.AT-02	AI Act Articles 4 and 26(2)
Known limits and foreseeable misuse	RA-3 Risk Assessment	ID.RA-05	NIST AI RMF 1.0 Map function

Common failure patterns

Headline accuracy with no conditions: a single "95 percent accurate" figure with no metric definition, test set or circumstances that degrade it fails (b)(ii) and gives deployers nothing to monitor against.
Intended purpose written as marketing: broad purposes such as "supports HR decisions" make it impossible to tell compliant use from misuse, and push risk onto the deployer.
Logging described as "available on request": deployers cannot meet the six-month retention in Article 26(6) if logs stay inside the provider's platform.
Instructions that lag the model: retraining or threshold changes ship without updated figures, so deployers operate against stale baselines.
Oversight left to the deployer in one line: "the deployer shall ensure human oversight" does not meet 13(3)(d), which requires the measures themselves.
No upstream information for embedded models: providers building on third-party models cannot describe training data or robustness because they never obtained it. See the AI Supply Chain and AI-BOM Guide.

Practitioner checklist

Map the instructions heading by heading to Article 13(3)(a) to (f) and (b)(i) to (vii).
Derive accuracy, robustness and cybersecurity figures from the same validation results as the Annex IV file.
State the intended purpose, operating envelope and precluded uses with illustrative examples.
List pre-determined changes declared at conformity assessment, and nothing vaguer.
Describe oversight measures, override and stop procedures and the permissions they need.
Document log schema, export, retention settings and access, and integration credentials and their scopes.
Test the instructions with a deployer by drafting a DPIA, FRIA and monitoring plan from them alone.
Version the instructions with the system and notify deployers of material changes.
For deployers: make Article 13 completeness a procurement and go-live gate.

Standards and references

This guide summarises Article 13 of the EU AI Act and related provisions as shown in the consolidated text on 11 November 2026 and is not legal advice. Related NHI Mgmt Group resources: EU AI Act High-Risk AI Systems Guide · EU AI Act Article 14 Guide · EU AI Act Article 15 Guide · Explainable and Fair AI Guide

EU AI Act Article 13 Guide: Writing Instructions for Use Deployers Can Rely On