Using Third-Party LLMs Under the EU AI Act: Obligations for Companies Building on GPT, Claude and Others

The Question Every Product Team Asks

Most organisations touching AI in 2026 are not training models; they are building on someone else's — calling a commercial large language model through an API, embedding it in workflows, or buying software that does. The first EU AI Act question for all of them is the same: what do we owe, given that the model is not ours? The answer under Regulation (EU) 2024/1689 is reassuring in one direction and demanding in the other. You do not carry the model provider's Chapter V duties — the technical documentation, training data summary and copyright policy belong to the company that placed the model on the market. But the regulation attaches its own obligations to what you build and how you use it, and those cannot be outsourced upstream.

First, Establish Your Role

The regulation distinguishes deployers — those using an AI system under their own authority in a professional context — from providers — those placing an AI system on the market or into service under their own name. Using an LLM-powered tool internally makes you a deployer of that system. Building a product on an LLM API and offering it to customers makes you the provider of an AI system (a general-purpose AI system or a purpose-specific one), with the model provider as your upstream supplier. Many companies are both at once, for different systems. The roles carry different duty sets, so an accurate internal inventory — which systems, which models, which role per system — is the foundation of everything else.

Universal Duty: AI Literacy

Article 4 has applied since February 2, 2025: providers and deployers must take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and others operating and using AI systems on their behalf, accounting for technical knowledge, experience, education and context of use. For a company rolling LLM tools across departments, this means documented, role-appropriate training: what the systems can and cannot do, hallucination and confidentiality risks, and the boundaries of permitted use. It is the cheapest obligation in the regulation to satisfy and one of the most commonly skipped.

Transparency Duties When the LLM Faces People

Article 50, applicable from August 2, 2026, attaches at several points where third-party LLMs meet users. If your product is a chatbot or assistant interacting directly with people, it must be designed so users know they are interacting with AI, unless that is obvious from context. If your system generates synthetic text, audio, image or video, the provider of that system — you, if you built the product — must ensure machine-readable marking of outputs as artificially generated, to the extent technically feasible and using state-of-the-art methods; check what marking support your model vendor offers and what survives your output pipeline. If you deploy generated content constituting a deepfake, or publish AI-generated text to inform the public without editorial responsibility, visible disclosure duties attach to you as deployer. None of these depend on owning the model.

The High-Risk Trigger: It Is About Use, Not Model

Annex III classifies systems as high-risk by their intended purpose — employment and worker management, credit scoring, education assessment, essential services access, and more. An LLM-powered application falls in scope when its use does, regardless of how general the underlying model is. If you provide a high-risk system, the full Chapter III programme applies from August 2, 2026: risk management, data governance, technical documentation under Annex IV, logging, instructions for use, human oversight design, accuracy and robustness evidence, conformity assessment and registration. If you deploy someone else's high-risk system, Article 26 duties apply: using it per instructions, assigning competent human oversight, monitoring, log retention, and — for many private deployers of certain systems and public bodies — fundamental rights impact assessments under Article 27. Quietly repurposing a general assistant into a high-risk use also converts roles under Article 25: the repurposer becomes the provider.

What the Model Provider Owes You

Your upstream vendor, as a GPAI model provider, owes downstream providers an information package under Article 53(1)(b) and Annex XII: capabilities, limitations, acceptable-use policies, integration requirements. If your application is high-risk, Article 25(4) requires a written agreement with suppliers of integrated AI components specifying the information, technical access and assistance you need for your own compliance. Use these levers in procurement: ask for the Annex XII package by name, contract for version-change notice (model updates can silently change your system's behaviour and invalidate your testing), secure marking and provenance feature continuity, and align incident-notification clauses with your own reporting duties under Article 73.

Data Protection Runs in Parallel

The AI Act does not displace the GDPR. Sending personal data to an LLM API engages the usual machinery — lawful basis, transparency to data subjects, processor terms with the vendor, international transfer safeguards where inference happens outside the EU, and data protection impact assessments for high-risk processing. Most corporate LLM incidents to date have been data governance failures — confidential or personal data pasted into tools without controls — which is one more reason the Article 4 literacy programme and a clear internal usage policy come first chronologically.

Vendor Due Diligence: What Good Looks Like

Because your compliance quality is capped by your vendor's transparency, model selection deserves a structured AI Act dimension alongside capability and price. A practical due diligence set for 2026: confirm the vendor is identifiable as the GPAI provider and, if established outside the EU, has an authorised representative under Article 54; check that its training data summary is published on the AI Office template and that a copyright policy and rightsholder contact exist — these are public artefacts, and their absence predicts deeper gaps; request the Annex XII package and assess whether its stated limitations cover your intended use; ask whether the model appears on, or is candidates for, the Commission's systemic-risk list, which signals both capability and supervisory attention; verify what output-marking and provenance support exists for your Article 50 duties; and review acceptable-use terms for exclusions that would push your planned application outside supported territory. Ten questions in a procurement template, answerable largely from public documents — and the vendors who answer them easily are, not coincidentally, the ones whose enterprise contracts also accommodate the change-notice and incident clauses you need.

A Concrete Example

A mid-sized insurer adopts third-party LLMs on three fronts. Internal copilot for staff: the insurer is a deployer; it ships a usage policy, role-based training under Article 4, and data controls blocking client personal data from unapproved tools. Customer-service chatbot built in-house on an LLM API: the insurer is the system's provider; the bot discloses its AI nature at conversation start, conversations are logged, and the Annex XII package from the model vendor sits in the technical file with a sixty-day version-change notice clause. Claims triage assistance: the insurer assesses whether the use affects access to essential private services under Annex III, concludes the configuration influences claim outcomes for consumers, treats the system as high-risk, and runs the full programme — human adjusters retain decision authority with real oversight, accuracy is tested on the insurer's own claims data, and the deployment is registered before the August 2026 deadline rather than argued around it.

Common Pitfalls

Five errors dominate: assuming the vendor's AI Act compliance statement covers your application — it covers their model; shipping chatbots without disclosure because the AI seemed obvious from context — document that judgement or add the notice; discovering Annex III late, after a sales team repositioned a general tool for hiring or credit decisions; ignoring model updates, so the system in production no longer matches the system that was tested; and skipping the written agreement and Annex XII package, leaving the conformity file structurally incomplete. All five are procurement and governance failures, not technology failures — and all five are visible to a supervisor within the first hour of an inspection.

Action Plan

Sequence the work pragmatically. Inventory every LLM touchpoint and assign roles. Stand up the usage policy and literacy programme now — the duty is already live. Classify each system against Annex III and Article 50, and start the high-risk programme for anything that qualifies. Rebuild procurement: Annex XII packages, Article 25(4) agreements, change notice, incident clauses. And put model-version monitoring into operations. Companies that do this discover the third-party-LLM position is regulatorily comfortable — the heavy model duties genuinely sit upstream — provided they hold their own layer with the same discipline they expect from their vendor.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.