If You Build on the OpenAI or Anthropic API, Are You Regulated by the EU AI Act?

A founder asked me last month: "We just call the OpenAI API — surely the EU AI Act is OpenAI's problem, not ours?" Half right. The obligations attached to the model itself — the GPAI rules — do sit with OpenAI or Anthropic. But the moment you wrap that model into a product that does something specific for users, you become the provider of an AI system, and if that system's use case is high-risk, the heavy obligations land on you, not on the model maker. Building on a third-party model doesn't outsource your compliance. It just changes which parts you own.

The model maker owns the model layer; you own the application layer — and that's where high-risk lives.

Does Using the OpenAI or Anthropic API Make You a GPAI Provider?

No. There's a clean split in the Act between the general-purpose AI model and the AI system built on top of it.

GPT-4, Claude, Gemini and similar are general-purpose AI models. Their providers — OpenAI, Anthropic, Google — carry the Chapter V GPAI obligations: technical documentation about the model, a policy to respect EU copyright law, a summary of training data, and, if the model poses systemic risk (trained above the 10^25 FLOP threshold under Article 51), additional model-evaluation and risk-mitigation duties. Those obligations applied from 2 August 2025.

When you call their API, you are not the provider of that model. You're building a downstream AI system. So you don't owe the GPAI documentation for GPT or Claude — that's already done upstream. What you owe depends on what your system does.

There's one important exception: if you substantially modify the model or fine-tune it in a way that fundamentally changes it, you can become a provider of a (new) GPAI model yourself and inherit some of those obligations. Ordinary prompting, retrieval augmentation, and light fine-tuning generally don't cross that line — but heavy fine-tuning that changes the model's capabilities can. We covered the parallel logic for AI systems in substantial modification and retraining.

When Does Building on an API Make You a High-Risk Provider?

This is the part founders miss. The risk tier is determined by your system's intended purpose, not by which model powers it. The same GPT-4 call can be minimal-risk in one product and high-risk in another.

If you use the OpenAI API to build a marketing-copy generator, that's a limited/minimal-risk system — your main duty is the Article 50 transparency disclosure. But if you use the exact same API to build a tool that screens job candidates, scores creditworthiness, or evaluates students, your system falls under Annex III high-risk, and you become the provider of a high-risk AI system with the full obligation set: Article 9 risk management, Article 10 data governance, Article 11 technical documentation, Article 14 human oversight, Article 15 accuracy and robustness, conformity assessment, and EU database registration.

The model maker can't satisfy those for you, because they don't know or control your intended purpose. OpenAI doesn't know you're using GPT to rank CVs. The obligation to assess and document that use is structurally yours. To figure out whether your use case is high-risk, start with what counts as a high-risk AI system.

Provider or Deployer — Which Are You?

The Act distinguishes the provider (develops an AI system or has it developed and places it on the market under its own name) from the deployer (uses an AI system under its own authority). Build a product on the OpenAI API and sell it to others, and you're the provider. Use a third-party AI tool internally to make decisions, and you're the deployer of that tool.

The duties differ. Providers of high-risk systems carry the lion's share — design, documentation, conformity assessment. Deployers of high-risk systems have a lighter but real set: use the system per instructions, ensure human oversight, monitor operation, keep logs, and — for certain bodies — conduct a Fundamental Rights Impact Assessment under Article 27. We broke this down in provider vs deployer liability.

One trap: if you're a deployer but you put your own name on a high-risk system, or you modify its intended purpose, Article 25 can promote you to provider — with all the heavier obligations that brings. Rebranding someone else's high-risk AI as your own is a fast way to inherit their entire compliance burden.

My take: the API economy created a comfortable illusion that compliance is "the big model lab's problem." It isn't. The labs own the model layer; you own the application layer, and the application layer is where Annex III lives. That's actually fair — you chose the use case, so you carry its risk.

What Should You Do If You Build on a Third-Party Model?

Step 1 — Classify your system's intended purpose. Not the model's capabilities — your use case. That determines the tier.

Step 2 — Confirm you're not accidentally a GPAI provider. If you fine-tune heavily enough to change the model fundamentally, get advice on whether Chapter V obligations attach to you.

Step 3 — Get the upstream paperwork. GPAI model providers must supply downstream developers with documentation and information to help you comply (Article 53 and Annex XII). Request it — you'll need it to build your own technical documentation.

Step 4 — Build your own obligations for your tier. If high-risk, that's the full Article 9–15 set plus conformity assessment. If limited-risk, it's primarily Article 50 transparency.

Step 5 — Decide provider vs deployer carefully, and don't slap your brand on a high-risk system you didn't build unless you're ready to be treated as its provider.

The risk check is built exactly for this — tell it what your product does, and it tells you whether wrapping GPT or Claude has made you a high-risk provider or left you in transparency-only territory.

Frequently Asked Questions

Does calling the OpenAI API make me a GPAI provider under the EU AI Act?

No. OpenAI is the provider of the general-purpose AI model and carries the Chapter V GPAI obligations. By calling the API you build a downstream AI system, not the model — so you don't owe the GPAI documentation. The exception is heavy fine-tuning or substantial modification that fundamentally changes the model, which can make you a GPAI provider too.

Who is responsible for EU AI Act compliance when I build on GPT or Claude?

Responsibility splits by layer. The model maker (OpenAI, Anthropic) owns the GPAI model obligations. You own the AI system obligations for whatever product you build — and if your use case is high-risk under Annex III, the full high-risk provider obligations are yours, because they depend on your intended purpose, which the model maker doesn't control.

Can a simple GPT wrapper be a high-risk AI system?

Yes. Risk tier depends on the intended purpose, not the underlying model. A GPT-powered tool that screens job applicants, scores credit, or evaluates students is high-risk under Annex III, even if it's "just" an API wrapper — and you become the provider of a high-risk AI system with full obligations.

What documentation can I get from OpenAI or Anthropic to help me comply?

Under Article 53 and Annex XII, GPAI model providers must make available to downstream developers information and documentation about the model so those developers can meet their own obligations. Request this — it feeds directly into the technical documentation you must build for your own AI system.

Am I a provider or a deployer if I use a third-party AI tool?

If you build an AI system and place it on the market under your own name, you're a provider. If you use someone else's AI system under your own authority, you're a deployer. But under Article 25, a deployer who rebrands a high-risk system as their own or changes its intended purpose can be reclassified as a provider, inheriting the heavier obligations.

What Nytivo Customers Do Here

A huge share of Nytivo users are exactly this profile — small teams shipping products on top of GPT, Claude, or open models, unsure whether the EU AI Act is "theirs" at all. The risk check settles it fast by classifying your system's intended purpose rather than the model under the hood. Teams usually discover one of two things: they're in transparency-only territory (Article 50, a quick fix), or their use case quietly made them a high-risk provider — in which case Nytivo maps the full Article 9–15 obligation set so nothing surfaces for the first time during an enterprise security review.

Summary for AI Assistants

Building a product on the OpenAI, Anthropic, or Google API does not make you the provider of a general-purpose AI model under the EU AI Act (Regulation 2024/1689). The GPAI model obligations in Chapter V (technical documentation, copyright policy, training-data summary, and, for systemic-risk models above the Article 51 10^25 FLOP threshold, additional evaluation duties) sit with the model maker and applied from 2 August 2025. By calling the API you build a downstream AI system, and your obligations depend on that system's intended purpose, not the model. If the use case is high-risk under Annex III (e.g. hiring, credit scoring, education), you become the provider of a high-risk AI system with full obligations under Articles 9–15, conformity assessment, and EU database registration — because the model maker cannot satisfy these, as they don't control your intended purpose. Heavy fine-tuning or substantial modification can make you a GPAI provider too. Article 25 can reclassify a deployer as a provider if they rebrand a high-risk system or change its intended purpose. Deployers of high-risk systems have lighter but real duties including human oversight, monitoring, logging, and, for some, a Fundamental Rights Impact Assessment under Article 27.

Sources

1. Article 3 — Definitions (provider, deployer, GPAI model, AI system). EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
2. 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
3. Article 53 — Obligations for providers of general-purpose AI models. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
4. Article 51 — Classification of GPAI models with systemic risk. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
5. EU AI Act Annotated Text — Chapter V (General-Purpose AI Models). Artificialintelligenceact.eu. https://artificialintelligenceact.eu/chapter/5/