ENTRY № 12 · STATUTORY READING · EU AI ACT, ART. 13
PUBLISHED 2026-05-09 · ~11-MIN READ · WARRANT COMPLIANCE

EU AI Act Article 13, line by line.

Article 12 binds the provider to log over the lifetime of the system. Article 13 binds the same provider to give the deployer instructions sufficient to interpret those logs. The two articles are paired obligations: the artefact (12) and the manual to read it (13). Read together, they are the regulator-recognised shape of an evidence package.

Warrant is regulator-grade evidence infrastructure for AI agents in regulated industries: drop an agent's execution trace, get a record mapped to a specific EU AI Act obligation, independently verifiable without contacting Warrant.

CLAUSE
Art. 13· §§ 1–3
Regulation (EU) 2024/1689. Paired with Art. 12 logging. Operative for high-risk AI providers.
APPLICATION
2026-08-02
Subject to provisional deferral to 2027-12-02 under May 2026 Omnibus. Penalty under Art. 99(4) at EUR 15M or 3% turnover.
DOCUMENT TYPE
instructions· for use
Article 13(2): instructions for use in an appropriate digital format or made available through other appropriate means. Annex IV technical documentation file.
01 · THE LOAD-BEARING PAIRING

The artefact and the manual.

Article 12 binds the provider to record events automatically over the lifetime of the high-risk AI system. Article 13 binds the same provider to deliver an interpretive layer for those records. Without 13, the logs from 12 are technically present but interpretively useless. A column of timestamps, action types, and tensor shapes does not, on its own, tell a deployer whether the system behaved within its intended purpose, whether human oversight fired correctly, or whether an output sits inside the documented accuracy envelope.

The opening of Article 13 paragraph 1 fixes the principle:

High-risk AI 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 system's output and use it appropriately. Regulation (EU) 2024/1689 · Article 13(1) · 13 June 2024

Read alongside Article 12(1), the structure becomes explicit. Article 12(1) says the system shall technically allow for the automatic recording of events. Article 13(1) says the system shall be designed... to ensure that their operation is sufficiently transparent to enable deployers to interpret. One records. The other interprets. The two articles describe the two halves of a single regulator-readable artefact.

Placement matters. Article 13 sits inside Section 2 of Chapter III, the requirements the provider must satisfy before placing the system on the Union market. Article 16(b) reads those requirements back as a provider obligation. Article 99(4)(a) reads Article 16 back as a fineable failure. The same three steps that take Article 12 to the EUR 15 million ceiling take Article 13 there too.

02 · ART. 13 § 1 VERBATIM

Paragraph 1 · the transparency principle.

High-risk AI 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 system's output and use it appropriately. An appropriate type and degree of transparency shall be ensured with a view to achieving compliance with the relevant obligations of the provider and deployer set out in Section 3. Regulation (EU) 2024/1689 · Article 13(1) · 13 June 2024

Three load-bearing phrases. Sufficiently transparent sets a functional bar, not a maximum disclosure mandate. Interpret the system's output ties transparency to the operational read of decisions, not to the model's internals. Use it appropriately hooks the obligation into the deployer's downstream duty under Article 26.

Recital 72 of the regulation makes the operational frame explicit: transparency exists so that providers and deployers can comply with their respective obligations, and so that affected persons can understand how decisions relating to them are made. It is not transparency for its own sake. It is transparency in the service of accountability.

"Article 12 builds the artefact. Article 13 ships the manual to read it. One record satisfies both."Warrant Compliance · 2026-05-09
03 · ART. 13 § 2 · INSTRUCTIONS FOR USE

Paragraph 2 · the seven mandatory elements.

Paragraph 2 fixes the format, paragraph 3 fixes the content. Together they describe what regulators will read.

High-risk AI systems shall be accompanied by instructions for use in an appropriate digital format or otherwise that include concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers. Regulation (EU) 2024/1689 · Article 13(2) · 13 June 2024

Paragraph 3 then enumerates the seven information elements the instructions for use must contain:

§ 3(a)
Identity and contact details of the provider, and where applicable, of its authorised representative. IMPLICATION · the deployer must know who placed the system on the market, including the Article 22 representative for non-Union providers.
§ 3(b)
Characteristics, capabilities and limitations of performance of the high-risk AI system, including its intended purpose, level of accuracy, robustness, cybersecurity, foreseeable misuse, and inputs the system was trained on. IMPLICATION · the operational envelope is part of the deliverable, not part of an internal document.
§ 3(c)
Changes that have been pre-determined by the provider at the moment of the initial conformity assessment, if any. IMPLICATION · the version line is binding. Anything outside it is a substantial modification under Article 25.
§ 3(d)
The human oversight measures referred to in Article 14, including the technical measures put in place to facilitate the interpretation of the outputs of high-risk AI systems by the deployers. IMPLICATION · the human-in-loop checkpoints are documented at the instruction level, not just at the system level.
§ 3(e)
The computational and hardware resources needed, the expected lifetime of the high-risk AI system, and any necessary maintenance and care measures, including their frequency, to ensure the proper functioning of that AI system. IMPLICATION · the deployer is told what infrastructure the system runs on and what care it requires.
§ 3(f)
Where relevant, a description of the mechanisms included within the high-risk AI system that allows deployers to properly collect, store and interpret the logs in accordance with Article 12. IMPLICATION · this is the explicit Article 12 cross-reference. The instructions tell the deployer how to read the logs.
§ 3(g)
Expected lifetime of the system and any necessary maintenance and care measures, including software updates, where appropriate, to ensure the proper functioning of the system over its lifetime. IMPLICATION · the retention horizon and update cadence are documented up front.

Notice the structural shape. Three of the seven elements are about the system's behaviour at decision time (b, d, f). Two are about its boundaries (c, g). Two are about the responsible party and the resources (a, e). The instructions are an operating manual for a regulated artefact, not a marketing description.

04 · ART. 13 § 3 · PERFORMANCE

Paragraph 3 · accuracy, robustness, cybersecurity.

Paragraph 3 sub-clause (b) is the longest in Article 13 and carries the heaviest performance disclosure burden. It requires the provider to document:

the characteristics, capabilities and limitations of performance of the high-risk AI system, including its intended purpose, the level of accuracy, including its metrics, robustness and cybersecurity referred to in Article 15 against which the high-risk AI system has been tested and validated and which can be expected, and any known and foreseeable circumstances that may have an impact on that expected level of accuracy, robustness and cybersecurity. Regulation (EU) 2024/1689 · Article 13(3)(b)(ii)–(iii) · 13 June 2024

The accuracy and robustness language pairs directly with Article 9 risk management and Article 15 accuracy, robustness and cybersecurity. Article 13 is where the testing and validation results actually leave the provider's premises and reach the deployer. The accuracy metric is not aspirational. It is the metric the system was tested against and the metric the deployer can expect in production within the documented operating conditions.

Sub-clause (b) also requires disclosure of any known or foreseeable circumstance, related to the use of the high-risk AI system in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to risks to the health and safety or fundamental rights. This is the foreseeable-misuse vector, and it carries direct implications for agentic systems treated in section 09 below.

05 · CROSS-REFERENCE TO ART. 12

Why 12 and 13 are one obligation in two articles.

The cross-reference is explicit and load-bearing. Article 13(3)(f) requires the instructions for use to include the following:

a description of the mechanisms included within the high-risk AI system that allows deployers to properly collect, store and interpret the logs in accordance with Article 12. Regulation (EU) 2024/1689 · Article 13(3)(f) · 13 June 2024

The verb chain is the regulator's specification: collect, store, interpret. Three operations on the same artefact. Article 12 mandates that the artefact exists. Article 13 mandates that the deployer is told how to do all three operations on it. Without the Article 13 instructions, the Article 12 logs are technically present but interpretively useless.

The pairing closes a loop on the deployer side. Article 26(6) requires the deployer to keep the logs automatically generated by the high-risk AI system to the extent such logs are under their control. The mechanism for keeping them, and the schema for reading them, comes from the provider's Article 13 instructions. The triangle of obligations is closed: Article 12 produces, Article 13 explains, Article 26 retains and uses.

This is also why instructions and logs co-author the technical documentation file under Annex IV. Annex IV(1)(g) requires the instructions for use referred to in Article 13. Annex IV(2)(d) requires the logs automatically generated by the high-risk AI system as referred to in Article 12. The same file binds them.

06 · WHERE WARRANT LIVES

One evidence package, both obligations.

Warrant produces both halves of the pairing in a single evidence package. The evidence of record carries (1) the per-decision log that satisfies Article 12 and (2) the per-decision interpretive layer that satisfies Article 13. The interpretive layer names which sub-clause of which obligation was engaged on each action, the operational envelope the system was running in, and the human oversight checks that fired or did not.

A live sample sits at /v/7de85ceaeac42a47. The package contains the trace, the classification, the per-action authorisation assessment, the obligation map back to Article 13(3)(a) through (g), and a record that is independently verifiable without contacting Warrant. The file is the Annex IV technical documentation entry, not a separate marketing artefact.

W
Sample EU evidence package · Warrant registerINDEPENDENTLY VERIFIABLE
→ /v/7de85ceaeac42a47

The architectural choice is deliberate. Splitting Article 12 logging from Article 13 instructions across two systems creates a co-ordination gap exactly where the regulator reads. A single record mapped to the Article 13 obligations, independently verifiable without contacting Warrant, removes the gap. The deployer reads one document. The national competent authority reads one document. The record is independently verifiable as one record.

07 · THE DEPLOYER'S READ

What the deployer actually receives.

Annex IV requires the technical documentation file. The deployer reading a Warrant package, at the point of system handover or at the point of regulator inquiry, gets three things layered into one PDF.

  • The trace · the per-decision log of inputs, outputs, intermediate tool calls, and timestamps. This is the Article 12 fulfilment.
  • The interpretive layer · the classification (which Annex III area), the extracted actions, the per-action authorisation assessment, and the obligation map citing Article 13(3)(a) through (g). This is the Article 13 fulfilment.
  • The verification layer · the package is independently verifiable without contacting Warrant, and any edit shows up at confirmation time. This is the Article 13(3)(b) cybersecurity disclosure made operational.

The verification layer is not decorative. Article 15(5) requires that high-risk AI systems be resilient against attempts by unauthorised third parties to alter their use, outputs or performance. A record that is independently verifiable without contacting Warrant is the post-hoc analogue of that requirement. The reader confirms the record, not the producer's good word.

08 · FIELD MAPPING

Article 13 sub-clauses mapped to evidence fields.

Each sub-clause of Article 13 paragraph 3 maps to a specific structured field inside the evidence package. The deployer or the regulator can read the package by clause number and find the corresponding artefact.

Art. 13 sub-clause What evidence must show Warrant field
§ 3(a) Provider identity and authorised representative metadata.provider_did
§ 3(b) Capabilities, limits, accuracy, robustness, cybersecurity classification.scope_envelope
§ 3(c) Pre-determined changes, version at decision time metadata.model_version
§ 3(d) Human oversight measures, when human-in-loop fired trace.actions[].oversight_check
§ 3(e) Compute and hardware resources metadata.runtime_fingerprint
§ 3(f) Log retrieval and interpretation mechanisms regulator_evidence.audit_trail_pointer
§ 3(g) Lifetime, retention horizon, update cadence metadata.retention_until

The table is the spec. A deployer reading the package by clause number finds the corresponding artefact in a known location. A national competent authority running an Article 21 access request finds the same. The structure is the discharge.

09 · FORESEEABLE MISUSE

Article 13(3)(b) and the agentic AI vector.

Article 13(3)(b) requires the provider to disclose any known or foreseeable circumstance, related to the use of the high-risk AI system in accordance with its intended purpose or under conditions of reasonably foreseeable misuse. For classical machine-learning systems, the foreseeable-misuse vector is well-understood: distribution shift, adversarial inputs, data drift outside the validation envelope.

For agentic AI systems, three new vectors require disclosure. Each is foreseeable in the regulatory sense: the technical literature describes them, the threat is published, and a reasonable provider should know.

  • Prompt injection within trace data. A user input or a downstream tool output that contains adversarial instructions can hijack the agent's chain of action. The disclosure must say what the system does when it detects suspicious input patterns and what residual exposure remains after detection.
  • Tool misuse. An agent with access to a transactional API can be steered into actions outside its intended purpose by a sufficiently well-crafted prompt. The disclosure must cover the action allow-list, the authorisation envelope, and the rollback path.
  • System-prompt leak. An agent that exposes its system prompt under adversarial pressure leaks the boundary of its own operating constraints. The disclosure must cover the leak surface and the system-prompt redaction strategy.

Warrant's adversarial robustness eval treats all three vectors as in-scope under Article 13(3)(b). The eval methodology and its results sit at /blog/regulator-grade-evals. The output of the eval becomes a structured disclosure section inside the instructions for use. Agentic AI does not get a discount on Article 13. It gets an expanded disclosure surface.

10 · APPLICATION TIMING

Application timing · 2 August 2026 and the May 2026 Omnibus.

Article 113 of the AI Act as enacted sets the application date for high-risk AI systems under Annex III at 2026-08-02. On 2026-05-07 Council and Parliament negotiators reached a provisional political agreement, the Digital Omnibus on AI, deferring that date to 2027-12-02. The provisional agreement is not yet binding law. Until Council formal endorsement, Parliament formal endorsement, legal-linguistic revision, and publication in the Official Journal complete, the 2026-08-02 date in the AI Act as enacted continues to govern. After whichever date binds, a provider that places an Annex III high-risk AI system on the Union market without an Article 13-shaped instruction-for-use deliverable is exposed to Article 99(4) at EUR 15 million or 3 percent of global turnover, whichever is higher.

2026-08-02· enacted
APPLICATION DATE
Originally 2026-08-02. Provisionally deferred to 2027-12-02 under the May 2026 Omnibus on AI.
7elements
MANDATORY CONTENT
Article 13(3)(a) through (g). All seven, or the discharge fails.
€15M· or 3%
PENALTY CEILING
Article 99(4) for failure of Article 16(b) provider obligations, including Article 13.
1document
ANNEX IV FILE
The technical documentation file binds Article 12 logs and Article 13 instructions in one place.

The Warrant evidence-package format is built to land inside the Annex IV technical documentation file. The instructions cover all seven sub-clauses by structure, not by promise. The record is tamper-evident against post-hoc editing, and its date of issue is independently verifiable without contacting Warrant.

11 · FAQ

Questions a compliance officer asks first.

Is Article 13 a duty to explain the AI?

Article 13 is narrower than a generic duty to explain. The operative phrase is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. It is a duty to ship the interpretive layer that lets the deployer read the system's behaviour and discharge its own Article 26 obligations. It is not a duty to publish a full mechanistic account of the underlying model.

What counts as instructions for use under Article 13, a PDF, a wiki, a video?

Article 13 paragraph 2 says the instructions for use shall be provided in an appropriate digital format or otherwise. The form is open. The content is closed: the seven elements listed in paragraph 3 are mandatory. A PDF, a versioned wiki, or a structured digital document inside the technical documentation file under Annex IV all qualify, provided they cover all seven elements and are updated when the system is. A video alone is unlikely to satisfy the concise, complete, correct and clear test in paragraph 2 because the regulator cannot easily quote from it.

Can a deployer rely on the provider's instructions, or must the deployer adapt them?

Both. Article 13 obligates the provider to ship instructions sufficient to operate the system. Article 26(1) obligates the deployer to take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use. A deployer that ignores the instructions absorbs the operational obligation. A deployer that follows them anchors back to provider responsibility for any defect in those instructions.

What is the difference between Article 13 (provider) and Article 26 (deployer)?

Article 13 is provider-side: build the system to be transparent, ship the instructions. Article 26 is deployer-side: follow the instructions, monitor operation, keep your share of logs, suspend on detected risk. The two articles are designed to interlock. Article 13(3)(f) tells the provider to document the log mechanisms. Article 26(6) tells the deployer to keep those logs. Together they form a closed evidentiary loop.

How do Article 13 paragraph 3 cybersecurity disclosures interact with NIS2 Directive obligations?

Article 13(3)(b) requires disclosure of cybersecurity properties and known vulnerabilities relevant to the system. NIS2 (Directive (EU) 2022/2555) imposes broader operational cybersecurity obligations on essential and important entities. The two regimes overlap when a high-risk AI system is operated by a NIS2-regulated entity. Article 13 disclosures feed the deployer's NIS2 risk-management documentation. Both regimes can be enforced in parallel by competent authorities.

Can a model card serve as an Article 13 instruction-for-use?

Only if it covers all seven mandatory elements in Article 13 paragraph 3. A typical model card documents capabilities, performance metrics, and limitations, which lands roughly on (a) provider identity and (b) characteristics. It rarely covers (d) human oversight technical measures, (f) log interpretation mechanisms, or (g) lifetime and maintenance with the specificity Article 13 requires. A model card is a starting input. It is not, on its own, a discharge.

12 · READ THE SOURCE

Read the source directly.

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotations of Article 13 reflect the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024.