Do You Need EU AI Act Compliance If You Just Use the OpenAI API?

The short answer under Regulation (EU) 2024/1689: it depends on your role and your use case, not on the fact that you call an API. Merely sending requests to the OpenAI API does not, by itself, settle your exposure — what settles it is the role you hold under the Regulation (Article 3) and what you actually do with the model.

OpenAI is the general-purpose AI (GPAI) model provider for the underlying model. Its obligations live in Chapter V (Articles 51–55) and have applied since 2 August 2025. Those duties sit with OpenAI, not with you. Your company building on the API is almost always a deployer (Article 3(4)) — and can become a provider of an AI system under Article 25 in specific, defined circumstances.

The obligation stack that lands on you is driven by the risk tier of your use case — minimal, limited, or high-risk — never by which model vendor you chose. This guide maps role to use to obligation, shows you exactly when a deployer flips into a provider, and tells you which deadlines are real today versus agreed-but-not-yet-law.

---

The Short Answer: Role and Use, Not the API

"We just use an API" is not a compliance answer. The Regulation does not classify you by your supplier; it classifies you by what you do. A finance team using the API to summarise internal reports sits at minimal risk. The same company wiring the same API into a tool that scores the creditworthiness of natural persons lands squarely in Annex III, with the full high-risk obligation stack.

Why "I just use an API" is not a compliance answer

Calling a GPAI API does not make you a GPAI provider. This is the single most common misconception we correct. The GPAI obligations in Articles 51–55 attach to the actor that develops and places the model on the market — OpenAI. Consuming that model through an API leaves those obligations with OpenAI. Your duties come from a different part of the Regulation entirely: the deployer rules (Article 26), the transparency rules (Article 50), and — if your use case is high-risk — the Chapter III stack.

What OpenAI owns vs what you own

OpenAI owns the model-level duties: technical documentation for the model, a copyright policy, and a sufficiently detailed summary of training data (Article 53), plus systemic-risk duties under Article 55 where they apply. You own everything downstream: telling users they are talking to an AI, marking synthetic content you publish, and — where your use case is high-risk — risk management, data governance, human oversight, and the deployer duties in Article 26. To classify your specific use against the statute rather than guessing from the vendor name, see the OpenAI API under the EU AI Act.

---

Who Is Who: Provider, Deployer, and the GPAI Model Provider

Three roles matter here, and they are not interchangeable.

The deployer default for API customers

A deployer (Article 3(4)) is a natural or legal person using an AI system under its own authority in a professional capacity. That is the default role for an OpenAI API customer: you take the model and put it to work in your product or operations. Most Article 50 transparency duties and the Article 26 deployer duties attach to you as the operator interacting with end users — not to OpenAI.

A provider (Article 3(3)) is the actor that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Roles are not mutually exclusive across the product lifecycle: you can be a deployer of OpenAI's model and, at the same time, a provider of your own downstream AI system.

Where OpenAI's GPAI obligations stop and yours begin

The GPAI model provider is OpenAI, carrying the Chapter V obligations (Articles 51–55): model technical documentation, a copyright compliance policy, and the training-data summary. Those obligations stop at the model boundary. The moment you wrap that model into something you operate or offer to others, your own deployer — and possibly provider — obligations begin. For the full role test, see provider versus deployer roles; for the model-level duties themselves, see GPAI obligations.

---

The Article 25 Role Shift: When a Deployer Becomes a Provider

This is the single biggest under-appreciated exposure for companies that assume "we only call an API." Article 25(1) reassigns provider obligations to a deployer (or a distributor, importer, or other third party) in three trigger situations.

The three Article 25(1) triggers in plain terms

1. Article 25(1)(a) — rebranding. You put your own name or trademark on a high-risk AI system that is already on the market (white-labelling or re-badging).
2. Article 25(1)(b) — substantial modification. You make a substantial modification to a high-risk AI system in a way that keeps it high-risk.
3. Article 25(1)(c) — purpose change. You modify the intended purpose of an AI system — including a GPAI system — such that it becomes high-risk under Article 6.

Any one of these shifts the full provider obligation stack onto your company.

Worked example: wrapping the API into a high-risk product

Suppose you build a hiring product on the OpenAI API that ranks and screens job applicants. You did not train the model, but you have given a GPAI system an intended purpose that is high-risk under Annex III. Under Article 25(1)(c), you are now treated as the provider of that high-risk AI system. That means Article 16 provider duties: a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), human oversight built into the design (Article 14), conformity assessment (Article 43), and EU-database registration (Article 49). The fact that the model came from a third party does not relieve you — the role moved with the use.

---

Classify by Use: From Internal Drafting to Credit Scoring

Risk tier is set by what the system does and the context it operates in. It is assessed per use case, not per organisation — one company can hold several tiers at once. For the full decision logic, see how LLM use is classified.

Minimal and limited risk: the common case

Using the API for internal drafting, brainstorming, or summarising for staff is typically minimal risk. No conformity assessment, no registration — but the Article 4 AI-literacy duty still applies to both providers and deployers, so staff operating the system must understand it at a level appropriate to their role.

Anything that interacts with people in natural language — a public-facing chatbot — crosses into Article 50 limited-risk transparency territory. And generating synthetic content (text, image, audio, video) engages the Article 50 content-marking duties, covered in the next section.

High-risk Annex III triggers most teams miss

Two high-risk triggers catch API builders most often:

• Employment — Annex III point 4. Using the API to recruit, select, or screen job applicants makes the system high-risk.
• Creditworthiness — Annex III point 5(b). Using the API to evaluate the creditworthiness or credit score of natural persons (access to essential private services) is high-risk.

Either one brings the full obligation stack and, via Article 25, very likely makes you the provider of that system as well as its deployer.

---

Article 50 Transparency: What You Must Tell Users

Most Article 50 transparency obligations are unchanged by the 2026 reform timeline. The content-marking detail aligns to a 2 December 2026 date. For the full breakdown, see Article 50 transparency duties.

Chatbot disclosure — Article 50(1)

Article 50(1) requires that AI systems intended to interact directly with natural persons inform those persons that they are interacting with an AI system, unless that is obvious to a reasonably well-informed user. The practical implication is blunt: a customer-facing chatbot built on the API needs a clear "you are talking to an AI" disclosure, regardless of your overall risk tier. A minimal-risk classification elsewhere does not exempt the chatbot.

Synthetic-content marking — Article 50(2) and (4)

Article 50(2) requires providers of systems that generate synthetic audio, image, video, or text to mark outputs in a machine-readable format as artificially generated or manipulated. Article 50(4) requires deployers of deep-fake content — and deployers of text published to inform the public on matters of public interest — to disclose that the content is artificially generated or manipulated.

Note the calendar: a new 2 December 2026 deadline was added by the reform package (a CSAM / "nudifier" prohibition plus content-marking detail). It is a fixed calendar date — the "stop-the-clock", standards-contingent approach was rejected, so this is not tied to the availability of harmonised standards.

---

Decision Table: Your Use, Your Role, Your Risk Tier

The table below reads left to right: pick the use, find your role, read the tier, then the obligations. The footnote is the whole point of this page.

How to read the table

The same API, five different obligation sets

The same OpenAI API appears in every row. The tier moves with the use, never with the vendor. That is why an organisation-wide answer ("are we covered or not?") is the wrong question — you classify each use case on its own facts.

---

Deadlines, Penalties, and the 2026 Reform Caveat

What is already in force vs what is moving

• Article 5 prohibited practices have applied since 2 February 2025.
• GPAI obligations (Articles 51–55) have applied since 2 August 2025 — these are OpenAI's, not yours.
• High-risk Annex III is the part in motion. The Digital Omnibus reached provisional political agreement on 6–7 May 2026, with COREPER text confirmed around 13 May 2026, agreeing to defer stand-alone high-risk Annex III (Article 6(2)) from 2 August 2026 to 2 December 2027, and Annex I product-embedded systems (Article 6(1)) from 2 August 2027 to 2 August 2028.

The critical caveat: as of June 2026 this deferral is agreed but not yet law. It still needs a European Parliament plenary vote, formal Council adoption, and publication in the Official Journal. Until then, the statute as enacted still reads 2 August 2026 for high-risk Annex III. The new dates are fixed calendar dates — the standards-contingent "stop-the-clock" proposal was rejected, so the delay is not tied to harmonised-standards availability.

Penalty exposure by obligation tier

---

What to Do Next: Inventory, Classify, and Assign Roles

A four-step starting workflow

1. Inventory. Map every place the OpenAI API touches your product and operations — internal tools, customer-facing features, and any automated decisions.
2. Classify. Assess each use case by tier against Article 6 and Annex III. Do not assume a single organisation-wide tier.
3. Assign roles. Per use case, confirm where you are a deployer and where Article 25 pushes you into provider status.
4. Implement controls. Apply Article 50 disclosures to interactive and synthetic uses, and the full Chapter III stack to any high-risk use.

Where deterministic classification removes the guesswork

For an adjacent worked example using the same engine, see classifying ChatGPT by use.

---

How Confir Helps

Add the OpenAI API to your AI register and Confir's AI inventory and classification module asks how you use it, not just what it is called. You answer structured intake questions — role, use case, data types, user population — and the engine derives your risk tier and obligation scope: an Article 5 prohibited-practice check first, then the Article 6 / Annex III scoping, then the Article 25 role test. Where you are a deployer, it shows the Article 26 and Article 50 duties; where the use is high-risk, it surfaces the full Chapter III stack and the Article 27 FRIA workflow.

The synthesis engine is deterministic and rule-based: the same intake produces the same finding, the same logic every time — no model inference, no hallucination. Every classification names the rule that fired in plain language, so any reviewer can check exactly why your use case landed where it did.

---

Frequently Asked Questions

Do I need EU AI Act compliance if I just use the OpenAI API?

It depends on your role and your use case, not on the API itself. You are typically a deployer, and may become a provider under Article 25. Internal drafting is usually minimal risk, a public chatbot triggers Article 50 transparency, and screening job applicants or scoring credit is high-risk under Annex III with the full obligation stack.

Does using the OpenAI API make me a GPAI provider?

No. OpenAI is the general-purpose AI model provider and carries the Chapter V obligations (Articles 51–55). Calling its API does not transfer GPAI provider status to you. Your obligations come from how you deploy the model and whether your specific use case is classified as limited or high-risk under the Regulation.

When does a deployer become a provider under the EU AI Act?

Article 25(1) treats a deployer as a provider in three cases: you put your name or trademark on a high-risk system, you substantially modify a high-risk system so it stays high-risk, or you change the intended purpose of a system so it becomes high-risk. Any trigger shifts the full provider obligation stack onto you.

Does a chatbot built on the OpenAI API need EU AI Act disclosure?

Yes. Article 50(1) requires that AI systems interacting directly with people inform them they are talking to an AI, unless that is obvious to a reasonably informed user. A customer-facing chatbot built on the API needs a clear AI disclosure regardless of whether the wider system is otherwise minimal or limited risk.

Is using the OpenAI API to screen job applicants high-risk?

Yes. Recruitment, selection, and screening of applicants fall under the employment category in Annex III point 4, making the system high-risk. That brings the full obligation stack: risk management, data governance, technical documentation, human oversight, deployer duties under Article 26, and a fundamental rights impact assessment under Article 27 where applicable.

What are the EU AI Act fines for getting OpenAI API compliance wrong?

Fines scale with the breach: up to EUR 35 million or 7% of global turnover for prohibited practices (Article 99(3)); up to EUR 15 million or 3% for most provider and deployer obligation breaches (Article 99(4)); and up to EUR 7.5 million or 1% for giving authorities incorrect or misleading information (Article 99(5)). SMEs get proportionate caps under Article 99(6).

When do high-risk EU AI Act obligations apply to API-based systems?

As enacted, high-risk Annex III obligations apply from 2 August 2026. The Digital Omnibus agreed on 6–7 May 2026 to defer this to 2 December 2027, but as of June 2026 that deferral is not yet law — it still needs a Parliament vote, Council adoption, and Official Journal publication, so the statutory date currently stands.

---

Related guides

• the OpenAI API under the EU AI Act
• provider versus deployer roles
• GPAI obligations
• how LLM use is classified
• Article 50 transparency duties
• classifying ChatGPT by use