WARRANTThe 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:
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(a) reads those requirements back as a provider obligation — providers shall ensure that their high-risk AI systems are compliant with the requirements set out in Section 2. 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.
Paragraph 1 · the transparency principle.
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 makes the operational frame explicit: transparency is required to address concerns related to opacity and complexity of certain AI systems and help deployers to fulfil their obligations under this Regulation, so that deployers can understand how the system works, evaluate its functionality and comprehend its strengths and limitations. It is not transparency for its own sake, and it is not addressed to the affected person — an affected person's right to an explanation of an individual decision sits separately in Article 86.
Paragraph 2 · the six mandatory elements.
Paragraph 2 fixes the format, paragraph 3 fixes the content. Together they describe what regulators will read.
Paragraph 3 then enumerates the information elements the instructions for use must contain — six of them, points (a) to (f), prefaced by at least:
Notice the structural shape. Three of the six elements are about the system's behaviour at decision time (b, d, f). One is about its boundaries (c). Two are about the responsible party and the resources it needs (a, e). Paragraph 3 opens with at least, so six is the floor, not the ceiling. The instructions are an operating manual for a regulated artefact, not a marketing description.
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 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.
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:
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.
Annex IV carries the instructions into the technical documentation file, but not the logs. Annex IV point 1(h) requires instructions for use for the deployer, and a basic description of the user-interface provided to the deployer, where applicable, and point 2(e) cross-refers expressly to Article 13(3), point (d) on human oversight. Annex IV does not mention Article 12 at all: the logs are kept under Article 19(1) by the provider and Article 26(6) by the deployer, and produced to a competent authority on a reasoned request under Article 21(2). The instructions are filed; the logs are retained and produced.
One evidence package, and what it does not hold.
Warrant produces the Article 13 half of the pairing. The signed record is a closed structure — its root properties are exactly classification, actions, authorizations, obligations, coverage_by_regime, deferred_regimes, risk_tier, refusal_reason and trace_metadata, and additionalProperties is false, so nothing else can be present. What it carries is the interpretive layer: which sub-clause of which obligation was engaged on each action, the per-action authorisation assessment, and the coverage summary per regime.
It does not carry the submitted trace. The inputs, outputs, intermediate tool calls and per-action timestamps a customer sends in are read during extraction and are not re-emitted into the signed record; each actions row retains exactly action_id, actor, action and subject, and no field points back into the source trace. Article 12 log-keeping therefore stays with the provider's own logging system. The gap is stated rather than papered over: the package is what makes those logs readable by clause, not a replacement for them.
A live sample sits at /verify?id=7de85ceaeac42a47. The package contains the classification, the extracted actions rows, the per-action authorisation assessment, the obligation map back to Article 13(3)(a) through (f) keyed by action id, and a record that is independently verifiable without contacting Warrant. It is an input to the Annex IV technical documentation file, not a separate marketing artefact.
The boundary is deliberate. The Article 13 interpretive layer is the part that has to be readable by a stranger, and it is the part that is signed. Keeping the raw trace out of the signed record keeps the customer's inputs and outputs in the customer's own systems, where Article 12 and Article 19 already put them. What that costs is stated plainly above: a reader holding a Warrant package cannot re-derive the underlying trace from it, and must obtain the logs from the provider or the deployer to do so.
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 two layers and one stated gap.
- The interpretive layer · the classification (which Annex III area), the extracted actions rows carrying action_id, actor, action and subject, the per-action authorisation assessment in authorizations, and the obligation map citing Article 13(3)(a) through (f), keyed by action id. This is the Article 13 material.
- 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 gap, stated · the submitted trace is not in the package. Inputs, outputs, intermediate tool calls and per-action timestamps are read during extraction and are not re-emitted, and no field addresses back into the source trace. Article 12 log-keeping is not discharged by this record and is not claimed to be.
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.
Article 13 sub-clauses against the fields that exist.
Each sub-clause of Article 13 paragraph 3 is set below against the field in the evidence package that carries it. Three of the six have a field, and it covers part of what the sub-clause asks for. Three have none, and the third column says so.
| Art. 13 sub-clause | What evidence must show | warrant-v1 field, or none |
|---|---|---|
| § 3(a) | Provider identity and authorised representative | None. actions[].actor carries the actor string supplied in the trace, which is not a provider identity and never an authorised representative. |
| § 3(b) | Capabilities, limits, accuracy, robustness, cybersecurity | classification.domain, .jurisdictions, .risk_tier and .risk_tier_justification. classification.regimes is defined in the schema but is left empty in production, so it is not data a reader can rely on. No field for accuracy, robustness or cybersecurity. |
| § 3(c) | Pre-determined changes, version at decision time | pipeline_models and pipeline_config_sha256 on the receipt, which record which models and which prompt configuration reached the conclusion. Neither is a version of the provider's own system, and no field records pre-determined changes. |
| § 3(d) | Human oversight measures, when human-in-loop fired | authorizations[].human_oversight_appropriate per action, and incomplete_oversight_count on the receipt. The first is Warrant's assessment of whether human oversight was appropriate for that action, not a record that a human was present or intervened. Neither records the oversight measures the provider designed in. |
| § 3(e) | Compute and hardware resources, expected lifetime, maintenance and software updates | None. |
| § 3(f) | Log retrieval and interpretation mechanisms | trace_metadata.package_id is the identifier the record is retrieved by; obligations is an object keyed by action id, so the clause id sits at obligations.<action_id>[].id, and coverage_by_regime summarises them per regime. |
Read the third column literally. The evidence schema sets additionalProperties to false at the top level, and its root properties are exactly classification, actions, authorizations, obligations, coverage_by_regime, deferred_regimes, risk_tier, refusal_reason and trace_metadata. There is no metadata root and no regulator_evidence root, so no path beneath either can appear in a conforming package. classification is closed the same way, which rules out any scope_envelope property on it. Where the column says None, no field exists — not a field under a different name.
What the structure delivers is narrower than what Article 13(3) asks for. A deployer, or a national competent authority running an Article 21 access request, can read the package by clause number: each obligation row carries the corpus clause id, a compliance status and an evidence string, and coverage_by_regime summarises them per regime. Article 13(3)(a) and (e), and the accuracy, robustness and cybersecurity limbs of (b), have no field. For those the instructions-for-use file remains the provider's own document, and the package does not stand in for it.
Article 13(3)(b) and the agentic AI vector.
Article 13(3)(b)(iii) 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, which may lead to risks to the health and safety or fundamental rights referred to in Article 9(2). 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.
Application timing · 2 December 2027 and the Digital Omnibus.
Article 113 of the AI Act as enacted set the application date for high-risk AI systems under Annex III at 2026-08-02. The Digital Omnibus on AI defers that date to 2027-12-02: Article 1(40)(b) of Regulation (EU) 2026/1744 (OJ L, 2026/1744, 24 July 2026, in force 27 July 2026) replaced Article 113, third paragraph, point (c) with two fixed calendar dates — 2 December 2027 for Article 6(2) and Annex III systems, and 2 August 2028 for Article 6(1) and Annex I, the latter read with the new Article 2(13) under which Articles 9 to 15 and 17 to 25 may be limited where Annex I Section A legislation gives equivalent or higher protection. From the applicable date, 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 total worldwide annual turnover for the preceding financial year, whichever is higher.
The Warrant evidence-package format is built to land inside the Annex IV technical documentation file. The instructions cover all six 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.
Questions a compliance officer asks first.
Read the source directly.
- Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
- Article 13 transparency and provision of information to deployers · annotated text
- Article 12 record-keeping · paired obligation
- Article 14 human oversight · cross-referenced by 13(3)(d)
- Article 26 obligations of deployers of high-risk AI systems
- Annex IV technical documentation file
- Article 99 penalties
- Per-obligation Warrant evidence field mapping
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.