Chapter 6: High-Risk Deployer — The 7 Obligations Explained
What you will know after reading this chapter: You will understand each of the seven deployer obligations under Article 26 in concrete, actionable detail — what each obligation requires, how to implement it, what evidence to keep, and the most common mistakes to avoid.
Before You Begin: What You Need from Your Provider
Before you can fulfil most of your deployer obligations, you need one critical document from your AI system provider: the Instructions for Use (IFU). Article 13 requires providers of high-risk AI systems to supply deployers with clear, comprehensive instructions that include the provider’s identity and contact details, the system’s intended purpose, the level of accuracy, robustness, and cybersecurity the system has been tested against, any known circumstances that may lead to risks to health, safety, or fundamental rights, the system’s performance regarding the persons or groups on which it is intended to be used, specifications for input data, and the human oversight measures built into the system.
If your provider has not given you this document, request it in writing. You cannot properly fulfil your obligations without it. The IFU is the foundation for almost everything that follows.
Obligation 1: Use the System According to the Provider’s Instructions (Article 26(1))
What the law requires
Deployers shall use high-risk AI systems in accordance with the instructions for use accompanying the systems.
What this means in practice
You must read the IFU and follow it. This is not a suggestion — it is a legal obligation. If the provider says the system is intended for screening job applications in the technology sector, you cannot use it to screen applications in healthcare and claim compliance. If the IFU specifies that the system requires human review of every output before action is taken, you must implement that review process.
How to implement it
Read the IFU thoroughly and identify every operational requirement it specifies. Compare each requirement against your actual use of the system. Document any gaps and take corrective action. Store the IFU in an accessible location and ensure all relevant staff know where to find it and what it contains. When the provider updates the IFU, review the changes and update your processes accordingly.
Evidence to keep
A copy of the current IFU, records of when it was received and by whom, documentation of any gap analysis conducted, and records of corrective actions taken.
Common mistake: Treating the IFU as a formality. Many organisations receive the IFU and file it without reading it. When an incident occurs and an authority asks how the system was being used versus how it was intended to be used, the gap becomes a compliance failure.
Obligation 2: Assign Human Oversight (Article 26(2))
What the law requires
Article 26(2) is short: “Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.”
The substance of what that oversight is for comes from Article 14, which the provider must build into the system: human oversight shall aim to prevent or minimise the risks to health, safety or fundamental rights that may emerge when a high-risk AI system is used in accordance with its intended purpose or under conditions of reasonably foreseeable misuse (Article 14(2)), and the oversight measures must enable the assigned person to intervene, interrupt or disregard the output (Article 14(4)). Your Article 26(2) duty is to put a person in that seat who can actually use those measures.
What this means in practice
You need a named individual (or individuals) who are responsible for overseeing the AI system’s operation, who understand how the system works, what it does, and what its limitations are, who have the authority to override, reverse, or disregard the system’s outputs, who have the practical ability to exercise that authority (meaning they are not under pressure to simply rubber-stamp the AI’s decisions), and who are trained to recognise when the system may be producing incorrect, biased, or harmful outputs.
How to implement it
Designate a specific person as the human oversight officer for each high-risk AI system. This can be an existing employee — it does not require a new hire. Define their responsibilities in writing, including the scope of their authority to override the system. Ensure they receive training on the specific AI system, its IFU, its known limitations, and the types of errors it may produce. Provide them with the time and resources to meaningfully review the system’s outputs rather than merely confirming them. Document the designation, including the person’s name, role, the date of designation, and the scope of their responsibilities.
Evidence to keep
Written designation of the oversight officer, documentation of their competence and training, the scope of their authority (including override authority), records of oversight activities performed, and records of any overrides or interventions made.
Common mistake: Assigning oversight to someone who lacks the practical ability to intervene. If the human oversight officer is a junior employee who feels unable to contradict the AI system because of organisational pressure, the oversight is not effective. The law requires not just a named person but genuine authority and independence to act.
Obligation 3: Ensure Data Input Quality (Article 26(4))
What the law requires
Deployers shall ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system, to the extent the deployer exercises control over the input data.
What this means in practice
The quality of an AI system’s output depends directly on the quality of its input. If you feed the system incomplete, outdated, or unrepresentative data, its outputs will be unreliable — and you bear responsibility for that unreliability.
How to implement it
Identify what input data you provide to the AI system. Assess whether that data is relevant to the system’s intended purpose as described in the IFU. Assess whether the data is sufficiently representative — does it reflect the diversity of the population or cases the system will be used on? Establish a regular review process to check that input data remains current and representative over time. If you discover data quality issues, take corrective action and document what you did.
Evidence to keep
Documentation of what input data is used, records of data quality assessments, corrective actions taken when quality issues were identified, and the schedule for ongoing data quality reviews.
Common mistake: Assuming data quality is the provider’s problem. The provider is responsible for training data quality. The deployer is responsible for the quality of operational input data — the data you feed into the system during day-to-day use.
Practical example: A bank uses an AI credit scoring system. The bank feeds customer financial data into the system. If the bank’s data contains outdated income information or systematically excludes certain types of income (such as gig economy earnings), the credit scores produced will be unreliable. The bank, as deployer, is responsible for ensuring the data it inputs is relevant and representative.
Obligation 4: Monitor the System’s Operation (Article 26(5))
What the law requires
Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72. Where deployers have reasons to consider that the use of the high-risk AI system may result in the AI system presenting a risk, they shall, without undue delay, inform the provider or distributor and the relevant market surveillance authority, and shall suspend the use of that system.
What this means in practice
You must actively watch how the system performs after deployment. This is not a one-time check — it is ongoing monitoring. You need to detect performance degradation, unexpected outputs, emerging biases, or any other indication that the system is not functioning as intended.
How to implement it
Define what metrics you will monitor, based on the IFU and the system’s intended purpose. Establish a monitoring schedule — daily, weekly, or monthly depending on the system’s criticality and volume of use. Create a process for escalating concerns. Define what constitutes a risk that requires notification to the provider and the market surveillance authority. Implement the monitoring and record the results.
Evidence to keep
Monitoring plan (what is measured, how often, by whom), monitoring results and records, records of any anomalies detected and actions taken, records of any notifications sent to the provider or authorities, and records of any suspensions of the system.
Common mistake: Passive monitoring. Some organisations treat monitoring as “we will notice if something goes wrong.” That is not monitoring — that is hoping. Article 26(5) requires active, structured monitoring based on the IFU.
Practical example: An HR department using an AI screening tool monitors the demographics of candidates passing and failing the AI filter each quarter. If the pass rates diverge significantly across demographic groups compared to the applicant pool, this signals a potential bias issue that requires investigation and possibly notification to the provider.
Obligation 5: Retain Logs (Article 26(6))
What the law requires
Deployers of high-risk AI systems shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law.
What this means in practice
The AI system should be generating logs automatically (this is a provider obligation under Article 12). Your obligation as a deployer is to retain those logs for at least six months. In practice, sector-specific regulations may require longer retention — for example, financial services regulations often require several years of record-keeping.
How to implement it
Confirm with your provider that the system generates automatic logs and that you have access to them. Determine where the logs are stored — on your infrastructure, on the provider’s cloud, or both. Establish a retention policy that meets the minimum six-month requirement and any sector-specific requirements. Ensure logs are stored securely and are not modified or deleted during the retention period. Establish a process for making logs available to authorities if requested.
Evidence to keep
Log retention policy, confirmation of log access and storage location, the logs themselves, and records of any authority requests for logs and your responses.
Common mistake: Assuming the provider handles log retention. Many cloud-based AI services retain logs for a limited time (often 30 days) by default. If you do not actively configure longer retention or export logs to your own storage, they may be automatically deleted before the six-month minimum expires.
Obligation 6: Inform Workers (Article 26(7))
What the law requires
Deployers shall inform workers’ representatives and the affected workers that they will be subject to the use of the high-risk AI system. This information shall be provided before putting the system into service or using it in the workplace.
What this means in practice
If you use a high-risk AI system in a way that affects your employees — performance monitoring, task allocation, scheduling, promotion decisions, or any other employment-related purpose — you must tell them about it before you start using it.
How to implement it
Identify all high-risk AI systems used in the workplace that affect workers. Prepare a clear, accessible notification for workers and their representatives. The notification should explain what AI system is being used, what it does, what decisions it influences, and what data it processes about them. Deliver the notification before the system is put into service. Document the notification — when it was provided, to whom, and by what method.
Evidence to keep
Copy of the worker notification, record of when and how it was delivered, confirmation of receipt by workers’ representatives (if applicable), and updates to the notification when the system changes.
Common mistake: Burying the notification in a general IT policy update or a terms-of-employment amendment. The AI Act requires that workers are specifically informed about AI systems. A vague reference to “digital tools” in a company-wide email does not satisfy this obligation.
Interaction with national labour law: Many EU Member States have additional consultation requirements with works councils or trade unions when introducing AI in the workplace. The AI Act obligation is a minimum — check your national labour law for additional requirements.
Obligation 7: Inform Affected Individuals and Ensure the Right to Explanation (Article 26(11) and Article 86)
What the law requires
This obligation has two parts. Part A — AI use disclosure (Article 26(11)): Deployers of high-risk AI systems that make decisions or assist in making decisions related to natural persons shall inform those natural persons that they are subject to the use of the high-risk AI system. Part B — Right to explanation (Article 86): Any affected person subject to a decision taken by the deployer on the basis of the output of a high-risk AI system listed in Annex III — with the exception of systems listed under point 2 of Annex III (critical infrastructure) — which produces legal effects or similarly significantly affects them in a way they consider to have an adverse impact on their health, safety or fundamental rights, has the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.
What this means in practice
Every person who is subject to a decision influenced by your high-risk AI system must be told that AI was involved. This includes job applicants screened by an AI tool, individuals whose credit scores were generated by AI, patients whose diagnoses were assisted by AI, and anyone else directly affected by the system’s output. For Annex III systems other than critical infrastructure (Annex III point 2), affected individuals must also be able to request and receive an explanation of how the AI system contributed to the decision about them, where the decision produces legal effects or similarly significantly affects them.
How to implement it
For Part A, develop a standard notification that informs individuals about the use of AI. This can be included in application forms, terms of service, or privacy notices — but it must be clear and specific to the AI system. For Part B, establish a procedure for handling explanation requests. Define who is responsible for responding, what information will be provided, and within what timeframe. Prepare template responses that explain the AI system’s role in plain language.
Evidence to keep
Copies of all notifications provided to individuals, the procedure for handling explanation requests, records of explanation requests received and responses provided, and template responses used.
Common mistake: Confusing GDPR notification obligations with AI Act obligations. GDPR Articles 13 and 14 require you to inform individuals about the existence of automated decision-making. The AI Act goes further — Article 26(11) requires notification about the use of AI specifically, and Article 86 gives affected persons a right to obtain meaningful explanations. These are three separate obligations. Note that Article 26(11) defers to Article 13 of Directive (EU) 2016/680 for high-risk AI systems used for law enforcement purposes, and that Article 86 does not apply to Annex III point 2 systems.
The FRIA and DPIA: Mandatory Assessments
In addition to the seven core obligations above, certain deployers must conduct impact assessments. These are covered in detail in Chapter 8, but the key points are:
Fundamental Rights Impact Assessment (FRIA) — Article 27: Deployers that are bodies governed by public law, or private entities providing public services, and deployers of high-risk AI systems referred to in Annex III points 5(b) (credit scoring) and 5(c) (life and health insurance) must conduct a FRIA before putting the system into use. Article 27(1) applies to Annex III high-risk systems with the exception of those intended to be used in the area listed in point 2 of Annex III (critical infrastructure). Note that Article 27(1) makes FRIA mandatory for all deployers of Annex III 5(b) and 5(c) systems regardless of whether they are public or private entities.
Data Protection Impact Assessment (DPIA) — Article 26(9): Deployers shall use the information provided by the provider under Article 13 to carry out a DPIA where required under GDPR Article 35 or the Law Enforcement Directive Article 27.
Implementation Timeline
| Priority | Action | Timeframe |
|---|---|---|
| ★ Immediate | Request IFU from provider | This week |
| ★ Immediate | Designate human oversight officer | This week |
| ★ Immediate | Conduct AI literacy training (Art 4) | This week |
| High | Implement worker notification (Art 26(7)) | Within 2 weeks |
| High | Implement individual notification and explanation procedure | Within 2 weeks |
| High | Set up log retention (Art 26(6)) | Within 2 weeks |
| Medium | Conduct data input quality assessment (Art 26(4)) | Within 1 month |
| Medium | Establish monitoring framework (Art 26(5)) | Within 1 month |
| Medium | Conduct FRIA if applicable (Art 27) | Within 1 month |
| Medium | Conduct DPIA if applicable (Art 26(9)) | Within 1 month |
| Ongoing | Monitor system operation | Continuous |
| Ongoing | Review and update processes | Quarterly |
Total estimated effort: 30 to 90 hours for initial implementation, depending on the number and complexity of your high-risk AI systems. Ongoing maintenance: 2 to 8 hours per month.
Self-Check: Deployer Obligations Compliance
For each high-risk AI system you deploy, assess your current status:
| # | Obligation | Status |
|---|---|---|
| 1 | Do you have the IFU and are you following it? | |
| 2 | Is a human oversight officer designated with documented authority? | |
| 3 | Have you assessed and documented input data quality? | |
| 4 | Is a monitoring framework in place with defined metrics and schedule? | |
| 5 | Are logs being retained for at least 6 months? | |
| 6 | Have workers been informed about the AI system? | |
| 7 | Are affected individuals notified and able to obtain explanations? | |
| 8 | Has a FRIA been conducted (if applicable)? | |
| 9 | Has a DPIA been conducted (if applicable)? |
Any item marked incomplete is a gap that needs to be addressed before the enforcement deadline of 2 December 2027.
Summary
Deployers of high-risk AI systems have seven core obligations: follow the provider’s instructions (Article 26(1)), assign human oversight (Article 26(2)), ensure input data quality (Article 26(4)), monitor system operation (Article 26(5)), retain logs (Article 26(6)), inform workers (Article 26(7)), and inform affected individuals (Article 26(11)) — who in turn hold a right to explanation under Article 86. The foundation of compliance is the Instructions for Use document from your provider — request it immediately if you do not have it. Additional obligations may apply: FRIA for certain deployers (Article 27) and DPIA where required under GDPR (Article 26(9)). Total implementation effort is 30 to 90 hours, with 2 to 8 hours per month of ongoing maintenance. The most common mistakes are treating the IFU as a formality, assigning human oversight without genuine authority, confusing provider data responsibilities with deployer data responsibilities, passive rather than active monitoring, relying on provider default log retention, and confusing GDPR notification with AI Act notification. Chapter 7 covers the equivalent obligations for providers. Chapter 8 covers FRIA and DPIA in detail.
← Back to Blog Summary