“We just use the OpenAI API” — does the EU AI Act apply?

Short answer: yes, almost certainly. If your team calls the OpenAI API, runs ChatGPT at work, or ships a product built on someone else’s model, the EU AI Act reaches you — not as the builder of the model, but as a deployer, and in some cases as the provider of your own AI system. One duty already binds you today: the AI literacy obligation in Article 4, which has applied since 2 February 2025 regardless of risk tier. Everything else depends on what you use the system for.

Why “we didn’t build the model” is the wrong test

The most common misconception among European SMEs is that the Act regulates model builders. It does not — or rather, not only. The Act is built on roles and uses, not on who trained the weights. Article 3(3) defines a provider as anyone who develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under their own name or trademark. Article 3(4) defines a deployer as anyone using an AI system under their authority, other than in a personal non-professional activity. Neither definition asks who paid for the GPUs. If you use an AI system at work, you are a deployer — full stop. For the wider framework, see our guide to the EU AI Act; for the role split in detail, see provider vs deployer.

What already applies to you, in July 2026

Two things bite today, whatever your risk tier. First, Article 4 (AI literacy), applicable since 2 February 2025, requires providers and deployers to take measures so that staff and other people operating AI systems on their behalf understand them sufficiently, proportionate to their technical background and the context of use. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026) softened this into an obligation of effort rather than of result — you need not certify individuals — but the duty to take documented, proportionate measures stands. Second, the Article 5 prohibited practices have applied since the same date: social scoring, manipulative or exploitative techniques causing significant harm, untargeted scraping of facial images, emotion inference in the workplace and in education, and certain biometric categorisation. These bind deployers directly and carry the heaviest fines — up to 7% of global turnover, with SMEs capped at the lower of the percentage and the fixed amount (see penalties and fines).

• A one-page written policy naming the approved tools, the data that must never be pasted into them, and who to ask when in doubt.
• One 60–90 minute session for all staff: what the tools do, where they fail (hallucination, bias, confidently wrong answers), and the Article 5 red lines.
• A deeper session for whoever actually builds on the API — prompt and data handling, logging, evaluation, human review of outputs before they reach a customer.
• An attendance record and a dated copy of the material. The obligation is to take measures; undocumented measures are indistinguishable from none.
• A refresh when you adopt a new tool or a new use case, not annually by reflex. Our AI literacy resources give you a starting curriculum.

Article 25: when building on someone else’s model makes you a provider

Deployer status is not permanent. Article 25 sets out three triggers that turn a distributor, importer, deployer or other third party into the provider of a high-risk AI system, with the full set of provider obligations attached. If you wrap an API in a product, read them closely — they are easier to trip than most teams assume. Where a trigger fires, the original provider must supply the technical information and access you need, unless it contractually excluded that modification.

1. Your own name or trademark — Article 25(1)(a). You put your brand on a high-risk system already on the market. In practice: you resell a white-labelled CV-screening engine as “Acme Talent Match”. The model is someone else’s; the system on the market is yours.
2. Substantial modification — Article 25(1)(b). You materially change a high-risk system already placed on the market and it remains high-risk. In practice: you fine-tune on your own decision history and bolt on a scoring layer that changes how the output is computed — not merely a new system prompt.
3. Change of intended purpose — Article 25(1)(c). You repurpose a system — expressly including a general-purpose AI system not previously classified as high-risk — so that it becomes high-risk. In practice: you build a document-summarisation tool on the API, then market it to HR teams for ranking job applicants. Same code, new intended purpose, new legal status.

Article 50: telling people they are dealing with a machine

Article 50 applies well below the high-risk threshold and is the deadline that matters most right now. Providers of systems that interact directly with natural persons must design them so people are informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed person. Providers of systems generating synthetic audio, image, video or text must mark the output in a machine-readable format, detectable as artificially generated or manipulated. Deployers carry their own duties: disclose deep fakes, disclose AI-generated text published to inform the public on matters of public interest unless it went through human editorial review, and inform people exposed to emotion recognition or biometric categorisation. The interaction-disclosure duties apply from 2 August 2026. The Article 50(2) marking duty applies from that same date for systems placed on the market after it, with a grace period to 2 December 2026 for systems already on the market before it. Practical detail for chatbots is in our generative AI and chatbots guide.

When “we just call an API” turns out to be high-risk

Risk under the Act is a function of use, not of architecture. A thin wrapper around a general-purpose model lands in Annex III the moment it serves a listed purpose. The headings that catch ordinary B2B SaaS are employment and worker management (analysing and filtering job applications, targeted job advertising, promotion and termination decisions, task allocation, performance monitoring); access to essential private and public services (creditworthiness evaluation and credit scoring other than fraud detection, risk pricing in life and health insurance, eligibility for public benefits); and education and vocational training (admission decisions, evaluation of learning outcomes, exam proctoring). If your product does any of that, the fact that you did not train the model is irrelevant. After the Digital Omnibus, the obligations for stand-alone Annex III systems apply from 2 December 2027, and for AI embedded in products already covered by EU product safety law from 2 August 2028 — later than the dates originally written into the Act, but not far off. The full list is in our Annex III high-risk guide.

What the model provider does for you — and what it does not

Chapter V places obligations on providers of general-purpose AI models: technical documentation, information and documentation for downstream providers who integrate the model, a copyright policy, and a sufficiently detailed public summary of training content, with heavier duties under Article 55 for models with systemic risk. Those duties sit with OpenAI, Anthropic, Google, Mistral and their peers — not with you, and you are not fined for their breaches. Nor does their compliance discharge yours: a model card says nothing about whether your use case is prohibited, whether your chatbot discloses itself, or whether your hiring feature is in Annex III. What you should extract from the vendor is concrete — the downstream documentation they must make available under Article 53, a written statement of the model’s intended purpose and known limitations, confirmation of which modifications your contract permits, and a GDPR data processing agreement covering the API traffic. File all of it as evidence in your own record: it is an input to your assessment, never a substitute for it. More in our GPAI model obligations guide.

Do it in this order

1. Inventory every AI touchpoint, including the shadow ones. Not just the API keys in your codebase: the ChatGPT accounts on personal cards, the AI features silently switched on inside your CRM and helpdesk, the meeting note-takers, the marketing copy tools. Most inventories miss half the estate on the first pass.
2. Assign a role per use case, not per company. You can be a deployer of ChatGPT for internal drafting and the provider of your own customer-facing product at the same time. Run each use case through the Article 25 triggers separately.
3. Run the Article 4 literacy training now. It is the only obligation already overdue, and it is by far the cheapest to close.
4. Test each use case against Article 5, then Annex III, then Article 50. Prohibited first, high-risk second, transparency third. Our SME compliance checklist walks through the sequence.
5. Write down the reasoning, not just the conclusion. A regulator will ask why you concluded a system is not high-risk. A dated assessment naming the use case, the Annex III headings considered and the reasoning is the whole defence. An undocumented conclusion is not one.

If you are unsure which side of any of these lines you sit on, the fastest way to find out is to classify one system properly. Our free Risk Checker walks a single use case through the Article 5, Annex III and Article 50 questions in a few minutes and returns a dated, exportable result; the full compliance platform then keeps the inventory, the role assignments and the evidence in one place as the deadlines arrive. This article is general information about the regulation, not legal advice — for a binding view on your specific systems, consult qualified counsel.