Article 26 of the EU AI Act sets out the obligations of deployers of high-risk AI systems. If your organisation uses a high-risk AI system in the course of its business — for example, an AI system that screens job applicants, evaluates creditworthiness, triages patients, or monitors employee performance — Article 26 applies to you directly, regardless of whether you built the system or bought it from a vendor. With the high-risk obligations for Annex III systems taking effect on 2 August 2026 (and 2 August 2027 for AI embedded in regulated products under Annex I), deployers now face a hard compliance deadline that many small and mid-sized enterprises have not yet prepared for. This article explains what Article 26 requires, why it matters, what practical steps deployers should take, and where organisations most often go wrong.
What Article 26 Actually Requires
Also worth reading: How Should B2B SaaS Companies Build a Renewal Strategy That Drives Growth? · How Should B2B SaaS Companies Price Software by Customer Value in 2026? · How Should Companies Train Employees on Responsible AI in 2026?
Article 26 contains ten distinct obligations for deployers of high-risk AI systems. First, deployers must use the system in accordance with the instructions for use provided by the provider (Article 26(1)). This sounds trivial, but it is the anchor obligation: if you deviate from the instructions, you may inadvertently take on provider-level obligations under Article 25, including the full conformity assessment regime. Second, deployers must ensure that a natural person with the necessary competence, training, and authority performs human oversight of the system (Article 26(2)). This is not a paper exercise — the overseer must genuinely be able to intervene, disregard, or reverse the AI system's output.
Third, where input data is relevant to the system's operation, deployers are responsible for ensuring that input data is relevant and sufficiently representative in light of the intended purpose (Article 26(4)). Fourth, deployers must monitor the system's operation based on the instructions and inform the provider or distributor of risks and serious incidents without undue delay (Article 26(5)). Fifth, deployers of systems that fall under specific EU worker-protection and safety legislation must keep logs automatically generated by the system for at least six months, unless other EU or national law requires longer retention (Article 26(6)). Sixth, deployers must complete a data protection impact assessment (DPIA) under Article 35 of the GDPR before first using a high-risk AI system, and consult the supervisory authority where required (Article 26(9)).
The Transparency and Information Duties
Beyond operational controls, Article 26 imposes information duties that catch many organisations off guard. Deployers of high-risk AI systems used in the workplace must inform workers' representatives and the affected workers before putting the system into service (Article 26(7)). This interacts with national labour law and works council regimes in Germany, France, the Netherlands, and other member states, so the practical mechanics vary considerably across the EU. Separately, deployers of systems that make or assist in decisions affecting natural persons must inform the individuals that they are subject to the use of a high-risk AI system (Article 26(11)), and must explain the role of the system in the decision-making procedure and the logic involved.
Deployers also carry a duty of cooperation: they must cooperate with competent authorities by providing, on request, documentation and logs necessary to demonstrate compliance (Article 26(8)). Public authorities and private entities providing public services that deploy high-risk AI systems must additionally register the system in the EU database established under Article 71 (Article 26(10)). Deployers of certain systems — including emotion recognition and biometric categorisation systems — must inform exposed persons of the operation of the system, a point that has drawn particular attention from privacy practitioners given the sensitivity of these technologies.
Who Counts as a Deployer (and Why the Definition Matters)
The AI Act defines a deployer as any natural or legal person using an AI system under their authority, except where the system is used in the course of a personal, non-professional activity. The definition is deliberately broad. A bank using a vendor's credit-scoring model is a deployer. A hospital using a diagnostic triage tool is a deployer. A staffing agency using an automated CV-screening product is a deployer. Even a company that merely integrates a high-risk AI component into its own workflow can become a deployer, and in some cases a deployer that substantially modifies a system, changes its intended purpose, or puts its name on it can be reclassified as a provider under Article 25.
This reclassification risk is one of the most underappreciated aspects of Article 26. If your organisation repurposes a general-purpose AI system for a high-risk use case, or makes a substantial modification to an existing high-risk system, you assume provider obligations: risk management under Article 9, data governance under Article 10, technical documentation under Article 11, logging, transparency, human oversight design, accuracy and robustness testing, and the conformity assessment procedure itself. Deployers should therefore document their intended use and any configuration decisions carefully, because the boundary between deploying and providing is determined by facts, not by contract labels.
Deployer vs Provider vs Distributor: A Comparison
Understanding where your organisation sits in the AI value chain determines which obligations apply. The table below summarises the core differences.
| Feature | Provider | Deployer | Distributor/Importer |
|---|---|---|---|
| Core role | Develops or markets the AI system under its own name | Uses the AI system under its authority in a professional context | Makes the system available on the EU market without modifying it |
| Key obligations | Risk management, data governance, technical documentation, conformity assessment, CE marking, registration | Use per instructions, human oversight, input data quality, monitoring, logging, DPIA, worker/individual information | Verify conformity marking and documentation, storage and transport conditions |
| Primary regulation | Articles 16–27 | Article 26 | Articles 23–24 |
| Liability exposure | Highest — defects in design and documentation | High — misuse, oversight failures, input data errors | Moderate — mainly verification failures |
| Can become provider? | Already is | Yes, under Article 25 if repurposing or substantially modifying | Yes, if it modifies the system or fails to identify the provider |
| Typical examples | AI vendor selling CV-screening software | Employer using that software on candidates | Reseller or distributor of the software |
Practical Steps Deployers Should Take Now
The first step is building a complete AI inventory. Many organisations discover during compliance reviews that they have more high-risk AI systems in use than management assumed — embedded in HR platforms, procurement tools, customer-service software, or financial systems purchased years ago. Each system should be mapped against the Annex III categories: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice and democratic processes.
The second step is gap assessment against each Article 26 obligation. For human oversight, this means identifying named individuals, defining their competence and training, and documenting their authority to intervene. For input data quality, it means establishing who validates the data feeding the system and how representativeness is checked. For logging, it means confirming that the system's automatic logging is switched on and that retention of at least six months is configured for systems within the scope of the relevant workplace and product-safety directives. For DPIAs, it means integrating the AI Act assessment into existing GDPR processes rather than running two disconnected exercises.
The third step is vendor management. Deployers should obtain and file the provider's instructions for use, declaration of conformity, and technical documentation summaries, and should negotiate contractual commitments on incident notification, updates, and cooperation with authorities. The fourth step is training. Article 4 of the AI Act — the AI literacy obligation, applicable since 2 February 2025 — requires providers and deployers to ensure a sufficient level of AI literacy among staff who operate AI systems on their behalf. Regulators are expected to treat documented training programmes as evidence of a functioning compliance culture, and employer L&D teams are the natural owners of this workstream.
Common Mistakes and Evidence Gaps
Compliance practitioners reporting on the run-up to the August 2026 deadline consistently identify the same evidence gaps, particularly among SMEs. The most common is the absence of documented human oversight arrangements: organisations assume that having a human 'in the loop' satisfies Article 26(2), but the provision requires competence, training, and authority, and regulators will ask for records proving all three. The second is missing DPIAs — many deployers have never run a GDPR Article 35 assessment for their AI tools, and Article 26(9) makes this mandatory before first use. The third is the failure to inform workers and their representatives, which in several member states can also trigger collective labour law consequences independent of the AI Act.
Other frequent errors include treating the six-month log retention rule as optional, ignoring the input-data representativeness duty because 'the vendor handles the data', and assuming that buying from a reputable provider transfers compliance. None of these assumptions survives contact with an audit. Deployers should also be wary of the interaction with national laws: several member states have designated or are designating market surveillance authorities and notified bodies, and national labour codes may impose additional consultation duties. Finally, deployers outside the EU should note that Article 26 applies extraterritorially where the output of the system is used in the EU — US companies face the same August 2026 obligations if their AI systems affect people in the Union.
Timeline and When to Act
The AI Act entered into force on 1 August 2024, and its obligations phase in over several years. The prohibitions and AI literacy duty applied from 2 February 2025. Governance rules and obligations for general-purpose AI models applied from 2 August 2025. The high-risk regime for Annex III systems — which covers most deployer obligations under Article 26 — applies from 2 August 2026. High-risk AI systems that are safety components of products subject to third-party conformity assessment under Annex I have until 2 August 2027. Penalties scale with the violation: up to EUR 35 million or 7% of global annual turnover for prohibited practices, up to EUR 15 million or 3% for most other obligations including deployer breaches, and up to EUR 7.5 million or 1% for supplying incorrect information.
Given that date context is August 2026, the deadline for Annex III systems is effectively now. Organisations that have not started should prioritise an inventory and gap assessment immediately, because DPIAs, worker consultations, and works council negotiations each take weeks to months. Deployers of Annex I product-embedded systems have a further year, but procurement lead times and vendor readiness mean preparation should still begin in 2026. Waiting for national implementing guidance is a risky strategy: the Regulation is directly applicable, and authorities can enforce from the application date without waiting for national transposition.
Costs, Resourcing, and Building Internal Capability
The cost of Article 26 compliance varies with the number and complexity of high-risk systems in use. For a mid-sized enterprise with a handful of systems, the main costs are internal: legal and privacy review, DPIA work, oversight training, and documentation. External support — specialist counsel, conformity consultants, or compliance tooling — typically ranges from tens of thousands of euros for a focused gap assessment to six figures for multi-system programmes with worker consultation across several jurisdictions. These figures are indicative; the dominant cost driver is usually staff time rather than fees.
A frequently underestimated line item is training. Article 4's AI literacy duty and Article 26(2)'s oversight competence requirement together mean that every employee who operates or supervises a high-risk AI system needs role-appropriate training, refreshed as systems change. For employer L&D teams, this is a concrete, budgetable programme: role-based curricula for overseers, awareness modules for the wider workforce, and records that demonstrate completion. Professional institutes and academies that deliver structured AI governance training to L&D teams can compress the timeline considerably, because building curricula from scratch is slower than adapting accredited ones. The alternative — treating compliance as a one-off legal project — tends to fail at the first system update or personnel change, since Article 26 obligations are continuous, not point-in-time.
A Critical View: Where Article 26 Falls Short and Where It Bites
It is worth being candid about the Regulation's limitations. Article 26 places substantial duties on deployers while giving them limited visibility into the systems they buy: deployers must ensure input data quality and effective oversight, but they depend on providers for the technical documentation needed to do either well. The six-month logging rule is minimal and may not suffice for meaningful incident investigation. The boundary between deployer and provider duties will likely be litigated, since Article 25's reclassification triggers — 'substantial modification' and change of intended purpose — are not precisely quantified. Deployers should not assume that compliance is a matter of ticking ten boxes; it is an operating discipline that must survive vendor changes, model updates, and staff turnover.
At the same time, the obligations are not optional and enforcement is coming. Market surveillance authorities across member states are standing up AI enforcement teams, and the first supervisory actions against deployers are expected in the months following the August 2026 application date. Organisations that can produce an AI inventory, per-system Article 26 gap assessments, signed oversight protocols, completed DPIAs, worker notifications, and training records will be in a defensible position. Those that cannot will be negotiating with authorities from weakness, with penalty ceilings of EUR 15 million or 3% of global turnover as the backdrop. The window for orderly preparation has effectively closed for Annex III systems; the remaining question is whether deployers close their evidence gaps before an inspector, a works council, or an affected individual forces the issue.