Assign Roles to the Actual System
An organisation can hold several AI Act roles across different systems. Buying a commercial tool commonly makes it a deployer; developing or commissioning a system under its own name can make it a provider. Using an external model does not automatically remove responsibility for the system built around it.
The Main Roles
| Role | Core distinction in Article 3 |
|---|---|
| Provider | Develops or has an AI system/model developed and places it on the market or puts it into service under its name or trade mark |
| Deployer | Uses an AI system under its authority, outside personal non-professional use |
| Authorised representative | An EU-established party with the provider’s written mandate for specified obligations |
| Importer | An EU-established party placing a third-country-branded AI system on the EU market |
| Distributor | A supply-chain party, other than provider/importer, making an AI system available in the EU |
The exact legal definitions and activity matter. A missing representative does not automatically turn a reseller into an authorised representative; that role requires a mandate.
High-Risk Provider Duties
Article 16 and related provisions address compliance with system requirements, identification, quality management, retained documentation and logs, conformity assessment, declaration of conformity, marking, relevant registration, corrective action and cooperation with authorities.
The work required depends on the system and what evidence already exists. There is no universal implementation time or consulting package that establishes compliance for every SME.
High-Risk Deployer Duties
Article 26 includes using the system according to its instructions, assigning competent human oversight, ensuring relevant input-data quality where the deployer controls it, monitoring operation and acting on risks or incidents. It also addresses logs under the deployer’s control, with a qualified retention requirement, and specified information and registration duties.
Workplace deployment, public-authority use and decisions affecting individuals can trigger additional requirements. Determine what applies to the actual use rather than copying a generic checklist into a procurement contract.
When a Role Can Change
Article 25 covers cases where another party becomes the provider of a high-risk system, including specified rebranding, substantial modification and changes of intended purpose that bring a system into high-risk use.
For example, adapting an existing tool into a branded candidate-ranking service requires a new assessment of the resulting system. Fine-tuning alone is not a universal legal test: consider the system, the modification and intended purpose together.
Record this assessment before modifying a supplier’s solution. Contracts should address documentation and cooperation, but cannot simply erase responsibilities imposed by law.
General-Purpose Models Are a Separate Layer
Articles 53–55 set duties for GPAI model providers, with additional requirements for models with systemic risk and qualified exceptions for some open-source models. A downstream business needs the documentation relevant to building and operating its system; it does not necessarily receive every detail of a provider’s training process.
An internal assistant, a customer-facing chatbot and a creditworthiness system built on the same model can have different obligations. Brand names such as Copilot or GPT do not determine the legal classification of every deployment. Article 50 transparency duties must be assessed for the particular interaction and the party responsible.
FRIA and DPIA
Article 27 requires a fundamental-rights impact assessment for specified deployers of certain high-risk systems, including bodies governed by public law, private entities providing public services and certain credit/insurance uses, subject to the provision’s scope and exclusions. It is not a universal requirement for every employer using AI.
A GDPR data-protection impact assessment has its own trigger and content. The assessments may reuse evidence, but one does not automatically satisfy the other. Identify affected people, risks, oversight, complaint routes and the relevant notification process.
A Practical Supplier Conversation
Ask who is the model provider, system provider and deployer; what the system is intended to do; whether changes affect the classification; which instructions, logs and assessment evidence are available; and who monitors and responds to incidents. Record the answers and the decision owner.
From the Inventory to an Implementation Plan
Q-Journey includes AiP Express and Platinum, with Lean and Muda consulting in Platinum. The agreed project scope determines which processes and technical gaps are examined. A technical review does not itself certify legal compliance; legal classification and any required assessment need the appropriate accountable specialists.
Primary Source
Regulation (EU) 2024/1689 on EUR-Lex. This article explains the framework in the adopted regulation. For a deployment decision, use the current consolidated text, applicable guidance and the facts of the system; publication of this article does not establish the status of later amendments.