guide6 min read

GPAI obligations for SMEs using third-party LLMs

You are probably not training a GPAI model, but Chapter V of the EU AI Act still applies to your team if you fine-tune a third-party model in a way that changes its intended purpose, or if you build a product on top of one. The obligations are narrower than the high-risk regime but real.

You are probably not training a GPAI

The Act defines a GPAI model with systemic risk by a compute threshold: 10^25 FLOPs at training time (Article 51). That puts the bar above all but a handful of frontier labs. Most SMEs using AI in their product are deployers or downstream providers, not model trainers.

Chapter V is still relevant to your team in two ways.

Substantial modification of a third-party model

If you fine-tune or modify a third-party GPAI model in a way that changes its intended purpose, you inherit downstream provider obligations under Article 25. The threshold is "substantial modification".

Cosmetic system-prompt changes do not count. Wrapping a model in a few prompts and exposing it through your UI does not count. A fine-tune that changes what the model is for (training it on your domain to perform a specialised task it could not previously perform) does count, and so does training on additional data that materially changes the model’s capabilities.

In practice, most SMEs that use an API never cross the substantial-modification threshold. SMEs that train custom adapters or LoRA fine-tunes on top of open-weights models can. The threshold is unsettled and guidance is evolving; document the change you make and the reasoning behind your classification.

Building on top of a GPAI: the deployer angle

If you build a product on top of a GPAI model (OpenAI, Anthropic, Mistral, an open-weights model from Hugging Face), the model provider has obligations under Article 53 to make documentation and risk information available to you. Read the model card and the acceptable-use policy of every GPAI you rely on.

Your obligations as a downstream deployer are lighter than the provider’s. You still need to comply with Article 50 transparency where it applies (users told they are interacting with an AI system, synthetic content labelled), and with any sectoral obligations the underlying use case carries.

Evidence to keep

  • The model card and acceptable-use policy of every GPAI you use, downloaded as of the date you adopted the model.
  • The model version and provider, captured per release of your product. Provenance and versioning are first-class evidence in product regulation.
  • Any system prompts, retrieval augmentation, or tools you wrap around the model, version-controlled.
  • A short rationale for why your modification does or does not cross the substantial-modification threshold.
  • For limited-risk transparency obligations triggered by your product, the user-facing disclosure text and how it is shown in the UI.

The Code of Practice

The Code of Practice for GPAI providers (drawn up under Article 56) covers transparency, copyright compliance, and safety. It is voluntary but signatories receive a presumption of compliance for the obligations it covers. If you are using a signatory model, that simplifies the documentation chain. If your provider is not a signatory, you carry more of the diligence load.

References