EU AI Act Article 26: deployer obligations explained

Article 26 of the EU AI Act contains twelve paragraphs with duties for deployers of high-risk AI systems. Paragraphs 1 to 9 cover use according to instructions, human oversight, input data, monitoring, logs, worker information, public-authority registration, and the DPIA bridge. Paragraph 10 is specific to targeted post-remote biometric identification by law enforcement. Paragraphs 11 and 12 add information to affected natural persons and cooperation with competent authorities. These duties cannot be shifted to a vendor by contract.

Most organizations implementing AI are not building it. They are buying it, licensing it, and deploying it to make decisions about customers, employees, or patients. Under the EU AI Act, these organizations are called deployers and Article 26 is written specifically for them.

The common misconception is that compliance sits with the vendor. It does not. The AI Act explicitly places independent, non-transferable obligations on the deployer. Your contract with the provider does not shield you. Your organization's name is on the line.

Article 26 contains general and context-specific duties. Each applicable duty requires concrete action before and during the use of a high-risk AI system. Here is what they mean in practice.

Who counts as a deployer?

Article 3(4) of the EU AI Act defines a deployer as any natural or legal person, public authority, agency or other body that uses an AI system under its own responsibility, except where the AI system is used in the course of a personal non-professional activity.

The key phrase is "under its own responsibility." The moment your organization deploys an AI system for professional purposes, you are a deployer, regardless of whether you built the system.

If your bank uses an AI credit scoring model built by a fintech vendor, the fintech is the provider. Your bank is the deployer. If your hospital uses diagnostic AI from a medical software company, the software company is the provider. Your hospital is the deployer. If your HR team uses an applicant screening tool, the tool vendor is the provider. Your organization is the deployer.

Not sure which role applies? The risk assessment tool can help you map your position in the AI Act value chain.

The obligations in Article 26

1. Follow the instructions for use (Article 26(1))

Deployers must use high-risk AI systems in accordance with the instructions for use provided by the provider. This sounds straightforward. In practice, it requires that you have actually received, read, and operationalized that documentation.

The instructions for use come from Article 13, which requires providers to make their high-risk AI systems transparent and interpretable for deployers. If your vendor has not provided this documentation, you cannot comply with Article 26(1). Request it explicitly before go-live.

In an HR context: if the recruitment AI is only approved for screening CVs in certain job categories, deploying it outside those categories is a violation. The instructions define the boundaries of lawful use.

2. Assign human oversight to competent persons (Article 26(2))

You must assign the responsibility for human oversight to natural persons who have the necessary competence, training, and authority to carry out the oversight role and to intervene when required.

This is not a formality. It means identifying specific individuals, ensuring they understand how the AI system works, training them on its limitations and failure modes, and giving them the actual authority to override or suspend the system's output.

A financial institution using an AI fraud detection system needs oversight staff who understand what the model flags, what it misses, and under what circumstances a human judgment should override the automated recommendation. Assigning this to a junior analyst with no real authority does not satisfy Article 26(2).

This obligation connects directly to the AI literacy measures duty under Article 4 of the EU AI Act. Providers and deployers must take measures to support the development of AI literacy, taking account of role, context, and risk.

3. Other obligations remain in force (Article 26(3))

The obligations under paragraphs 1 and 2 are without prejudice to other obligations of the deployer under Union or national law, and without prejudice to the deployer's freedom to organize its own resources and activities to implement the human oversight measures indicated by the provider.

In practice: Article 26 does not replace your GDPR obligations, sector-specific regulations, or employment law. It adds to them. A public sector deployer using AI in social benefits decisions must comply with both the AI Act and public law procedural requirements. A healthcare deployer must comply with both the AI Act and medical device regulation.

4. Ensure data quality when you control input data (Article 26(4))

To the extent the deployer exercises control over the input data, it must ensure that the data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system.

This obligation applies to the extent you control the data fed into the AI system. That can also be the case with software as a service when your organisation selects or supplies the inputs. Document who controls the input data and how relevance and representativeness are assessed.

This is particularly relevant in public sector applications. Where a municipality controls the input data for an AI system used to allocate social housing, it must ensure that the data is relevant and sufficiently representative for the intended purpose. Unrepresentative input data can produce discriminatory outcomes and create a compliance risk under Article 26(4).

5. Monitor, report, and suspend when necessary (Article 26(5))

Deployers must monitor the operation of the high-risk AI system on the basis of the instructions for use. Where deployers have reason to consider that use of the system in accordance with the instructions may result in a risk within the meaning of Article 79(1), they must without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend use of that system. Where a serious incident is identified, the deployer must immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities.

This is an active, ongoing obligation, not a one-time check. It requires a monitoring framework, clear escalation paths, and someone responsible for deciding when to pull the plug.

Article 26(5) does not set a generic 15-day deadline for deployers. For a risk, the deployer must inform without undue delay and suspend use. For a serious incident, it must immediately inform the provider first, followed by the importer or distributor and the relevant market surveillance authorities. Record that sequence in the incident procedure before deployment.

6. Keep logs for at least 6 months (Article 26(6))

Deployers must retain the logs automatically generated by the high-risk AI system for at least six months, unless Union or national law requires a different retention period or the logs contain personal data with a shorter retention requirement under GDPR.

Logs are your audit trail. They demonstrate that the system was used correctly, that oversight was exercised, and that the system's outputs can be reviewed after the fact. Without logs, you cannot prove compliance and you cannot investigate incidents.

Check whether your vendor's system generates logs by default, where those logs are stored, whether you have access to them, and whether six months of retention is configured.

7. Inform workers and their representatives (Article 26(7))

Before deploying a high-risk AI system that will be used at the workplace, deployers who are employers must inform the workers' representatives and the affected workers. This obligation applies specifically to deployers in the role of employer, not to every deployer category.

This obligation is frequently overlooked. Organizations focus on technical compliance and forget the human dimension. The AI Act explicitly requires worker notification, not just as a procedural courtesy but as a compliance requirement.

In a manufacturing context: before deploying AI-powered quality control systems that monitor worker performance, employees and works councils must be informed. In an office environment: before deploying AI tools that assess employee productivity, the same notification requirement applies.

The scope of "high-risk AI systems at the workplace" is broader than many expect. Systems that affect employment decisions, task allocation, or performance monitoring can fall within the high-risk category. Check Annex III of the EU AI Act and also apply the exception in Article 6(3).

Works councils, trade unions, and employee representatives should be involved early. Do not treat this as a post-decision formality.

8. Public authorities must register before use (Article 26(8))

Where deployers are public authorities, agencies, or bodies, they must comply with the registration obligations under Article 49. The registration itself takes place in the EU database referred to in Article 71. If a system intended for use has not been registered in that database, the public authority must not use it and shall inform the provider or distributor.

This is a hard stop for government deployers. No registration, no use. The EU AI Act database is the transparency mechanism for government use of high-risk AI. Procurement of AI systems in the public sector should include registration as a pre-go-live step.

9. Use Article 13 information for DPIA compliance (Article 26(9))

Deployers must use the information provided under Article 13 (transparency and information provision) to comply with their DPIA obligations under GDPR Article 35 or the Law Enforcement Directive Article 27.

This is the direct bridge between the AI Act and GDPR. Article 13 requires providers to supply detailed technical documentation about their AI system, including its capabilities, limitations, and risks. Deployers must use this documentation when conducting Data Protection Impact Assessments.

If a high-risk AI system processes personal data, assess separately whether GDPR Article 35 or Article 27 of Directive (EU) 2016/680 requires a DPIA. Where that duty applies, Article 26(9) requires use of the provider's Article 13 information. Without adequate provider documentation, that assessment is incomplete.

Article 26(9) concerns the DPIA. The FRIA is a separate duty under Article 27. It applies to bodies governed by public law and private entities providing public services when they deploy a high-risk system under Article 6(2), except systems in Annex III point 2. It also applies to every deployer of systems in Annex III points 5(b) and 5(c): creditworthiness assessment or credit scoring of natural persons, excluding fraud detection, and risk assessment or pricing for life and health insurance. Annex III point 5(a) is not the separate financial trigger under Article 27.

10. Targeted post-remote biometric identification (Article 26(10))

Law enforcement follows a specific authorisation route when using post-remote biometric identification for the targeted search of a person in a criminal investigation. Prior authorisation by a judicial authority or a binding administrative authority is the rule. Only under the conditions in paragraph 10 may it be requested without undue delay and no later than 48 hours after use begins.

11. Inform natural persons (Article 26(11))

Deployers of Annex III systems that make or assist decisions about natural persons must inform those persons that they are subject to the use of the high-risk AI system. Article 50 and the rules for law enforcement remain applicable.

12. Cooperate with competent authorities (Article 26(12))

Deployers must cooperate with competent authorities in actions those authorities take to implement the AI Act. Internally identify who coordinates information requests, supervisory questions, and corrective actions.

Two obligations that organizations get wrong most often

Paragraph 7 (worker notification) applies specifically to deployers who act as employers, not to every deployer. Organisations sometimes treat it as an internal communication task, but it is an independent information duty. Omitting it creates a demonstrable compliance gap that can weigh heavily during supervision or a dispute.

Paragraph 9 (DPIA bridge) is misunderstood because organisations treat AI Act compliance and GDPR compliance as separate tracks. The AI Act explicitly connects them. Your DPIA and AI Act compliance documentation should reference each other. Article 27(4) separately allows a FRIA to cross-reference or include relevant parts of a DPIA.

Article 26 deployer checklist

Before and during the use of a high-risk AI system, verify all applicable points:

• Received and reviewed the instructions for use from the provider (Lid 1)
• Named specific individuals responsible for human oversight with documented competence and authority (Lid 2)
• Mapped AI Act obligations against existing GDPR, sector, and employment law obligations (Lid 3)
• Assessed and documented input data quality and representativeness, if you control input data (Lid 4)
• Established monitoring procedure, incident escalation path, and criteria for suspension (Lid 5)
• Confirmed log generation and 6-month retention is configured and accessible (Lid 6)
• If acting as employer: notified workers' representatives and affected employees, with records of notification (Lid 7)
• Registered the system in the EU database if you are a public authority (Lid 8)
• Completed or updated DPIA using provider's Article 13 documentation (Lid 9)
• For targeted post-remote biometric use by law enforcement: implemented the authorisation route in paragraph 10
• Informed affected natural persons where paragraph 11 applies
• Assigned an owner and process for cooperation with competent authorities under paragraph 12

Where to go from here

Article 26 compliance requires more than a checklist. It requires documented processes, trained staff, and integration with your existing governance frameworks.

Use the FRIA generator only where your organisation and system fall within Article 27. A FRIA may cross-reference or include relevant parts of a DPIA, but it does not replace the separate DPIA assessment under Article 26(9).

For a full picture of how your organization's AI use maps against the EU AI Act risk categories, the risk assessment tool walks you through the classification logic.

The full legal text of Article 26 is available on this site if you need to verify the exact wording for your compliance documentation.

Whether a use case in HR, financial services, or public services falls within Annex III depends on the concrete use case and the Article 6(3) exception. Classify the application before assuming that the high-risk duties apply.