Article 13 of the EU AI Act is titled "Transparency and provision of information to deployers." It applies to providers of high-risk AI systems and sets out what information must accompany the system to enable deployers to use it correctly, interpret its outputs, and maintain appropriate human oversight. It is one of the most practically consequential provisions for engineering and product teams, because it defines what must be built and written before a high-risk system can legally be placed on the EU market.

This guide explains what Article 13 actually requires—not what marketing departments tend to say it requires. There is a significant gap between genuine transparency documentation and PR copy about "responsible AI." Market surveillance authorities can audit your technical file and instructions for use; they cannot be satisfied with brand messaging.

What Article 13 Actually Requires

Article 13(1) establishes the core obligation: high-risk AI systems shall be designed and developed so that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. This is a design requirement, not just a documentation requirement—the system itself must be interpretable to the degree that the instructions for use can be followed meaningfully.

Article 13(3) specifies the minimum content of the instructions for use. These must cover:

  • Identity and contact details of the provider and, where applicable, their authorised representative in the EU.
  • Characteristics, capabilities, and limitations of the system—including its intended purpose, the level of accuracy, robustness, and cybersecurity against which the system has been tested and validated, and any known or foreseeable circumstances that may lead to risks.
  • Performance on relevant populations—specifically, the expected performance with respect to specific persons or groups of persons for whom the system is intended to be used, and with respect to the specific geographical, behavioural or functional setting.
  • Input data specifications—the form and format of the data inputs the system is designed to process, including the type, volume, and diversity of data required for the system to function as intended.
  • Human oversight measures—the measures to be taken by the deployer to enable, implement, and maintain human oversight, including the technical and organisational measures necessary for natural persons to interpret, oversee, and where necessary intervene in or override the system's output.
  • Expected lifetime and maintenance—the expected lifetime of the system and any necessary maintenance and care, including software updates, to maintain the system in conformity.
  • Description of the mechanisms built into the system to allow persons affected to request an explanation of decisions where applicable.

What "Transparency" Means vs Marketing Spin

The EU AI Act's transparency requirement is operational, not philosophical. A statement like "our AI is built on principles of fairness and explainability" does not satisfy Article 13. What the regulation requires is specific, measurable, and actionable information that a deployer can use to configure human oversight and interpret outputs in a real operational context.

Consider accuracy claims as a concrete example. Many product pages for AI systems describe accuracy in vague terms: "industry-leading accuracy," "state-of-the-art performance," or "99% accurate." Article 13 requires you to state:

  • The specific metric used (precision, recall, F1, AUC-ROC, etc.)
  • The dataset on which that metric was measured (size, composition, time period)
  • Whether the test dataset was held out from training or whether there is any risk of data leakage
  • The performance on subgroups relevant to the system's use case (demographic subgroups where the system is used for employment decisions, for example)
  • The conditions under which accuracy degrades (out-of-distribution inputs, edge cases, adversarial inputs)

This is not what most product documentation currently contains. Closing this gap is a significant engineering and documentation effort for most teams.

Specific Documentation Fields Required

Based on Article 13(3) and the technical documentation requirements under Annex IV, here are the specific fields your instructions for use and technical file must address:

System Description

  • Intended purpose: the specific task the system is designed to perform, the persons and groups it is intended to be used with or for, and the operational contexts in which it is deployed.
  • System version and date of last update.
  • Hardware and software environment required for operation.

Input Data Characteristics

  • What data the system accepts as inputs (format, type, volume).
  • What data quality is assumed (completeness, freshness, encoding standards).
  • What input conditions may cause degraded or unreliable outputs.
  • Whether the system processes special categories of personal data under GDPR Article 9.

Training Methodology and Data Governance

  • High-level description of training approach and data sources (specificity required depends on whether this is in the technical file or the instructions for use).
  • Bias analysis results: which protected characteristics were tested, what disparate impact was found, what mitigations were applied.
  • Known limitations due to training data (geographic coverage, temporal range, demographic representation).

Accuracy and Performance Metrics

  • Named metrics with specific values, measured on a named test dataset.
  • Confidence intervals or uncertainty estimates where available.
  • Performance disaggregated by relevant subgroups.
  • Conditions under which performance was measured vs conditions it may degrade in deployment.

Known and Foreseeable Risks

  • Known failure modes and the conditions that cause them.
  • Foreseeable misuses and the potential harms they could cause.
  • Risk mitigations built into the system and their limitations.

Human Oversight Measures

  • Specific description of how a deployer should configure human review of system outputs.
  • The competence requirements for human overseers (what qualifications or training are assumed).
  • How to pause or override the system.
  • Thresholds at which human review is mandatory rather than discretionary.

Provider vs Deployer Obligations: The Article 26 Split

Article 13 sits on the provider side: it is the provider's obligation to create and supply adequate instructions for use. But Article 26 creates separate, parallel obligations for deployers. Understanding this split is essential for B2B AI products, where the provider and deployer are different organisations.

Provider obligations (Article 13 + Chapter III generally):

  • Design the system to be interpretable.
  • Write instructions for use containing all Article 13(3) fields.
  • Maintain the technical file.
  • Update documentation when the system changes materially.
  • Report serious incidents to market surveillance authorities.

Deployer obligations (Article 26):

  • Use the system only in accordance with the instructions for use.
  • Assign human oversight to appropriately competent persons.
  • Ensure the input data is relevant and representative for the system's intended purpose.
  • Monitor operation of the system and report anomalies to the provider.
  • Suspend use where risks are identified.
  • Inform affected workers when the system is used in employment contexts.
  • Conduct a DPIA where required under GDPR.

For SaaS AI products with enterprise customers, this means your contract and onboarding materials must clearly specify which compliance obligations sit with your team (as provider) and which sit with your customer (as deployer). Leaving this ambiguous creates liability exposure for both parties.

Structuring Your Technical File: A Practical Template

The technical file required under Article 11 and Annex IV is separate from the instructions for use but overlaps significantly. Here is a practical section structure:

  1. Cover page: System name, version, provider identity, date, classification determination.
  2. Section 1 — System description: Intended purpose, operational context, affected persons.
  3. Section 2 — Architecture and components: Model architecture, external APIs, data flows, system boundaries.
  4. Section 3 — Data governance: Training data sources, preprocessing pipeline, bias assessment, data quality controls.
  5. Section 4 — Risk management: Risk register, hazard analysis, mitigation measures, residual risks.
  6. Section 5 — Testing and validation: Test datasets, metrics, results, disaggregated performance, adversarial testing results.
  7. Section 6 — Human oversight design: Override mechanisms, oversight competence requirements, escalation paths.
  8. Section 7 — Logging and monitoring: What events are logged, retention period, post-market monitoring plan.
  9. Section 8 — Conformity assessment: Self-assessment results or notified body certificate reference.
  10. Annex A — Instructions for use (the Article 13 document, version-controlled).
  11. Annex B — EU Declaration of Conformity.
  12. Annex C — Change log (material changes since initial conformity assessment).

Common Compliance Gaps

These are the gaps most commonly found in AI documentation during compliance gap assessments:

  • Vague accuracy claims: Stating "95% accurate" without naming the metric, the dataset, or the evaluation conditions. Article 13 requires specificity.
  • Missing data governance section: Many technical files describe the model architecture in detail but say nothing about how training data was sourced, cleaned, and validated for bias.
  • No human oversight protocol: Instructions for use that describe the system's outputs but provide no specific guidance on when and how a human reviewer should intervene or override.
  • Static documentation for a live system: The technical file describes the model at a point in time but has no versioning process or trigger for updates when the model is retrained or fine-tuned.
  • Conflating the instructions for use with the technical file: The instructions for use is a deployer-facing document; the technical file is a regulator-facing document. They serve different purposes and require different levels of technical detail.
  • No disaggregated performance data: Aggregate accuracy figures on a balanced test set tell a regulator very little about how the system performs on the specific subgroups it will encounter in production.