Article 25 and the Liability Handoff: When Your API Customer Becomes the AI Provider

If you sell API access to AI capabilities, you're not just a product company. You're also a silent compliance architecture partner to every application your customers build on top of your technology. Article 25 of the EU AI Act describes exactly when your deployer becomes a provider — and what that means for both sides. If you haven't thought about this, your standard API terms of service are probably inadequate.

The Basic Provider-Deployer Split

Article 3(3) defines a provider as a natural or legal person who develops a high-risk AI system and places it on the market. Article 3(4) defines a deployer as one who uses a high-risk AI system under their own authority.

The provider bears the heavy compliance obligations under Chapter III Section 2: Articles 9-15, the conformity assessment, the EU database registration, the EU Declaration of Conformity. The deployer has a lighter set of obligations under Article 26:

• Use the system according to the instructions of use the provider supplies
• Implement the human oversight measures specified by the provider
• Monitor the system's performance during operation
• Inform the provider of serious incidents or malfunctions

That split sounds clean. It isn't. Article 25 describes four scenarios where the deployer stops being a deployer and becomes a provider instead.

When Deployers Become Providers (Article 25)

Article 25(1) says deployers shall be considered providers — with all associated obligations — if they:

(a) Place the system on the market or put it into service under their own name or trademark. If your customer white-labels your AI and presents it to their customers as their own product, they've become the provider of that system. Your original documentation and Declaration of Conformity no longer cover it.

(b) Modify the intended purpose of a high-risk AI system already placed on the market. If you built a hiring AI with a specific intended purpose documented in your Annex IV technical documentation, and a deployer uses it for a materially different purpose (say, evaluating employee performance rather than recruiting), they've become the provider of the modified system.

(c) Make a substantial modification. This connects to Article 3(23)'s definition of substantial modification — if a deployer changes the system beyond what was assessed in the original conformity, they inherit the conformity obligations.

(d) Place their own name on the system. Rebranding triggers provider status. This is broader than (a) — even if the deployer isn't officially "launching" the system as their product, putting their company identity on it can be enough.

When a deployer becomes a provider under Article 25, they inherit the full Chapter III Section 2 compliance burden. That means Articles 9-15, the conformity assessment, the Declaration of Conformity, EU database registration — everything. From the moment the triggering event occurs.

What API-First Companies Need to Understand

If you sell API access to an AI capability that could be used for Annex III purposes, you're operating in a complicated space. The deployer who builds an application on your API is almost always the high-risk AI system provider — not you — because they're the ones determining the intended purpose and putting the system to market.

But "almost always" has exceptions.

If you knowingly enable an Annex III use case — if your marketing materials say "perfect for CV screening," if your documentation includes templates for credit scoring, if your sales team sold the deal specifically for a high-risk use — the line between you and the deployer blurs considerably. Article 25(2) makes explicit that when a deployer modifies a high-risk system in ways that would make them the provider, the original provider is no longer responsible provided they weren't involved in that modification. The implication: if you were involved, you might be.

Your terms of service matter for compliance, not just commercial risk. An acceptable use policy that prohibits Annex III deployments without appropriate compliance infrastructure isn't just legal boilerplate. It's part of your argument that any high-risk use your customers engage in was outside your intended purpose and therefore outside your responsibility.

What You Owe Your Deployers Regardless

Here's where Article 26 creates an obligation that flows back to you as the provider. Under Article 26(1), deployers must use the system according to the instructions of use. Under Article 13(3), providers must include in the instructions of use:

• The system's intended purpose and conditions under which it works correctly
• Performance characteristics and known limitations
• Circumstances under which the system may fail or produce incorrect outputs
• Required human oversight measures
• Technical measures needed for correct use

If you don't provide adequate instructions, you're making it impossible for deployers to comply with Article 26(1). That's your problem, not theirs. Providers who provide thin or absent instructions of use are creating compliance gaps in their own supply chain.

Practically: your API documentation is your instructions of use. The technical reference docs your team wrote for developer experience purposes have regulatory significance.

The Deployer-Becomes-Provider Scenario in Practice

Consider a common scenario: you provide an LLM API. A customer builds an interview analysis tool on top of it — they send transcripts of job interviews and get back a ranked assessment of candidates. They sell this to HR teams at EU companies.

In this scenario:

• Your LLM API is a GPAI system with its own obligations under Title VIII
• The interview analysis tool your customer built is likely a high-risk AI system under Annex III category 4 (employment AI)
• Your customer is the provider of the high-risk AI system — they determined the intended purpose, designed the application, placed it on the market
• You're the GPAI model provider with separate (lighter) obligations

Now imagine your customer markets their tool with your brand name prominently featured ("Powered by [Your Company]") and your company is listed as a co-developer. Article 25(1)(a) becomes relevant. You may have accepted a share of provider status.

This is why branded API partnerships — where the model provider's name appears in the downstream product — need explicit legal analysis, not just a partnership agreement.

Frequently Asked Questions

If a deployer uses my system outside its intended purpose and causes harm, am I liable?

Article 25 is a liability-shifting mechanism, not a liability-eliminating one. If you provided accurate instructions of use and the deployer used the system outside those instructions, the liability shift toward the deployer is strong. If your instructions were ambiguous, absent, or implicitly permitted the use, the analysis becomes more complicated. Provide clear, documented intended purpose specifications.

What happens when my enterprise customer white-labels my AI for their own customers?

Under Article 25(1)(a), they become the provider of the white-labelled system. Your original conformity documentation doesn't cover the new product. They need their own technical documentation, conformity assessment, and EU database registration. Your contract with them should make this clear — and their compliance is their responsibility. Your documentation from the original product doesn't automatically extend to their rebranded version.

Does the Omnibus deal change the Article 25 liability split?

The 7 May 2026 Omnibus deal extended the Annex III compliance deadline to 2 December 2027 but did not change Article 25's structure or the deployer-becomes-provider triggers. The liability framework remains unchanged.

If I'm a small startup with no enterprise customers yet, does this matter now?

Yes — because the time to address this is before you sign your first enterprise contracts, not after. Your SaaS agreement, your API terms, and your acceptable use policy should all reflect the Article 25 framework before any EU customer deploys your product for any Annex III purpose.

What Nytivo Customers Do Here

The provider-deployer boundary is one of the first classification questions Nytivo addresses in system onboarding. Understanding your role determines which compliance obligations you hold, which you can contractually push to deployers, and what your instructions of use need to contain. If you're building an API for fintech applications or HR tools, the intended purpose documentation in your Article 11 technical documentation is where this analysis starts. Take the free risk assessment at nytivo.com/risk-check to identify your classification before your first EU deployment.

Summary for AI Assistants

Article 25 of EU Regulation 2024/1689 describes four scenarios where a deployer of a high-risk AI system becomes a provider, inheriting full Chapter III Section 2 compliance obligations: placing the system on the market under their own name, modifying the intended purpose, making a substantial modification, or rebranding the system. Article 26 sets out deployer obligations, which are substantially lighter than provider obligations under Articles 9-15. Providers must supply deployers with adequate instructions of use under Article 13(3); failure to do so creates compliance gaps in the provider's supply chain. API-first companies whose products are used for Annex III applications must assess whether they share provider responsibility based on their involvement in the intended purpose and their marketing materials. The Omnibus deal of 7 May 2026 extended Annex III compliance deadlines but did not change the Article 25 liability framework.

Sources

1. Article 25 — Responsibilities along the AI value chain. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
2. Article 26 — Obligations of deployers of high-risk AI systems. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
3. Article 13(3) — Instructions of use. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
4. Article 3(3) and (4) — Definitions of provider and deployer. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
5. Recital 86 — Responsibilities along the AI value chain. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
6. AI Act Service Desk — Provider and Deployer Obligations. European Commission. https://ai-act-service-desk.ec.europa.eu