August 2:
what attaches for deployers
On 2 August 2026, EU AI Act Article 26 deployer obligations come into force for every high risk AI system. Article 27 FRIA gets the headlines, but Article 26 is the universal trigger. Here’s the practical breakdown of all twelve deployer obligations, what each requires in operational terms, and how national workforce rules layer on top.
The one thing to understand
Article 27 FRIA scope is narrow (public bodies, public service providers, credit/insurance deployers). Article 26 is universal: every Annex III high risk AI system deployer is subject to it from 2 August 2026, regardless of public/private status or sector. If you only read one part of the EU AI Act before August 2, read Article 26.
What Article 26 actually is
Article 27 Fundamental Rights Impact Assessment scope is narrow. It attaches to public bodies, private entities providing public services, and deployers of creditworthiness or insurance pricing AI. (We covered the precise scope and what fills the gap in Article 27 FRIA: who it actually applies to.)
Article 26 is different. It applies to every deployer of a high risk AI system. Every deployer means every natural or legal person using a high risk system under their authority in the course of professional activity. Public body or private company, in-house or via SaaS, transport or e-commerce, the obligations apply.
Article 26 is twelve paragraphs of obligations. Some operational. Some procedural. Some narrow. This article unpacks all twelve, grouped by what they actually require you to do.
Who is a deployer
The Regulation distinguishes two main roles along the AI value chain: provider and deployer.
A provider places an AI system on the market or puts it into service under its own name or trademark, whether free of charge or for payment. OpenAI is a provider of GPT-4. Microsoft is a provider of Copilot.
A deployeris “a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity” (Article 3(4) definition). A law firm using Copilot to draft contract first drafts is a deployer. A hospital using a radiology classifier is a deployer. A ride hailing platform using driver allocation AI is a deployer.
One organisation can be both. If you take a provider’s high risk system and substantially modify it (within the meaning of Article 25(1)(b)), you become a provider of the modified system and inherit provider obligations on top of deployer ones.
The operational five
Paragraphs 1, 2, 4, 5, and 6 are the operational core: how you actually use the system day to day.
Use per instructions for use
Deployers shall take appropriate technical and organisational measures to ensure they use the high risk AI system in accordance with the instructions for use accompanying the system. In practical terms, the provider’s instructions for use bind your operational practice. If the instructions say the system is validated only for adult subjects, you cannot deploy on minors. If they specify input data ranges, your pipeline must respect them. The instructions become enforceable as a matter of compliance, not just provider liability.
Human oversight by competent persons
Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Three concrete elements: competence (do they understand the system’s outputs and limitations), training (have they been trained on the specific high risk system), and authority (can they actually override the system or escalate). Oversight by a person who lacks any of these three is not Article 26 compliant.
Input data relevance
To the extent the deployer controls the input data, the deployer must ensure that input data is relevant and sufficiently representative in view of the intended purpose. This is conditional: in many SaaS deployments the input pipeline is provider-controlled. Where you do control inputs (e.g., uploading your customer dataset to a credit scoring AI), the obligation lands on you.
Monitor and notify
Deployers must monitor operation of the high risk AI system based on the instructions for use and, where relevant, inform providers of risks observed in operation. Where a deployer identifies a risk to health, safety, or fundamental rights, the deployer must notify the provider or distributor and the relevant market surveillance authority without delay and suspend use. Serious incidents trigger an immediate provider notification, followed by distributor and authority notification.
Log retention for at least six months
Deployers must keep the logs automatically generated by the high risk AI system, to the extent the logs are under the deployer’s control, for a period appropriate to the intended purpose, of at least six months, unless provided otherwise in applicable Union or national law. The "at least" floor is important: longer retention may be required under sector rules or by the provider’s instructions.
The transparency two
Paragraphs 7 and 11 are the human-facing transparency obligations.
Worker notification before workplace deployment
Before putting into service or using a high risk AI system at the workplace, employer-deployers must inform workers’ representatives and the affected workers that they will be subject to the use of the system. This obligation is independent of the consultation rights that flow through national workforce law (e.g., Germany’s BetrVG, Spain’s Ley Rider). Even where no national workforce regime applies, Article 26(7) requires the notification.
Individual notification before AI decisions
Deployers of high risk AI systems referred to in Annex III that make decisions or assist in making decisions related to natural persons must inform those persons that they are subject to the use of the high risk AI system. This is broader than Paragraph 7 because it covers any individual affected by an AI-supported decision, not only workers.
Together, paragraphs 7 and 11 create a two-layer transparency stack: workers when AI is used in the workplace, and any affected individual when AI is used to make decisions about them. Both layers run independently of any GDPR transparency obligations (Articles 13, 14 GDPR), although the documentation can often be combined.
The compliance interfaces
Paragraphs 9 and 12 govern how Article 26 interacts with other rules.
DPIA coordination
Deployers shall use the information provided under Article 13 of the AI Act (provider transparency obligation) to comply with their obligation to carry out a data protection impact assessment under Article 35 of the GDPR or Article 27 of the Law Enforcement Directive (Directive 2016/680), where applicable. Practical translation: when you do your GDPR DPIA for a high risk AI system, the provider’s Article 13 instructions for use document is a required input.
Cooperation with competent authorities
Deployers shall cooperate with competent authorities in any action those authorities take in relation to the high risk AI system to implement the AI Act. In practice, this means responding to information requests, providing logs and instructions for use, and supporting inspections.
The narrower obligations
Paragraphs 8 and 10 are scope-specific.
Public authority registration
Public authorities (and Union institutions, bodies, offices, and agencies) using a high risk AI system must register that use in the EU database referred to in Article 71, and must not use a system that is not registered in that database. Private commercial deployers are not subject to the registration obligation under paragraph 8.
Biometric identification in criminal investigations
Deployers using a high risk AI system for post-remote biometric identification in the context of investigating targeted searches must request authorisation by a judicial or administrative authority prior to use (or within 48 hours after the start of use, in limited circumstances). Usage must be limited to specific listed offences, documented, and reported annually. Highly relevant to law enforcement deployers, less relevant to most commercial AI use.
The savings clause
Paragraph 3is a procedural clarifier rather than a substantive obligation. The obligations in paragraphs 1 (instructions for use compliance) and 2 (human oversight) do not exclude other obligations under Union or Member State law and shall not affect the deployer’s freedom to organise its own resources and activities for the purpose of implementing the human oversight measures indicated by the provider.
In practical terms: Article 26 is a floor, not a ceiling. Other rules can layer on top. And the way you implement human oversight in particular is for you to organise, provided the substance meets the Article 26(2) competence/training/authority requirements.
How national rules layer
Article 26 sets the floor. Member State workforce law, sector regulation, and other Union instruments can impose additional obligations that operate alongside it.
Spain’s Ley Rider(Royal Decree-Law 9/2021, amending Article 64.4(d) of the Workers’ Statute) requires platforms to inform worker representatives of the parameters, rules, and instructions on which algorithms or AI systems are based when they influence working conditions, access to or maintenance of employment, and profiling. The Ley Rider obligation overlaps with Article 26(7) on worker notification but goes further on substantive content (parameters and rules, not just notification of use).
Germany’s Works Constitution Act (BetrVG)gives works councils co-determination rights over technical equipment intended to monitor employee behaviour or performance under § 87(1)(6). The Federal Labour Court has interpreted this broadly enough to cover AI based monitoring. The 2021 Works Council Modernization Act (Betriebsrätemodernisierungsgesetz) added explicit AI provisions at § 80(3) (expert consultation), § 90(1) (planning information), and § 95(2a) (AI in personnel selection guidelines). Co-determination obligations under BetrVG go further than Article 26(7) on procedural rights.
The Platform Work Directive (Directive (EU) 2024/2831, transposition deadline 2 December 2026) will harmonise much of the platform-specific workforce regime across the EU. It introduces a presumption of employment for platform workers and mandatory transparency obligations for algorithmic management. Once transposed, the Directive will overlap substantially with both Article 26 deployer obligations and Article 27 FRIA (for those it applies to).
The implication for a deployer running workforce AI in multiple Member States: Article 26 is the universal baseline, but national workforce rules and the Platform Work Directive transposition add layers that vary by jurisdiction. The compliance work is to identify the union of obligations across your operating footprint, not just the Article 26 baseline.
Practical implementation before August 2
The deliverable structure for an Article 26 readiness programme.
Inventory
Identify every Annex III high risk AI system your organisation deploys. Without an inventory, the rest of the work is undefined.
Instructions for use binder
Collect the provider’s Article 13 instructions for use document for each high risk system. Confirm it is current. Map operational constraints (validated input ranges, intended purpose, monitoring directions) into your operational procedures.
Human oversight assignment
Assign a named natural person to each high risk system as the Article 26(2) oversight contact. Document their competence, training, and authority. Authority specifically means they can override or suspend system use, not just receive escalations.
Input data pipeline review
Where you control the input data, document how relevance and representativeness are maintained. This may involve sampling, data validation, or dataset documentation depending on the system.
Monitoring and notification process
Stand up a process for monitoring system operation, identifying risks, and notifying providers and market surveillance authorities. This is operational, not just policy. The notification path needs to actually work in practice.
Log retention configuration
Confirm automatic log generation is enabled and that retention is set to at least six months. Check sector rules for longer floors where applicable.
Worker and individual notification stack
Draft and deploy the Article 26(7) worker notification and the Article 26(11) individual notification. These can often be combined with existing GDPR Article 13/14 transparency notices.
DPIA refresh
Update existing GDPR DPIAs for high risk AI systems to incorporate provider Article 13 information. Where Article 27 FRIA also applies, document how the FRIA complements the DPIA under Article 27(3).
Each item is a discrete artefact your supervisory authority can ask you to produce after 2 August.
What FRIA adds for those it applies to
For the subset of deployers in scope of Article 27 FRIA (public bodies, private entities providing public services, deployers of creditworthiness or insurance pricing AI), the FRIA layers on top of Article 26 with six structured inputs and a notification to the market surveillance authority. The Article 27 FRIA scope guide covers who’s in, who’s out, and the working template. For everyone else, Article 26 alone is the operational target for 2 August.
Get the Article 26 readiness analysis for your AI systems
ActComply runs the Article 26 deployer classification analysis end to end. Send us one AI surface and we return Annex III categorisation, the specific paragraphs that attach, mapping to your existing DPIA and oversight documentation, and a practical implementation checklist tailored to your operating jurisdictions.
Assess your AI systems free →No credit card required
Related guides
More EU AI Act compliance pieces from ActComply.
EU AI Act Compliance Checklist
All 27 obligations across high risk, limited risk, general provider, and GPAI categories.
EU AI Act Risk Classification
Walk through the four risk tiers and how to classify your AI system.
High Risk AI Systems
Annex III categories and what counts as high risk under the AI Act.
Omnibus Update
How the May 2026 provisional agreement shifts high risk deadlines, and what stays unchanged.
Article 27 FRIA Scope
Who the Fundamental Rights Impact Assessment actually applies to, and what fills the gap when it doesn't.
Article 27 FRIA Template
Working one page template covering the six Article 27(1) inputs, with PDF download.
Article 50 Transparency Obligations
Provider and deployer obligations across chatbots, generative content, emotion recognition, and deep fakes.
Article 25(1)(b) Substantial Modification
When a deployer becomes a provider through substantial modification, and what crossing the line costs.
GPAI Provider Obligations
Article 53 + 55 obligations for general purpose AI model providers, plus the 10 July 2025 Code of Practice.