Provider versus deployer under the EU AI Act

Provider vs deployer under the EU AI Act: How to classify your role for each AI system

Provider or deployer is not semantics. The answer changes your obligations, your evidence, and your roadmap.[1]

Under the EU AI Act, a provider develops an AI system (or has it developed) and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional context. One company can act as provider for the AI systems it offers to customers and as deployer for third-party systems it uses internally or in service delivery.[2]

This distinction is operational, not theoretical. It determines who must maintain technical documentation, run conformity assessments, implement quality management systems, perform post-market monitoring, ensure human oversight, or focus primarily on following instructions, monitoring operations, and reporting serious incidents.

Current law applies the core definitions now. GPAI model obligations have applied since 2 August 2025. Most high-risk AI system rules are scheduled for 2 August 2026 (with possible adjustments under the Digital Omnibus proposal). This page reflects the law in force as of April 2026 and draws exclusively from official EU sources.

Current law status Definitions of provider and deployer are in force (Article 3). GPAI provider obligations apply. High-risk system obligations (including detailed provider/deployer splits) are not yet fully applicable. The Commission has published guidelines on the AI system definition and prohibited practices to support early application. Timelines for high-risk rules may be adjusted based on availability of standards and support tools. Always verify the latest on the AI Act Service Desk. No certification or guaranteed compliance is offered here—this is operational guidance only.

Classify your role per AI system, not per company. Ask four practical questions in sequence:

1. Did you develop the system (or commission its development)?
2. Is the system placed on the market or put into service under your name or trademark?
3. Did you make a substantial modification that keeps it high-risk or changes a non-high-risk system into a high-risk one?
4. Are you simply using a third-party system under your authority without the above?

Answering “yes” to the first three typically makes you a provider for that system. Answering “yes” only to the fourth makes you a deployer. Contracts can allocate responsibilities between parties but cannot override the legal classification if you meet the provider criteria (e.g., rebranding or substantial modification).[1]

A startup embedding an external model like OpenAI via API into a customer-facing product is usually the provider of the resulting AI system while remaining a deployer (or downstream user) of the underlying GPAI model. An enterprise buying a third-party recruitment screening tool is typically the deployer. A company that white-labels, rebrands, and materially modifies a vendor’s model usually becomes the provider of the modified system.

Getting the classification right avoids wasted effort on the wrong documentation, incorrect assumptions about transparency duties, or flawed procurement contracts that leave gaps in your evidence file.

Use this matrix as a repeatable checklist for every AI system or feature in your inventory. Apply it system-by-system because roles are not company-wide.

Provider versus deployer matrix

One company can—and often will—hold both roles simultaneously across its portfolio. A SaaS provider is a provider to its customers but a deployer when it uses external GPAI models or tools to run its own operations. Document the classification and supporting rationale for each system; this forms the foundation of your evidence file.[3]

Link to related guidance: see AI system versus GPAI model: the distinction that changes obligations for the distinction between the underlying model and the integrated system, and General-purpose AI model obligations under the AI Act for GPAI-specific provider duties.

Real-world implementations rarely fit neatly into “we built it” or “we just use it.” The AI Act anticipates this through the concepts of substantial modification, rebranding, value-chain responsibilities, and the treatment of GPAI models versus AI systems built on them.

White-label tools: If you take a vendor’s chatbot, apply your branding, and offer it to your customers as “Our AI Assistant,” you are likely placing it on the market under your name and are therefore the provider. Contractual language saying the original vendor remains responsible does not change the legal classification, though it can clarify practical support arrangements.

Significant modification: Official guidance ties this to changes that affect the system’s risk profile, intended purpose, or compliance with essential requirements. Examples include retraining on new domain-specific data that materially changes accuracy or bias characteristics, altering decision thresholds in a high-risk recruiting tool, or changing the use case from internal analytics to customer-facing recommendations in a way that creates new fundamental-rights risks. Minor prompt engineering, configuration, or integration via API usually does not qualify. For GPAI models, the Commission’s guidelines state that only significant modifications create new provider obligations.[4]

System integrators: If you combine multiple components (e.g., a GPAI model, a retrieval system, and a user interface) but do not substantially modify the underlying model or change its intended purpose, you are generally the provider of the integrated AI system while remaining a downstream user of the original GPAI model. This is one of the most commercially important splits: the model provider supplies technical information to you; you handle system-level compliance.

Internal tools built on external models: Using a third-party GPAI model or API internally for marketing copy, data analysis, or internal HR screening typically makes you a deployer. You must follow the provider’s instructions, maintain human oversight where required, and monitor for prohibited or high-risk uses. If you fine-tune heavily on proprietary data and then deploy the fine-tuned version internally at scale, assess whether the modification is substantial enough to shift obligations.

Marketplaces and platforms: An app store or model marketplace is usually a distributor rather than a provider unless it rebrands, modifies, or offers systems under its own name. Downstream developers integrating marketplace models are often providers of their final applications.

Product manufacturers: When AI is a safety component in a product already covered by sector legislation (medical devices, machinery, vehicles), the product manufacturer is often treated as the provider of the AI system under the AI Act’s interplay rules. The obligations align with existing conformity assessment under that sector law.

Edge-case examples

These examples show why role classification must be evidence-based and documented. A startup embedding an external model into its product is usually the provider of the customer-facing AI system and must prepare the relevant technical documentation, even if it relies on the model provider’s information for parts of that file.

Misclassification creates immediate practical problems:

• Wrong documentation requests: You may ask a vendor for detailed technical documentation that only you, as provider of the integrated system, are required to maintain. Conversely, as a deployer you may fail to request the information you need to conduct a fundamental rights impact assessment or ensure proper human oversight.
• Wrong transparency assumptions: Deployers of certain interactive systems have Article 50 duties to inform users they are interacting with AI. If you incorrectly believe you are only a deployer when you are actually providing the system to customers, you may omit required disclosures or CE marking.
• Wrong procurement posture: Companies that assume “the vendor handles everything” often discover too late that their use case, fine-tuning, or rebranding has made them the provider. This leaves gaps in risk management, quality systems, and incident reporting procedures.
• Evidence and audit gaps: National authorities and the AI Office will look for a coherent, system-by-system classification with supporting rationale. Inconsistent internal documents or contracts that contradict the legal role increase enforcement risk and slow down audits.

Operationally, the cost is wasted work on the wrong artifacts, delayed roadmaps, and procurement contracts that allocate responsibilities incorrectly. The AI Act’s value-chain provisions (Article 25) and Recital 84 exist precisely to prevent parties from escaping obligations through creative contracting when their actions meet the provider definition.[1]

Can we be both provider and deployer? Yes. Roles are determined per AI system. Most organizations will be providers for systems they develop or substantially modify and offer to the market, and deployers for the external tools and models they use internally. Document both clearly in your inventory.

Does white-labeling make us provider? Usually yes, if you place the system on the market under your name or trademark. Recital 84 explicitly addresses putting your name on an existing system. Minor cosmetic re-skinning without assuming design responsibility may be treated differently, but authorities will look at substance over form.

What counts as significant (substantial) modification? Changes that affect the system’s risk profile, intended purpose, or compliance with essential requirements—such as retraining that materially alters bias or accuracy, changing from internal analytics to customer scoring, or architectural modifications that increase autonomy. Minor configuration, prompt tuning, or integration via documented APIs generally does not qualify. The Commission’s AI system definition guidelines and GPAI provider guidelines provide further practical criteria. Always document your assessment.

Does using an API always make us only a deployer? No. If you wrap the API into a product or service you offer to customers under your own name, you are typically the provider of that AI system. You remain a downstream user of the underlying GPAI model. The distinction between the model provider and the system provider is one of the most important operational splits in the AI Act.

• Treating role as a company-wide status instead of a per-system assessment.
• Assuming all API or cloud-service usage automatically keeps you in the deployer category even when you market the output as your own AI feature.
• Relying solely on vendor contracts to determine legal role rather than the statutory criteria (development, naming, substantial modification).
• Failing to request or retain the technical information that upstream providers must supply under Article 53 (for GPAI) or Article 13 (for high-risk systems).
• Not updating classification when you materially fine-tune, change use cases, or rebrand—especially when moving a system from low-risk internal use to customer-facing or high-risk use.
• Overlooking that a deployer can become a provider by modifying intended purpose in a way that triggers high-risk classification.
• Maintaining inconsistent documentation across procurement, legal, product, and compliance teams.

• Inventory every AI system, feature, and material GPAI integration in your organization.
• Apply the decision tree and matrix above to each one; record the date, rationale, and evidence relied upon.
• For systems where you are provider, map the specific obligations (technical documentation, risk management, conformity, instructions for deployers).
• For systems where you are deployer, map usage controls, oversight measures, monitoring processes, and incident reporting channels.
• Review all vendor and customer contracts against the legal classification; update templates to reflect accurate role allocation and information-sharing requirements.
• Document substantial modification assessments with before-and-after analysis of risk profile and intended purpose.
• Assign owners for ongoing monitoring of role changes (new fine-tuning, new use cases, product rebranding).
• Run your current inventory through a structured evidence gap analysis.

Ready to turn this classification into a living, auditable record? Use the Evidence Scanner to map your provider and deployer roles across your AI portfolio, auto-generate the appropriate evidence lists, and maintain an up-to-date compliance view as your products and use cases evolve.

Start free Evidence Scanner scan

Sources (official EU only)

• Regulation (EU) 2024/1689 (AI Act), especially Articles 3, 25, Recital 84, and Chapter V (eur-lex.europa.eu).
• AI Act Service Desk timeline, FAQ, and Article pages (ai-act-service-desk.ec.europa.eu).
• Commission Guidelines on the definition of an artificial intelligence system and on prohibited practices (digital-strategy.ec.europa.eu).
• Guidelines for providers of general-purpose AI models (digital-strategy.ec.europa.eu).

All legal claims are anchored in these primary sources. This page does not constitute legal advice.