What Makes You a Deployer Rather Than a Provider

The EU AI Act draws a critical distinction between those who build AI systems and those who use them. Understanding which category your organisation falls into determines which obligations you must meet. A deployer is any natural or legal person, public authority, agency or body other than the provider who uses an AI system. This definition means that if you purchase, lease or otherwise obtain an AI system to use in your business, you are a deployer. The regulation treats deployers and providers as having fundamentally different roles and responsibilities.

Providers are the organisations that design, develop, train, test and deploy AI systems before releasing them to the market. They bear the primary responsibility for ensuring systems are safe, documented and compliant with the regulation. A provider might be a software company selling a customer relationship management system with an AI module, a consultancy deploying a bespoke risk assessment tool, or any organisation that decides to make an AI system available to others.

The distinction matters because providers must conduct extensive work before a system leaves their control. They must perform risk management, gather training data with proper governance, establish technical documentation, build logging and monitoring capabilities, and ultimately achieve conformity assessment where required. Providers must also issue instructions for use that deployers can actually follow. Deployers, by contrast, are responsible for using systems correctly and monitoring their impact in real-world settings.

Consider a financial services firm that licenses a credit scoring AI from a software vendor. The vendor is the provider. The financial services firm is the deployer. The vendor has built the model, tested it, documented its training data, and determined which use cases it is safe for. The financial services firm must now deploy it properly, assign human oversight, keep records of decisions, and tell applicants when AI influenced their credit decision.

Some organisations occupy both roles at once. A healthcare provider might deploy a diagnostic assistance tool from a vendor (deployer role) whilst also building an internal scheduling AI for staff (provider role). These dual responsibilities must be managed separately, with different compliance activities for each. You must map which AI systems fall into which category within your organisation.

Clarity on this distinction shapes your entire compliance strategy. Deployers do not need to build conformity assessment packs or conduct fundamental rights impact assessments for all systems. Instead, deployers focus on vendor due diligence before purchase, proper implementation during deployment, human oversight once live, and record keeping for audit. Vendors should provide the raw material for compliance; your job as a deployer is to use it correctly and verify it works as promised in your specific setting.

Deployer accountability in practice

The deployer’s accountability is practical and operational. You are accountable for how the system is actually used on the ground. If an AI system that a vendor sold to you makes discriminatory lending decisions, affected applicants will sue you for discrimination. The vendor shares responsibility, but you, as the deployer, cannot hide behind the claim that the vendor built it. You deployed it. You are accountable for how it behaves.

This accountability extends to the people your organisation affects. If your customer service team uses an AI chatbot to respond to customer complaints and the system gives incorrect information to customers, customers will hold you accountable, not the chatbot vendor. Your organisation is the customer’s only point of contact; the vendor remains invisible to them.

Dual-role hazards

If you modify a system you bought from a provider, you may cross into the provider category. If you combine a vendor’s model with your own data, training or fine-tuning, the regulatory line shifts. The regulation is explicit: anyone who modifies an AI system and then deploys it becomes a provider of that modified system. This is explored in depth in Lesson 10 but is worth noting here because the distinction is not always clean.

Once you are a provider, your compliance obligations expand dramatically. You must perform risk management on the modified system. You must document how you modified it and why. You must test the modified system and gather evidence about its performance and safety. You must prepare technical documentation. This is far more demanding than the deployer role. Many organisations are surprised to learn that a small modification they made turned them into providers with significant compliance obligations.

Frequently asked questions

What is a deployer under the EU AI Act?

A deployer is any natural or legal person, public authority or body other than the provider who uses an AI system. Deployers buy, lease or otherwise obtain AI systems that others have built and use them in their operations. The EU AI Act treats deployers differently from providers because deployers do not design or build systems; they are responsible for using systems correctly and monitoring their real-world impact.

What are the obligations of an AI deployer?

Deployers of high-risk systems must use the system according to the vendor’s instructions, assign human oversight to trained people with authority to override, monitor input data quality, keep records of system activity and decisions, inform workers before using the system to evaluate them, and report serious incidents to vendors and authorities. Public authorities must also conduct fundamental rights impact assessments and inform affected people when AI influences decisions. Deployers must also ensure staff receive AI literacy training and verify general-purpose AI systems display machine-readable marking.

Does a company that only buys AI software need to comply with the EU AI Act?

Yes. If a company buys a high-risk AI system, the company is a deployer and must comply with Articles 26 and 27. These articles have been in force since 2 February 2025 for Article 4 and Article 26 requirements, though some aspects have transitional periods. Compliance is not optional; it applies to all deployers of high-risk systems, regardless of company size.

When does a deployer become a provider under the EU AI Act?

A deployer becomes a provider if they modify an AI system and then deploy the modified version. Modification includes retraining on new data, fine-tuning, adding decision logic or combining systems. If you modify a system, you are the provider of the modified system and must ensure it complies with provider requirements including risk management, documentation and conformity assessment.

Do employers have to tell staff that AI is being used on them?

Yes. Article 26 requires that workers are informed before high-risk AI systems are used to monitor or evaluate their work. The notification must be clear and understandable. Workers should be told what the system does, what data it collects, how it influences employment decisions and what their rights are to contest decisions the system influences.

How long must AI system logs be kept under the EU AI Act?

The regulation does not specify a precise retention period. Logs should be kept as long as the system is in use and for a period after that which reflects the liability window for decisions. For most decisions, this is typically three to five years from the date of the decision. For decisions that could result in long-term harm (healthcare, safety), retention might be longer to ensure evidence is available if harm emerges years later.

Who has to carry out a fundamental rights impact assessment?

Article 27 requires public authorities (national, regional and local government bodies, public agencies) that use high-risk AI systems to conduct a fundamental rights impact assessment. Private sector deployers do not have this explicit requirement, though assessing AI impact on human rights is good practice regardless. The assessment examines which fundamental rights could be affected by the system and what mitigations are in place.

What should be in an AI vendor due diligence questionnaire?

A vendor questionnaire should ask about the vendor’s compliance with Article 9 risk management (what risks were identified and how were they managed?), Article 10 data governance (what data was the system trained on and is it representative?), Article 11 documentation (what technical documentation is available?), Article 12 logging (what does the system log?), Article 26 human oversight support (was the system designed to enable meaningful oversight?), and modification support (does the vendor permit fine-tuning or retraining, and who is responsible for compliance of modified systems?). The questionnaire should be grounded in regulation and vendor answers should flow into contract terms.

Who is liable when a bought AI system causes harm?

Liability depends on the cause of harm. If harm results from a vendor defect (the vendor’s training data was biased, the system was not designed correctly), the vendor is liable. If harm results from a deployer’s misuse (using the system outside its approved scope, failing to perform human oversight), the deployer is liable. Contracts should allocate liability clearly, with vendors warranting compliance and indemnifying deployers for breaches of vendor warranties. In practice, both vendor and deployer may face liability and must maintain insurance to cover potential damages.