Provider or distributor, deployer on paper or for real? What the AI Act means for managed service providers and other providers deploying AI solutions for their customers – with role allocation, risk classification and a go-live checklist in five questions.
Matthias Allitsch-Wutte · GEKI founder
2 October 2026 · 10 min read
AI brings enormous possibilities. But AI also comes with responsibility. Especially when AI systems don’t just generate text, but use company data, talk to customers, prepare decisions or carry out actions themselves.
Not legal advice. This article gives practical orientation from an engineer’s point of view – it does not replace legal review of your specific case.
But we did take a closer look at what the AI Act means in very practical terms for managed service providers and other solution providers that deploy bots or other AI systems for their end customers. We write here from the day-to-day of a managed service provider – but the logic applies to anyone operating AI systems for others.
One thing matters here: It fundamentally doesn’t matter which provider and which model is behind it. Whether you implement a Copilot bot, build an AI system on Grok, OpenAI or Gemini, or run a sovereign AI solution on GEKI – the underlying questions are the same. What matters is not how powerful a model is, but what you use it for. The chain starts further up, with the provider of the base model and its own GPAI obligations – but that changes nothing about your questions. The AI Act cares less about the logo on the model than about the concrete deployment: What does the AI system do? Who offers it? Who operates it? Who controls it? And what risk does that create? These are exactly the questions every managed service provider – and any other provider operating AI for customers – should answer before a go-live.
As of October 2026: what already applies?
- Prohibited AI practices (e.g. social scoring) have applied since February 2025.
- Obligations for GPAI model providers (documentation, transparency) have applied since August 2025.
- High-risk obligations phase in gradually: partly from August 2026, for many Annex III cases from August 2027.
So going live today does not mean working towards some distant deadline – a good part of the AI Act already applies.
For the typical day-to-day work of a managed service provider, we focus on three roles:
Put simply, the provider is the party 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 – as the AI Act puts it:
“under its own name or trademark”
The distributor is an actor in the supply chain who makes an already existing AI system available on the market without being the provider themselves.
The deployer is the party that actually uses the AI system in its own organisation – the AI Act speaks of a person or organisation using an AI system
“under its authority”
And that definition is particularly important for managed service providers.
Being a pure distributor – selling, installing and supporting an existing solution unchanged – makes little sense for a managed service provider in the long run. Customers pay for added value: own workflows, adapted interfaces, own decision logic, automated processes, their own brand.
But exactly that added value usually turns the MSP into a provider. Whoever substantially shapes a system and delivers it under their own name carries the provider role – regardless of what the contract says.
Let’s take a simple email classification bot. The bot reads incoming emails and sorts them into the categories invoice, support and complaint, for example. The emails are then automatically routed to the right team.
The MSP takes an existing model or AI platform, builds its own “Smart Mail Bot” on top, develops its own workflows and its own interface, and sells that solution to customers under its own name – the role allocation can then look like this:
| Party | Role |
|---|---|
| Managed service provider | Provider |
| End customer | Deployer |
This is an important point: just because some other vendor’s model runs under the hood does not automatically mean the MSP is only an integrator in regulatory terms. If it turns that into its own AI system and offers it under its own brand, it can be the provider itself.
The MSP sells and implements an already existing AI solution from a vendor. It does not substantially modify the product and does not place it on the market under its own brand – the role allocation can then look like this:
| Party | Role |
|---|---|
| Vendor of the AI solution | Provider |
| Managed service provider | Distributor |
| End customer | Deployer |
This is likely the classic case for many managed service providers: they sell and implement an existing solution, configure it and support the customer in running it. But they are not automatically the provider of the AI system. Frankly, though, that delivers little added value for the customer – and is likely too little for many managed service providers in the long run.
In both cases, the end customer should be the deployer in a typical customer project – because the customer decides:
That matches the AI Act’s definition exactly:
“under its authority”
That is the key phrase.
And this is where it gets particularly important: it is not enough to put one sentence in the contract:
The customer is the deployer within the meaning of the AI Act.
The actual circumstances have to match: if the customer is supposedly the deployer, but:
then it may not hold up in practice.
The AI Act ties precisely to actual use under its authority. With high-risk systems, this idea becomes even clearer: for human oversight, Article 26 requires people with
“necessary competence, training and authority”
(ai-act-service-desk.ec.europa.eu)
So competence, training and real authority. In practice that means: someone functionally responsible at the customer has to actually be able to act – including the authority to stop the system.
With the email classification bot, we would watch five points.
For example:
The AI system classifies incoming customer emails and routes them to defined teams.
The customer defines this purpose, the MSP implements it technically.
Which mailboxes are connected, which documents may the system use, which information may be processed? Those decisions belong to the customer.
Who may use the system, what may the bot do – may it only classify, move emails, reply automatically, trigger downstream processes? With agents in particular, we always distinguish three levels:
Read → Write → Execute
The further right you go, the more governance matters.
For the email bot, that could be the head of customer service – this person decides whether:
The customer should be able to:
That is the practical expression of “under its authority”.
In my opinion, unnecessary fear gets created here at times: not every bot is high risk, and not every AI system needs a large compliance apparatus. A few typical examples:
| AI system | Typical purpose | Rough classification |
|---|---|---|
| Email classification bot | Sorts general customer mail | typically not high risk |
| IT helpdesk bot | Answers internal IT questions | typically not high risk |
| Knowledge bot | Searches company knowledge | typically not high risk |
| Sales assistant | Drafts quotes | typically not high risk |
| Customer service bot | Answers customer enquiries | typically not high risk; check transparency |
| Recruiting agent | Filters or scores applicants | potentially high risk |
| Employee performance system | Evaluates employee performance | potentially high risk |
| Credit scoring | Assesses creditworthiness of natural persons | potentially high risk |
| Education admission system | Supports admission decisions | potentially high risk |
| certain AI in critical infrastructure | Affects safety-relevant processes | potentially high risk |
The decisive point is: The model does not determine the risk class. The concrete use case does. One and the same technical platform can run a completely uncritical knowledge bot or a high-risk recruiting agent.
For many typical AI systems, the extensive high-risk obligations do not apply – a few things we would always check anyway.
People working with the AI system should understand:
That does not mean every employee needs a two-day compliance seminar. But: Whoever operates or administers an AI system should know what they are working with.
For AI systems that interact directly with people, Article 50 is relevant: people should generally be able to recognise that they are interacting with an AI system. For a customer service bot, that can be as simple as:
I am the AI assistant of Muster GmbH.
I think that makes sense – no five pages of disclaimer, just be transparent.
For high-risk systems, the requirements become considerably more extensive. For deployers, these include among others:
On logs, the AI Act gets concrete: insofar as automatically generated logs are under the deployer’s control, they generally have to be kept for an appropriate period of at least six months. (ai-act-service-desk.ec.europa.eu) Here too, you see it again: The deployer has to actually fill the role. Technically, the MSP can:
But the customer should know:
Distilled: before offering customers an AI solution, these five questions must be answered cleanly.
1. Is the MSP provider or distributor?
2. Who is really the deployer – not just according to the contract?
3. What exactly may the AI system do?
4. Is the use case high risk or not?
5. Who at the customer actually has control and can intervene?
As long as any of these questions is open, you don’t go live.
In our view, an opportunity – for the IT industry and especially for managed service providers.
The AI Act creates a safe framework in which everything runs in an orderly way: whoever operates AI in a controlled, traceable and responsible manner plays by clear rules. And that is exactly where managed service providers can score – with know-how, expertise and customer proximity instead of pure resale.
The service of the future is not:
We sell you the AI solution of a US giant – plus a one-hour training session.
But:
We bring your AI system into production in a controlled, traceable and responsible way.
For that, we consider the AI Act – for all the justified criticism of individual points – a rather usable framework.
Open models on European hardware, under your control – with full compliance, permissions, logs and everything you need to successfully roll out AI solutions at customer sites.
