Organisations that describe themselves as “building with AI” are, in legal terms, downstream deployers of general-purpose AI (GPAI) models. They are not training models. They are not releasing foundation weights. They are calling an API and using the output in a product or workflow.
This is an important distinction under the EU AI Act, and one the regulation takes seriously. Calling yourself a “customer” of OpenAI or Google does not exempt you from the Act’s scope. As a downstream deployer, you have your own set of legal obligations; some of which have already been in force since August 2025, and others that apply from August 2026.
This page explains what those obligations are, where they come from in the legislative text, and what a practical compliance posture looks like for an engineering or product team building on top of an LLM API. It also addresses the question most downstream builders eventually reach: at what point does our application tip into high-risk territory, and what changes if it does?
The answer depends on what you build, not just what API you call.
Am I a deployer or a provider?
This is the first question to settle, because the obligations differ substantially.
Under Article 3 of the EU AI Act, a deployer is any natural or legal person that uses an AI system under their authority, except where the system is used for personal non-professional activity. A provider is any natural or legal person that develops an AI system or has one developed and places it on the market or puts it into service.
For teams working with LLM APIs, the practical distinction works as follows:
You are a deployer if you:
- Access a GPAI model via an API and pass user inputs to it
- Build a product or internal tool whose core AI capability comes from an upstream model
- Wrap, prompt-engineer, or orchestrate a model without changing its weights or architecture
- Build a RAG (retrieval-augmented generation) pipeline on top of an existing model
You are (or become) a provider if you:
- Fine-tune a GPAI model to a degree the AI Office considers a “substantial modification”
- Release a new AI system built on top of a GPAI model and place it on the market yourself
- Adapt a GPAI model in a way that creates genuinely new capabilities or a new risk profile
The boundary between deployer and provider is not always sharp. The AI Office’s Guidelines on the scope of obligations for providers of GPAI models (published July 2025) clarify that only significant modifications trigger provider status; minor adjustments such as prompt customisation, retrieval integration, or basic fine-tuning on a narrow task do not. But organisations doing extensive domain-specific fine-tuning should take legal advice on their classification.
There is also a combined role: a company building a hiring tool using GPT-4 via API is a deployer of GPT-4 (the GPAI model), but a provider of the hiring tool itself (the AI system they place on the market). If that hiring tool qualifies as high-risk under Annex III, Article 6, the company carries provider obligations for it, regardless of the fact that the underlying model was built by someone else.
The Digital Omnibus adds a further wrinkle to enforcement, though not to the underlying obligations themselves: the AI Office now holds exclusive competence over AI systems built on a general-purpose AI model where the model and the system are developed by the same provider, and over AI systems integrated into, or constituting, very large online platforms or very large online search engines. For most downstream deployers building on a third-party model such as GPT-4, Claude, or Gemini, this doesn’t change anything, since the model and the wrapping application come from different organisations. It matters more where an organisation is itself both the GPAI model provider and the application provider, or operates a large platform or search engine with AI features built in.
This dual role is one of the most consequential concepts in the Act for downstream builders, and it is addressed in detail in the section below on downstream high-risk consequences.
What “deploying a GPAI model” means under the Act
The EU AI Act defines a GPAI model (Article 3(63)) as an AI model trained on large amounts of data using self-supervision at scale, displaying significant generality, and capable of competently performing a wide range of tasks; regardless of how it is placed on the market or into which downstream systems it is integrated. This definition covers the major commercial LLMs in use today: GPT-4 and its successors, Claude (Anthropic), Gemini (Google), Mistral, Cohere Command, and similar systems.
A GPAI system (Article 3(66)) is an AI system based on a GPAI model that has the capability to serve a variety of purposes; whether used directly or integrated into other applications. When you call an LLM API and expose its output to users through your product, you are operating a GPAI system.
This matters because GPAI systems sit in a distinct regulatory track. They are not automatically high-risk. They are subject to the GPAI obligations framework in Articles 51–55, which has been in force since 2 August 2025, and they are subject to the Article 50 transparency obligations that apply from 2 August 2026.
The risk classification of a GPAI system depends on what it does in context, not on the model it runs on. Using GPT-4 to summarise meeting notes is minimal risk. Using GPT-4 to screen job applications is high-risk under Annex III, employment category. The API is the same. The regulatory treatment is entirely different.
Your obligations as a downstream deployer
The following obligations apply to organisations deploying GPAI models within the EU. Some are already in force; the timeline position of each is noted.
1. AI literacy (Article 4 – in force since 2 February 2025)
Providers and deployers must take measures to ensure a sufficient level of AI literacy among their staff and any other persons dealing with AI systems on their behalf.
In practical terms, this means documenting the AI training your team has received, ensuring that product and engineering staff working with LLM outputs understand the model’s capabilities and limitations, and periodically reviewing whether that understanding is current. This is not a heavy obligation, but it is a real one, and it was the first obligation to come into force under the Act.
Under the Digital Omnibus, the wording was softened: deployers are now required to support the development of AI literacy rather than guarantee a specific level. The underlying expectation of documented, demonstrable staff awareness remains.
2. Prohibited practices (Article 5 – in force since 2 February 2025)
Regardless of your role in the value chain, you cannot deploy a prohibited AI system. The prohibition falls on both providers and deployers. Calling yourself downstream of the model provider does not transfer this obligation upstream.
If your application uses an LLM to manipulate users through subliminal techniques, exploit individuals’ vulnerabilities, enable unauthorised biometric categorisation, or facilitate social scoring by public authorities, the application is prohibited; and you bear liability for deploying it.
For most LLM-based products, the Article 5 screening exercise is straightforward: the prohibited categories do not apply. But organisations in social media, recruitment, marketing, and public sector should review their use cases explicitly against the eight prohibited categories, including the two new prohibitions introduced by the Digital Omnibus (AI-generated CSAM and non-consensual intimate imagery), which apply from 2 December 2026.
3. Transparency obligations (Article 50 – applies from 2 August 2026)
This is the most broadly applicable obligation for downstream deployers and the one most likely to require engineering work.
Article 50 imposes transparency duties on both providers and deployers of certain AI systems. For organisations building on LLM APIs, two sub-obligations are most relevant:
Article 50(1): Disclosure of AI interaction. Providers of AI systems that interact directly with natural persons must ensure those persons are informed they are interacting with an AI system. As a downstream builder, if you deploy a chatbot, virtual assistant, or voice agent built on an LLM, you carry this disclosure obligation; it must be designed into the interface, not buried in a terms of service document.
Article 50(4): Synthetic content disclosure. Deployers who publish AI-generated or AI-manipulated image, audio, or video content must disclose that it is artificially generated or manipulated. This applies to marketing, advertising, media, and any product that surfaces generative output to end users. Note: this is a deployer obligation that does not depend on whether the upstream model provider has marked the content.
Article 50(2): Machine-readable marking of AI-generated output. Applies to providers. If you are placing a generative system on the market, this obligation applies to you as a provider. New systems must comply from 2 August 2026; systems already on the market before that date have until 2 December 2026 under the Omnibus grace period.
4. Instructions for use and downstream information (Article 25 – applies from 2 August 2026 for standalone high-risk systems)
Where a GPAI model is integrated into a high-risk AI system, deployers must use the system in accordance with the provider’s instructions for use. This is not passive compliance: it requires you to have actually received those instructions, to have read them, and to be operating the system within their stated parameters.
Under Article 25, providers of GPAI models are required to provide downstream deployers with the information needed to understand the model’s capabilities and limitations and to comply with their own obligations. If your LLM API provider has not supplied this documentation, you should request it. The obligation to provide it has been in force since August 2025.
5. Human oversight (Article 26 – applies from 2 December 2027 for standalone Annex III high-risk systems, post-Omnibus)
For deployers of high-risk AI systems, Article 26 requires that human oversight measures are implemented in practice, not merely referenced in documentation. This means assigning oversight responsibility to named individuals, ensuring those individuals have the authority and the tools to intervene or suspend the system, and logging that oversight activity.
For organisations building on LLM APIs whose application falls into a high-risk Annex III category (employment screening, credit assessment, education, biometrics, etc.), this is the most operationally demanding obligation. It requires integrating oversight into the product workflow, not treating it as an audit formality.
Following the Digital Omnibus, standalone Annex III high-risk obligations (including Article 26) are deferred from 2 August 2026 to 2 December 2027.
6. Logging and record-keeping (Article 26(6) – applies with high-risk obligations)
Deployers of high-risk AI systems must keep the logs generated by the system for at least six months. This is not a documentation task; it requires your infrastructure to capture, store, and protect model interaction logs at a level that would satisfy a market surveillance authority conducting an audit.
For organisations using LLM APIs, this means retaining structured logs of inputs, outputs, model versions, timestamps, and any human review decisions. If your current architecture sends API calls and discards the response once it is displayed to the user, you are not compliant with this requirement.
7. Fundamental Rights Impact Assessment (Article 27 – applies with high-risk obligations)
Deployers of high-risk AI systems that are bodies governed by public law, or private operators providing services to the public, must carry out a Fundamental Rights Impact Assessment (FRIA) before deploying the system. The FRIA must assess the potential impact of the high-risk AI system on fundamental rights and must be registered with the EU database for high-risk AI systems.
For private sector organisations, the obligation to complete a FRIA applies where the deployer is providing a service to the general public, not purely internal enterprise tooling.
The downstream high-risk question
The most consequential question for organisations building on LLM APIs is whether their application tips into high-risk territory. If it does, they become the provider of a high-risk AI system; with the full conformity assessment, technical documentation, and post-market monitoring obligations that entails.
Annex III of the EU AI Act lists the categories of AI systems that are presumed high-risk. The categories most relevant to LLM-based applications include:
- Employment and workers management: AI used for recruitment, candidate screening, performance evaluation, task allocation, promotion, or termination decisions
- Education and vocational training: AI used to determine access to educational institutions or assess student performance
- Access to essential private services: AI used in credit scoring, insurance risk assessment, or similar financial decisions
- Biometric identification: AI used to identify or categorise natural persons based on biometric data
If you are building an LLM-based hiring assistant, a credit assessment copilot, a student evaluation tool, or an identity verification workflow, your application almost certainly falls within Annex III. This means you are a provider of a high-risk AI system, and the GPAI model provider (OpenAI, Anthropic, Google) is not responsible for your conformity assessment. You are.
The EU AI Office’s Guidelines on classification (published May 2026) provide additional detail on how to assess whether a specific use case meets the Annex III threshold. The key test is whether the AI system poses a significant risk of harm to health, safety, or fundamental rights; assessed in the context of the specific use, not in the abstract.
What your LLM provider owes you
Under Article 53, providers of GPAI models placed on the EU market are required to:
- Maintain technical documentation covering model architecture, training procedures, computational resources used, and known limitations
- Provide documentation to downstream providers (including deployers integrating the model) sufficient for them to understand the model’s capabilities and comply with their own obligations
- Publish a sufficiently detailed summary of training data content, following the AI Office’s published template
- Implement and publish a copyright policy complying with the EU Copyright Directive’s text-and-data-mining provisions
These obligations have been in force since 2 August 2025 for new GPAI models. Legacy GPAI models (on the market before that date) must comply by 2 August 2027.
In practice, this means that providers like OpenAI, Anthropic, Google, and Mistral are legally required to give you documentation about their models. If they are not doing so, they are non-compliant. You should request it and, if you cannot obtain it, document that request. If a GPAI provider cannot supply adequate capability and limitation documentation, that is itself a compliance signal worth acting on before integrating the model into a high-risk application.
For models with systemic risk (those trained above the 10²⁵ FLOP threshold, currently including the frontier models from OpenAI, Anthropic, Google, and Meta) additional obligations apply to the provider: adversarial testing and red-teaming before release, serious incident reporting to the AI Office within 72 hours, cybersecurity protections, and energy efficiency metrics disclosure. These do not flow through to downstream deployers directly, but they affect the evidentiary quality of the technical documentation the provider supplies.
Deeploy’s role in deployer compliance
Deeploy is a model monitoring and governance platform built for organisations operating AI in production. For downstream deployers building on LLM APIs, Deeploy addresses the most operationally demanding obligations:
Logging and audit trails: Deeploy captures structured interaction logs (inputs, outputs, model versions, timestamps, confidence scores) and retains them in a format that satisfies Article 26(6)’s six-month minimum. Logs are queryable and exportable for market surveillance requests.
Human oversight tooling: Deeploy’s review workflows make it possible to route model outputs to human reviewers before they are acted upon; the mechanism Article 26 requires for high-risk systems. Oversight decisions are logged alongside the model outputs they review.
Drift and performance monitoring: The Act’s post-market monitoring requirements under Article 72 demand that deployers detect when their system’s behaviour changes in ways that create new risks. Deeploy monitors output distributions, flags anomalies, and alerts responsible persons when thresholds are crossed.
Documentation support: Deeploy generates and maintains the technical records that form the basis of a conformity assessment audit trail; model cards, performance baselines, monitoring logs, and incident records.
Frequently asked questions
You are a deployer of OpenAI's GPAI model, but a provider of your own AI system built on top of it. If your system is classified as high-risk, you carry provider obligations for that system, including conformity assessment and technical documentation, even though you did not train the underlying model yourself.
Potentially. If your fine-tuning constitutes a "substantial modification" to the original model, you may be reclassified as a provider and take on the associated obligations. The AI Office has provided partial guidance on this boundary but it remains a grey area. Extensive fine-tuning that changes the system's intended purpose or performance profile carries the higher risk of triggering provider status.
Under Article 26, deployers must: use the system in accordance with the provider's instructions for use; assign a human oversight person with the authority and capability to intervene; monitor the system's operation; inform employees or their representatives where AI is used in the workplace; conduct a Fundamental Rights Impact Assessment where required; keep logs for the periods specified; and report serious incidents to the relevant authority.
Providers of high-risk AI systems must supply instructions for use covering the system's intended purpose, performance characteristics, limitations, maintenance requirements, and the level of human oversight required. Without adequate documentation from your provider, you cannot demonstrate compliance with your own deployer obligations. This is a contractual point worth addressing before deployment.
A General-Purpose AI (GPAI) model is a model trained on large amounts of data that can perform a wide range of tasks and be integrated into many downstream applications.
Examples include GPT-4, Claude, Gemini, Llama, and Mistral. GPAI models are regulated under a parallel track in the Act (Articles 51–56), distinct from the high-risk system framework. All GPAI providers must publish technical documentation and a training data summary, and must comply with EU copyright rules.
Partially. Providers of free and open-licence GPAI models are exempt from most documentation and transparency obligations. They are not exempt from the obligation to comply with EU copyright rules or to publish a training data summary. Crucially, the exemption does not apply if the open-source model is classified as having systemic risk; in that case, all obligations apply in full.
