EU AI Act Article 13: Transparency and Information for Deployers of High-Risk AI

Article 13 of Regulation (EU) 2024/1689 imposes a specific, mandatory transparency obligation on providers of high-risk AI systems: before a system is placed on the market or put into service, the provider must supply the deployer with written information sufficient for the deployer to understand what the system does, how well it does it, and when it may fail. This is not a general "be transparent" principle. It is an operational requirement with defined content, a defined recipient, and real enforcement consequences.

Non-compliance carries fines of up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)). Under the Digital Omnibus agreed in May 2026, the obligation applies to stand-alone high-risk Annex III systems from 2 December 2027 — pushed back from the original 2 August 2026 date — and from 2 August 2028 for high-risk AI embedded in regulated products under Annex I. That breathing room is real, but assembling compliant instructions for use takes longer than most providers expect.

This guide unpacks what Article 13(1), (2), and (3) actually require; how Article 13 differs from Article 50 (the transparency obligation that applies to limited-risk systems and end users, not deployers); how it relates to Article 14 (human oversight); and the practical gaps that audit teams find most often. It then covers enforcement, sector examples, supply-chain responsibilities, and documentation structure.

---

What Article 13 Actually Requires

Article 13 governs the provider-to-deployer relationship for high-risk AI. Its purpose is to ensure that the organisation responsible for deploying a high-risk AI system has enough information to do so correctly — to interpret the system's output, identify when the output should not be acted upon without review, and apply the human oversight measures Article 14 requires.

Article 13(1): Transparency by design

Article 13(1) establishes the foundational standard: high-risk AI systems must be designed and developed so that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. Transparency under Article 13 is not a document you produce after the fact. It is a design requirement. A system that generates outputs its deployer cannot meaningfully interpret fails Article 13(1) regardless of what the accompanying documentation says.

The provision adds a further qualifier: the transparency must be of "an appropriate type and degree" to achieve compliance with the provider's and deployer's obligations under the Act. This means the transparency standard is calibrated to the specific deployment context, not set at a single universal level. A credit-scoring model supplied to the risk management team of a regional lender needs to expose different information — at a different level of technical depth — than the same model supplied to a non-technical procurement function in a public authority. The provider must think through who will read the output and what they need to use it responsibly.

Article 13(2): Instructions for use — the delivery vehicle

Article 13(2) specifies how the transparency obligation is discharged: through instructions for use. The instructions must be concise, complete, correct, clear, relevant, accessible, and comprehensible to the deployer. Each adjective has operational significance.

"Concise" rules out burying the mandatory content in a 300-page technical appendix. "Complete" rules out omitting failure modes because they are commercially inconvenient. "Correct" means the performance claims must reflect the system's actual measured behaviour. "Accessible" means the format and language must match the deployer's actual reading context — not just technically available, but practically reachable. "Comprehensible" means the deployer can understand the content without hiring an expert to decode it.

The instructions must be supplied before the system is placed on the market or put into service. A deployer who receives documentation only at contract signature — or only via a link buried in terms of service that the deploying team never reads — is not receiving compliant instructions for use.

Article 13(3): Mandatory content

Article 13(3) specifies what the instructions must contain. The requirements break into five substantive areas.

Provider identity and contact details. The legal name, registered address, and contact details of the provider, and of any authorised representative under Article 22 where applicable. For a non-EU provider, the authorised representative is the primary compliance contact for EU-based deployers. The contact must be a responsible legal or compliance contact — not a generic helpdesk address.

Characteristics, capabilities, and limitations. This is the core disclosure and the section most often done inadequately. It encompasses:

• The system's intended purpose — the specific task, in the specific operational context, for which the provider designed the system. Vague descriptions like "general decision support" do not satisfy this requirement. If the system classifies loan applications for consumer credit decisions in the EU, say so.
• The level of accuracy, robustness, and cybersecurity as defined under Article 15, including the metrics used and the conditions under which they were measured. "Robustness" here is the statutory term from Article 15 — it means resilience to adversarial inputs, unexpected inputs, and operating environment variation. The cybersecurity dimension means the provider must disclose whether, and to what degree, the system has been assessed for model-level vulnerabilities such as input manipulation or data poisoning.
• Known or foreseeable circumstances that may affect the system's performance — distribution shift between training and deployment data, noise in real-world inputs, edge-case populations, temporal degradation as the world changes and the model does not.
• Foreseeable misuse: uses that the provider has reason to anticipate even though they were not intended. A provider who designs a hiring screening tool for shortlisting candidates must disclose if the output is being used by some deployers as a definitive rejection decision, and flag that this exceeds the intended purpose.
• Performance variations across specific persons or groups — the equity dimension. Article 13(3) makes this mandatory disclosure, not an optional appendix. If the system performs differently for women than men, for different age cohorts, for different language backgrounds, that must be stated.

Input data specifications. A technical description of the data the system requires: format, type, volume, and quality requirements. This allows a deployer to assess whether their operational data environment is fit to run the system. A deployer who feeds a system data it was not designed for, without knowing that, cannot apply meaningful oversight.

Human oversight measures. Article 13(3) explicitly requires that the instructions describe the measures to support the human oversight obligations under Article 14. This is the structural connection between the two articles: Article 14 requires that high-risk systems be designed to allow qualified human intervention; Article 13 requires that the deployer be told how that intervention works in their specific context. The instructions must describe who is responsible for oversight (by role, not just by name), the conditions under which human review is mandatory, the override procedure, and what information the oversight person should consult when deciding whether to act on the system's output.

Logging mechanisms. A description of the record-keeping and logging capabilities built into the system in accordance with Article 12 — what is recorded, for how long, in what format, and how the deployer can access the logs. The deployer needs this information to conduct their Article 26 monitoring obligations and to support any serious incident report under Article 73. It also matters for any Fundamental Rights Impact Assessment under Article 27, which requires a deployer to be able to trace how decisions were made.

Article 13(3) also covers the system's expected operational lifetime and the computational and hardware resources required for operation and maintenance. These are less prominent but matter for deployers making multi-year procurement decisions: a system that becomes technically unsupported within two years, or that requires hardware infrastructure the deployer cannot maintain, creates compliance risk that should be disclosed before the contract is signed.

One aspect of the Article 13(3) performance disclosure that often gets under-specified is the cybersecurity dimension. Article 15 sets out the obligations for accuracy, robustness, and cybersecurity — and Article 13(3) requires the provider to report on those properties. For cybersecurity, this means the provider must disclose what model-level threat assessment has been conducted: whether the system has been tested against adversarial input manipulation, whether it is resilient to data poisoning at inference time, and what access controls govern who can query the system. Providers who have never run model-level security testing cannot credibly claim Article 15 compliance, which means they also cannot credibly populate the Article 13(3) cybersecurity disclosure. The two obligations are linked.

The equity dimension of the performance disclosure deserves particular attention because it is the area most likely to attract enforcement attention in high-profile sectors. In employment AI, law enforcement AI, and credit-scoring AI, the performance variation across demographic groups is not just a technical metric — it is directly relevant to the deployer's obligations under the EU Charter of Fundamental Rights and, in many member states, national anti-discrimination law. A provider who withholds that data — or who has not produced it — is effectively preventing the deployer from meeting their own legal obligations. That is a significant exposure, not a minor gap.

---

Article 13 vs. Article 50: Two Different Transparency Obligations

These two articles are frequently conflated. They address different obligations directed at different audiences, and satisfying one does not discharge the other.

Article 13 applies to high-risk AI systems and is directed at the professional deployer — the organisation that will integrate, operate, and be responsible for the system in their context. The deployer is assumed to be a sophisticated commercial or public-sector actor. The transparency obligation is about giving them the technical and operational information they need to deploy responsibly. The obligation rests with the provider and must be met before deployment begins. Its output is a set of instructions for use: detailed, technical, operational.

Article 50 applies to limited-risk AI systems and to specific interactions where end users or affected natural persons need to know they are interacting with AI. It requires disclosure to the people who interact with an AI system, or who are affected by its outputs, that they are dealing with an AI. A chatbot must disclose it is not human. AI-generated audio or video must be labelled. Systems that detect or categorise natural persons based on emotional states must inform those persons. Article 50 applies generally from 2 August 2026 — it was not deferred by the Digital Omnibus.

The two obligations operate at different layers of the deployment stack. Article 13 runs from provider to deployer: it is a B2B information obligation about the system itself. Article 50 runs from the deployer (or provider, in direct-to-consumer deployments) to the end user: it is a consumer-facing disclosure about the AI nature of the interaction or output. The audience, content, and legal purpose are entirely distinct.

A high-risk system may carry both sets of obligations. A high-risk credit-scoring system that communicates outcomes to loan applicants through an automated interface must satisfy Article 13 (instructions to the lender deploying it) and may also have Article 50 disclosure duties toward the applicants. But conflating the two obligations creates real compliance gaps: a provider who issues a detailed technical datasheet to the lender has not done anything to meet the applicant's right to know they are subject to automated processing. And a lender who displays an "AI decision support" label in the application interface has not done anything to meet their Article 26 obligation to actually use the Article 13 information they received.

Another common conflation: treating Article 13 as the "transparency article" for GPAI models. It is not. GPAI provider obligations are governed by Articles 53 and 55. Article 13 applies to the high-risk AI system placed on the market — which may use a GPAI model as a component — but the Article 13 obligation rests with the provider of the high-risk system, not the GPAI model developer.

---

Article 13 and Article 14: Information and Oversight as a Pair

Article 13 and Article 14 are complementary but govern different things. Getting the distinction right matters because they require different compliance work.

Article 13 is an information obligation. It runs from provider to deployer, before the system is in use. Its output is documentation — the instructions for use. The obligation is discharged at the point of supply, though it must be updated when the system changes.

Article 14 is a design and operational obligation. It requires that high-risk systems be built so that the humans overseeing them can correctly interpret outputs, detect failures, decide not to use the output in a given situation, and intervene or override when necessary. Article 14 also requires that the oversight function be assigned to identifiable natural persons with the necessary competence, authority, and means. The system must be designed to allow this — it is not enough to tell people they can override if the system provides no mechanism for doing so.

The connection is explicit in Article 13(3): the instructions for use must describe the measures in place to help deployers interpret outputs and support the Article 14 oversight function. In other words, Article 13 documentation must operationalise Article 14 for the deployer's specific context. A provider who delivers performance metrics without explaining when and how a human should exercise judgment over the system's output has addressed Article 13(3)(a) but not Article 13(3)(b).

The practical test: are the deployer's oversight personnel told who is responsible, under what conditions, what information to use, and how to act? If the answer to any of those is "they would have to figure that out themselves," the Article 13 documentation is incomplete.

A worked example makes the distinction concrete. A fintech company deploying a credit-scoring model for consumer loan decisions must:

• Under Article 13: supply the lender's compliance and operations team with a datasheet covering the model's input variables, default-prediction accuracy by borrower cohort, known underperformance on self-employed applicants, and the procedure for a credit officer to override a rejected application.
• Under Article 14: design the system so that the credit officer can see the score, the inputs that drove it, and a flag when the applicant falls into a population where the model has known lower accuracy — and so that the override decision is recorded.

The Article 13 documentation describes the Article 14 mechanism. The Article 14 mechanism makes the Article 13 disclosure meaningful in practice. A provider who ships a detailed datasheet but a system that provides no visibility into its reasoning has satisfied the letter of Article 13 and violated the substance of Article 14. A provider who builds the oversight tools but ships no documentation has done the reverse. Both situations produce a non-compliant deployment.

A second distinction matters for deployers: Article 13 documentation does not substitute for the deployer's own Article 26 analysis. The deployer must assess whether the provider's instructions for use are actually adequate for their specific deployment context. A hospital deploying a diagnostic AI receives a provider's datasheet validated on one imaging system type. If the hospital uses a different type, the instructions are not automatically adequate — the hospital must either obtain supplementary information or restrict use to the validated scope. The deployer's due diligence is not discharged by receipt of the documentation.

---

High-Risk Classification and the Article 6(3) Filter

Article 13 applies only to high-risk AI systems as defined under Article 6 and Annex III. Before doing any Article 13 work, confirm the classification. A provider who prepares instructions for use for a system that turns out not to be high-risk has wasted effort; a provider who skips Article 13 on the assumption the system is not high-risk without documenting that assessment has created enforcement exposure.

The eight Annex III categories are: biometrics (remote biometric identification, biometric categorisation, emotion recognition); critical infrastructure (safety components in digital infrastructure, road traffic, and utilities); education and vocational training; employment and worker management (recruitment, screening, promotion, termination, task allocation, monitoring); access to essential private and public services (creditworthiness scoring, health and life insurance risk assessment, emergency service dispatch, public benefits eligibility); law enforcement; migration, asylum, and border control; and administration of justice and democratic processes.

Being in an Annex III category does not automatically mean the system is high-risk. Article 6(3) provides a genuine exemption: a system in an Annex III area is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights. Four scenarios can support this conclusion:

• The system performs a narrow procedural task — for example, a tool that formats job postings for publication, not one that ranks or filters applicants.
• The system improves the result of a previously completed human activity — for example, a spell-checker applied to a recruiter's written evaluation of a candidate, not a tool that produces that evaluation itself.
• The system detects decision patterns without influencing or replacing human assessment — for example, an analytics dashboard that shows a hiring manager their own historical decision patterns, without suggesting changes.
• The system performs preparatory work with no direct operational effect on the decision — for example, a document classifier that routes incoming CVs to the right inbox.

The Article 6(3) exemption has a hard limit: it does not apply to any system that profiles natural persons. Profiling — processing personal data to evaluate aspects of a person's performance, economic situation, health, preferences, or behaviour — is always high-risk. A system that scores or ranks people based on personal data characteristics does not qualify for the exemption, regardless of how it is positioned commercially.

Providers claiming the Article 6(3) exemption must document the assessment in writing and register the conclusion. This documentation is the baseline defence in an enforcement inquiry. If the system is exempted and Article 13 therefore does not apply, the provider should still retain the reasoning, because a deployer or a market surveillance authority may ask for it.

If your system is genuinely limited-risk under Article 50 rather than high-risk under Article 6, Article 13 does not apply. The transparency obligations shift entirely: you owe disclosure to end users about the AI nature of the system, not a set of technical instructions to a professional deployer.

---

Supply-Chain Responsibilities

The primary obligation under Article 13 rests with the provider. A provider cannot satisfy Article 13 by pointing to a product website, by including a brief FAQ in a contract annex, or by assuming the deployer will work out what they need to know. The instructions for use must be actively supplied before deployment begins.

Deployers have corresponding obligations under Article 26. They must use the system in accordance with the instructions, apply the human oversight measures described in those instructions, and ensure that the personnel who operate the system have access to the Article 13 information. A deployer who receives compliant documentation from a provider but never routes it to the team operating the system has not met its Article 26 obligations. In practice, deployers should request Article 13 documentation during vendor due diligence — before contracting, not after onboarding.

Importers (Article 23) and distributors (Article 24) must pass Article 13 documentation downstream intact. They cannot modify or suppress the provider's disclosure. Where an importer brings a third-country provider's system into the EU market, both the importer's and the original provider's identity must appear in the instructions for use.

Authorised representatives (Article 22) are relevant where the provider is established outside the EU. The authorised representative must be named and their EU contact details included in the instructions for use. They carry compliance responsibilities on the provider's behalf within the EU.

Role shifts under Article 25 apply where a deployer modifies a high-risk system or substantially changes its intended purpose: that party assumes provider obligations for the modified system and must produce compliant instructions for use covering the modification. A company that takes a third-party AI system and integrates it with additional data sources or decision logic in a way that changes its risk profile cannot rely on the original provider's Article 13 documentation.

---

Sector Examples: What the Instructions for Use Look Like

Employment: resume-screening AI

A 40-person HR-tech company providing a resume-screening system to European employers must disclose: overall accuracy and accuracy disaggregated by gender, age group, and where training data allows, by ethnicity; the specific job categories or industries where the training dataset is thinnest; whether the system outputs a binary pass/fail or a ranked score and what score thresholds the provider recommends; the override mechanism available to hiring managers; and the process through which a filtered-out candidate can request human review. Stating a headline accuracy of 87% without demographic disaggregation does not meet Article 13(3). Performance variation across groups is mandatory content, not an optional transparency statement.

Credit and finance: credit-scoring model

A provider supplying an AI credit-scoring model to regional lenders must disclose: the input variables and their relative weight in the scoring outcome; default-prediction accuracy by loan segment and borrower cohort; known underperformance on populations underrepresented in training data (for example, self-employed applicants or recent migrants with limited credit history); and the mechanism through which the lender's credit officer can override the model's recommendation and what information they should consult when doing so. Article 13 and GDPR Article 22 intersect here: the instructions for use should describe the procedure through which a refused applicant can request human reconsideration, since the lender needs that information to meet its own obligations.

Law enforcement: facial recognition

A provider supplying remote biometric identification capability to law enforcement must disclose false match and false non-match rates under operational conditions — not laboratory benchmarks — disaggregated by age group and skin tone where that data exists; the minimum image quality threshold below which the system output should not be relied upon; whether the output is intended as an investigative lead requiring independent verification or as grounds for operational action; and the procedure for the deploying authority to report suspected false identifications to the provider for investigation. The instructions must be in the language of the deploying authority and reviewed before the system is put into operation.

Healthcare: diagnostic AI

A provider of a radiology AI that detects lung nodules must disclose: sensitivity and specificity under the specific conditions in which the system was validated (imaging equipment type, patient age range, nodule size threshold); the patient populations excluded from validation or where accuracy was not measured; whether the system is a screening aid where all outputs require radiologist review, or a decision-support tool where a negative output may be relied upon; and the process for clinical teams to report discrepancies between the system's output and the radiologist's finding. Article 13(3) requires disclosure of known and foreseeable failure circumstances. In a clinical context, "foreseeable failure circumstances" includes the patient populations where the model's behaviour is simply unknown, not just the ones where it has been shown to underperform.

Education: student assessment AI

A provider of an AI-based essay or examination scoring tool deployed in secondary schools must disclose: the evaluation methodology (what features the system uses to produce a score, at a level a classroom teacher can understand); the student cohorts and assessment types used in training and their geographic and socioeconomic diversity; accuracy limitations for specific student groups, particularly non-native speakers or students with learning disabilities; and the override mechanism through which the teacher retains final grading authority. Article 13(2) requires that instructions be comprehensible to the deployer — in this context, the deployer is likely a school administrator or teacher, not a machine learning engineer.

---

Step by Step: Building Your Instructions for Use

The following sequence gives a practical path from blank page to compliant documentation. It is not the only valid approach, but it addresses the gaps that most commonly cause problems.

Step 1: Confirm high-risk classification. Run the Annex III category check and apply the Article 6(3) filter. Document the conclusion with the reasoning. If the system is high-risk, proceed. If the Article 6(3) exemption applies, document why and register the assessment — but you are done with Article 13.

Step 2: Define the deployer audience. Who will receive the instructions? A large bank's risk management team requires different depth and framing than a 15-person HR consultancy. The same system may be deployed by multiple types of organisation. If that is the case, you may need deployer-type-specific versions, or a single document with clearly signposted sections for technical and non-technical readers. Article 13(2) requires the instructions to be comprehensible to the deployer — which means you need to know who that deployer is.

Step 3: Gather the performance data. Pull the performance metrics from the system's test documentation — accuracy, precision, recall, and any domain-specific metrics (false match rate for biometrics, AUROC for clinical diagnostics). Crucially, pull the demographic disaggregations. If those disaggregations were not run, run them before finalising the instructions. Article 13(3) requires disclosure of performance variations across specific persons or groups. If you cannot produce that data, you have a testing gap, not just a documentation gap.

Step 4: Document the failure modes. List the circumstances in which the system has been observed to perform below its headline metric, and the circumstances in which degraded performance is foreseeable even if not yet observed. This includes: input data quality below a specified threshold; deployment populations that differ from the training population; temporal drift (the system was trained on data from a period that no longer reflects current conditions); and adversarial inputs. For each failure mode, describe what the deployer should do — escalate, override, suspend use of the output.

Step 5: Write the oversight section. This is where most documentation falls short. Do not just state that "human oversight is required." State who (by role), under what conditions (output confidence below X, decision above threshold Y, affected person in a protected class), how (the override procedure step by step), and what information the oversight person should consult in making their judgment. This section operationalises Article 14 for the deployer's context. It should be written as operational guidance, not regulatory compliance prose.

Step 6: Describe logging and reporting. Specify what the system logs, at what granularity, with what retention period, and in what format. Describe how the deployer accesses the logs. Provide the contact and procedure for incident reporting. State what constitutes a reportable incident under the provider's own policy, and where the threshold for Article 73 serious incident reporting might be crossed (even if the deployer, not the provider, typically bears the initial reporting obligation).

Step 7: Deliver, version, and record. Issue the instructions before the system is deployed. Record the delivery: date, recipient, version number, and method. If you update the instructions, re-issue to all active deployers and update the delivery record. Keep this log for the system's full operational lifetime.

Documentation Format and Length

There is no prescribed format for instructions for use under Article 13. The content requirements are defined; the format is not. In practice, most providers use a system card structured around the Article 13(3) categories, a technical datasheet that accompanies the procurement contract, or a disclosure document embedded within the system interface. All three can work. All three need to be versioned, delivered in a way that creates an audit trail, and available in the language of the deploying organisation.

Keep the document proportionate. For most high-risk AI systems, a working datasheet of 10–20 pages with annexes available on request satisfies "concise" without sacrificing "complete." A document no one reads because it is 300 pages satisfies neither.

Update the instructions when the system undergoes a substantial modification under Article 3(23) — changes to training data, model architecture, intended purpose, or risk profile that materially affect performance. Article 43(4) requires re-assessment and re-issuance of conformity documentation after substantial modification; the instructions for use are part of that package. Maintain version control and document when each version was issued and to whom.

---

Common Compliance Gaps

Audit readiness assessments for Article 13 repeatedly surface the same six findings.

Performance claims that match the marketing brief, not the system. The instructions for use restate the commercial pitch — high accuracy, broad applicability, fast inference — without the caveats Article 13(3) requires. Known failure modes and performance gaps across demographic groups are the hardest information for a provider to include and the first thing an enforcement authority will look for.

Technical disclosure that is inaccessible to the deployer. F1 score 0.87, AUC-ROC 0.92, precision-recall trade-off at threshold 0.65. These figures may be technically correct but are operationally meaningless to a loan officer, a school administrator, or a public authority procurement manager. Article 13(2) requires comprehensibility. The instructions must translate technical performance into actionable guidance: when to escalate, when to override, what a score in a given range means in practice.

Static documentation with no update process. Providers issue instructions for use once at product launch and treat them as permanent. Article 13(3) requires disclosure of known and foreseeable failures; "known" is a category that expands as the system is used in the field. Build a review cycle into your post-market monitoring process (Article 72), and establish a documented trigger for re-issuing instructions when performance data changes materially.

Disclosure buried in contractual boilerplate. Instructions for use embedded in a 60-page master service agreement are not "accessible" or "comprehensible" under Article 13(2). A deployer should be able to locate and read the Article 13 content without legal assistance. A separate disclosure document — or a clearly labelled section with a direct link — is the practical standard.

Language mismatch. A high-risk AI system deployed in Germany, Poland, or Spain must have instructions for use in a language the deployer's team reads. There is no explicit language prescription in Article 13(2), but the accessibility and comprehensibility requirements are not satisfied by documentation in a language the deployer does not use.

No audit trail of delivery. Providers cannot demonstrate compliance if they cannot show when the instructions were provided, to whom, in what version, and in what format. An email thread from two years ago without a version number or a delivery confirmation is not a defensible record. Create a disclosure log: date, recipient, version, delivery method, and any confirmation of receipt. Maintain it through the system's operational lifetime.

---

Enforcement Timeline and Penalties

Under the Digital Omnibus agreed in May 2026, the Article 13 obligation for stand-alone high-risk Annex III systems applies from 2 December 2027. For high-risk AI systems that are safety components of Annex I products — medical devices, machinery, aviation equipment, and similar regulated products — the date is 2 August 2028.

Two December 2027 is not as distant as it sounds for providers who have not started. The instructions for use require input from the teams that built the system (for performance data and training data characteristics), the teams that tested it (for failure modes and demographic performance gaps), and the teams responsible for deployment and support (for the oversight procedures and escalation paths). Those teams rarely work from the same documents. Coordination takes time. Providers who wait until late 2027 to start will produce documentation in a hurry; rushed Article 13 documentation is exactly what enforcement authorities look for.

Enforcement sits with national market surveillance authorities and, for systemic issues, with the European AI Office. Non-compliance with Article 13 carries fines of up to €15,000,000 or 3% of worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)). For smaller companies, Article 99(6) caps fines at the lower of the percentage and fixed-amount threshold — a proportionality mechanism, not a get-out.

Practical enforcement triggers will include: deployer complaints about systems whose outputs they could not interpret; incident reports under Article 73 that expose inadequate pre-deployment disclosure; and market surveillance inspections following serious incidents in healthcare, law enforcement, or financial services. Missing or incomplete instructions for use are an easy finding in an inspection — they are either present or they are not.

---

How Confir Supports Article 13 Compliance

Article 13 sits within Confir's AITO (Transparency & Human Oversight) compliance area, alongside Article 14 (human oversight design) and Article 27 (Fundamental Rights Impact Assessment). When you register a high-risk system through Confir's Guided Intake, the rule-based classification engine scopes Article 13 automatically and surfaces the relevant obligations within your compliance dashboard.

The AITO-01 control (Transparency & Explainability) structures the Article 13(3) content as a checklist, mapping each required element — provider identity, intended purpose, performance metrics, foreseeable failure modes, input data specifications, human oversight measures, logging mechanisms — to the corresponding Article 13 sub-paragraph. Each checklist item links to the Guided Intake answers already captured for the system, reducing rework. Completed responses feed into the Conformity Package, which includes a pre-structured instructions-for-use template built around the mandatory content categories. The Datasheet PDF export produces a versioned, timestamped disclosure document ready for vendor questionnaires and regulatory submissions.

The immutable audit log records when each disclosure element was completed, by whom, and against which version of the system record. When a registered system is flagged for substantial modification, Confir triggers a re-assessment task linked to Article 13 and Article 43(4), ensuring the instructions for use stay current through the system's operational lifetime.

---

Pending Developments to Watch

Article 13 as written in Regulation (EU) 2024/1689 is the operative text. The Digital Omnibus defers the high-risk deadline but does not alter the substantive obligations. Two developments in the period to 2027 are worth monitoring.

The Commission's standardisation mandate under Article 40 may produce harmonised standards for instructions for use in specific high-risk sectors — healthcare AI, financial services AI, and employment AI are the most likely candidates. Compliance with an adopted harmonised standard will create a presumption of conformity with Article 13. As of June 2026, no such standard has been adopted. Providers in those sectors should track CEN/CENELEC and ISO/IEC 42001 developments, as sector-specific guidance is likely to emerge before the December 2027 deadline.

The European AI Office is developing a model transparency notice framework for voluntary use by GPAI providers, which may also inform what national market surveillance authorities consider adequate disclosure for Article 13 purposes. Providers in high-risk sectors who want early signal on enforcement expectations should monitor that work and the AI Office's guidance publications as they emerge.

---

Related guides

• EU AI Act Article 26: Deployer Obligations & Compl
• high-risk AI system definitions
• EU AI Act compliance requirements
• Article 14 human oversight requirements
• Article 16 provider obligations