What's Your Role Under the EU AI Act? Practical Decision Tree.
Provider. Deployer. Importer. Distributor. Authorized Representative.
You’re in a meeting room with six people who’d rather be somewhere else. The subject line said “AI Act — Role Classification Workshop.” Two hours, blocked calendars, mandatory attendance. The energy is exactly what you’d expect.
You’ve got a shared spreadsheet on the screen. Every AI system the company uses, fourteen of them as of last Thursday’s count. You’re working through them one at a time. Column D says “Our Role Under the EU AI Act”. You type deployer for the first one. A vendor’s analytics tool. Easy. Deployer for the second, a customer service chatbot from a SaaS platform. Deployer for the third. You’re making good progress. Maybe this won’t take two hours.
Then the head of data science mentions, casually, like it’s obvious, that his team has been fine-tuning one of the vendor models on the company’s proprietary data for the past six months. “Same tool, just trained on our stuff.” You stop typing.
Someone from marketing adds that they rebranded the vendor’s customer-facing interface. The company’s logo, the company’s name, the company’s colour scheme. “It just looked better.” You look at column D.
Then the colleague from the EU subsidiary, the one who joined the call from Frankfurt, asks a question you weren’t expecting: “We’re the ones who brought the US vendor’s system into Europe. Does that make us the importer?”
Your clean column of deployer, deployer, deployer now has three question marks. And you’re not even halfway through the list.
The Question Before All Other Questions
The EU AI Act has a lot of moving parts: risk classification, conformity assessment, prohibited practices, transparency obligations, deadlines that keep shifting. But before any of that matters, there’s a prior question:
What are you?
Your role determines your obligations. A deployer’s life fits on one page: operational duties, human oversight, inform people when AI is making decisions about them. A provider’s life is a different job entirely. Quality management system. Technical documentation. Conformity assessment. CE marking. Post-market monitoring. Incident reporting. The difference between the two isn’t negligible.
And unlike GDPR, where both controllers and processors carry real obligations, the EU AI Act creates a sharp asymmetry. Getting your role wrong means either over-investing in obligations you don’t have, or not meeting obligations you do. Neither is free.
The regulation defines five roles. Many commentaries cover only two. This piece covers all five and gives you a way to assign them.
If you’re not sure whether the EU AI Act applies to your company at all, especially if you’re outside the EU, that question comes before this one.
The Five Roles:
1. Provider — Article 3(3)
A person or entity that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Whether for payment or free of charge.
Two elements, both required. First: you developed it, or you had someone develop it for you. Second: your name is on it. Miss either element and the definition doesn’t apply.
The part that catches companies: “puts it into service” includes internal use. A company that builds an AI system for its own operations, not selling it, not licensing it, is a provider. It developed the system and put it into service under its own name. The fact that it never left the building doesn’t matter.
“Provider” doesn’t mean “seller”.
2. Deployer — Article 3(4)
A person or entity using an AI system under its authority, except for personal non-professional use.
The simplest definition and the most common role. You bought or licensed an AI system. You use it in your business. You didn’t build it. You didn’t put your name on it. Deployer.
“Under its authority” means the company controls the deployment, not the individual employee who clicks the button. The company is the deployer. The employee is the user. This matters because deployer obligations (monitoring, human oversight, informing affected people) attach to the entity with operational control.
However, the risk here is that this role can change without you noticing. Rebrand the system, substantially modify it, or repurpose it into a high-risk use case, and Article 25 transforms you into a provider. No grace period. No transition window. The moment it happens, provider obligations apply.
For the deep dive on when a deployer becomes a provider, including the substantial modification analysis and what “foreseen in the conformity assessment” actually requires, see the separate piece:
3. Importer — Article 3(6)
An EU-based entity that places a non-EU provider’s AI system on the Union market, where the system bears the non-EU provider’s name or trademark.
The importer is the compliance gatekeeper at the EU border. They don’t need to understand the system’s internals the way the provider does. They need to verify that the paperwork is in order: conformity assessment done, technical documentation marked down, CE marking affixed, authorized representative appointed (Article 23).
Two things make this role less straightforward than it sounds:
First: it was designed for physical supply chains. Products crossing borders, intermediaries handling goods. For cloud-based AI systems delivered as SaaS, the concept of “placing on the market” doesn’t map cleanly. If a US company offers an AI system directly to EU customers through its website, with no intermediary, there’s no importer. The US company is the provider, subject to the regulation through its mandatory authorized representative.
Second: if the importer puts its own name on the system instead of the non-EU provider’s, that’s rebranding. Article 25(1)(a) kicks in. The importer becomes the provider. Congratulations on your new compliance obligations.
4. Distributor — Article 3(7)
An entity in the supply chain, other than the provider or the importer, that makes an AI system available on the Union market.
The lightest role. A tech reseller. A value-added reseller bundling an AI system with other services. A retailer stocking AI-enabled devices. The distributor’s job is verification: check the CE marking, check the conformity documentation, don’t distribute non-compliant systems, report problems up the chain (Article 24).
The “value-added” part of value-added reseller is where the role gets fragile. If the value you’re adding involves modifying the system, training it on custom data, or rebranding it, you may have crossed from distributor into provider territory. Article 25 applies to distributors too.
The lightest role in the regulation turns out to have a trapdoor.
5. Authorized representative — Articles 22 and 54
An EU-based entity appointed by a non-EU provider, through a written mandate, to perform certain compliance obligations on the provider’s behalf.
This isn’t an optional service. Non-EU providers of high-risk AI systems must appoint one before making their systems available in the EU (Article 22). Non-EU providers of general-purpose AI models must do the same (Article 54).
Three things about this role that aren’t obvious:
The authorized representative can be fined. They qualify as an “operator” under Article 3(8). The same penalties that apply to providers (up to €15 million or 3% of global annual turnover) apply to them. This is not a paperwork role. It’s a liability position.
The authorized representative must blow the whistle on its own client. Article 22(4): if the representative considers or has reason to consider the provider is acting contrary to its AI Act obligations, it must terminate the mandate and immediately inform market surveillance authorities. Not may. Must. The regulation built a compliance-cop function into what looks like a commercial relationship.
And for GPAI models, the representative’s exposure extends beyond the model itself. They must cooperate with authorities investigating downstream AI systems that integrated the GPAI model, even though their mandate comes from the model provider, not the system provider.
Who needs to think about this role?
Non-EU companies selling high-risk AI into the EU (they need to appoint one),
EU-based companies buying from non-EU providers (importers must verify one exists under Article 23(1)(d)), and
EU entities considering serving as authorized representatives (they need to understand the liability before they sign).
The Decision Tree
To decide on your company’s role, for each AI system your company touches (not once per company, once per system) walk through these steps:
Step 1: Did you develop (or have developed) the AI system?
YES, and your name or trademark is on it? You are a provider. Full provider obligations apply under Articles 16-21. This includes internal use. If you built it for your own operations, you’re “putting it into service” under your own name, which is one of the two paths to provider status alongside “placing on the market”.
YES, but someone else’s name is on it? The entity branding it is likely the provider. You’re a development contractor. Your obligations should be governed by a written agreement (Article 25(3)), but you’re not the provider under the regulation.
NO: go to Step 2.
Step 2: Are you using an AI system under your authority for business purposes?
YES: provisionally, you’re a deployer. But before you stop here, check the Article 25 triggers:
Have you put your name or trademark on a high-risk AI system that was already on the market? If so, you’re now a provider under Article 25(1)(a).
Have you made a substantial modification to a high-risk AI system? A modification not foreseen in the original conformity assessment that affects compliance or changes the intended purpose? You’re a provider under Article 25(1)(b). If you’re not sure whether your modification qualifies (and this is the hardest question in the entire regulation) the Provider vs. Deployer article covers the analysis in detail. The short version: if you’ve changed the model architecture, modified decision logic beyond vendor-specified parameters, or used the system for a purpose the vendor didn’t assess, treat yourself as a provider until you can confirm otherwise.
Have you changed the intended purpose of an AI system so that it now falls into a high-risk category? If so, you’re a provider under Article 25(1)(c). No code change required. Just a different use case.
None of the above? You’re a deployer. Article 26 obligations apply.
NO: go to Step 4.
Step 3: Are you in the supply chain?
YES and you are first EU-based entity placing a non-EU provider’s system on the market (under the non-EU provider’s name)? You’re an importer. Obligations under Article 23 apply to you.
YES but another entity in the supply chain making it available? You’re a distributor. Obligations under Article 24 apply to you.
NO: go to Step 4.
Step 4: Are you a non-EU provider?
YES: You must appoint an authorized representative in the EU. Obligations under Articles 22 or 54 apply to you, depending on whether you are providing a high-risk AI system or GPAI model.
NO: None of the above? Check Article 2. You might be outside the scope entirely. Personal non-professional use is excluded. Research, testing, and development before market placement or putting into service are excluded. Systems for exclusively military purposes are excluded.
The GPAI Layer — When Foundation Models Complicate the Picture
If you’re building anything on top of a foundation model, and in 2026 that covers a lot of companies, the role question has an extra dimension.
Most modern AI deployments involve at least two regulatory actors. Sometimes three.
Layer 1: The GPAI model provider. OpenAI for GPT, Anthropic for Claude, Meta for Llama, Google for Gemini. Obligations under Chapter V: technical documentation, copyright compliance, training data summaries, and for systemic-risk models, evaluation and adversarial testing.
Layer 2: The AI system provider. The company that takes the foundation model and wraps it in a product: a chatbot, a document analyzer, a recruitment screener, a diagnostic tool. If that system is high-risk, full provider obligations under Chapter III apply.
Layer 3: The deployer. The company using the system in its operations. Article 26.
Each layer carries its own obligations. The GPAI model provider’s obligations don’t cover the system built on top of the model. The system provider’s obligations don’t reach down into the model’s architecture. Separate tracks, separate responsibilities.
Four scenarios
You use ChatGPT through the web interface for general business tasks. You’re a deployer. OpenAI is the provider of both the GPAI model and the AI system. You’re using it. That’s it.
You integrate the OpenAI API into your own product and sell it. You’re the provider of an AI system. OpenAI is the GPAI model provider at Layer 1. You built the system at Layer 2. If your system is high-risk (credit scoring built on GPT, for example) full provider obligations apply to you. OpenAI’s obligations are at the model level, not the system level.
A practical complication: your ability to comply depends partly on what the GPAI model provider gives you. Article 53(1)(b) and Annex XII require GPAI model providers to share information about the model’s capabilities, limitations, and risks, information you need for your technical documentation and risk assessment. If that documentation is thin, you face a compliance gap that isn’t fully within your control. Your contracts with the GPAI model provider need to address this.
You fine-tune an open-source model (Llama, for example) and deploy the resulting system. You’re the provider of whatever AI system you build with the fine-tuned model. Whether you also become a GPAI model provider depends on how far you went. The Commission’s GPAI Guidelines use an indicative threshold: if the compute used for fine-tuning exceeds one-third of the compute used to train the base model, you may become a GPAI model provider for the modified model. Most fine-tuning falls well below this.
One thing that doesn’t cascade: Meta’s open-source exemption. The lighter GPAI model provider obligations that Meta benefits from don’t extend to you. Your obligations as the AI system provider are unaffected by what the model provider’s obligations look like. Their exemption is theirs.
You build a RAG system on a foundation model via API. You connect a foundation model to your company’s knowledge base and deploy it as an internal tool or customer-facing assistant. You are the AI system provider. If you also use it internally, you’re both provider and deployer of the same system.
Multiple Roles: the Norm, Not the Exception
The EU AI Act doesn’t prevent a single entity from holding multiple roles simultaneously. In practice, most companies of any size will.
A company that builds a proprietary AI tool for its core product (provider) while using off-the-shelf AI tools from vendors for HR, marketing, or operations (deployer for each). Three, four, five different role classifications across different systems. That part is straightforward. The harder versions:
Provider AND deployer of the same system
A company that builds an AI system for its own internal use. It’s a provider because it developed the system and put it into service under its own name (Article 3(3)). It’s also a deployer because it’s using the system under its authority (Article 3(4)). No mutual exclusivity clause in the regulation.
The dual classification matters because the deployer role creates specific obligations the provider role alone doesn’t cover.
Article 26(11): informing affected natural persons. The provider’s transparency obligation runs toward deployers (instructions for use). The deployer’s obligation runs toward the people affected by the system’s output. When you’re both, you bear both transparency flows.
Article 26(7): informing workers’ representatives before deployment. This triggers through the deployer role, not the provider role.
Article 27: the fundamental rights impact assessment. For public bodies and certain private entities, this obligation applies per the deployer role. A public hospital that builds its own diagnostic AI is a provider, but the FRIA triggers through its deployer capacity.
Article 26(2): human oversight. Providers must design systems to enable oversight (Article 14). Deployers must assign competent, trained people to perform it. When you’re both, you must do both. Design the capability and staff the function. Different obligations, same entity.
Distributor who starts customizing
A reseller distributes a vendor’s AI system. Over time, the reseller starts offering a “customized” version: training the system on industry-specific data, adjusting parameters, putting its own logo on the interface. The reseller started as a distributor. It may have crossed into provider territory through substantial modification or rebranding. The obligations don’t shift gradually. They shift all at once, the moment Article 25 triggers. One day you’re checking CE markings. The next you need a conformity assessment.
The practical implication
Don’t assign one role to the company. Assign roles system-by-system. Build a register that tracks, for each AI system: what it is, what your role is, when you last assessed that role, and what would trigger reassessment (modification, retraining, new use case, contract renewal).
One note on risk categories for that register: the EU AI Act doesn’t use the terms “limited-risk” or “minimal-risk.” Those are common shorthand but not regulatory categories. The actual tiers: prohibited practices (Article 5), high-risk systems (Article 6, Annexes I and III), systems with specific transparency obligations (Article 50), and everything else.
The Grey Zones
“Had developed” and whose name is on it
The provider definition has two cumulative elements: develops or has developed, AND places on market or puts into service under its own name or trademark. Both must be present.
A company commissions a vendor to build a custom AI system. The vendor brands it. Even if the company “had it developed” (detailed specs, iterative reviews, full design control) the vendor’s name is on the product. The company isn’t the provider. The vendor is. The company is a deployer of a customized product. That part is clear.
The real grey zones are elsewhere. A company commissions a system for internal use. No product label, no marketing, no brand on the interface. Whose “name” is it under? Internal deployment might constitute putting into service under your own name. The company is the entity operating the system and taking responsibility. But the regulation was written with market-facing branding in mind, not internal tools. The text doesn’t address this directly.
Or: two companies co-develop an AI system. Both contribute to the design. Both names appear. Article 3(3) doesn’t say there can be only one provider. But the regulation’s obligations (conformity assessment, technical documentation, quality management) are designed for a single accountable entity. How do you split them between two co-providers? The regulation doesn't directly address this. Article 25(3) requires written agreements when a deployer, distributor, or importer assumes provider status — a succession scenario, not a joint-development one. By analogy, co-providers would need a similar agreement allocating obligations, but the text doesn't prescribe one. The regulatory classification itself remains ambiguous.
SaaS and the importer question
The importer and distributor roles were designed for physical products. A US company offering an AI SaaS directly to EU customers, with no intermediary, creates no importer. No distributor. The US company is the provider, subject to the regulation through its authorized representative.
An EU company reselling access to a US-built AI SaaS might be an importer or a distributor. But “placing on the market” was defined in Article 3(9) for products, not services. The definition is doing a job it wasn’t designed for.
For most companies: if you’re using an AI SaaS tool, you’re a deployer. The SaaS vendor is the provider. Importer and distributor questions arise mainly for companies that resell or redistribute AI products, not end users.
Embedded AI and the Omnibus
AI embedded in a medical device, a car, an industrial machine. The EU AI Act applies alongside the relevant sectoral legislation: Medical Devices Regulation, Vehicle Safety Regulation, Machinery Regulation. Who’s the AI system provider? The product manufacturer? The AI component supplier?
The Digital Omnibus on AI, the simplification package provisionally agreed on May 7, 2026, changes this picture.
Machinery products with embedded AI are now exempted from AI Act high-risk obligations entirely. They comply with the Machinery Regulation only. For other sectors (medical devices, automotive, aviation) the Commission can adopt implementing acts to limit the AI Act’s application where sectoral legislation already covers equivalent ground. Until those implementing acts land, the overlap persists.
The omnibus also extended timelines. Standalone Annex III high-risk systems: 2 December 2027 (pushed from August 2026). Annex I product-embedded systems: 2 August 2028 (pushed from August 2027). Obligations already live (prohibited practices, AI literacy) are unaffected.
The omnibus is provisional as of June 2026. Formal adoption is expected before August 2026. Verify the adopted text before acting on the extended timelines.
The Practical Steps
1. Build the AI inventory
Before you can assign roles, you need to know what AI systems your organization touches. This is harder than it sounds. AI is embedded in tools people don’t think of as “AI”.
What to inventory:
systems you built or commissioned (provider candidates),
systems you bought or licensed (deployer candidates),
systems you resell (distributor or importer candidates),
foundation models you build on (system provider candidates),
AI-powered features within broader platforms you use (deployer candidates).
And the one that keeps surfacing in every assessment I’ve seen: AI systems employees are using without formal procurement. Shadow AI. You’re still potentially a deployer.
2. Classify risk, then assign roles
For each system, determine the risk level first. Is it high-risk? Most EU AI Act obligations for deployers, importers, and distributors only apply to high-risk systems. Providers carry some obligations regardless (AI literacy under Article 4, transparency under Article 50), but the heavy requirements are for high-risk.
Then run each system through the decision tree. Document your reasoning. This isn’t just good practice. It’s the evidence a regulator will want to see.
3. Check for Article 25 triggers
For every system where you’re initially a deployer, distributor, or importer, check whether anything you’ve done transforms your role. Rebranding. Substantial modification. Repurposing into a high-risk category. If any of these apply, you’re a provider for that system.
4. Map the GPAI layer
For every system built on a foundation model: identify the GPAI model provider, confirm they’re providing the Annex XII information you need, and ensure your contracts address the information-sharing gap. If you’ve fine-tuned the model, check the one-third compute threshold from the Commission’s GPAI Guidelines.
5. Check cross-border dynamics
Non-EU provider? Has it appointed an authorized representative? Are you the first EU entity handling the system? That might make you the importer.
6. Document and revisit
Role assignment isn’t a one-time exercise. Set triggers for reassessment: every modification or retraining, every new use case, every contract renewal. When the Commission publishes guidance (particularly the still-pending guidance on substantial modification) reassess in light of it.
At minimum: annually.
Column D Problem
It’s been ninety minutes. The spreadsheet has changed. Column D has a mix of provider, deployer, one importer, and four entries that say needs further assessment. The head of data science is having a quiet crisis about the fine-tuning. Marketing is Googling “rebranding AI Act Article 25”. The colleague from Frankfurt is reading Article 23 on her phone.
This is the meeting nobody wanted to have. And it’s the most important meeting the company will have about the EU AI Act, because every other question depends on this one. Risk classification depends on your role. Obligations depend on your role. Deadlines, documentation, conformity assessment: all of it flows from what you are.
The answers exist. The definitions are in Article 3. The transformation triggers are in Article 25. The obligations are in Articles 16-26. The decision tree works.
The answers are also per system, not per company. They change when the system changes. And the regulation doesn’t wait for you to figure it out.
Column D isn’t going to fill itself.
Thanks for this. Your "the deployer role can change without you noticing" is the sharpest observation in an already sharp piece, and it's more structurally true than the legal framing alone captures. The system-by-system role classification you prescribe runs directly into the fact that most organizations can't enumerate the systems they'd need to classify: surveys across enterprise deployments show more than 50% lack any systematic AI inventory, and roughly 60% of AI systems run outside IT visibility. The silent deployer-to-provider transition isn't an edge case to watch for; it's the modal enterprise situation, and it's structurally invisible precisely because the AI inventory that would surface it is the single most common governance gap. Your decision tree is well-designed; the problem is that step one is failing before step two begins.