EU AI Act Article 26: Obligations of Deployers of High-Risk AI Systems
Article 26 of the EU AI Act sets eight obligations for deployers of high-risk AI systems. Understand what applies from 2 December 2027 and what to do now.
Article 26 of Regulation (EU) 2024/1689 sets out what you must do once you put a high-risk AI system to work in your organisation. It does not matter whether you built the system or licensed it from a vendor: the moment you operate a system that falls under Annex III — say, an AI tool that screens job applications, scores creditworthiness, or allocates access to public benefits — Article 26 obligations apply to you directly.
Most companies in the EU are deployers rather than providers. That distinction matters. Providers build and place systems on the market; deployers use them. The obligations are different in character: providers face the heaviest pre-market engineering and documentation burdens; deployers face operational, governance, and monitoring duties that begin the day a system goes live. Neither set cancels out the other.
Under the Digital Omnibus agreed in May 2026, stand-alone high-risk AI systems (the Annex III list) must comply from 2 December 2027, extended from the original 2 August 2026 date. High-risk AI embedded in regulated products covered by EU product law (Annex I) follows on 2 August 2028. That is useful breathing room, not a reprieve: some of these obligations — particularly the Article 27 Fundamental Rights Impact Assessment and the worker-notification requirement — take more time to execute properly than organisations expect.
What Article 26 Actually Requires
Article 26 contains eight distinct obligations. They are not a checklist you tick once at deployment; most are ongoing.
1. Use the system according to the instructions for use (Article 13)
Article 26 requires you to operate the high-risk AI system in accordance with the instructions for use that the provider supplies under Article 13. Those instructions specify the system's intended purpose, the conditions under which it is reliable, any known limitations, and the human oversight measures the provider has built in.
Practically, this means your operational procedures must stay within the documented scope. If the instructions say the system is validated for candidates with at least a secondary-school qualification, you cannot deploy it for roles with different requirements and assume compliance carries over. Deviations from the instructions for use move legal exposure firmly onto you.
2. Assign human oversight to competent natural persons (Article 14)
You must assign the human oversight functions defined in Article 14 to natural persons who have the necessary competence, training, and authority — and who receive the support needed to exercise oversight effectively.
Three things need to be documented: that a named individual (or defined role) holds the oversight function; that this person has been trained on the system's capabilities, failure modes, and intervention procedures; and that they have genuine authority to halt, override, or escalate a decision without manager sign-off every time. Oversight on paper that cannot be exercised in practice is not oversight under the regulation.
Staff competence for AI systems is also addressed by Article 4 (AI literacy), in force since 2 February 2025. Article 4 is not about AI development; it requires organisations to ensure staff and anyone else operating AI systems have a sufficient understanding of those systems for their role. Document this separately from Article 26(b) training — they are related but distinct obligations.
3. Control the input data (where you control it)
Where you control the input data fed into the system, Article 26 requires you to ensure that data is relevant and sufficiently representative for the system's intended purpose. This applies in particular when you are not using the system's default or pre-set inputs, but supplying your own datasets — for instance, a regional lender feeding local customer records into a third-party credit-scoring model.
This is not an obligation to re-train the model. It is an obligation to verify that the data you supply matches the conditions under which the system was designed and validated. If your data differs substantially — geographically, demographically, temporally — document that assessment and the steps you took to address any gaps.
4. Monitor operation and report risks and incidents
You must monitor the operation of the high-risk AI system according to the provider's instructions for use, and keep track of whether it continues to perform as expected in your operational context.
Where you have reason to believe that use of the system presents a risk within the meaning of Article 79(1) — or where you identify a serious incident — you must take three steps without undue delay:
- Inform the provider or distributor.
- Inform the relevant market-surveillance authority (the national competent authority).
- Suspend use of the system where appropriate.
A serious incident under Article 73 means an incident that has or could have caused death, serious injury, or significant harm to health, safety, or fundamental rights. The obligation to inform the authority and suspend use is the part most deployers underestimate. It is not optional and is not conditional on completing an internal investigation first.
5. Keep the automatically generated logs for at least six months
Article 26 requires you to retain the automatically generated logs for at least six months, unless Union law or national law requires a longer period. Sector-specific rules commonly extend this: financial services regulations, for example, often require five to seven years of records.
Two points are worth stressing. First, this obligation covers the logs the system itself generates — not just the documents your compliance team writes. Second, "at least six months" is a floor, not a target. A deployer that cannot produce logs from the past six months during a market-surveillance inspection has no defence.
6. Inform workers' representatives and affected workers before workplace deployment
If you deploy a high-risk AI system in the workplace, Article 26 requires you to inform workers' representatives and the affected workers themselves that they will be subject to the system, before putting it into service. This applies to systems in Annex III category 4 (employment, workers management, access to self-employment) but also to any high-risk system deployed in a workplace context.
This obligation catches organisations by surprise. A logistics company deploying an AI system that monitors driver behaviour or allocates shifts must notify workers' representatives — typically the works council or equivalent body — and the workers in scope, before the system goes live. The notification requirement applies regardless of what labour law in your jurisdiction says about consultation rights; those rights may add additional procedural obligations on top.
7. Registration (for public authorities and EU bodies)
Where you are a public authority or an EU institution, body, office, or agency acting as deployer, Article 26 requires you to comply with the registration obligation in Article 49. This means the high-risk system must be registered in the EU database before you put it into service. Private-sector deployers do not bear this registration obligation directly, though providers registering their systems may include deployer-relevant information.
8. GDPR DPIA cross-reference
Where the processing of personal data makes a Data Protection Impact Assessment (DPIA) under the GDPR obligatory, Article 26 requires you to use the information provided by the provider under Article 13 when conducting that DPIA. This is a coordination obligation, not a duplication: you draw on the provider's documentation of data processing, risk analysis, and technical measures as inputs to your DPIA rather than starting from scratch. For systems in Annex III, a GDPR DPIA will frequently be mandatory given the sensitivity of the decisions involved.
When Deployers Become Providers: Article 25
One of the most consequential provisions for companies that customise or white-label third-party AI tools is Article 25, which governs responsibilities along the value chain.
A deployer becomes a provider — and takes on the full Article 16 provider obligations — in three situations:
- You put your name or trademark on the high-risk AI system and place it on the market or put it into service under your own name.
- You substantially modify the system (including its intended purpose).
- You modify the intended purpose of a high-risk AI system such that the system now falls under Annex III in a way the original provider did not intend.
The practical test is not whether you wrote the underlying code. A regional bank that takes a generic credit-scoring model, rebrands it as its own product, and deploys it to assess loan eligibility has become a provider for that use. A staffing agency that takes a CV-screening tool designed for tech roles and repurposes it for medical recruitment has substantially modified the intended purpose. In both cases, Article 25 shifts the full provider compliance stack — risk management system under Article 9, technical documentation under Article 11, conformity assessment under Article 43 — onto the party that made the modification.
If you are a SaaS company that builds workflows on top of third-party AI tools and sells the result to your own customers, check Article 25 carefully before assuming deployer status.
Article 27: The Fundamental Rights Impact Assessment
Article 27 creates a separate obligation for certain deployers to carry out a Fundamental Rights Impact Assessment (FRIA) before putting a high-risk AI system into service. This is not the same as a GDPR DPIA, though the two should be coordinated.
The FRIA requirement applies to:
- Public bodies deploying high-risk AI systems.
- Private operators providing public services (utilities, public transport operators, similar).
- Deployers of systems used for creditworthiness assessment or credit scoring (Annex III, category 5(b)).
- Deployers of systems used for life insurance and health insurance risk assessment and pricing (Annex III, category 5(c)).
The assessment must cover the categories of persons and groups likely to be affected, the specific risks to fundamental rights, the measures envisaged to address those risks, and the expected effects of the measures. It must be submitted to the relevant market-surveillance authority.
If your organisation falls into any of these categories — and many financial services companies, insurers, and public-sector organisations do — the FRIA is not optional and is not satisfied by a generic risk register entry. A 20-person credit union deploying an AI credit-scoring tool needs to conduct this assessment before the system goes live. The documentation must be substantive enough to withstand scrutiny.
Article 50: Transparency Obligations
Where a high-risk AI system also falls within the scope of Article 50 — for instance, a system that involves emotional recognition or biometric categorisation — deployers must comply with the relevant Article 50 transparency requirements as well. Article 50 applies from 2 August 2026 for limited-risk systems. Its core obligations for deployers include informing natural persons that they are interacting with an AI system and labelling AI-generated or manipulated content appropriately.
For post-market biometric identification systems where specific authorisation is required by law (for instance, remote biometric identification in public spaces under the conditions permitted by Article 5), additional use restrictions apply. Deployers must not use the system beyond those authorised conditions.
What Article 26 Does Not Require Deployers to Do
It is worth being precise about what stays with the provider. Deployers are not responsible for:
- Conducting the conformity assessment under Article 43 (provider obligation).
- Creating the Article 11 / Annex IV technical documentation (provider obligation).
- Establishing the Article 9 risk management system as it applies to the system's design and training (provider obligation, though deployers must operate within it).
- Issuing the Article 47 EU Declaration of Conformity (provider obligation).
This does not mean you can ignore these documents. Article 26 requires you to follow the instructions for use, which reference all of the above. You need to read and understand the provider's technical documentation to discharge your own obligations competently.
The Worked Example: A 40-Person HR-Technology Firm
Consider a 40-person firm that sells recruitment software to medium-sized companies across Germany and the Netherlands. The firm licenses a CV-screening model from a US AI vendor and integrates it into its own hiring workflow product. The firm's customers — the HR departments that use the tool — are deployers. The firm itself needs to determine its role under Article 25.
If the firm's product simply passes CVs through the vendor's model and surfaces the output with its own branding, it has put its name on a high-risk AI system. Under Article 25, it has become a provider. It must complete the conformity assessment, create the Annex IV technical documentation, and register the system in the EU database under Article 49 before placing it on the market.
If instead the firm sells direct access to the unbranded vendor tool, configured but not rebranded, it is likely a deployer. Its Article 26 obligations then include:
- Operating within the vendor's documented instructions for use (Article 13 information).
- Assigning oversight to trained HR staff with authority to override the system's rankings.
- Notifying the works councils of customers' employee-facing implementations before those go live — or ensuring customer contracts place this obligation on the customer.
- Keeping the system's automatically generated logs for at least six months.
- Conducting the Article 27 FRIA if any customer is a public body or falls within the creditworthiness or insurance categories.
- Suspending use and notifying the market-surveillance authority in Germany or the Netherlands if a serious incident occurs.
The distinction between these two scenarios is not a legal technicality — it determines whether the firm faces conformity assessment obligations before the end of 2027 or operational compliance duties.
Penalties
Non-compliance with Article 26 is penalised under Article 99 of the regulation. The fine ceiling for most Article 26 violations is €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher.
For smaller companies, Article 99(6) provides a proportionality protection: fines are capped at the lower of the percentage-based figure and the fixed amount. A deployer with €5 million annual turnover faces a ceiling of €150,000 (3% of €5M), not €15 million. That is not trivial, but it is proportionate.
The obligation to suspend use and notify the market-surveillance authority on a serious incident is itself part of the Article 26 obligations. Failure to report, or continuing to operate a system after identifying a serious risk, compounds the enforcement exposure.
How Confir Helps
Confir's rule-based compliance engine walks through your deployed systems and derives your obligations from the Article 6 classification and Article 26 deployer checklist. Three areas are directly relevant:
System registration and role determination. Confir registers each deployed system in your AI inventory and determines whether you are acting as deployer, provider (under Article 25), or both, based on how you have configured and branded the system.
Article 27 FRIA. For systems where the FRIA is mandatory — public-body deployers, credit-scoring, life and health insurance — Confir runs the structured assessment and generates the submission-ready documentation.
Oversight and log tracking. The compliance dashboard tracks human oversight assignments, training records, and the six-month log retention clock for each high-risk system in your register.
Start your free compliance assessment
Frequently Asked Questions
Who qualifies as a deployer under Article 26?
Any natural or legal person that uses a high-risk AI system under their authority in a professional capacity is a deployer under Article 26. This includes a recruitment agency using a third-party CV-screening tool, a regional bank deploying a licensed credit-scoring model, or a public authority using an AI system to process benefit applications. Deployers are distinct from providers (who build and place systems on the market) and distributors (who supply systems without using them). A deployer that rebrands or substantially modifies a system may become a provider under Article 25.
What is the compliance deadline for Article 26 deployer obligations?
Under the Digital Omnibus agreed in May 2026, the obligation date for stand-alone high-risk AI systems listed in Annex III is 2 December 2027, deferred from the original 2 August 2026 date. High-risk AI systems that are safety components of Annex I regulated products follow on 2 August 2028. The Article 27 Fundamental Rights Impact Assessment must be completed before a system is put into service, so organisations subject to the FRIA obligation should begin that work well before the applicable deadline.
What are the main Article 26 obligations in plain terms?
Article 26 requires you to: operate the system within the provider's documented instructions for use (Article 13); assign human oversight to trained, authorised staff (Article 14); ensure any input data you control is relevant and representative; monitor operation and report serious incidents to the provider, distributor, and market-surveillance authority; retain the automatically generated logs for at least six months; notify workers' representatives and affected workers before deploying the system in the workplace; if you are a public body, register the system under Article 49; and use the provider's Article 13 information when conducting any GDPR DPIA.
Who must carry out the Article 27 Fundamental Rights Impact Assessment?
The FRIA is mandatory for four categories: public bodies deploying any high-risk AI system; private operators providing public services; deployers using systems for creditworthiness assessment or credit scoring (Annex III, category 5(b)); and deployers using systems for life or health insurance risk assessment and pricing (Annex III, category 5(c)). Private-sector deployers outside these categories are not currently required to conduct a FRIA, though many choose to do so as part of general due diligence. The assessment must be submitted to the relevant market-surveillance authority.
When does a deployer become a provider under Article 25?
Article 25 converts a deployer into a provider — with the full Article 16 obligation stack — in three situations: the deployer puts its own name or trademark on the system; the deployer substantially modifies the system; or the deployer changes the intended purpose such that the system now qualifies as high-risk in a way the original provider did not design for. The test is not whether you wrote the code; it is whether you are presenting the system to the market as your own product or have materially changed what it does.
How long must deployers keep automatically generated logs?
Article 26 sets a minimum retention period of six months for automatically generated logs, unless Union or national law requires a longer period. Sector-specific rules frequently require longer retention — financial services regulations often mandate five to seven years. The six-month floor applies to the logs the system itself generates, not just internal compliance documentation. A deployer unable to produce these logs during a market-surveillance inspection has no procedural defence.
What happens if a deployer identifies a serious incident?
On identifying a serious incident (an event that has or could cause death, serious injury, or significant harm to health, safety, or fundamental rights), you must inform the provider or distributor and the relevant market-surveillance authority without undue delay, and suspend use of the system where appropriate. This is a direct Article 26 obligation, not a discretionary step. Non-compliance carries penalties under Article 99 of up to €15,000,000 or 3% of worldwide annual turnover, whichever is higher.
Related guides
- Article 26 compliance for SMBs
- AI system inventory management
- AI risk classification requirements
- EU AI Act compliance software
- AI governance for the EU AI Act
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →