EU AI Act Art.13 2026: Transparency and Information Obligations for High-Risk AI Providers

Post #1397 in the sota.io EU AI Act Provider Compliance Series

EU AI Act Article 13 sits at the handoff point between provider and deployer. It is the obligation that makes the rest of the provider compliance stack actionable: a deployer cannot perform the human oversight required by Art.14, cannot configure the system correctly without input data specs, and cannot demonstrate conformity without knowing the system's accuracy metrics. Art.13 is the information bridge — and if it is incomplete, every downstream obligation in the deployer's stack becomes unverifiable.

This guide covers every requirement in Art.13, how it connects to Art.9, Art.10, and Art.11, what the instructions-for-use document must contain, and a 20-item checklist to confirm your system is compliant before the August 2026 deadline.

What Art.13 Requires: The Core Obligation

Art.13(1) states the design-level requirement: high-risk AI systems must be built so that their operation is sufficiently transparent to enable deployers to interpret outputs and use the system appropriately. This is not a documentation obligation alone — it is a design constraint that must be considered during development, not added at the end.

Art.13(2) establishes the instructions-for-use mandate: every high-risk AI system must be accompanied by instructions in an appropriate digital format (or otherwise), that are:

• Concise — not buried in lengthy contracts
• Complete — covering all required categories without omission
• Correct — factually accurate and up to date
• Clear — comprehensible to deployers with relevant domain knowledge

The instructions-for-use document is the primary deliverable of Art.13. It is distinct from the technical documentation required by Art.11, which serves market surveillance authorities. The instructions-for-use serves the deployer.

The 10 Required Information Categories (Art.13(3))

Art.13(3) specifies what the instructions-for-use must contain. Understanding each category is essential for building a compliant document.

1. Provider Identity and Contact Details

The instructions must identify the provider by name and provide contact details for technical support and compliance queries. This enables deployers to report issues, request updates, and demonstrate their supply-chain due diligence under Art.26.

What to include:

• Legal entity name and registered address
• Technical support contact (email/portal)
• Compliance contact for regulatory enquiries
• Reference to the provider's EU declaration of conformity under Art.47

2. System Characteristics, Capabilities, and Limitations

This is the most substantive section. Deployers need to understand what the system does, what it does not do, and the boundaries within which performance claims are valid.

What to include:

• Functional description of the high-risk AI system
• Annex III classification and the specific intended purpose(s)
• Known performance boundaries (e.g., "accuracy degrades below a certain input resolution threshold")
• Explicit statement of what the system cannot do
• Description of any known biases and their potential impact on outputs

3. Hardware and Software Operating Environment

Deployers need to know the technical prerequisites for correct operation. A system validated on a specific hardware configuration may not perform equivalently elsewhere.

What to include:

• Minimum and recommended hardware specifications
• Operating system and software dependency requirements
• Network and connectivity requirements
• Any cloud or on-premises deployment constraints that affect performance

4. Intended Purpose and Use Contexts

The intended purpose must be defined precisely. This section does not duplicate the technical documentation — it translates the technical definition into operational guidance for the deployer.

What to include:

• Specific use cases the system is designed for
• Categories of natural persons the system will make decisions about (required by Art.13(3)(b))
• Geographic scope if limitations apply
• Prohibited uses — contexts where deployment is explicitly not intended
• Professional qualifications or domain expertise required for the human reviewer

5. Level of Accuracy and Performance Metrics

Art.13(3) requires disclosure of the level of accuracy and the metrics used to measure it. This section must be honest: overstating accuracy creates liability when the system underperforms.

What to include:

• Primary accuracy metric (e.g., F1 score, AUC-ROC, precision/recall balance)
• Performance figures broken down by relevant subgroups where bias assessment has been performed (linked to Art.10 data governance work)
• Robustness and error rates
• Known sources of variance or performance degradation
• Reference to the testing conditions under which metrics were measured

6. Description of Human Oversight Measures

Art.13 requires providers to describe the human oversight measures that deployers should implement. This directly feeds the deployer's obligation under Art.14 to put those measures in place. If the provider does not specify them, the deployer cannot implement them correctly.

What to include:

• Specific oversight checkpoints in the decision workflow
• The minimum level of human expertise required for meaningful review
• Recommended review frequency and sample sizes for monitoring
• Indicators that should trigger manual escalation or system halt
• Description of any built-in override or stop mechanisms

7. Computational and Hardware Resources Needed

Operational planning requires knowing the resources the system consumes. This matters for deployers operating in regulated industries where infrastructure costs form part of compliance cost-benefit analysis.

What to include:

• CPU/GPU requirements and scaling behaviour
• Memory footprint at peak load
• Storage requirements for inference logs (relevant to Art.12 record-keeping)
• Energy consumption indicators where relevant

8. Expected Lifetime and Maintenance Requirements

High-risk AI systems degrade over time as the world changes and training data becomes stale. Art.13(3) requires providers to state the expected operational lifetime and the maintenance schedule needed to preserve conformity.

What to include:

• Expected operational lifetime of the current version
• Model retraining or recalibration schedule
• Update policy — how and when the provider will issue updates
• Version management process and how deployers are notified of changes that require re-evaluation
• Deprecation timeline and successor path

9. Pre-Deployment Testing Requirements

Where applicable, providers must specify any testing that deployers must perform in their specific context before going live. This is particularly relevant for systems deployed in clinical, judicial, or critical infrastructure contexts.

What to include:

• Acceptance testing criteria the deployer must verify
• Integration test scenarios
• Any site-specific calibration required
• Minimum dataset size for validation in the deployment context

10. Input Data Specifications

The system can only perform as documented if it receives inputs that match its design assumptions. Art.13(3) requires providers to specify these requirements in the instructions-for-use.

What to include:

• Required data formats, types, and ranges
• Input quality thresholds below which performance is not guaranteed
• Data preprocessing steps required before inference
• Reference to technical documentation (Art.11, Annex IV) for full dataset specifications used in training, validation, and testing

How Art.13 Integrates with the Provider Obligation Stack

Art.13 is not standalone — it synthesises work done across other provider obligations into a deployer-facing document.

Art.9 → Art.13 Linkage

The risk management system built under Art.9 identifies residual risks and required mitigations. Those residual risks must be communicated through the Art.13 instructions-for-use so deployers can implement matching controls. A risk that is identified in the Art.9 risk register but not disclosed in the instructions is an Art.13 violation.

Practical step: After completing each Art.9 risk assessment cycle, extract all deployer-relevant residual risks and add them to the Art.13 instructions, specifying the corresponding oversight measure deployers should implement.

Art.10 → Art.13 Linkage

The data governance work under Art.10 generates key metrics that must appear in the Art.13 instructions: bias assessment results, data quality metrics, and the characteristics of training datasets that affect performance in deployment contexts outside the training distribution.

Practical step: After each Art.10 bias examination, update the Art.13 accuracy section with the bias assessment findings and any performance disparities across subgroups.

Art.11 → Art.13 Linkage

The technical documentation maintained under Art.11 is the source of record. The Art.13 instructions-for-use draws from it but must be accessible to deployers who are not technical documentation reviewers. The instructions are a curated, operational extract of the technical documentation — not a copy of it.

Practical step: Maintain a traceability matrix that maps each Art.13 disclosure category to the corresponding section of the Art.11 technical documentation. When the technical documentation is updated, trigger a review of the affected Art.13 sections.

Art.14 → Art.13 Dependency

Art.14 requires deployers to implement human oversight measures. But deployers can only implement those measures correctly if providers have specified them in the Art.13 instructions. If your instructions-for-use does not specify what human oversight should look like, you have created a gap in the deployer's ability to comply — and you may share liability for the resulting failure.

Instructions-for-Use Document: Structure and Format

A well-structured instructions-for-use document follows a predictable format that deployers can audit efficiently.

INSTRUCTIONS FOR USE
[High-Risk AI System Name] v[Version]

1. Provider Information
   1.1 Identity and contact details
   1.2 EU declaration of conformity reference (Art.47)
   1.3 Notified body details (where applicable, Art.43)

2. System Overview
   2.1 Intended purpose and Annex III classification
   2.2 Characteristics, capabilities, and limitations
   2.3 Prohibited uses

3. Technical Requirements
   3.1 Hardware and software operating environment
   3.2 Input data specifications
   3.3 Computational resource requirements

4. Performance and Accuracy
   4.1 Primary accuracy metrics
   4.2 Subgroup performance analysis
   4.3 Known error patterns and performance boundaries

5. Human Oversight
   5.1 Required oversight measures
   5.2 Recommended review procedures
   5.3 Escalation triggers and override mechanisms

6. Operational Lifecycle
   6.1 Expected operational lifetime
   6.2 Maintenance and update schedule
   6.3 Deprecation policy

7. Pre-Deployment Requirements
   7.1 Acceptance testing criteria
   7.2 Site-specific calibration requirements

Appendix A: Traceability to Technical Documentation (Art.11)
Appendix B: Risk Register Summary (Art.9 residual risks)
Appendix C: Data Governance Summary (Art.10 bias assessment)

The document must be available in machine-readable format (typically PDF with structured metadata, or a structured data format). It must be provided to deployers before deployment and updated whenever a significant change is made to the system.

Significant Changes and Art.13 Updates

One of the most operationally demanding aspects of Art.13 is keeping the instructions-for-use current. The regulation requires that when a provider makes a substantial modification to the high-risk AI system (as defined in Art.1(4)), the instructions-for-use must be updated accordingly.

Substantial modifications include:

• Changes that affect the system's intended purpose
• Changes to the AI system that alter compliance with the applicable requirements
• Changes that affect the accuracy or performance profile materially

Version management process:

1. Maintain a change log that records each update to the system
2. For each change, assess whether it constitutes a substantial modification
3. If substantial: update the instructions-for-use before releasing the new version
4. Notify deployers of the updated instructions and the nature of the change
5. If the change requires updated conformity assessment, pause deployment of the new version until assessment is complete

SME Considerations

For small and medium-sized providers, the Art.13 compliance burden is proportionate. The key principle is completeness over complexity: a clear, accurate 15-page instructions-for-use document is compliant; an 80-page document that omits key accuracy metrics is not.

Art.62 of the EU AI Act explicitly provides support measures for SMEs and start-ups, including access to regulatory sandboxes and guidance. The European AI Office is expected to publish standardised instructions-for-use templates that SME providers can adapt.

SME checklist for instructions-for-use:

• Use the structure above as a template
• Draft in plain language accessible to deployers with domain expertise (not AI expertise)
• Reference the technical documentation (Art.11) for depth rather than reproducing it
• Version control the document alongside the model
• Ensure legal review of the intended purpose statement and limitation disclosures

Penalties for Art.13 Non-Compliance

Art.13 violations are provider obligations violations. Under Art.99(3), non-compliance with provider obligations for high-risk AI systems attracts fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher.

The fine schedule reflects severity:

• Incomplete instructions-for-use: likely addressed through corrective action orders first
• Materially incorrect accuracy disclosures: higher severity — deployers made decisions based on false information
• Failure to update instructions after substantial modification: may trigger market surveillance intervention under Art.74

Art.13 Provider Compliance Checklist (20 Items)

Use this checklist to verify your instructions-for-use is complete before August 2026.

Identity and Declaration

• Provider name, address, and support contact are current
• Reference to EU declaration of conformity (Art.47) is included
• Notified body reference included where third-party conformity assessment applies (Art.43)

System Description

• Annex III classification and intended purpose clearly stated
• Categories of persons affected by system outputs identified
• Prohibited uses explicitly listed
• Known limitations described honestly without omission

Technical Environment

• Minimum and recommended hardware/software specifications documented
• Input data format, quality thresholds, and preprocessing steps specified
• Computational resource requirements stated

Performance and Accuracy

• Primary accuracy metric(s) and measurement methodology documented
• Subgroup performance results from Art.10 bias assessment included
• Known error patterns and performance degradation thresholds stated

Human Oversight

• Specific oversight measures deployers must implement are described (Art.14 linkage)
• Escalation triggers and override/stop mechanisms documented

Lifecycle and Maintenance

• Expected operational lifetime stated
• Maintenance and update schedule published
• Change notification and version management process described

Integration

• Traceability to Art.11 technical documentation maintained
• Residual risks from Art.9 risk register reflected in human oversight section

What Comes Next in the Provider Sprint

This is Post #4 in the EU AI Act Provider Compliance Sprint. Post #5 will close the series with a comprehensive provider compliance finale: the full provider obligation stack (Art.9 through Art.17 and Art.72) mapped into a single August 2026 readiness checklist.

The five provider obligations covered in this sprint are the foundation of EU AI Act conformity for high-risk AI system developers. Providers who have completed Art.9 risk management, Art.10 data governance, Art.11 technical documentation, Art.13 transparency obligations, and the lifecycle management requirements will be substantially ready for the August 2026 deadline — and will be able to demonstrate that readiness to market surveillance authorities, notified bodies, and deployers alike.

Key Takeaways

• Art.13 is the information bridge between provider and deployer: incomplete instructions-for-use break the deployer's ability to comply with Art.14
• The instructions-for-use is distinct from technical documentation — it is operational guidance for deployers, not a market surveillance document
• Art.13(3) specifies 10 required information categories — all must be present for compliance
• Substantial modifications trigger an update obligation — version management is a continuous compliance requirement
• Art.9, Art.10, and Art.11 feed directly into Art.13 — the instructions-for-use is a synthesis of provider compliance work, not a standalone document
• Fines for non-compliance: up to €15 million or 3% of worldwide annual turnover under Art.99(3)