theLLMs

Last checked: 2026-05-28

Scope: EU. Sources checked as of 2026-05-28. This is operational guidance, not legal advice. UK organisations should track the UK government's separate AI regulation approach.

AI draft model: gemma4:26b

AI review model: deepseek-r1:32b

Key terms:

>_ large language model (LLM) >_ RLHF (Reinforcement Learning from Human Feedback) >_ LLM-as-a-judge >_ batch API >_ API (Application Programming Interface) >_ EU AI Act
Hero image for EU AI Act for LLM buyers: what to track without overclaiming

EU AI Act for LLM buyers: what to track without overclaiming

If you buy LLM API access and use it in a product or internal tool, you are a “deployer” under the EU AI Act — not a provider. Your obligations are lighter than the model provider’s, but they are real: human oversight, transparent usage disclosure, risk assessment for high-risk use cases, and record-keeping. The Act does not ban LLM use. It does require you to know what you are deploying and where it sits on the risk ladder.

TL;DR

If you buy LLM API access and use it in a product or internal tool, you are a deployer under the EU AI Act. Your obligations are lighter than the model provider’s but they are real: transparency (tell users they are interacting with AI), human oversight for high-risk use cases, record-keeping, and a risk assessment against Annex III. Most LLM use — chatbots, internal tools, content drafting — is minimal or limited risk and requires no conformity assessment. The Act does not ban LLMs; it requires you to know where your deployment sits on the risk ladder and to act accordingly.

What it means

The EU AI Act divides AI systems into risk categories: minimal, limited, high, and unacceptable. Most LLM API use — customer support bots, internal knowledge tools, content drafting — falls into minimal or limited risk, which means no conformity assessment is needed. But there are specific obligations that apply downstream:

Provider duties (the LLM API vendor):

  • General-purpose AI (GPAI) model providers must publish a summary of training data, comply with copyright rules, and implement a safety policy.
  • If the model poses systemic risk (measured by training compute threshold or market designation), additional obligations apply: model evaluations, adversarial testing, incident tracking.

Deployer duties (your team using the API):

  • Transparency — inform users they are interacting with an AI system (unless obvious from context).
  • Human oversight — ensure meaningful human review for high-risk use cases.
  • Record-keeping — maintain logs of system operation for high-risk deployments.
  • Risk assessment — determine whether your specific use case is high-risk under Annex III.
  • Fundamental rights impact assessment — required for high-risk deployers.

Where teams misuse it

“We just use the API — the provider is responsible for compliance.” The provider is responsible for the model’s training-data compliance and safety policy. You are responsible for how you deploy it. The Act explicitly separates provider and deployer duties.

“We do not have any ‘high-risk’ use cases.” Many teams assume this without checking Annex III. Use cases like credit scoring, employee evaluation, access to education, biometric categorisation, and critical infrastructure management are explicitly listed. If your LLM touches any of these, you need a conformity assessment.

“We will figure out compliance when enforcement starts.” The Act’s provisions apply in phases. GPAI rules were among the earliest to take effect. Deployer obligations for high-risk systems follow a later timeline. Ignorance does not delay the effective dates.

Practical decision check

For every LLM feature you deploy:

  1. What is the use case? Match it against Annex III (high-risk categories). If it fits, plan a conformity assessment.
  2. Who is the deployer? If the system is used within the EU, deployer obligations apply to the organisation deploying it — even if the developer is outside the EU.
  3. Are users informed? The transparency obligation applies regardless of risk level. If a user talks to your AI feature, they should know.
  4. What records do you keep? For high-risk use cases, maintain logs of system inputs, outputs, and human oversight decisions.
  5. Is there a human review process? High-risk systems require meaningful human oversight — not rubber-stamping.

Lightweight compliance steps for small teams

  1. Document every LLM use case — maintain a simple register: model, provider, use case, data types processed, risk categorisation.
  2. Add a transparency notice — “You are interacting with an AI system” on chatbot interfaces, AI-generated content labels for automated outputs.
  3. Keep an incident log — record any harmful outputs, safety refusals on sensitive topics, or data leakage events. This satisfies record-keeping requirements and helps with provider reporting.
  4. Limit high-risk use unless assessed — do not deploy LLMs for Annex III use cases without a documented risk assessment and human oversight process.
  5. Track provider compliance — check that your API provider publishes training-data summaries and a safety policy. If they do not, consider the compliance gap as a procurement risk.

Methodology

  • Data checked: 2026-05-28
  • Sources consulted: Regulation (EU) 2024/1689 (EU AI Act official text), European Commission AI Act FAQ, European AI Office publications, ICO AI guidance (for UK comparison), Allen & Overy legal explainers
  • Assumptions: Phased enforcement means some obligations have effective dates still in the future as of May 2026. Implementation guidance from the European Commission and national regulators is evolving. This article assumes the reader is building or procuring LLM-based features for use within or serving the EU market.
  • Limitations: This article provides operational guidance, not legal advice. Risk categorisation depends on specific use cases, not the model. The Act is supplemented by national legislation in some EU member states. UK organisations should track the UK government’s separate AI regulation approach — it diverges from the EU framework post-Brexit. Annex III interpretation and enforcement practice will evolve as national regulators issue guidance.
  • Jurisdiction: EU. Specific references to Regulation (EU) 2024/1689 and European Commission guidance. UK organisations should consult ICO and UK government sources separately.

Source list

Trust Stack

  • Last checked: 2026-05-28
  • Corrections: Contact us to report errors

Change log

  • 2026-05-28: Full editorial review against 16-gate checklist. Restructured article: converted inline short answer to proper Quick Answer section, added three Editor’s Note aside cards, created standard Methodology and Source List sections (previously embedded in “Evidence and caveats”), added Trust Stack section with corrections policy and affiliation declaration, slugified all heading IDs, corrected scope from “Global” to “EU” with UK divergence note, updated lastChecked and source access dates.
  • 2026-05-25: Initial publication. Added direct source URLs to evidence section.