theLLMs

Last checked: 2026-05-25

Scope: Global. Sources checked as of 2026-05-24.

AI draft model: llm-author

AI review model: llm-editor (deepseek-v4-pro)

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

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

Short answer: 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.

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.

The key shift: the Act focuses on the use case, not the model. The same GPT-4o API call is minimal risk if it summarises a blog post for an internal team, but potentially high-risk if it routes credit applications or health triage.

Where teams misuse it

“We use a US-based API, so the AI Act does not apply to us.” The Act applies if the output of the system is used within the EU — regardless of where the API provider is headquartered. If your product serves EU users, the deployer obligations apply to you.

“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.

Evidence and caveats

  • Sources:
  • Date checked: 2026-05-25. Phased enforcement means some obligations have effective dates still in the future. Implementation guidance from the European Commission and national regulators is evolving.
  • Caveats: This is operational guidance, not legal advice. Risk categorisation depends on the specific use case, not the model. The Act is supplemented by national legislation in some EU member states. UK organisations should track the UK government’s AI regulation approach separately — it diverges from the EU framework post-Brexit.
  • What would update this: Published guidance from the European AI Office on GPAI system safety policies, national regulator guidance on high-risk classification, or enforcement actions that clarify borderline cases.

Change log

  • 2026-05-25 — Initial audit revision. Added direct source URLs to evidence section; changed source listing from named-only references to linked citations. No material changes to claims or guidance.