The Other Half of the AI Act: A Deployer’s Field Guide

For two years, almost everything written about the EU AI Act has been about the model makers — OpenAI, Anthropic, Mistral, Google. The law has a special name for them: providers of “GPAI”, which stands for general-purpose AI. That’s the loud part of the regulation. For most organisations, it’s the wrong part to be reading.

If your company doesn’t train foundation models — and almost no company does — what actually matters to you is buried in two articles, 26 and 27, plus a handful of supporting ones. These are the deployer obligations. A deployer in the Act’s vocabulary is just an organisation that uses AI for things that affect people. The deployer rules start applying broadly on 2 August 2026. They are more specific than the headlines suggest, and they are more enforceable than most companies have priced in.

This is the field guide I wish had existed when I started fielding “does this apply to us?” questions from operating companies last year. It is not legal advice — get a real lawyer involved before you do anything risky — but it should let you walk into that conversation knowing roughly where the lines are.

First: are you a deployer?

The law’s definition is broad. If you use AI under your authority, for anything other than personal life admin, you’re a deployer. Buying a SaaS HR product that scores candidates with AI? You’re the deployer of that product, even though you didn’t build it. Letting your team use ChatGPT to draft customer responses? Deployer.

The “personal use” carve-out is narrow — it covers an individual using ChatGPT to write a holiday card, not a team using it inside a business.

You’re in scope if your organisation runs in the EU, OR if your AI’s output lands in the EU even when you sit outside it. That second part catches more people than they realise. A US recruiter screening EU candidates is in scope. A UK consultancy whose AI-generated recommendations are acted on in Frankfurt is in scope.

So the threshold question isn’t “are we a deployer?” — almost everyone is. The real question is what kind of AI you’re deploying.

Are you using a high-risk system?

Most AI use isn’t high-risk. The Act puts AI into a high-risk category in only two situations.

Situation one: AI baked into a regulated product — medical devices, machinery, lifts, toys, vehicles. If that’s you, you already know.

Situation two: AI used in eight specific areas, listed at the back of the law in something called Annex III. (An “annex” is just an attached list — Annex III is the one that catches most operating companies.) The eight areas:

1. Biometrics (facial recognition, emotion recognition, biometric categorisation)
2. Critical infrastructure (water, gas, electricity, traffic, digital infrastructure)
3. Education (admissions, grading, exam monitoring, learning-path assignment)
4. Employment (recruitment, performance evaluation, task allocation, promotion or termination decisions)
5. Essential public and private services (benefits eligibility, credit scoring, life and health insurance pricing, emergency triage)
6. Law enforcement
7. Migration, asylum, border control
8. Justice and elections

Read that list with your real workflows in mind. AI-assisted CV screening? High-risk (it’s in area 4). An employee-monitoring tool that flags performance? High-risk. A credit decisioning model? High-risk. AI scoring loan applications, even as a “first pass” before a human sees them? High-risk. Insurance pricing? High-risk.

The Act does offer a narrow exemption: an Annex III system isn’t high-risk if it only does a narrow procedural task, only refines work a human has already finished, only flags unusual patterns for human review, or only does prep work. The provider of the system makes that call and has to document it. As the deployer, you generally inherit their classification.

Two traps in the exemption. First: if the system does any kind of automated profiling of people — meaning it builds a personal profile to make decisions about them — the exemption is voided automatically. The system is high-risk, full stop. Second: claiming the exemption when you shouldn’t is itself an offence under the Act. So “we’ll just argue it’s not high-risk” is not the strategy people sometimes hope it is.

If you’re using an Annex III system and the provider hasn’t claimed an exemption, treat it as high-risk. That’s your starting point for everything below.

The deployer playbook

Here’s what the law actually requires of a deployer of a high-risk AI system, in plain operational terms.

Use the system the way the provider says you should. This sounds trivial, but the instructions-for-use document the provider gives you carries real legal weight. You don’t get to repurpose a tool sold for narrow tasks into a high-stakes decision tool and pretend nothing changed. Read the instructions. If they’re inadequate, that’s a contractual lever to push back on the provider — not a free pass.

Put real people in charge of oversight. The law requires you to assign oversight to people who actually understand what the system does, have the authority to override it, and have the training and time to do the job properly. The role can’t be a tick-box on someone’s job description. Those people have to be able to stop the system if needed. They also have to be alert to automation bias — the human tendency to over-trust whatever the model says — which the Act explicitly names as a risk. For decisions of any consequence, the oversight role should be filled by a senior, named person with documented training, not whichever junior is on shift.

Pay attention to your input data. Where you control what goes into the system, you’re responsible for it being relevant and representative. If you’re feeding a vendor’s CV-screening model with five years of historical hires from a homogeneous team, the bias problem is now partly yours.

Monitor and report. You have to monitor the system in use against the instructions, and tell the provider and the relevant national authority quickly if you suspect it’s causing harm. Suspend use in those cases. If a serious incident actually happens — death, serious harm, infrastructure disruption, breach of fundamental rights, or major property or environmental damage — you’re on a strict reporting clock (more on that below).

Keep the system’s logs for at least six months, where the logs are under your control. Many SaaS deployments will need a vendor conversation before this is even contractually possible.

Tell your workers. This is the obligation most often missed. Before you put a high-risk AI system into use at the workplace, you have to inform workers’ representatives and the affected workers themselves. Existing national worker-information laws still apply on top. If your works council finds out about the new productivity-monitoring AI from an internal Slack screenshot rather than from you, you have already broken the law.

Plug the provider’s information into your existing GDPR work. Under GDPR you already produce a Data Protection Impact Assessment, or DPIA, when you process personal data in risky ways. The information sheet the AI provider gives you should feed straight into that DPIA. The DPIA isn’t optional just because the AI Act is here — it stacks on top.

Public bodies have to register the system. If you’re a public-sector deployer and the system isn’t in the EU’s central database, you can’t use it.

Tell the people affected by the AI’s decisions. If the system makes or assists decisions about individuals, you have to inform those individuals they’re subject to AI use. You can mostly fold this into existing consent and privacy notices, but it has to actually be there.

The new one: Fundamental Rights Impact Assessment (FRIA)

A FRIA is a structured, written check of how a particular high-risk AI system could affect people’s basic rights — non-discrimination, dignity, free expression, due process. It’s a brand-new requirement that didn’t exist before the AI Act, and it catches a specific subset of deployers.

You have to do a FRIA before deploying an Annex III high-risk system if you are:

• A public-sector body, or
• A private organisation providing public services (e.g. a contractor running citizen-facing services), or
• A bank or non-bank lender deploying credit-scoring AI, or
• An insurer deploying AI for life or health insurance pricing.

Critical infrastructure is excluded from the FRIA requirement. Everyone else in that high-risk-deployer set is in.

The FRIA isn’t a glossy environmental, social, and governance (ESG) document you use for marketing brochures or websites. It’s closer to the DPIA under the GDPR.

The Act tells you what’s in it:

• A description of where in your operations the system will be used
• How long and how often you intend to use it
• Which categories of people and groups will be affected
• The specific risks of harm to those groups, drawing on the provider’s information sheet
• Your human oversight arrangements
• What you’ll do if the risks materialise — including governance and complaint channels

When complete, you notify the national market surveillance authority of the results, using a template the EU’s new AI Office is producing. You have to redo or update the FRIA if the situation changes during deployment.

If you’ve already done a GDPR DPIA covering some of this, the FRIA complements it. It doesn’t replace it. The DPIA stays with you and your data protection authority. The FRIA goes to the market surveillance authority. Different audiences, different documents.

The practical implication: if you’re a bank deploying credit scoring AI, an insurer pricing health policies, a council using AI to allocate benefits, or a contractor running public services on an Annex III system — your compliance documentation just grew, the audience for it changed, and the work has to happen before you go live.

The trap most organisations don’t see: when deployers become providers

Article 25 is the one every operations and product team needs printed on the wall. It says you stop being a deployer and become a provider — with all the heavier provider obligations attached — if you do any of these:

• Put your own brand or trademark on a high-risk AI system already on the market
• Substantially modify a high-risk system in a way that keeps it high-risk
• Modify a non-high-risk system enough to turn it into a high-risk system

The first one catches white-label deployments — selling someone else’s AI under your brand. The second catches anything material you do to a vendor’s model: fine-tuning it, swapping in your own retrieval layer, extending the use case beyond what’s documented. The third catches the “we just connected this generic chatbot to our hiring pipeline” pattern that’s all over the place right now.

If you trip this rule, you inherit the full provider stack: a quality management system, ten years of technical documentation, your own logs, a formal compliance check by an independent EU-approved third party, a CE marking on the product, official compliance paperwork, and database registration. The original provider you bought from is no longer the provider for your version — they have to cooperate with you, but the legal load is now yours.

This is the single biggest reason organisations should be careful with the rush of “build your own AI agent” and “fine-tune your domain model” projects. There’s a real risk of waking up on 2 August 2026 having become, on paper, an AI provider — without any of the engineering, governance, or legal infrastructure providers normally have.

The other one to design in early: the right to an explanation

If your AI system makes or significantly contributes to a decision about a person — and that decision has legal effect or significant impact, and the person thinks it harmed them — they have the right to ask you for a plain-English explanation of how the AI was used and what the main factors in the decision were.

This applies to most Annex III systems (critical infrastructure is excluded). It’s narrower than the existing GDPR right to challenge automated decisions, but it complements that right rather than replacing it. The point: if you’re using AI in hiring, lending, public benefits, insurance underwriting, or anything similar, you need an explanation flow ready. Not “the algorithm decided”. Plain language about what the system did and what mattered.

Build this in from day one. Retrofitting explanations after a system has been live for a year is painful, and the deadline is fixed.

Incidents, penalties, and the calendar

If something seriously goes wrong, you’re on a tight clock.

A “serious incident” — death, serious harm, infrastructure disruption, fundamental rights breach, or major property or environmental damage — has to be reported to the national market surveillance authority within 15 days of you or the provider establishing a causal link. 10 days if a person has died. 2 days for a widespread fundamental rights breach or a serious irreversible disruption of critical infrastructure. You can file an initial incomplete report and follow up — but you can’t file late.

Most organisations I’ve worked with have nothing resembling an AI-incident reporting workflow. If you’re a deployer of high-risk systems, building one this year is non-optional.

Penalties for breach of deployer obligations can reach €15 million or 3% of worldwide annual turnover, whichever is higher. Penalties scale with the size of the offender. Large companies as mentioned, face up to €15M or 3% of worldwide turnover, whichever is higher, for breaching deployer obligations. SMEs and start-ups (under 250 employees and €50M turnover) get the lower of the two — meaning a small company’s exposure is essentially capped at 3% of its own revenue. A €5M-revenue start-up’s maximum is €150,000, not €15M.

The headline-grabbing tier above (€35M / 7%) is reserved for breaching the absolute bans on certain AI uses, like real-time mass biometric surveillance. The lower tier (€7.5M / 1%) is for lying to regulators. SMEs and start-ups get the lower of the cap and the percentage — a real concession but not a small-fines regime.

The calendar for high-risk-system deployers:

• 2 February 2025: prohibited AI practices already in force
• 2 August 2025: GPAI rules, governance, and the penalty framework already in force
• 2 August 2026: high-risk deployer obligations apply broadly — this is your date
• 2 August 2027: high-risk AI in regulated products covered by existing EU product safety rules

High-risk systems already in use before 2 August 2026 don’t have to retrofit unless you significantly change them after that date — but the moment you do, you’re back in scope. Public-sector pre-existing systems get until 2 August 2030. There’s no general grace period for new deployments after the application date.

What to actually do this quarter

If you take nothing else from this, take these:

1. Inventory your AI use. Every system, every vendor, every workflow. For each one: does it touch hiring, performance, credit, insurance, education, biometrics, public services, law enforcement, migration, or justice? If yes, flag for high-risk review.

2. Get the provider’s classification in writing. For every Annex III-adjacent system, ask the provider: do you classify this as high-risk, or are you claiming the exemption? Get the documentation. If they can’t answer, that’s a procurement signal.

3. Map your “deployer becomes provider” exposure. Where are you fine-tuning, white-labelling, or repurposing AI? Each one is a candidate for accidental provider status. Prioritise reviewing those.

4. Set up an incident workflow. Who decides a serious incident has happened? Who reports it to the provider and the authority? Who tracks the 2/10/15 day clocks? Build it before you need it.

5. For credit, insurance, public-services and public-body deployers: start your FRIA. The official template will land later but the structure of what goes in it is already specified. You can begin now.

6. Talk to your works council. If a high-risk AI system is going into the workplace, the worker-information requirement is binding from day one. Build the conversation into your rollout plan.

7. Design the explanation flow. For every Annex III system that makes decisions about people, plan how plain-English explanations will be generated and delivered. This is mostly a product and process question, not a legal one.

The AI Act will not, in itself, kill responsible AI adoption inside organisations. The companies that get hurt are going to be the ones that treated it as a Brussels problem about model makers, woke up in mid-2026, and discovered the law was about them all along.

The signal to take seriously isn’t the headline penalties. It’s that the law is finally catching up with the gap between “we deployed AI” and “we know what it’s doing”. That gap is the actual problem in most enterprise AI rollouts I see. Closing it for the regulator happens to also close it for your customers, your board, and your own engineers.

Which is to say: this is a forcing function for the discipline you wanted to have anyway.

In our service model egoHive/dataHive is something that alleviates these issues (demo available if needed), but I would always consult with a professional lawyer as my knowledge on this subject is a layman, so this shouldn’t be treated as legal advice.