If you are a deployer — what you must do

Who is a deployer

A deployer is, in the Act's words, "a natural or legal person, public authority, agency or other body using an AI system under its authority". In plain language: you bought it, you are running it, you are responsible for how it operates in your context.

Crucially, the deployer category catches a much larger population than the provider category. Almost every European organisation that uses AI is, somewhere, a deployer. Most are not providers.

Deployer duties on high-risk AI systems

These are the duties when the AI system you are using is high-risk under the framework from Lesson 2. There are seven main ones; we will walk through each.

1. Use the system in accordance with the provider's instructions

This sounds obvious but is the deployer obligation most often breached in practice. You must operate the system in line with the instructions for use. If the provider tells you it has been validated for use in country X with applicant population Y, you cannot turn around and use it in country Z on population W without taking on additional responsibility.

The classic failure mode is repurposing. A tool sold for "candidate ranking" used as "automatic rejection". A medical-imaging assistant sold for "second-read" used as "primary screening". Either change can take the system outside its validated use, which the Act treats as a substantial modification — at which point you may become the provider for that use (more below).

2. Operate the human oversight that the provider built in

Article 14 requires the provider to design human-oversight measures into the system. Article 26 requires the deployer to actually use them. You must assign human-oversight tasks to people who have the competence, training, authority, and support to do the job effectively. You cannot delegate the oversight to a junior or to a part of the organisation that does not have the authority to override the system's output.

For a CV-screening tool, this means: the recruiter who reviews the system's outputs must be trained, must understand what the model can and cannot see, must have the authority to overrule a low score, and must have time in their day to actually do so.

3. Make sure input data is relevant and representative

If you control the input data going into the system (which the deployer often does), you must ensure that data is sufficiently relevant and representative for the system's intended purpose. This is the deployer-side mirror of the provider's data-governance duty.

4. Monitor the operation of the system; report serious incidents

You must monitor the system based on the provider's instructions, and inform the provider of any incident or malfunction. For serious incidents — those causing or capable of causing harm to a person's health, safety, or fundamental rights — you must report to the provider and to the relevant national authority. The 15-day timeframe applies (72 hours for the most serious cases).

5. Keep automatic logs

Where the system generates automatic logs, you must keep them for at least six months. This is so that you, or an authority, can later trace what happened — particularly important when affected persons exercise their right to an explanation (see point 7).

6. Inform workers when AI is used in the workplace

If you are a deployer in an employment context, you must inform workers and their representatives that they will be subject to a high-risk AI system before it is put into use. National law and collective agreements may add further duties on top.

This means: if your HR team is rolling out an AI-driven performance-management tool, the workforce must be informed before it goes live. Not after the first reviews are run.

7. Inform individuals affected by AI-driven decisions

For high-risk AI systems used to make or assist with decisions that have legal effects on a person (or similarly significant effects), the deployer must inform those individuals that the system is being used. On request, the deployer must also provide a clear and meaningful explanation of the role of the AI in the decision and of the main elements of the decision taken. This is the AI Act's complement to the GDPR's existing rights on automated decision-making.

The Fundamental Rights Impact Assessment (FRIA)

A specific obligation that applies to a subset of deployers: bodies governed by public law, private operators providing public services, and certain financial institutions using high-risk AI systems in particular Annex III categories must carry out a Fundamental Rights Impact Assessment before deployment.

The FRIA covers:

• The deployer's processes in which the system will be used.
• The time period and frequency of intended use.
• The categories of natural persons likely to be affected.
• The specific risks of harm to those persons.
• The human-oversight measures that will be in place.
• What happens if those measures fail.

The FRIA is documented; it must be sent to the relevant national authority. If you already do a GDPR DPIA for the same use, the two assessments can be combined — they cover overlapping ground.

When a deployer becomes a provider

This is the most easily missed point in the entire Act. Under Article 25, a deployer is treated as the provider — taking on the full provider obligations from Lesson 3 — if any of three things happens:

1. Branding. The deployer puts its own name or trademark on a high-risk AI system already placed on the market. White-labelling is a classic trigger.

2. Substantial modification. The deployer substantially modifies the system in a way that it remains high-risk. Significant fine-tuning, integrating it into a new product, changing the data flows materially.

3. New intended purpose. The deployer changes the intended purpose so that the system becomes high-risk (or stays high-risk under a different Annex III heading).

The reason this matters: many enterprises buy a foundation-model API and build "their own AI product" on top of it. The moment you brand that as your product, fine-tune it materially, or deploy it for a new high-risk purpose, you have become the provider. You inherit the nine obligations from Lesson 3, you owe a conformity assessment and a CE marking, and the original API provider's compliance work does not save you.

Three deployer scenarios in practice

Role: Deployer.
Duties: Use within provider's instructions; ensure human oversight by trained recruiters;
keep logs; inform workers; inform unsuccessful applicants on request; report incidents.
Risk to watch: scope creep — using the tool to auto-reject without human review crosses Article 22 GDPR and weakens Act compliance.

Role: Deployer + (under Article 27) subject to a FRIA before deployment.
Duties: Provider's instructions; human oversight; logs; inform claimants; do the FRIA; submit FRIA to authority; address ongoing risks in operation.
Risk to watch: the FRIA must reach the authority before the tool goes live, not after.

Role: Was deployer of the foundation model; substantial modification + Annex III use makes the bank a provider of the resulting credit-decision system.
Duties: Full provider obligations from Lesson 3 — risk management, data governance, technical documentation, conformity assessment, CE marking, registration, post-market monitoring.
Risk to watch: assuming the foundation-model provider's compliance carries through. It does not.

Looking ahead

Lesson 5 is the wrap. It covers the rules for general-purpose AI models (the Act's other major regulatory pillar), the staggered timeline of enforcement dates that has already started and runs through 2027, and a 30-day personal compliance checklist you can use this week.