“The Vendor Has Already Handled It”: AI Provider or Deployer?

SMEs using external AI usually remain deployers and retain responsibility for purpose, data, users, oversight, and how outputs are used. The vendor is responsible only for obligations attached to its own role as provider. A company may assume provider duties when it markets, substantially modifies, or repurposes a system for high-risk use.

Legal status reviewed on July 14, 2026. This article provides operational guidance and is not a substitute for legal advice.

Why is relying entirely on the AI vendor insufficient?

Most mid-sized companies do not train foundation models. They purchase a finished application, activate AI inside existing software, or commission a technology partner to configure an assistant. This often leads to the assumption that the supplier has already handled the EU AI Act, data protection, information security, and every other requirement.

That assumption confuses product responsibility with deployment responsibility.

The provider may be responsible for the system’s development, technical properties, documentation, and applicable conformity activities. The provider normally does not decide which customer employees use the system, which quotation documents they upload, which CRM records the assistant can retrieve, or whether an output is sent to a customer without professional review.

An HVAC contractor may buy an AI phone assistant. The contractor still decides whether the assistant only captures callback details or also assesses faults, books appointments, and creates service jobs. A CRM vendor may provide predictive lead scoring. The customer determines whether the score is one input for a salesperson or the reason certain inquiries receive no response.

The same principle applies to tender analysis, construction documentation, technical translation, field-service reports, customer portals, and company knowledge assistants. The supplier does not know every customer commitment, confidentiality clause, work instruction, or professional approval rule.

The EU AI Act therefore distributes responsibilities along the value chain. Provider and deployer are not two alternatives where only one party can be responsible. Each party can have separate obligations based on its role, the system, its regulatory category, and its actual use.

What is the difference between a provider and a deployer?

The EU AI Act defines a provider as a person or organization that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark. The definition applies whether the system is supplied for payment or free of charge.

A deployer is a person or organization that uses an AI system under its authority for professional or organizational activity. Personal, nonprofessional use is excluded.

This distinction leads to a practical rule.

A company using finished AI software for its own operations is usually a deployer. A company developing or commissioning its own AI application and putting it into service or supplying it under its own name may be a provider.

The roles attach to the particular system. One business can therefore be both a deployer and a provider. It may use Microsoft Copilot internally while separately offering a customer-facing assistant built on an external model under its own brand.

Several providers may also exist at different technical layers. One organization supplies a general-purpose model, another integrates it into an AI system, and another combines the system with an industry workflow. The AI Act uses the term downstream provider for a provider of an AI system that integrates an AI model.

Contract labels do not determine the regulatory role by themselves. Terms such as customer, reseller, integrator, technology partner, and platform user describe a commercial relationship but may not capture the function performed under the AI Act.

What role does a company have when using ChatGPT, Microsoft Copilot, or Claude?

A business using ChatGPT from OpenAI (https://openai.com/), Microsoft Copilot from Microsoft (https://www.microsoft.com/), or Claude from Anthropic (https://www.anthropic.com/) as a finished service for its own operations is generally a deployer of the relevant AI system.

Common examples include using the system to:

• draft emails and proposals,
• summarize meetings,
• research public information,
• structure internal drafts,
• translate or revise text,
• explain software code,
• create service reports from notes.

The technology company remains responsible for obligations associated with its provider role. The customer remains responsible for the way the service is used inside the organization, including authorized users, permitted data, professional review, approvals, and error handling.

A product name does not determine risk classification. A general writing assistant is not automatically a high-risk system. The assessment changes when the same underlying technology is configured for applicant ranking, employee evaluation, workforce monitoring, safety recommendations, or another use affecting protected interests.

The specific service also matters. A free consumer account, an enterprise subscription, an API, a Microsoft 365 feature, and a service delivered through an intermediary may involve different contracting entities, data flows, administrative controls, and retention conditions.

The statement “we use Copilot” is therefore not a complete use-case description. The inventory should identify which Copilot product is used, for what purpose, with which connected sources, by which employees, and under which contractual terms.

Which responsibilities remain with the deployer of standard AI?

A deployer retains control over several decisive elements.

The first is purpose. A provider may offer a general productivity assistant. The customer decides whether it will be used for marketing content, technical troubleshooting, applicant files, customer assessments, or contract drafts.

The second is input. The deployer determines whether employees enter personal data, quotations, pricing calculations, contracts, drawings, customer communications, source code, maintenance records, or trade secrets.

The third is output use. An AI system may produce content, a recommendation, or a score. The deployer decides whether the output remains an internal draft, is professionally reviewed, is published, or contributes to a decision about a customer, applicant, or employee.

Additional responsibilities arise under the EU AI Act and other legal frameworks. Depending on the use case, these include:

• supporting AI literacy,
• preventing prohibited AI practices,
• meeting deployer transparency duties,
• complying with privacy and employment requirements,
• implementing information-security controls,
• monitoring operational use,
• addressing incidents and inappropriate output.

For high-risk systems, deployer duties become more extensive. They include using the system according to its instructions, assigning qualified human oversight, monitoring performance, managing input data under the deployer’s control, retaining available logs, and reporting relevant risks or serious incidents.

Under the current EU timeline, the extensive rules for stand-alone high-risk uses, including certain employment applications, are scheduled to apply from December 2, 2027. Rules for AI embedded in specified regulated products are scheduled for August 2, 2028.

How do provider, deployer, and related roles compare?

The table presents common scenarios. One organization may hold several roles, depending on its development work, branding, intended purpose, distribution, modifications, and operation.

When can an SME become a provider?

A company can become a provider without training its own foundation model.

The first scenario is an AI application developed internally or commissioned from a technology partner and put into service under the company’s own name. Outsourcing software development does not automatically make the contractor the provider of the complete business solution. The organization defining the purpose, functionality, and branded system may hold that role.

A common example is an industry-specific customer assistant. The business combines an external model with its own knowledge, interface, CRM integrations, and workflows. When the finished application is offered to customers or affiliated companies under the business’s brand, the provider role requires assessment.

An internally used custom system can also fall within the provider definition when the company has it developed and puts it into service under its own name for the intended purpose. Selling the application to a third party is not the only relevant event.

Article 25 adds specific role-shift rules for high-risk AI systems. A deployer, distributor, importer, or other third party can become the provider of a high-risk system when it:

1. places its own name or trademark on an existing high-risk system,
2. substantially modifies a high-risk system while it remains high-risk,
3. changes the intended purpose of a system that was not high-risk so that it becomes high-risk.

The new provider generally assumes the associated provider obligations. Under specified conditions, the initial provider must cooperate and provide the information, technical access, and assistance reasonably required for compliance.

These Article 25 role shifts do not apply to every adjustment made to an ordinary office assistant. The provision addresses high-risk systems in this context. The broader provider definition may still apply when a company creates a distinct branded AI application from external components.

Does ordinary configuration make a company a provider?

Ordinary configuration does not automatically turn a deployer into a provider.

Creating user accounts, restricting permitted data, selecting an available model, or preparing internal prompt templates are generally deployment activities. Connecting a standard assistant to approved documents may also remain within the deployer role when the system is used according to its intended purpose.

The issue becomes more significant when customization changes the purpose, functionality, risk profile, or market presentation.

A company knowledge assistant that only retrieves internal policies remains closer to ordinary deployment. If it develops into a separately branded customer product with automated decisions, external users, and write access to business applications, the provider assessment becomes more relevant.

The European Commission (https://commission.europa.eu/) also distinguishes minor changes to a general-purpose AI model from significant model modifications. Its guidelines state that only significant modifications can result in corresponding general-purpose-model provider obligations; routine minor adjustments do not.

This model-level question is separate from responsibility for the complete AI system. A company may not be the provider of the underlying model but may still become the provider of the application built around that model.

Useful assessment questions include:

• Is the company only configuring an existing feature or creating a new function?
• Does the vendor’s intended purpose remain unchanged?
• Whose name and trademark appear on the solution?
• Is the system used only internally or made available to customers?
• Are actions, data sources, or decisions added that the original provider did not intend?
• Does the change increase the effect on employees, applicants, customers, health, or safety?

These questions should be addressed during design and procurement rather than after production launch.

What applies to resale and white-label AI?

White-label arrangements allow a company to sell a technology partner’s solution using its own brand, interface, and customer contract.

This commercial structure can alter the AI Act role.

When a business places its own name or trademark on a high-risk AI system, Article 25 may treat it as the provider. For systems outside that category, the general provider definition may still be relevant when the company has the solution developed and supplies or puts it into service under its own name.

The technical supplier contract can allocate activities. It can define who prepares documentation, tests releases, reviews model changes, investigates incidents, supplies evidence, and supports regulatory inquiries. The contract does not remove the need to determine the company’s actual role based on branding, functions, purpose, and market behavior.

A particularly weak arrangement occurs when a reseller presents itself to customers as the complete solution provider but receives little technical information from the upstream vendor. The reseller may then assume a broad customer-facing role without the documentation or access needed to support it.

Before launching a white-label solution, the company should determine:

• who defines the intended purpose,
• whose name appears on the system,
• who communicates capabilities and limitations,
• who approves model and feature changes,
• who handles support and incidents,
• who supplies regulatory and technical records,
• what happens if the upstream supplier exits the relationship.

Changing a logo can have consequences beyond branding.

What applies to embedded AI in CRM, ERP, and industry software?

Embedded AI is easily overlooked because the company does not purchase a separate AI product. A feature appears inside an approved platform and can often be activated through a routine configuration change.

A CRM platform may add meeting summaries, lead scoring, sales forecasts, or automated email drafting. An ERP application may categorize invoices, predict material demand, or recommend accounting entries. HR software may draft job advertisements, match candidates, or rank applications.

The software vendor will generally remain the provider of the embedded AI function, while the customer acts as deployer. The customer must still assess the actual business use.

The central issue is whether the feature assists employees or materially influences decisions. An automatically drafted CRM note has a different impact from a system that deprioritizes customer inquiries. Writing support for a job description differs from ranking applicants for employment.

The company should also review whether the AI function was covered by the original contract and assessment. New features can introduce additional model providers, subprocessors, data transfers, logging, and retention arrangements.

Software releases should therefore be reviewed not only for technical compatibility but also for changes to purpose, data access, automated actions, suppliers, and risk classification.

An embedded feature does not become irrelevant merely because users access it through an existing application.

Why must AI Act roles and privacy roles be assessed separately?

Provider and deployer are roles under the EU AI Act. Privacy law uses different concepts, including controller, processor, and joint controller.

These roles are not equivalent.

A company can be a deployer under the AI Act and a controller under data protection law because it determines why and how personal data is used. The AI vendor may act as processor for certain activities while acting in another capacity for separate provider purposes.

The European Data Protection Supervisor (https://www.edps.europa.eu/) expressly notes that provider, developer, and deployer terminology does not correspond to controller, processor, and joint-controller concepts. Each framework requires its own assessment.

A data processing agreement therefore does not settle the AI Act role. Conversely, being “only a deployer” under the AI Act does not remove privacy responsibility.

Information security, intellectual property, employment rules, employee representation, product safety, and sector requirements form additional layers. A single contract statement that the vendor is compliant does not address all of them.

Procurement files should therefore contain at least two separate role assessments: one for the EU AI Act and one for data protection.

Which questions should SMEs ask before purchasing AI?

An effective vendor review should not begin and end with “Are you AI Act compliant?” That question invites a broad answer without connecting it to the customer’s actual implementation.

More useful questions address functionality, roles, evidence, and change.

Which AI functions are included?
The vendor should identify modules that generate content, predict outcomes, classify records, score people or cases, recommend actions, or execute tasks. Planned features and functions that are available but disabled also matter.

Who provides the complete system, and who provides the underlying model?
The software vendor, model provider, hosting provider, reseller, and integration partner may be different organizations.

What intended purpose is documented?
The vendor should describe supported use cases, excluded uses, operating conditions, and any industries or decisions for which the system was not designed.

How has the vendor assessed the system under the EU AI Act?
For potential high-risk systems, the customer should request the classification rationale, instructions, conformity materials, registration information, and required markings.

What data does the service process?
The answer should cover input, output, metadata, logs, recordings, transcripts, diagnostics, and support access.

Where is information processed and stored?
The review should include hosting regions, subprocessors, remote support, backup locations, and international transfers.

Is customer data used for model training or product improvement?
The answer should be enforceable through the contract rather than existing only in sales material.

How are identity and permissions managed?
Relevant topics include single sign-on, multifactor authentication, administrative access, tenant separation, source permissions, and access termination.

Which logs can the customer access?
The business may need evidence of use, connected sources, administrative changes, and actions executed by the system.

How are model and feature changes communicated?
A model change can affect performance, data handling, output behavior, and risk assessment.

How are failures and incidents handled?
The company needs reporting routes, response periods, technical contacts, investigation support, and cooperation with affected customers or authorities.

How does the system support human oversight?
Useful functions include approval, rejection, correction, interruption, rollback, and manual fallback.

Which documents will the vendor provide?
Depending on the use case, this may include system descriptions, instructions, security records, privacy terms, testing information, model documentation, and release notes.

How can the customer leave the service?
Data export, deletion, migration, account closure, and continued access to necessary records should be addressed before signing.

Which contract terms should be reviewed for external AI?

The following checklist provides a starting point for procurement, IT, privacy, security, and the responsible business unit:

• The product, AI functions, and intended purpose are described in binding contract documents.
• Provider, deployer, integration, distribution, and privacy roles are allocated.
• Permitted data categories and prohibited information are specified.
• Hosting, subprocessors, support access, and transfer locations are documented.
• Use of customer data for training or independent vendor purposes is addressed.
• Retention, deletion, export, and account-closure procedures are defined.
• Security, authentication, permissions, tenant separation, and logging are described.
• Model, supplier, and feature changes require advance notice where material.
• The vendor supplies required operating, security, and compliance documentation.
• Incident, malfunction, and authority-request cooperation duties are stated.
• Rights to inputs, outputs, customizations, and company knowledge are addressed.
• Availability, support, fallback, interruption, and shutdown procedures are covered.
• Audit or evidence rights are proportionate to the application’s risk.
• Termination, data return, deletion, and migration support are included.

The required depth depends on the system. A writing assistant limited to public content differs from an AI phone system with CRM access or an employment application processing candidate records.

Which records should the company maintain itself?

The vendor can supply product documentation. The customer must document its own deployment context.

A practical internal record should contain:

• system name and defined business use case,
• business and technical owner,
• system provider, model provider, and significant subprocessors,
• intended business purpose,
• users and affected individuals,
• processed data and connected sources,
• the company’s AI Act role,
• risk category and rationale,
• privacy and security review,
• approved and excluded uses,
• required human oversight,
• training and onboarding requirements,
• notices for customers or employees,
• approval decision and outstanding actions,
• last review and next review date.

A customized or internally developed application also needs architecture records, system instructions, tool permissions, testing scenarios, versions, and change history.

Documentation should not be created only for a potential regulatory inquiry. It supports normal operation by establishing ownership, use restrictions, approval authority, and escalation routes before a problem occurs.

How should an SME organize AI procurement?

The process should be proportionate to risk but begin early enough to influence the purchase.

First, describe the use case.
The business unit should explain the task, users, data, output, and planned automation. “We need Copilot” is not a sufficient business requirement.

Second, make a preliminary role assessment.
Determine whether the company will use finished software, commission a custom application, sell a white-label solution, or integrate a model into its own product.

Third, apply a tiered review.
Privacy, security, procurement, IT, the business owner, and employee representatives should participate according to the use case. A low-impact writing assistant requires less work than candidate ranking or technical decision support.

Fourth, connect the contract to operating rules.
Contractually available functionality is not automatically approved for every employee and every purpose. Internal controls may restrict features that the vendor technically enables.

Fifth, prepare production operation.
Before launch, assign ownership, users, permissions, training, professional review, transparency notices, fallback, and incident handling.

Sixth, reassess material changes.
New models, data sources, write permissions, automated actions, or user groups may make the original decision outdated.

A structured process does not have to slow procurement. Standard questions, templates, and review tiers allow low-impact services to move faster because the organization does not restart the assessment for every purchase.

Which four figures show why vendor assessment matters?

Eurostat (https://ec.europa.eu/eurostat/) reported that 20 percent of EU businesses with at least ten workers used AI technologies in 2025. AI purchasing is therefore no longer limited to technology vendors. It increasingly occurs through ordinary office software, customer-service platforms, and industry applications.

In McKinsey & Company’s (https://www.mckinsey.com/) 2025 global AI survey, 88 percent of respondents said their organizations regularly used AI in at least one business function. The survey is not a representative measure of German SMEs, but it illustrates how quickly provider-deployer relationships are becoming part of routine operations.

Vendor choice is also becoming a strategic issue. Deloitte’s (https://www.deloitte.com/) State of AI in the Enterprise study found that 77 percent of surveyed companies consider an AI solution’s country of origin in vendor-selection decisions. Data sovereignty, supply-chain dependency, and jurisdiction are joining functionality and price as purchasing criteria.

The security-assessment gap remains significant. In the World Economic Forum’s (https://www.weforum.org/) Global Cybersecurity Outlook 2025, only 37 percent of surveyed organizations reported having a process for assessing the security of AI tools before deployment. A signed agreement should therefore be the outcome of technical and organizational review, not a substitute for it.

How can AI procurement become an operating governance structure?

Dependable AI procurement connects four elements.

The AI inventory records the system, purpose, vendor, model, users, and data. The AI policy defines permitted tools and information. The approval process involves the business unit, IT, privacy, information security, and procurement according to risk. Training enables users and owners to apply the agreed restrictions.

This prevents two opposite errors. The company neither relies entirely on vendor claims nor attempts to take over technical product duties that belong to the provider.

Governance can remain compact for a writing assistant. An AI phone system, company knowledge platform, employment application, or autonomous business workflow needs additional documentation and controls.

KrambergAI GmbH, https://krambergai.com/, supports mid-sized companies in connecting vendor review, the AI inventory, internal policy, roles, training, and operating documentation. The work begins with the actual process, whether the system supports proposals, field service, dispatch, customer communication, or internal knowledge.

Which sources support the figures used in this article?

Eurostat: 20 Percent of EU Enterprises Use AI Technologies
https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20251211-2

McKinsey & Company: The State of AI – Global Survey 2025
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

Deloitte: The State of AI in the Enterprise
https://www.deloitte.com/cz-sk/en/services/consulting/research/the-state-of-ai-in-the-enterprise.html

World Economic Forum: Global Cybersecurity Outlook 2025
https://www.weforum.org/publications/global-cybersecurity-outlook-2025/in-full/1-understanding-complexity-in-cyberspace-587e8c5eba/

Which sources belong in “Further reading”?

European Commission: Guidelines for Providers and Deployers of High-Risk AI Systems
https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems

European Data Protection Supervisor: Revised Orientations on Generative AI and Data Protection
https://www.edps.europa.eu/system/files/2025-10/25-10_28_revised_genai_orientations_en.pdf

German Federal Office for Information Security: Generative AI Models – Opportunities and Risks for Industry and Government
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Generative_KI-Modelle.html

FAQ

Is a company always only a deployer when using ChatGPT?

A business using a finished ChatGPT service for internal work is generally a deployer. If it uses an API to build a separate application, defines that application’s purpose, and puts it into service under its own brand, it may become the provider of the resulting AI system. Each use case and technical arrangement requires its own role assessment.

Is Microsoft responsible for every risk associated with Copilot?

No. Microsoft (https://www.microsoft.com/) is responsible for its provider role and contractual product commitments. The customer determines users, permissions, connected information, and output use. Excessive SharePoint access, inappropriate prompts, or unreviewed use in employment decisions do not become the software provider’s sole responsibility merely because Copilot supplied the output.

Does an internal prompt template make the company a provider?

An internal prompt template normally remains part of configuration and deployment. The assessment can change when prompts, proprietary data, tools, automated actions, and an interface are combined into a separate application operated or marketed under the company’s brand. The relevant object is then the complete AI system rather than the individual instruction supplied to the model.

When is a modification considered substantial?

Under the AI Act, a substantial modification is an unplanned post-market change that affects a high-risk system’s compliance or changes the intended purpose for which it was assessed. Ordinary settings do not automatically meet that definition. The analysis must consider functionality, automation, decision impact, data access, testing, and whether the previous conformity assessment remains applicable.

Does a reseller automatically become a provider?

Not every reseller is automatically a provider. The business may initially act as a distributor. Provider duties may arise when it applies its own brand, substantially modifies a high-risk system, or changes a system’s purpose so that it becomes high-risk. Contract terms, branding, technical work, sales claims, and the actual customer offering must be evaluated together.

Must the vendor provide an AI Act certificate?

There is no universal AI Act certificate covering every low-risk product and every customer use. High-risk systems involve specific conformity procedures, documentation, declarations, marking, and sometimes registration. A general sales statement that a product is compliant does not replace the required evidence, the vendor’s instructions, or the customer’s assessment of its own deployment.

Can an SME rely on the vendor’s risk classification?

The vendor’s classification is an important starting point but must be compared with the customer’s actual use. The provider assesses the intended purpose it has documented. Different data, users, integrations, automated actions, or decision effects can produce another context. Employment, safety, and significant customer decisions deserve a documented internal assessment before production deployment.

Must a vendor notify customers about model changes?

The applicable legal duty depends on the system, role, contract, and risk category. The agreement should require advance notice when a model change may affect performance, data processing, hosting, subprocessors, security, or output behavior. Without change control, a previously reviewed service can continue operating under materially different technical conditions without a new customer decision.

Is a data processing agreement sufficient for AI procurement?

No. A data processing agreement addresses personal data processed on behalf of the customer. The company also needs an AI Act role assessment, intended-purpose review, security evaluation, output controls, transparency analysis, and operating responsibilities. Intellectual property, employment rules, employee representation, product safety, and sector requirements may add further contract and governance work.

Who should review an AI contract inside the company?

Procurement can coordinate the review but should not decide alone. The business unit assesses purpose and professional impact, IT reviews architecture and integration, privacy addresses personal data, and information security evaluates technical risk. HR and employee representatives should participate when workers are affected. A named system owner should document the consolidated approval decision.

Must a free AI tool also be reviewed?

Yes. AI Act roles do not depend on price. Free services may have different retention, provider-training, support, contractual, and administration terms from enterprise products. Because employees can activate them without a normal purchase request, they frequently become unapproved business tools. The organization should record their professional use and apply its data and approval rules.

Who is responsible when an AI answer is professionally incorrect?

Responsibility depends on the contract, the defect, the resulting harm, and how the output was used. A provider may be responsible for product defects or unmet commitments. The deploying company remains responsible for unsuitable use, inadequate review, and its own decisions. Technical, contractual, safety-related, and customer-facing statements should therefore receive appropriate professional verification.