Unintentionally Becoming an AI Provider

Most companies that use AI are deployers. They use ready-made systems and carry the corresponding deployer obligations. The more extensive provider obligations do not apply to them. That is the theory. In practice, however, a deployer can become a provider faster than expected, often without noticing.

Three routes from deployer to provider

Article 25 of the EU AI Act defines three scenarios in which a deployer becomes the provider of a high-risk system and thereby takes on all provider obligations: conformity assessment, technical documentation, CE marking, a quality management system.

The first scenario concerns brand use. Whoever distributes a high-risk AI system already on the market under their own name or brand becomes a provider. That is understandable and usually a conscious decision.

The second scenario concerns substantial modifications. Whoever changes a high-risk system so that it no longer matches the original conformity assessment or receives a new purpose of use becomes a provider. That too is usually an active decision, for example with fine-tuning using your own data.

The third scenario is the problematic one: whoever changes the intended purpose of an AI system so that a non-critical system becomes a high-risk system also becomes a provider. And here lies the trap.

The GPAI problem

Most companies today use general-purpose systems. ChatGPT, Claude, Copilot and similar tools are deliberately not intended for specific use cases. Their intended purpose is broad: text generation, analysis, assistance. No high-risk.

What happens when an employee uses such a system for applicant assessments? Or for performance evaluations? Or to pre-assess loan applications? The use case falls under Annex III, so high-risk. The system was not intended for this. The intended purpose has, in effect, been changed.

The regulation speaks of modification of the intended purpose, but does not define precisely what counts as a modification. Is mere use enough? Or does it require active adaptations like system prompts, knowledge bases, workflow integrations? The EU Commission’s guidelines on this are still pending.

Why this is dangerous

The first two scenarios are controllable. Nobody accidentally puts their brand on someone else’s AI system. Nobody accidentally retrains a model. The third scenario is different. It can happen gradually, in a decentralised way, without the compliance officers finding out.

A team in HR experiments with ChatGPT for pre-selection. A clerk uses an AI tool to assess the risk of customer enquiries. A department head builds an internal assistant for performance feedback. Each individual case could trigger the switch from deployer to provider.

The consequences are significant. Provider obligations for high-risk systems are extensive: a risk management system, technical documentation, conformity assessment, EU database registration, post-market monitoring. The effort is many times what deployers have to provide. And the company may not even know it has these obligations.

The provider terms-of-service trap

The providers of the large GPAI systems are aware of this risk. In their terms of use they often explicitly exclude high-risk applications. In its enterprise AI terms, Microsoft prohibits applications with significant impact on employment, finance or fundamental rights without appropriate human oversight. Google excludes clinical applications and medical advice.

That worsens the situation. If the original provider has clearly communicated that its system is not intended for high-risk purposes, it may, under Article 25, have no obligation to supply the unintentional new provider with documentation or support. The company is left on its own.

What SMEs should do

The first step is awareness. Employees have to know which use cases fall under Annex III. That is part of the AI literacy under Article 4. Whoever does not know what high-risk means cannot recognise when a use becomes problematic.

The second step is clear internal guidelines. Which AI tools are approved for which purposes? Where are the limits? An explicit ban on using general AI systems for HR decisions, credit assessments or similar high-risk areas creates clarity.

The third step is the right tool selection. For high-risk applications, systems should be used that are explicitly intended for them and assessed accordingly by the provider. An HR tool certified as a high-risk system makes the using company a deployer with manageable obligations. A general-purpose chatbot repurposed for the same task may make it a provider.

The logic behind it

The EU AI Act follows an understandable principle: high-risk applications require specialized, tested systems. The regulation wants to prevent companies from using general-purpose AI for critical decisions without anyone taking responsibility for quality and safety.

If no provider bears this responsibility, because the system was not intended for this purpose, it falls to whoever uses it that way anyway. That is the inner logic of Article 25. Not punishment, but the assignment of responsibility.

For companies this means: the freedom to use AI tools flexibly has limits. Whoever knows and respects these limits remains a deployer. Whoever ignores them becomes a provider unintentionally and faces a compliance effort that exceeds the original time saving many times over.

---

About the author

Jochen Stier is co-founder of NADOVO with over 20 years of experience in process management and IT service management. He helps German SMEs implement the requirements of the EU AI Act systematically and pragmatically. His 5-phase framework NADOVO combines regulatory requirements with practical feasibility, without enterprise budgets or complex tools.

Further reading:

• Art. 25 EU AI Act full text
• EU AI Act compliance: a guide