AI Act Role Mapping: Provider, Deployer, Importer and Distributor

This article accompanies Hour 3: EU AI Act Scope, Obligations and Governance in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.

A company buys an AI tool from a vendor, configures it for its own terminology, connects it to its customer database, embeds it into a client portal and then offers the enhanced service to its own clients.

At the first procurement meeting, the answer sounds simple: the vendor is the provider and the company is the customer. By the time the system is live, that answer may be too thin. The company may be using the AI system under its own authority. It may also have changed the intended purpose, added its own branding, integrated the tool into a regulated service, or made the system available to others. Each of those facts can matter.

That is why AI Act role mapping is not a decorative exercise. It determines which evidence the organisation should ask for, which obligations may sit internally, which contractual terms matter, and when the privacy team should slow a deployment down long enough to understand what has changed.

For DPOs and privacy leads, the role map also needs to sit beside GDPR analysis. The AI Act does not replace controller and processor mapping. A company may be a deployer under the AI Act and a controller under GDPR. A vendor may be a provider under the AI Act and a processor for some personal data processing, while acting as an independent controller for analytics, security monitoring or model improvement. If those maps are collapsed into one field, the governance record will probably mislead the people relying on it.

This article is general CPD-support information, not legal advice on a specific AI system. The classification and role outcome will depend on the system, intended purpose, contractual structure, market placement, modification and real-world use.

Why Role Mapping Comes First

The EU AI Act is a risk-based regime, but risk classification depends on knowing what system is being assessed and which actor is doing what with it. A privacy team cannot sensibly ask for provider documentation, deployer instructions, transparency wording, DPIA evidence or human oversight controls until it knows where the organisation sits in the AI value chain.

The Act uses several core roles. A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trade mark. A deployer uses an AI system under its authority, other than for purely personal non-professional activity. An importer places on the EU market an AI system bearing the name or trade mark of a person established outside the EU. A distributor makes an AI system available on the EU market in the supply chain, other than as provider or importer.

Those definitions are practical, not academic. They affect who must supply instructions, who must hold technical documentation, who must monitor post-market performance, who must keep logs, who must cooperate with authorities, and who is responsible if the system is substantially modified.

Article 25 is especially important for organisations that customise or wrap third-party systems. A deployer, importer, distributor or other third party can be treated as the provider of a high-risk AI system in certain circumstances, including where it places its own name or trade mark on the system, makes a substantial modification, or changes the intended purpose in a way that makes the AI system high-risk. That means a company cannot rely forever on the role label assigned at purchase. Role mapping must be revisited when the system is configured, integrated, repurposed, branded or offered to others.

The Working Scenario

Imagine a professional services company, Northbridge Advisory. It buys an AI document review tool from a non-EU vendor. The tool can summarise documents, identify themes, rank files by urgency and draft suggested responses. Northbridge then:

• configures templates for its own service lines;
• connects the tool to its client document management system;
• adds a branded client portal so clients can upload documents;
• uses the tool internally to prioritise work;
• offers AI-assisted review as part of a paid client service.

At the intake stage, the privacy team is told: "It is just a vendor tool. We are not building AI." That may be true for some parts of the arrangement. It is not enough for governance.

The DPO's first task is not to pronounce a final legal answer. It is to make the facts visible. Who developed the system? Who places it on the EU market? Is there an EU importer or distributor? Who controls configuration? Is Northbridge changing the intended purpose? Are clients interacting directly with the AI feature? Is personal data uploaded? Does the system rank people, recommend decisions or affect access to services? Are outputs used only as drafting support, or do they shape decisions about individuals?

The role map should be built around those facts, not around the commercial label "customer".

A Practical Role-Mapping Table

The following table shows how a privacy team might document the first version of the Northbridge analysis. It is simplified, but it shows the kind of record that can support a real governance discussion.

This table does not pretend the answer is always obvious. It shows the decision points. That is the point of the role-mapping exercise: not to create legal theatre, but to stop hidden assumptions from turning into operational risk.

What Is Still Unknown

In the Northbridge scenario, the privacy team should not approve deployment from the first table alone. Several facts remain open.

The vendor's intended purpose may be broad or narrow. The tool may be marketed for general document productivity, or specifically for regulated legal, financial, employment or insurance decision support. Northbridge may be using the tool in a way the vendor expected, or may be stretching it into a new context. The system may process only business documents, or may process sensitive personal data, complaint material, health information, employment records or data about vulnerable individuals.

The technical integration also matters. If Northbridge simply uses a hosted interface, deployer analysis may be relatively straightforward. If it fine-tunes a model, creates its own scoring layer, suppresses provider safeguards or embeds the AI output into an automated client-facing workflow, the role and risk analysis may change.

The decision question for the privacy team is therefore: can the organisation evidence that it is using the system within the provider's intended purpose and instructions, with appropriate GDPR controls, or has it moved into a role that carries greater AI Act responsibility?

Checks the DPO or Privacy Team Should Perform

A useful role-mapping review is short enough to run before deployment, but structured enough to catch the real risks. For a system like Northbridge's, the DPO or privacy team should check:

• the specific AI system or model being used, including version, vendor, EU supply-chain actor and intended purpose;
• whether the organisation is using, branding, integrating, reselling, substantially modifying or changing the intended purpose of the system;
• whether the organisation is a deployer, provider, importer, distributor, product manufacturer or more than one of these across different uses;
• whether the system may be prohibited, high-risk, subject to transparency obligations, GPAI-related or minimal/no-risk in the specific context;
• what personal data is processed, whose data it is, whether special category or criminal offence data is involved, and whether outputs create inferences about people;
• the GDPR controller, processor or joint-controller position for each material processing activity;
• whether a DPIA, legitimate interests assessment, transfer assessment, vendor review or security review is required or already exists;
• whether provider documentation is sufficient to support use in the organisation's context;
• who owns human oversight, monitoring, complaints, incident escalation and review after deployment.

The role map should not be a one-off procurement attachment. It should have a review trigger. A new data source, new client use, new brand wrapper, model update, changed output type, new jurisdiction, new category of affected person or new reliance on the output can all justify revisiting the map.

Evidence That Should Exist Afterwards

After the review, the privacy team should be able to point to a small, coherent evidence pack. It does not need to be ornate. It does need to be usable.

For the Northbridge scenario, that pack should include a role-mapping decision record explaining the current AI Act roles and the assumptions behind them. It should include the GDPR role analysis separately, so that controller and processor conclusions are not confused with provider and deployer status. It should include the vendor evidence reviewed, any gaps or follow-up questions, the system's intended purpose, the actual use case, and the risk classification reached for that use.

The evidence pack should also connect to the DPIA or assessment notes, data-flow record, transparency materials, contract review, security review, human oversight procedure, user training record and post-deployment monitoring plan. Where a point remains uncertain, the record should say so plainly. A documented uncertainty with an owner and review date is better than a confident label that no one can defend.

A role map should also state what would trigger escalation. For example:

• the system is used for employment, recruitment, education, essential services, credit, insurance, healthcare, law enforcement or another sensitive decision context;
• Northbridge adds its own scoring or ranking logic;
• clients begin relying on outputs without meaningful human review;
• staff upload new categories of sensitive personal data;
• the vendor changes the model, intended purpose, hosting location or documentation;
• a complaint, incident, audit finding or regulator query challenges the system's use.

Those triggers matter because AI governance often fails at the point of change. The initial approval may be careful. The later configuration change may be invisible.

How This Connects to AI/DPIA Lifecycle Support

Role mapping is where AI Act governance and GDPR accountability first meet. The AI Act asks what the organisation is doing in the AI value chain. GDPR asks what the organisation is doing with personal data. Real systems usually require both answers.

That is why XpertDPO's AI Governance and DPIA Lifecycle Support is relevant for organisations that need a repeatable review model. The useful output is not a long theoretical memo. It is a working process that helps teams identify AI use cases, map roles, screen risk, request provider evidence, connect DPIA records, agree controls and review the system when it changes.

XpertDPO's DPIA Support and DPO Support are also relevant where the issue is not ownership of AI compliance as a whole, but disciplined challenge: are the assumptions sound, is the evidence sufficient, and does the organisation know who must act if the system behaves unexpectedly?

What This Means for CPD

For Event B Hour 3, the practical learning is that AI Act role mapping should be done before an organisation argues about fine legal detail. A DPO or privacy lead should be able to ask: what is the system, who provides it, who uses it, who modifies it, who offers it to others, what risk category is being assumed, and what evidence supports that assumption?

The smallest safe next step is to take one AI use case that is already live or close to launch and complete a role-mapping record beside the existing GDPR record. If those two records tell different factual stories, the organisation has found its first governance gap.

This article is intended to support the learning covered in Hour 3 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.