EU AI Act deployer obligations — Article 26 explained

Most European companies will engage the EU AI Act as deployers, not providers. The provider chapter (Articles 9–17) is what makes headlines; Article 26 is what most companies will actually live with. This guide is the deployer’s working interpretation.

What “deployer” means

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

If your company uses an AI tool in your business — whether you bought it, fine-tuned it, or embedded it — you’re a deployer. The provider built the system; you put it to work.

When Article 26 applies

Article 26 applies to deployers of high-risk AI systems. If the system you use is limited risk (chatbots, generative content), the lighter Article 50 transparency obligations apply instead, not Article 26.

The hard step is therefore confirming whether the system you deploy is high-risk under Annex III. See Is my AI system high-risk?.

The full Article 26 deployer obligations

For deployers of high-risk AI systems, the obligations include:

1. Take technical and organisational measures to use the system per the provider’s instructions

Article 26(1). The provider’s instructions for use are not optional reading. They form part of the conformity assessment basis. Deviating materially can flip your deployment into “substantial modification” territory, which makes you a provider yourself (with the heavier Articles 9–17 obligations following).

2. Assign human oversight to natural persons with the necessary competence, training, and authority

Article 26(2). The person providing oversight must:

• Have the competence to understand the system
• Have the training to use the human-oversight measures built into the system
• Have the authority to actually disagree, override, or stop the system
• Have the necessary support — time, resources, organisational backing

Rubber-stamp human review does not count. The EDPB and AI Office have both made this clear.

3. Ensure input data is relevant and sufficiently representative

Article 26(4). Where the deployer exercises control over input data, that data must be relevant to the system’s intended purpose and sufficiently representative in view of that purpose.

For a deployer who provides input data (e.g., uploading documents to an AI tool), this means filtering and curation — don’t feed garbage and expect compliant outputs.

4. Monitor the operation of the system per the provider’s instructions

Article 26(5). The deployer is responsible for monitoring during use. If the system shows signs of operating outside expected parameters, the deployer must inform the provider and may need to suspend use.

Anomalies, model drift, unexpected outputs — these are the deployer’s signal-to-act.

5. Keep automatically generated logs for at least 6 months

Article 26(6). Where the deployer has control over the logs, they must be retained for at least 6 months (or longer if other EU/national law requires).

For SaaS deployments, the provider often keeps logs on the deployer’s behalf — that’s fine, but document the arrangement.

6. Inform workers’ representatives before deploying a high-risk AI system at work

Article 26(7). When a high-risk AI system is used in the workplace, the deployer must inform workers and their representatives before deployment. In the EU context this means union or works-council consultation timelines apply.

7. Inform natural persons subject to the system

Article 26(11). When a high-risk system is used to make a decision concerning a natural person, the deployer must inform them. The disclosure must be clear and at the point relevant to the person (not buried in terms).

8. Register the deployment (where required)

Article 49(3) requires registration in the EU database when the deployer is a public authority, agency, or body (or a private body acting on behalf of one).

9. Fundamental Rights Impact Assessment (Article 27)

Required from certain deployers — public bodies, private entities providing public services, and private deployers using AI in credit and insurance. The FRIA must be completed before deploying a high-risk AI system. See DPIA vs EU AI Act risk assessment.

10. Cooperate with supervisory authorities

Article 26(12). Deployers must cooperate with supervisory authorities on any action they take in relation to the AI system.

What this looks like in practice

For a typical mid-sized B2B SaaS company deploying a high-risk vendor product (say, an AI candidate-screening tool):

1. Read the vendor’s instructions for use. Identify the human-oversight roles the provider expects.
2. Designate the human-oversight role internally. Name a person. Give them training. Give them authority to override or reject the AI’s output.
3. Document data inputs. What goes in, where it comes from, how it’s curated.
4. Set up monitoring. Output quality samples weekly or monthly. Track agreement rate between AI and human decisions.
5. Retain logs for 6+ months. Confirm whether the vendor or you retain them; document the arrangement.
6. Notify workers’ reps. Before the tool is used in HR decisions, inform the works council or union.
7. Inform affected candidates. Standard disclosure at application time that AI is part of the screening.
8. Complete a FRIA if required. For most private B2B deployers using AI in HR, FRIA is not mandatory but is good practice. For deployers in credit/insurance, mandatory.

What deployers do NOT have to do

It’s worth being clear on what’s not in Article 26:

• No conformity assessment. That’s the provider’s job.
• No technical documentation per Annex IV. That’s the provider’s.
• No EU database registration (unless you’re a public-sector deployer).
• No risk-management system per Article 9. That’s the provider’s.

This is the architectural reason most companies will engage the Act as deployers, not providers. The deployer’s load is significant but proportionate.

What deployers can outsource — and what they can’t

The “use of human oversight,” the “informing affected persons,” and the “cooperation with supervisory authorities” can’t be outsourced. They’re functions of your organisation’s deployment.

The “log retention” and “monitoring” can often be handled by the provider on your behalf, but the legal responsibility stays with you — document who does what.

The “Fundamental Rights Impact Assessment” can be drafted with consultants, but the assessment must reflect your organisation’s actual deployment context, not a template.

How software helps

The deployer’s biggest practical headache is keeping a running audit trail of which systems you deploy, which decisions human reviewers accepted, and which persons were informed. That’s exactly what Maditon’s audit log, reviewer notes, and transparency-page features are built to maintain — so when a supervisory authority asks “show me your Article 26 deployment records for Q1 2026,” you can.