The AI Act is a European Union regulation that organises obligations around artificial intelligence systems by risk class and by the role an organisation plays. A company that rolls out off-the-shelf tools is a deployer: it supports the AI literacy of its operating staff, ensures transparency where required and, for high-risk systems, follows the provider’s instructions and ensures human oversight.
Quick Overview
What you’ll learn:
- What a deployer is and how it differs from a provider of a system
- Which risk classes impose duties and which leave discretion
- What the duty to support AI literacy means for an ordinary team
- Where to start a compliance rollout so you do not start with a document
Who this article is for:
- People accountable for compliance and risk in mid-size organisations
- Managers rolling out AI tools inside business teams
- Process owners whose AI system supports decisions about people
Reading time: 7 minutes
Provider or Deployer: Everything Follows From This
The regulation separates roles and attaches a different weight of duties to each. A provider develops an AI system and places it on the market under its own name. A deployer uses the system under its own authority in the course of its activity. Importers and distributors hold intermediate roles that matter along the supply chain.
The distinction is not a formality. A company that buys a tool and uses it as intended remains a deployer. The same company becomes a provider if it puts the system on the market under its own brand or substantially changes its intended purpose — at which point duties that belonged to the manufacturer transfer to it. This is one of the few situations where a marketing decision moves regulatory accountability.
The second dimension is risk class. The regulation distinguishes prohibited practices, high-risk systems, systems subject to transparency obligations, and everything else, for which it sets no specific requirements. Most office tooling lands in the last group; the high-risk group covers uses such as recruitment, worker evaluation, access to services and critical infrastructure.
The Duties That Apply to a Deployer
The text of Regulation (EU) 2024/1689 published on eur-lex.europa.eu, in Article 26, requires a deployer of a high-risk AI system to use it in line with the provider’s instructions, to assign oversight to people with the necessary competence, and to monitor how the system operates. Article 4, as replaced by Regulation (EU) 2026/1744 from 27 July 2026, requires providers and deployers to take measures supporting the AI literacy of staff and others operating AI systems on their behalf, without having to guarantee any specific level for any individual. Article 50 imposes transparency duties towards people interacting with a system and in respect of machine-generated content.
High-risk systems add duties that are harder operationally: retaining event logs, informing workers that such a system is being used in relation to them, and in defined cases assessing the impact on fundamental rights. Under Regulation (EU) 2026/1744 (eur-lex.europa.eu), these high-risk provisions (Chapter III, Sections 1–3, including Articles 26 and 27) apply from 2 December 2027 to Annex III systems, such as recruitment and worker evaluation, and from 2 August 2028 to Annex I systems linked to products under EU harmonisation legislation. The practical consequence is that classifying a system is not an academic exercise — it decides whether instructions and training suffice or whether the process needs documenting.
The AI literacy duty is often read as an obligation to buy a course. The current wording asks for supporting measures that reflect people’s knowledge, experience and the context of use. A useful test is whether operators understand a system’s limits, know when an output needs verifying, and know how to report a malfunction. A course is one such measure, not evidence of the result.
Documenting What You Deployed
Oversight has a prerequisite that is easy to skip: knowing what the system was built for. Model documentation conventions described on huggingface.co — intended use, known limitations, evaluation data, out-of-scope uses — exist precisely so that whoever puts a model into a process can state its limits without reverse-engineering them. For a deployer that documentation is the raw material for a classification record: it says what the supplier claims, which is what the deployer’s own instructions have to stay inside.
Where the documentation is silent, that silence belongs in the record too. A system whose intended purpose cannot be established from supplier material is not thereby low-risk; it is a system whose risk nobody has yet assessed, and the person who put it into a process owns that gap.
Where the GDPR Meets the AI Act
Where an AI system processes personal data, Regulation (EU) 2016/679, available on eur-lex.europa.eu, applies alongside the AI Act. The frames ask different questions. The GDPR asks about the legal basis for processing, data scope, individual rights and the data protection impact assessment. The AI Act asks about the system’s risk class, human oversight, transparency and the competence of the people operating it.
Compliance with one frame does not deliver compliance with the other, though work already done for the GDPR usually reduces the effort. A record of processing activities is a natural anchor for an inventory of AI systems, and a data protection impact assessment is often where part of the risk analysis has already been written down. As amended by Regulation (EU) 2026/1744, Article 27(4) lets a deployer’s fundamental rights impact assessment cross-refer to, or include, relevant parts of its data protection impact assessment; it applies with the rest of Article 27, from 2 December 2027 or 2 August 2028 depending on the system category (text on eur-lex.europa.eu).
Keeping the registers separate can be pragmatic, on one condition: both must name the same process owner. Two registers with two different accountable people drift apart within a quarter.
Read Also
- AI Act 2026 — what changes for IT teams? — the schedule of changes and what they mean for technical work
- AI Act and Team Competencies - How to Prepare Your Company — the competence requirement from the organisational side
- IT risk management in practice: A Rollout Plan for Team Managers — the register these duties can be handled in without a separate process
Build Your Skills
This topic is developed in the AI Governance and EU AI Act — AI systems risk management and AI Act regulations in business practice courses. The first works on risk and oversight, the second on duties inside business processes. Contact us to match the scope to the role your organisation actually plays.
Frequently Asked Questions (FAQ)
Does the AI Act apply to a company that only uses off-the-shelf tools?
Such a company is a deployer. Whatever the risk class, it must support the AI literacy of its operating staff and, in the cases set out in Article 50, meet transparency duties. For high-risk systems, the Article 26 duties are added — following the provider’s instructions and human oversight among them — applying from 2 December 2027 or 2 August 2028 depending on the system category, under the amendments published on eur-lex.europa.eu. Provider duties — technical documentation, conformity assessment — stay with the manufacturer until the company places the system on the market under its own brand.
Is GDPR compliance enough to satisfy the AI Act?
No, because the two frames ask different questions. The GDPR governs the processing of personal data; the AI Act governs a system’s risk and the way it is used. An AI system may process no personal data at all and still carry duties, and a data protection impact assessment does not answer the question of risk class.
Where should a rollout start: with an inventory or with a policy?
With the inventory. A policy written before the actual state is known describes an idea of the company and parts company with practice at the first internal review. An inventory is also the only way to catch AI features embedded in tools bought earlier for an unrelated purpose.
Does the regulation require an external audit?
For most uses, no. Conformity assessment procedures apply to defined categories of high-risk systems and fall primarily on the provider. A deployer documents its own duties — classification and competence, plus oversight and monitoring for high-risk systems — and may review them internally, provided the review leaves a record.