You did not build the AI model. Under EU law, that does not reduce your obligations.

Most of the AI agents deployed in Europe in 2026 were not built by the organisations that operate them. They were assembled from foundation models, application frameworks, vector databases, and retrieval pipelines, with the underlying intelligence provided by a model accessed via API from OpenAI, Anthropic, Google, Mistral, or one of a growing number of other providers. The enterprise that deploys the resulting agent to its customers or employees may have written no machine learning code at all.

This is economically rational. Building frontier foundation models requires capabilities and capital available to a small number of organisations globally. Deploying those models in useful applications does not. The vast majority of AI value creation in the near term will come from deployment innovation, not model building. The layered structure of the AI value chain is a feature, not a problem.

But the EU AI Act does not care about the economic structure of the AI value chain when it comes to assigning compliance obligations. It cares about the role each party plays in placing an AI system before users or in a business process. For the majority of enterprises, that role is deployer. And the deployer role under EU AI Act Articles 25 and 26 carries a defined set of obligations that are yours regardless of who built the underlying model.

This guide explains those obligations in detail, describes when a deployer crosses into provider territory under Article 25, and sets out what a certification assessment requires as evidence when the AI system being assessed is built on a third-party model.

The EU AI Act value chain: provider, deployer, and the boundary between them

The EU AI Act uses two primary classifications for organisations in the AI value chain: providers and deployers. These are defined in Article 3(3) and Article 3(4) respectively.

A provider is an entity that develops an AI system or a general-purpose AI model with a view to placing it on the market or putting it into service under its own name or trademark. The development and market introduction of the system is the provider's act. OpenAI developing and offering GPT-4o via API is a provider act. Anthropic developing and offering Claude via API is a provider act.

A deployer is an entity that uses an AI system under its own authority in a professional context. This includes using a third-party AI system accessed via API to power a product or business process. The enterprise that calls the OpenAI API to generate responses in a customer-facing chatbot is a deployer. The company that uses the Anthropic API to power a document analysis workflow is a deployer. The startup that builds an agent on top of Gemini to automate a business process is a deployer. The nature of the underlying model, and the fact that it was built by someone else entirely, does not affect this classification.

This distinction matters because provider obligations and deployer obligations are structured differently. Provider obligations, in Articles 9 to 16, address the technical design and development of the system: risk management during development, technical documentation, logging design, transparency provisions, human oversight design, accuracy and robustness requirements, and cybersecurity. These obligations are placed on the provider because they concern aspects of the system that only the provider has the ability to address.

Deployer obligations, in Article 26, address the governance of the system in use: how it is deployed, how it is overseen, how incidents are handled, and how affected individuals are informed of their rights. These obligations are placed on the deployer because they concern aspects of deployment that only the deployer can control.

The logical structure is clear: each party is responsible for the layer it controls. Providers are responsible for the technical system. Deployers are responsible for the deployment governance. Neither can discharge the other's obligations, because neither controls the other's layer.

Article 26: what deployers of high-risk AI systems must do

Article 26 of Regulation (EU) 2024/1689 sets out the core obligations of deployers of high-risk AI systems. For enterprises using third-party foundation models in contexts that fall within the Annex III high-risk categories, these obligations apply from the date on which the relevant provisions come into force.

The Annex III high-risk categories relevant to most enterprise deployments include: AI systems used in employment and worker management (recruitment, promotion, monitoring, dismissal); AI systems used in access to education; AI systems used in access to credit and financial services; AI systems used in critical infrastructure management; and AI systems used by law enforcement or border control authorities. Organisations deploying AI agents for customer service, internal HR processes, financial analysis, or operational management should assess whether their deployment falls within these categories.

The Article 26 obligations for deployers of high-risk AI systems are as follows.

Use in accordance with instructions. Deployers must take appropriate technical and organisational measures to ensure they use high-risk AI systems in accordance with the instructions of use provided by the provider. This requires that the deployer has obtained and read the provider's documentation, understood the permitted use cases and the conditions under which the system should not be used, and implemented controls that ensure actual deployment respects those conditions. Where the provider's documentation does not cover a specific use case the deployer intends to implement, the deployer cannot proceed without further clarification from the provider.

Human oversight implementation. Deployers must ensure that human oversight is implemented by individuals who have the necessary authority, competence, and resources to intervene when the AI system produces incorrect or harmful outputs. The Article 14 design requirements for human oversight, which the provider must satisfy in the system's design, are complemented by Article 26's requirement that deployers actually implement those oversight mechanisms in their operational context. It is not sufficient for the system to have been designed for human oversight if the deployer's operational processes do not include the personnel and procedures to exercise that oversight.

Monitoring and logging. Deployers must monitor the operation of the high-risk AI system on the basis of the provider's instructions of use, implement the logging requirements set out in Article 12, and retain records of system operation for a period appropriate to the deployment context. The logging obligation is particularly significant for organisations using foundation models, because the deployer's log must capture sufficient information to enable post-incident investigation even when the deployer does not have access to the model provider's internal logs.

Incident reporting. Deployers must report serious incidents or malfunctions to the provider without undue delay after they become aware of the incident. For incidents affecting fundamental rights or causing significant harm, deployers may also have obligations to report to national supervisory authorities. The incident reporting obligation applies regardless of whether the incident is believed to be caused by the provider's model or by the deployer's application layer.

Informing affected individuals. Where the AI system makes decisions that affect individual users, particularly in employment, credit, or service access contexts, deployers must inform those individuals that they are subject to an AI system covered by the EU AI Act, in accordance with Article 26(6). This requirement links to the GDPR Article 22 rights in automated decision-making contexts, which require that individuals be informed of the logic involved and have the right to meaningful human review.

Article 25: when you become the provider

The deployer role has a boundary. Article 25 of the EU AI Act defines the conditions under which a deployer crosses into provider-level obligations. Understanding this boundary is essential for any organisation building on third-party foundation models, because the consequences of inadvertently crossing it are significant.

Article 25 states that a deployer assumes provider-level obligations in four circumstances.

First, when the deployer places the AI system on the market or puts it into service under its own name or trademark. If you take a foundation model, wrap it in an interface, and sell or offer it as your AI product under your brand, you are the provider of that product, even if the underlying model was built by someone else. A company that offers an AI-powered analytics service, branded under its own name, is the provider of that service under the EU AI Act, regardless of which foundation model powers the analytics.

Second, when the deployer modifies the intended purpose of an AI system. If a foundation model is accessed for general-purpose text generation, but a deployer applies it in a medical diagnosis context that falls within Annex III, the deployer has modified the intended purpose and assumes provider-level obligations for the resulting high-risk deployment. The regulatory classification follows the actual use, not the provider's intended use.

Third, when the deployer makes a substantial modification to a high-risk AI system that has already been placed on the market. Fine-tuning a foundation model on proprietary data, re-training it for a specific domain, or materially altering its system prompt in ways that change its fundamental behaviour are candidates for substantial modification, though the precise threshold will be clarified through guidance. Organisations that fine-tune third-party models should assess whether their modifications cross this threshold.

Fourth, when a deployer modifies a general-purpose AI model in ways that result in a new high-risk AI system. This provision specifically addresses organisations that access general-purpose models and configure, combine, or constrain them to produce a system that functions as a high-risk AI system in the Annex III sense.

The practical consequence of crossing into provider territory is that Articles 9 to 16 apply in full. These include mandatory risk management during development, technical documentation to Annex IV standards, automatic logging design, transparency provision design, accuracy testing, cybersecurity requirements, and post-market monitoring obligations. These are substantially more demanding than deployer obligations and require engineering capacity that many organisations using foundation models via API will not have. Organisations that believe they may have crossed this line should seek legal advice on their specific configuration.

What transparency documentation you can and should obtain from providers

Article 13 of the EU AI Act requires that providers of high-risk AI systems supply deployers with information sufficient to enable them to use the system appropriately and meet their deployer obligations. In practice, what documentation is actually available from major foundation model providers varies significantly.

OpenAI publishes system cards, usage policies, model cards, and API documentation for its models. Anthropic publishes a model card for Claude and maintains detailed usage policies. Google publishes model cards for Gemini and Gemma. Mistral publishes technical reports. The quality and specificity of this documentation varies by provider and by model. Much of it addresses general capabilities and limitations rather than the specific deployment-context information that a deployer needs to assess whether their particular use case is covered.

For Article 26 compliance, a deployer needs documentation that specifically addresses the intended use cases of the provider's system, the conditions under which the system should not be used, the accuracy and robustness characteristics for the relevant use case, and any known limitations that are particularly relevant to the deployment context. Where a provider's published documentation does not address these specifics, a deployer should send a formal request to the provider for supplementary documentation and retain records of that request and any response.

The inability to obtain adequate documentation from a provider does not eliminate the deployer's compliance obligation, but it does strengthen the deployer's case that they exercised appropriate diligence if an incident occurs. It may also indicate that the use case is one the provider has not validated, which should inform the deployer's risk assessment under Article 9.

For certification purposes, the Agent Certified assessment reviews what documentation was obtained from the model provider, whether it was assessed against the specific deployment context, and what compensating controls were implemented where documentation was insufficient. The assessment framework maps these controls to the specific EU AI Act articles they satisfy. For a full picture of the seven certification dimensions and how they apply to third-party model deployments, see the methodology page.

Human oversight when you cannot see inside the model

Article 14 of the EU AI Act requires that high-risk AI systems be designed so that they can be effectively overseen by natural persons. This is a provider-level design obligation. But Article 26 requires that deployers implement human oversight in practice. There is a gap between these two requirements that is particularly significant for third-party model deployments.

When a deployer uses a foundation model via API, they have limited visibility into the model's internal processing. They can observe the outputs the model produces. They can observe that a given input produced a given output. But the reasoning steps that produced that output, the confidence level the model assigned to different responses, the way the model weighted different parts of the input, these are not accessible in the way they would be for a model the deployer had built and maintained internally.

This reduced transparency creates a practical challenge for human oversight. An oversight process that relies on humans understanding why a model produced a specific output may not be practical when the model is a third-party foundation model accessed via API. The deployer must design human oversight that compensates for this limitation.

In practice, this means designing oversight at the output layer rather than the reasoning layer. Humans review the outputs the model produces and assess whether they are appropriate for the specific context, rather than reviewing the model's internal reasoning. For high-stakes deployment contexts, this may mean that human reviewers check outputs before they are acted on. For lower-stakes contexts, it may mean statistical sampling of outputs on a regular basis. The specific design depends on the risk level of the deployment and the nature of the consequences of incorrect outputs.

The Agent Certified certification assessment includes a specific dimension for human oversight design in third-party model deployments, which evaluates whether the oversight structure is proportionate to the risk level and whether it is designed to catch the failure modes that are most likely given the model's known limitations. For practical guidance on how the seven certification dimensions apply to AI agents using third-party models, see the seven dimensions article.

Version control and update management

One challenge specific to third-party model deployments is that model providers update their models over time, sometimes substantially, and these updates may not be announced in advance or may not be described with sufficient specificity to enable deployers to assess their compliance implications.

OpenAI, Anthropic, and Google periodically update the models behind their API endpoints, sometimes in ways that change model behaviour. Deployers who have certified their deployment against the behaviour of a specific model version may find that a model update changes the behaviour of their system in ways that affect their compliance position. The deployer's risk management system under Article 9 should include a process for monitoring model updates from providers and assessing the compliance implications of those updates.

Where a provider offers version pinning, meaning the ability to lock an API call to a specific model version, this should be considered as a risk management tool. Pinned versions may eventually be deprecated, but they provide a period of stability during which compliance documentation remains accurate. For high-risk deployments, version pinning should be evaluated as part of the governance documentation required under Article 26.

Incident reporting through the value chain

When a serious incident occurs in a system built on a third-party foundation model, Article 26(5) requires the deployer to report the incident to the provider without undue delay. This is in addition to any reporting obligations to national supervisory authorities under Article 73.

In practice, incident reporting to foundation model providers requires that the deployer has a clear channel for doing so, and that the provider has an established process for receiving and responding to such reports. For major providers like OpenAI, Anthropic, and Google, these channels exist through their developer support and safety teams. For smaller model providers, the deployer should establish this channel before deployment, not after an incident occurs.

The incident reporting requirement also requires that the deployer maintains an incident log that is sufficiently detailed to support the report. The log should include: a description of the incident and its consequences; the system state at the time of the incident, including the inputs provided to the model and the outputs produced; the oversight actions taken; the individuals and entities affected; and the corrective actions implemented. This is the logging record that Article 12 and Article 26 require the deployer to maintain.

For practical guidance on how AI insurance underwriters assess incident logging as part of their underwriting questionnaire, see the related coverage guide at agentinsured.eu. The underwriting requirements and the EU AI Act compliance requirements are closely aligned in this area.

What a certification assessment requires for third-party model deployments

An Agent Certified assessment for an AI deployment built on a third-party foundation model follows the same seven-dimension framework as any other assessment, but the evidence set in each dimension reflects the specific characteristics of a third-party model deployment.

In the governance dimension, the assessment examines whether the deployer has a documented governance structure that addresses the third-party model relationship specifically: version control policy, update monitoring process, provider documentation management, incident reporting channel, and the review process for assessing whether model updates trigger compliance re-assessment.

In the training data and context dimension, the assessment addresses the extent to which the deployer can describe the training data provenance of the model they are using. For major foundation models, this relies primarily on provider-published documentation. The assessment reviews whether that documentation exists and whether the deployer has assessed its adequacy for their specific deployment context. Where training data provenance is opaque, the assessment examines what compensating controls address the risks this creates.

In the deployment and distribution dimension, the assessment examines the human oversight design: whether oversight is proportionate to the risk level, whether it is designed to compensate for reduced model transparency, and whether it includes specific coverage of the failure modes most likely in third-party model deployments such as hallucination, scope drift, and inconsistent behaviour across model updates.

In the Article 25 boundary dimension, the assessment specifically examines whether the deployer's configuration of the third-party model crosses into provider territory: whether fine-tuning, substantial prompt engineering, or domain-specific adaptation has occurred that may constitute a substantial modification, and whether the deployer has assessed the Article 25 implications of their specific configuration.

To begin an assessment for your third-party model deployment, see the assessment request page. For the complete methodology and scoring framework, see the methodology page.