OpenAI API and the EU AI Act: Who Is the Provider, and What Must You Do?

The EU AI Act does not mention OpenAI by name. It asks a different question: what does this AI system do, and who is placing it on the market? If you integrate the OpenAI API to build a product or feature you ship to users, you are almost certainly the provider of the resulting AI system under Article 16 of Regulation (EU) 2024/1689 — not a bystander riding someone else's compliance. Your classification, and therefore your obligation stack, depends entirely on what your system does with that API.

This guide explains how to determine your role, how to classify your system by use, what the GPAI model layer means for you as a downstream developer, and what Confir can do to shortcut the documentation work.

OpenAI Is the GPAI Provider. You Are Probably the AI System Provider.

OpenAI holds GPAI model obligations under Article 53. Those include: technical documentation per Annex XI, downstream information per Annex XII (which you, the API customer, receive), a copyright policy, and a training-data summary. If GPT-4o crosses the 10²⁵ FLOP threshold that triggers systemic-risk classification under Article 51, OpenAI also owes model evaluations and adversarial testing under Article 55. These are OpenAI's obligations. You do not inherit them.

What you do inherit is Article 16 provider status for any AI system you build on top. The Act's definition of "provider" (Article 3(3)) covers any natural or legal person that develops or has an AI system developed and places it on the market or puts it into service under its own name or trademark. If you ship a CV-screening tool, a credit-assessment assistant, a customer-facing chatbot, or an internal workflow product under your company name — you are the provider of that system. OpenAI is a component supplier (the GPAI model provider), not the provider of your product.

Article 25 makes this explicit: if you put your name on a system, substantially modify it, or modify its intended purpose, provider obligations transfer to you. Wrapping GPT-4o in a product interface and selling it is exactly that.

One exception: if you use the OpenAI API purely for internal operations — say, a back-office text summarisation tool used only by your own staff, not placed on the market — your role is deployer under Article 26. Deployer obligations are meaningfully lighter.

Step One: Classify by What the System Does

The Act sorts AI systems into four tiers. The tier is determined by the system's use, not by the underlying model.

Prohibited (Article 5) — in force since 2 February 2025

Some applications are banned outright regardless of the technology stack. Building on the OpenAI API does not exempt you. A system that uses emotion recognition to infer workers' emotional states in the workplace or in education falls under the Article 5(1)(f) prohibition. A system that scores individuals' social behaviour to determine access to services falls under Article 5(1)(c). A system that exploits vulnerabilities of specific groups to distort behaviour falls under Article 5(1)(b).

These prohibitions are not aspirational — they are in force. If your product currently operates in one of these areas, you need legal advice before continuing, not a compliance framework.

High-Risk (Article 6 + Annex III) — applies from 2 December 2027

An AI system is high-risk if it falls within one of the eight Annex III headings and does not qualify for the Article 6(3) exemption. Stand-alone Annex III systems must comply by 2 December 2027 under the Digital Omnibus political agreement reached in May 2026 (the original 2 August 2026 date has been deferred). For AI embedded in regulated products (Annex I), the date is 2 August 2028.

The Annex III areas most commonly implicated when building on the OpenAI API:

• Employment and worker management (Annex III, point 4): Recruitment screening, CV shortlisting, performance evaluation, task allocation, and monitoring. A 40-person HR-tech company selling a CV-scoring product built on GPT-4o is squarely in point 4(a). As provider, it owns the full obligation stack: risk management system (Article 9), data governance (Article 10), technical documentation per Annex IV (Article 11), logging (Article 12), transparency instructions for deployers (Article 13), human oversight by design (Article 14), accuracy and robustness (Article 15), quality management system (Article 17), conformity assessment (Article 43), EU Declaration of Conformity (Article 47), CE marking (Article 48), and registration in the EU database (Article 49).
• Access to credit and insurance (Annex III, point 5): Creditworthiness assessment and credit scoring fall under point 5(b) — fraud detection is carved out. Life and health insurance risk and pricing fall under point 5(c). A fintech that pipes OpenAI API outputs into an underwriting decision workflow is a high-risk provider. Robo-advisory and AML tools are generally not high-risk on this basis.
• Education and vocational training (Annex III, point 3): Systems determining admission to educational institutions, evaluating student performance, or proctoring exams.
• Biometrics (Annex III, point 1): Biometric categorisation and emotion recognition systems (outside the Art 5 prohibitions), and remote biometric identification under the narrow law-enforcement carve-outs.

The Article 6(3) filter: A system that falls within an Annex III area is not automatically high-risk. You may document that it poses no significant risk of harm — for example, because it performs a narrow procedural task, improves a previously completed human activity, detects decision patterns without replacing or influencing human assessment, or does preparatory work only. The filter requires only one of these conditions, not all four. But any system that profiles natural persons is always high-risk and cannot claim the exemption. Providers claiming the Article 6(3) exemption must document the assessment and still register the system under Article 49.

Limited Risk (Article 50) — applies from 2 August 2026

If your system does not reach high-risk but involves a chatbot interface, you must disclose to users that they are interacting with an AI system (Article 50(1)). If it generates synthetic audio, image, video, or text intended to be mistaken for real (deepfakes), labelling obligations apply (Article 50(4)). Emotion recognition systems that do not fall under Article 5's prohibition must disclose their operation under Article 50(2).

A general-purpose customer support chatbot built on the OpenAI API — one that does not make consequential decisions — is likely limited-risk. The disclosure requirement is the obligation, and it applies from 2 August 2026.

Minimal Risk

Internal tools, general productivity assistants, and content-generation features that do not touch Annex III use cases and do not involve chatbot interaction or synthetic media are minimal-risk. No mandatory obligations apply.

What the Annex XII Downstream Information Means for You

OpenAI, as a GPAI model provider under Article 53, must supply downstream developers with the Annex XII information package. This includes: instructions for use, the system's capabilities and limitations, the intended use cases, and sufficient information for you to discharge your own provider obligations. In practical terms, this is OpenAI's model cards, usage policies, and system documentation.

You should incorporate the Annex XII documentation you receive from OpenAI into your own Article 11 technical documentation file. For high-risk systems, Annex IV specifies exactly what that file must contain: a general description of the system, a description of the elements and development process, information about the data used, monitoring and maintenance plans, and risk management documentation. The technical documentation must be kept for ten years after the system is placed on the market (Article 18).

Role Shifts Under Article 25

Three scenarios convert a deployer into a provider — and the provider obligations follow automatically:

1. You put your name or trademark on an AI system originally developed by a third party (including an OpenAI-based system you did not substantially modify).
2. You substantially modify a high-risk AI system.
3. You place a high-risk AI system on the market or put it into service under your own name.

Most SaaS companies building commercial products on the OpenAI API trigger scenario 1 or 3. If you are selling or licensing a product feature that incorporates the OpenAI API to other companies, you are a provider of a downstream AI system, and the risk classification of that system — not OpenAI's model — determines your obligations.

Data, GDPR, and API Data-Handling

Using the OpenAI API for business processing involves personal data in most serious use cases. GDPR requirements apply in parallel: you need a lawful basis for processing, data processing agreements with OpenAI, and a data protection impact assessment (GDPR Article 35) if you are processing special-category data or making solely-automated decisions (GDPR Article 22).

On data residency: OpenAI offers an EU data residency option for API customers (data processed in the EU, not sent to US servers). For high-risk AI Act compliance — particularly the Article 10 data governance requirements — EU residency also simplifies demonstrating that training and validation data meet the Act's requirements. If your system is high-risk, the Article 10 obligation attaches to your system's training and validation data, not to OpenAI's model weights.

By default, OpenAI does not use data sent via the API to train or improve its models (subject to the terms of your enterprise agreement). Confirm this with your contract. The Article 10 data-quality obligations are yours regardless.

What the High-Risk Obligation Stack Actually Requires of You as Provider

If your system is high-risk, you own all of the following before you place it on the market:

Risk management system (Article 9): A continuous, iterative process — not a one-time audit. You must identify foreseeable risks, assess their probability and severity, implement mitigation measures, and update the assessment whenever the system or its context changes. For an OpenAI API-based system, this means documenting hallucination risk, bias risk in outputs, prompt-injection exposure, and reliance on a third-party API you do not control.

Data and data governance (Article 10): Training, validation, and test datasets must be relevant, representative, free of errors, and complete to the extent possible. If you fine-tune the model on your own data, that data governance falls on you. If you use the base model without fine-tuning, document the OpenAI model's known limitations (from Annex XII) and how your system mitigates them.

Technical documentation (Article 11 + Annex IV): The documentation file must exist before market placement. It covers system description, design choices, intended purpose, known limitations, testing results, risk management records, and post-market monitoring plans. Keep it for ten years (Article 18).

Transparency and instructions for deployers (Article 13): If you sell your high-risk AI system to other companies (B2B), you must provide clear instructions for use, information on the system's performance, and what human oversight is required. This is distinct from Article 50's end-user transparency requirement.

Human oversight (Article 14): The system must be designed so that a natural person can effectively oversee it, understand its output, and override or stop it. This is a design requirement, not just a policy.

Conformity assessment (Article 43): Before you place a high-risk system on the market, you must assess its conformity with the Act's requirements. For most Annex III categories, this is an internal self-assessment under Annex VI. For Annex III point 1 (biometrics), the Annex VII notified-body route is generally required.

Registration (Article 49): Register the system in the EU database for high-risk AI systems established under Article 71, before market placement.

Post-market monitoring (Article 72): A monitoring plan must be in place from day one. Track performance data, collect user feedback, and update the risk management system accordingly.

Serious incident reporting (Article 73): If a serious incident occurs — defined in Article 3(49) — report to the competent authority of the affected member state within 15 days of becoming aware (or 2 days if there is widespread infringement or serious risk to critical infrastructure; 10 days if a death has occurred).

How Confir Helps

Confir's classification and documentation engine is rule-based and deterministic — same inputs produce the same outputs, with the rule that fires shown in plain language. No hallucination, no guesswork, audit-defensible from day one.

For an OpenAI API deployment, Confir does three things: registers the system in your AI inventory, classifies it through plain-English scenarios against Articles 5 and 6 with full Annex III logic to derive the risk tier and your role (Provider under Article 16 or Deployer under Article 26), and then drives a structured assessment across four compliance areas — AIRC (risk classification and conformity: Articles 5, 6, 43, 50), AITR (data and technical robustness: Articles 10, 11, 15), AITO (transparency and human oversight: Articles 13, 14, 27, 50), and AIGM (governance and post-market monitoring: Articles 9, 72, 73).

The output is a print-ready Annex IV technical documentation pack, an Article 47 EU Declaration of Conformity, and — where required — an Article 27 Fundamental Rights Impact Assessment. Pricing starts at €600 per year. No consultants, no implementation project.

Frequently Asked Questions

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

No. A GPAI provider is the entity that trains and makes available a general-purpose AI model — in this case, OpenAI. When you integrate the API to build a product, you become the provider of the downstream AI system under Article 16. OpenAI's Article 53 obligations (Annex XI technical documentation, Annex XII downstream information, copyright policy, training-data summary) stay with OpenAI. You receive the Annex XII downstream information as part of your API access, and incorporate it into your own Article 11 technical documentation.

My product uses GPT-4o for a customer-facing chatbot. Is it high-risk?

Probably not, but it depends on what the chatbot does. A general support or information chatbot is limited-risk under Article 50 — you must tell users they are speaking with an AI system. That obligation applies from 2 August 2026. If the chatbot makes or substantially influences consequential decisions (credit eligibility, benefits entitlement, recruitment shortlisting), the use case needs a full Annex III analysis. Classification follows function, not the model name.

What is the deadline for high-risk compliance if I build on the OpenAI API?

Stand-alone high-risk AI systems listed in Annex III must comply by 2 December 2027, under the Digital Omnibus political agreement reached in May 2026 (the original August 2026 date has been deferred). If your system is a safety component of an Annex I regulated product, the date is 2 August 2028. The Article 50 limited-risk transparency requirement for chatbots and synthetic content applies from 2 August 2026 — that date has not moved.

What are the penalties if I fail to comply?

Fines under Article 99 come in three tiers. Breaching the Article 5 prohibitions: up to €35 million or 7% of total worldwide annual turnover, whichever is higher. Non-compliance with most other obligations — including provider and deployer duties, high-risk requirements, and Article 50 transparency — up to €15 million or 3% of worldwide annual turnover. Supplying incorrect or misleading information to authorities or notified bodies: up to €7.5 million or 1% of worldwide annual turnover. For companies below the SME threshold, Article 99(6) caps fines at the lower of the fixed amount or the percentage — a genuine proportionality protection, but not a pass.

Do GDPR obligations change when I use the OpenAI API?

GDPR applies alongside the EU AI Act, not instead of it. If you process personal data via the API, you need a lawful basis, a data processing agreement with OpenAI, and — for high-risk or special-category processing — a data protection impact assessment under GDPR Article 35. GDPR Article 22 also limits solely automated decisions that produce legal or similarly significant effects on individuals; if your system makes such decisions without human review, you need either explicit consent or one of the GDPR Article 22 exemptions. The two regimes are complementary, and a high-risk AI Act system processing personal data triggers obligations under both.

I use the OpenAI API only internally, not in a product I sell. Does the Act apply?

Internal-only use means you are a deployer under Article 26, not a provider. Deployer obligations are lighter: use the system in accordance with the provider's instructions, monitor performance, maintain records, ensure human oversight where required, and — if you are a public body deploying a high-risk system or a deployer of certain creditworthiness or insurance systems — carry out a Fundamental Rights Impact Assessment under Article 27. If you substantially modify the system or put your name on it, Article 25 shifts you into provider status.

How does OpenAI's EU data residency option relate to the EU AI Act?

They are separate frameworks but practically linked. EU data residency means OpenAI processes your API traffic within EU infrastructure, which simplifies GDPR compliance on data transfers. For the EU AI Act, what matters is your system's Article 10 data governance: the training, validation, and testing data for the system you are building must meet the Act's quality and governance requirements. If you are fine-tuning the model or building a retrieval-augmented system on EU-resident data, documenting that data governance becomes straightforward. OpenAI's Annex XII downstream information will also specify the base model's training data scope, which you incorporate into your own technical documentation.

Related guides

• open-source exemptions under Article 6(1)
• Article 8 high-risk compliance requirements
• deployer obligations by market role
• SaaS compliance framework
• Article 26 deployer requirements
• Article 13 transparency obligations
• high-risk versus general-purpose classification tools
• Annex III social benefits assessment
• provider obligations checklist
• Article 3 key definitions
• systematic risk classification frameworks