All insights
EU AI Act · GPAI

EU AI Act GPAI obligations: what changes when you integrate a foundation model

Using a foundation model does not make you its provider. Role in the value chain decides the evidence you need.

Using a general-purpose AI model does not automatically make an enterprise the provider of that model. The EU AI Act distinguishes between the organisation providing a GPAI model and downstream providers or integrators building systems on top of it.

That distinction matters because the compliance evidence you need depends on your role in the value chain.

GPAI model providers

Providers placing general-purpose AI models on the EU market have obligations around technical documentation, information for downstream providers, copyright policy and public transparency about training content. Providers of models with systemic risk face additional safety, evaluation, incident and cybersecurity obligations.

The European Commission states that the GPAI obligations became applicable on 2 August 2025, and Commission enforcement powers apply from 2 August 2026.

Downstream providers and integrators

Most enterprise AI teams are not training a foundation model from scratch. They combine a model with retrieval, tools, business logic, data sources and a user interface.

That still creates responsibilities.

A downstream provider should be able to explain:

  • which model and version the system uses;
  • what the model is expected to do inside the product;
  • what limitations are known;
  • what information was received from the upstream model provider;
  • how the model was evaluated for the specific use case;
  • what controls exist around prompts, retrieval, tools and outputs;
  • how model changes are tested before production rollout.

Open-weight models do not eliminate governance

Self-hosting an open-weight model can improve control over data flow and infrastructure, but it does not remove the need to classify the resulting AI system under the Act.

The legal role depends on what the organisation does with the model, how substantially it modifies it, and how the resulting system is placed on the market or used. From an engineering perspective, the safe default is to preserve model provenance, configuration, evaluation results and deployment history.

Vendor due diligence becomes part of AI architecture

When an enterprise depends on a third-party model provider, contract and architecture decisions become linked.

The downstream team should request enough information to assess the model in the deployed context. Useful questions include:

  1. What model version is being supplied and how are updates communicated?
  2. What technical documentation is available to downstream providers?
  3. What are the known limitations and intended-use boundaries?
  4. What security and incident channels exist?
  5. Can the customer pin a model version?
  6. Where are prompts and outputs processed and retained?
  7. What happens when the provider changes model behaviour?

Build a model register

A practical enterprise control is a model register linked to each production system.

For each model, record:

  • provider and model identifier;
  • version or checkpoint;
  • licence and usage constraints;
  • deployment location;
  • quantisation or fine-tuning state;
  • evaluation set and acceptance thresholds;
  • known limitations;
  • change history;
  • systems that depend on the model.

This gives engineering, security and compliance teams one shared source of truth.

The LMXAI approach

LMXAI treats foundation models as replaceable components inside a governed system. The architecture should make it possible to switch providers or self-host models without losing evaluation, logging, access control or audit evidence.

That model-agnostic design is useful not only for sovereignty and cost control; it also reduces compliance risk when upstream models change.

Primary sources

Related reading

Next step. If you want this to ship, LMXAI scopes the integration as a system — not a workshop series.

Start a project