EU AI Act Provider vs Deployer: What SaaS Companies Must Understand

The EU AI Act places the heaviest obligations on providers of high-risk AI systems -- but most SaaS companies are also deployers of third-party AI they use internally. These roles carry different obligations, can apply simultaneously, and can shift under Article 25. Here is how to map your position.

One of the most consequential -- and most misunderstood -- distinctions in EU AI Act Regulation 2024/1689 is the difference between a provider and a deployer. Getting this wrong means either over-engineering your compliance programme or, more commonly, under-estimating your obligations and leaving yourself exposed to enforcement.

The Definitions

Provider (Article 3(3)): A natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.

Deployer (Article 3(4)): A natural or legal person, public authority, agency or other body that uses an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity.

The key difference: providers build and distribute. Deployers use.

Why SaaS Companies Often Get This Wrong

The confusion arises because most SaaS companies occupy both roles simultaneously -- they are providers of their own AI-powered product to their customers, and deployers of third-party AI (like an LLM API) within their product. Each relationship carries different obligations.

If your product uses GPT-4, Gemini, or Claude under the hood to deliver an output that affects hiring, credit, or other Annex III use cases -- you are a deployer of a high-risk AI system, regardless of whether you built the model.

Provider Obligations (Articles 8-17)

Providers of high-risk AI systems must:

  • Establish and maintain a risk management system (Article 9)
  • Implement data governance practices for training and validation data (Article 10)
  • Prepare and maintain technical documentation (Article 11, Annex IV)
  • Enable automatic logging (Article 12)
  • Ensure transparency to deployers (Article 13)
  • Design for human oversight (Article 14)
  • Achieve accuracy, robustness, and cybersecurity standards (Article 15)
  • Implement a quality management system (Article 17)
  • Complete a conformity assessment (Article 43) and register in the EU database (Article 49)
  • Affix CE marking where applicable

Deployer Obligations (Articles 26-29)

Deployers of high-risk AI systems must:

  • Use the AI system in accordance with the provider's instructions for use
  • Assign human oversight to competent persons and ensure they receive adequate training (Article 26(1))
  • Monitor the operation of the high-risk AI system (Article 26(5))
  • Inform affected workers and their representatives when AI is used in the workplace (Article 26(7))
  • Conduct a Fundamental Rights Impact Assessment where required (Article 27)
  • Log operation to the extent within their control (Article 26(6))
  • Inform individuals that they are subject to automated decision-making where applicable

Scenario Mapping for SaaS Companies

ScenarioYour roleKey obligations
You build and sell an AI hiring screening tool to enterprise customersProviderArticles 8-17, conformity assessment, CE marking, EU database registration
Your enterprise customer uses your hiring tool within their HR processTheir role: DeployerArticles 26-29, human oversight, FRIA if applicable
You use an external LLM to power credit scoring in your fintech productDeployer of the LLM; Provider of your fintech productBoth sets of obligations apply in parallel
You provide an AI tool that your customer customises and deploysYou: Provider. Customer who customises: may become Provider under Article 25Article 25 re-classification rules apply; written agreement required
You build an internal AI tool for your own HR decisionsProvider and Deployer simultaneouslyFull provider obligations apply; deployer obligations apply to internal use

Article 25: When the Deployer Becomes the Provider

Article 25 is critical for SaaS companies that offer customisable AI. If a deployer substantially modifies a high-risk AI system -- changes its intended purpose, makes material changes to performance, or puts it into service under their own name -- they are reclassified as a provider and assume all provider obligations. This must be addressed in your customer contracts.

The Practical Implication

Most AI SaaS companies need to run two compliance tracks simultaneously: a provider track covering their own product and a deployer track covering third-party AI they use internally. Classifying your AI system is the first step to determining which track applies where.


Frequently Asked Questions

If I use an external LLM API in my product, am I a provider or deployer?

You are a deployer of the LLM (the LLM provider carries the GPAI obligations). But if your product built on the LLM falls into an Annex III high-risk category -- such as hiring screening or credit assessment -- you are the provider of that high-risk AI system and carry full provider obligations under Articles 8-17.

When does a customer become a provider under Article 25?

Article 25 reclassifies a distributor or deployer as a provider when they substantially modify a high-risk AI system or put it into service under their own name or trademark. Substantial modification includes changes that affect compliance with Articles 8-15 or changes to the intended purpose. This must be addressed in customer contracts.


Vigilens automates EU AI Act compliance -- turning Articles 9, 12, 13, and 14 into machine-executable controls with continuous evidence from your engineering tools.

CLASSIFY YOUR AI SYSTEM → GET EARLY ACCESS