Trust and compliance · 2026-09-08
The EU AI Act and LLM APIs: A Practical Guide for Developers
Understand your role under the EU AI Act when you consume an LLM API, what risk classification actually depends on, and how transparency duties translate into everyday engineering practice.
Establish your role first
The EU AI Act allocates duties by role. Training and placing a model on the market is not the same responsibility set as using an existing model inside your own product. Most teams consuming an LLM API are not the model's provider; they are a party deploying it in an application.
That distinction has practical consequences: part of the documentation, risk management and conformity work sits with the model provider. What remains on your side is the purpose you serve, the users you serve it to, and the assurances you attach to it.
Risk class is a property of the use, not the model
The same language model can sit behind a marketing copy generator and behind a recruitment screening tool; those are not in the same risk class. Classification follows from what the system does and who it affects, not from the model's technical specification.
Model choice is therefore not a substitute for a risk assessment. Using a model hosted in Europe does not turn a high-risk use case into a low-risk one; it answers a question on the data-protection side only.
How transparency duties show up in daily practice
Where a system interacts with people directly, they are expected to know they are dealing with an AI system. In practice that is a label in the interface and language that does not hide the possibility of a wrong answer. Systems producing synthetic content carry a separate marking expectation.
On the engineering side this turns into unglamorous but effective habits: record which model version was used on which date, version the system prompt, and keep every setting that changes model behaviour somewhere reviewable.
What model selection contributes here
Model choice does not settle the picture, but it makes part of it easier: if what a model does has been measured, describing what your system does becomes easier too. In the EU category of the LLMTR catalog, capabilities are not copied from a provider's marketing page — each model is run and tried before it is listed.
Concretely: tool calling was verified over a full two-turn loop on all 34 chat rows, 14 rows were measured to genuinely read images, and the eight rows that spend no reasoning tokens are named. Those are not just technical documentation; they are the ground you can stand on when describing your system's behaviour.
Frequently asked questions
If I use an LLM API, am I a provider under the EU AI Act?
Usually not; deploying an existing model in your application is a different role from placing a model on the market. That can change if you substantially modify the model or put it out under your own name. Confirm the determination with your legal counsel.
Does using a model hosted in Europe make me AI Act compliant?
No. Hosting location answers a data-protection question; AI Act duties follow from the system's intended purpose and risk class. They are separate assessments.
Which records should I start keeping now?
The model identifier and version in use, the version of your system prompt, significant parameter changes, and the points where human review enters the loop. These records serve regulatory questions and your own debugging equally well.