Using Third-Party AI Systems and LLMs: Deployer Obligations Under the EU AI Act

90% of organisations using AI are deployers integrating third-party models — OpenAI, Anthropic, Azure AI, or AI SaaS tools. Understand your obligations: what the provider must give you, what you must do, and when you become a provider yourself.

The Reality of Third-Party AI: Most Organisations Are Deployers

The majority of European organisations using AI are neither OpenAI, nor Mistral, nor a research laboratory. They integrate existing models — via an API, a SaaS platform, an Azure AI component, or a business tool plugin. Salesforce Einstein, Copilot for Microsoft 365, an HR chatbot powered by a large language model, a credit scoring solution purchased from a specialist vendor: in all these cases, you are a deployer of an AI system built by someone else.

This position is occupied by the vast majority of organisations affected by the EU AI Act. It carries precise obligations — different from those of the provider, but non-negligible. It can also evolve: if you modify the system or resell it, your legal status changes.

Understanding your position in the AI value chain is the first step in any compliance effort.

Your Obligations as a Deployer

Deployer obligations differ depending on the risk level of the AI system you are using.

For High-Risk AI Systems (Annex III)

If you deploy a third-party AI system that qualifies as high-risk (creditworthiness assessment, biometric identification, recruitment screening, critical infrastructure management, etc.), your obligations under Art. 26 are:

1. Follow the instructions for use Use the system only for its intended purpose and in accordance with the instructions the provider is required to supply. Using a high-risk AI system outside its validated scope is a compliance failure even if you are only a deployer.

2. Assign human oversight Designate a natural person with the competence, authority, and resources to perform meaningful human oversight over the AI system's outputs. This person must be able to understand what the system is doing, detect anomalies, and override or halt the system when necessary.

3. Ensure input data quality Ensure that data you feed into the system is relevant, sufficiently representative, and appropriate for the intended purpose in your specific deployment context. A system validated on one population may perform differently on yours — that is your risk to manage.

4. Monitor operation and detect anomalies Actively monitor the system's operation for anomalies, unexpected outputs, or performance degradation. This is not the provider's responsibility in deployment — it is yours.

5. Retain logs Activate and retain the automated logs produced by the system for the period required by the Act (and any sectoral regulation that may apply). Do not turn off logging to save storage costs.

6. Report serious incidents If you become aware of a serious incident or malfunction — one that caused or could cause death, serious harm, fundamental rights violations, or significant property damage — notify the provider without undue delay. In some cases (particularly where the deployment involves public-facing services or law enforcement adjacent activities), direct reporting to the national market surveillance authority may also be required.

7. Fundamental rights impact assessment (public bodies) If you are a public body, or a private entity deploying AI systems in areas likely to affect fundamental rights (healthcare, social services, education, law enforcement), you must conduct a Fundamental Rights Impact Assessment before deployment (Art. 27).

For Transparency-Only AI Systems (Art. 50)

If you deploy a chatbot, AI-generated content system, or emotion recognition tool that is not high-risk but falls under Art. 50 transparency obligations, you must:

• Inform users they are interacting with an AI system (Art. 50(1))
• Ensure AI-generated content is technically marked (Art. 50(4)) where applicable
• Inform exposed persons when emotion recognition or biometric categorisation is being used (Art. 50(2)–(3))

These obligations apply even when using a third-party API or SaaS tool. The provider is responsible for building in the technical capability; you are responsible for activating it and ensuring the disclosure actually reaches users.

For Minimal-Risk AI Systems

No specific legal obligations under the AI Act. Voluntary codes of conduct apply. Good governance practice still recommends basic documentation of AI systems in use and periodic review of their performance.

What to Demand from Your Third-Party AI Provider

Your ability to fulfil deployer obligations depends directly on what the provider gives you. The EU AI Act requires providers of high-risk AI systems to supply specific information — and GPAI model providers have parallel documentation obligations. Use this checklist when procuring third-party AI:

For Any AI System

• System description: What does the system do, what inputs does it take, what outputs does it produce, and what decisions can it influence?
• Intended purpose: Precisely for which use cases has the system been designed, validated, and approved?
• Known limitations: Under what conditions does the system perform poorly? What populations, languages, or data types are outside its validated scope?
• Instructions for use: The full set of instructions the provider is required to supply under Art. 13 for high-risk systems

Specifically for High-Risk Systems

• Declaration of Conformity or summary of conformity assessment results
• Risk management documentation — what risks were identified and how were they mitigated?
• Bias and fairness testing results — what protected characteristics were tested, what metrics were used, and what results were found?
• Performance metrics — accuracy, false positive/negative rates, and disaggregated performance by relevant demographic groups
• Logging capability — confirmation that the system generates the logs required by Art. 12, and instructions for accessing and retaining them
• Incident notification process — who to contact, in what timeframe, and by what channel when a serious incident occurs
• Update policy — how does the provider notify you of material updates, and what re-validation is required after updates?

For GPAI Models (APIs and Foundation Model Access)

• Model card or technical summary — capabilities, limitations, training data summary, evaluation results
• Copyright compliance statement — how the provider addresses copyright law for training data and outputs
• Acceptable use policy — what use cases are prohibited by the provider, and what happens if you breach them?
• Data processing terms — how does the provider handle your input data? Is it used for further training?

When You Become a Provider

The EU AI Act's Art. 25 is crucial for third-party AI users: it defines when a deployer transitions into a provider and assumes all provider obligations.

You become a provider when you:

1. Substantially Modify a High-Risk AI System

If you take a high-risk AI system and make substantial changes that go beyond what the provider intended — changing the model, retraining on your data, altering core logic — you are now a provider of a new or substantially modified system. All provider obligations apply: conformity assessment, technical documentation, CE marking, EU database registration.

Key question: Is your customisation "use within the intended parameters" or "development of a new capability"? Fine-tuning a model on your domain data may or may not be substantial modification depending on the degree of change and whether it affects the risk profile.

2. Change the Intended Purpose to High-Risk

If you take a system not classified as high-risk and deploy it for a high-risk use case — using a general text classifier to make employment decisions, for example — you have changed the intended purpose in a way that triggers high-risk classification. You become the provider of a high-risk AI system and must comply with all provider obligations for that deployment.

3. Place the System on the Market Under Your Own Name

If you purchase or license an AI system and resell it or offer it to others as your own product (white-labelling), you place it on the market under your own name and become the provider. This is common in the SaaS sector: integrating a third-party model into your own product offering makes you the provider for that product.

4. Make Major Changes to a GPAI Model

If you take a GPAI model and make major modifications to its capabilities or use case — beyond fine-tuning within the provider's intended parameters — you may become a provider of a new GPAI model with your own Chapter V obligations.

Contractual Protections for Deployers

Because your compliance depends on what the provider gives you, your contracts with third-party AI vendors are a critical compliance tool. Key clauses to include:

Information Rights

• Right to receive and regularly updated version of the instructions for use
• Right to access the declaration of conformity and conformity assessment summary
• Right to receive bias testing results and performance metrics
• Right to receive documentation of material model updates before deployment

Incident Management

• Obligation on provider to notify you of any serious incidents or vulnerabilities they become aware of, within a defined timeframe
• Clear channel and process for you to report incidents to the provider
• Commitment from provider to cooperate with your incident investigations and regulatory inquiries

Audit Rights

• Right to audit or to receive audit reports on the provider's compliance with AI Act obligations
• Right to request updated documentation when significant changes occur

Update Obligations

• Provider must notify you before deploying material updates to the AI system
• Provider must advise whether an update constitutes a substantial modification requiring re-validation
• Continuity of documentation — updated technical documentation must be provided with each material update

Liability Allocation

• Clarity on which party is responsible for which obligations under Art. 25
• Indemnification for losses arising from provider non-compliance with supplier obligations
• Limitation of liability provisions that do not undermine your ability to meet regulatory obligations

The Vendor AI Market: What to Watch

The market for AI tools and services is evolving rapidly, and the EU AI Act compliance posture of vendors varies significantly:

• Major cloud and AI providers (Microsoft, Google, AWS, OpenAI, Anthropic) have invested heavily in AI governance and GPAI compliance documentation. Their terms of service and model cards provide more information than most other vendors.
• Specialist vertical AI vendors (HR tech, legal tech, fintech, healthtech) are at varying stages of EU AI Act readiness. Many are SMEs that have not yet fully mapped their obligations.
• Embedded AI in SaaS tools (AI features in CRM, ERP, productivity tools) may not be marketed as "AI products" — but if they make or influence consequential decisions about individuals, EU AI Act obligations apply.

Procurement teams should add AI Act compliance screening to vendor due diligence — asking vendors to attest to their compliance status, provide conformity documentation for high-risk systems, and commit to ongoing information-sharing as the regulatory landscape develops.