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

Integrating a general-purpose AI model does not make an organisation that model's provider, but it does create duties of its own. This article separates the obligations of GPAI model providers from the evidence a downstream integrator needs, explains why open weights do not remove governance, and describes vendor due diligence and a model register. Research on foundation models supplies the technical rationale: defects in an upstream model are inherited downstream.

Keywords EU AI Act · general-purpose AI · foundation models · downstream integrator · model register · due diligence

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.

The term foundation model was introduced for models trained on broad data and adapted to many downstream tasks. The same report warns that this homogenization means the defects of the foundation model are inherited by all adapted models downstream^[1]. That is the technical reason an integrator cannot treat the upstream model as someone else's problem.

Transparency upstream is limited. An index of 100 indicators, scored for ten major developers in 2023, found that no developer disclosed significant information about the downstream impact of its flagship model^[2]. Legal analysis of generative AI proposes distinguishing developers, deployers, users and recipients and tailoring duties to each^[3], and the Regulation sets obligations for general-purpose AI models separately from those for the systems built on them^[4]. For the integrator's own records, model cards offer a compact format for intended use and evaluation results^[5].

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.

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.

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.

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?

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.

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.

• European Commission — GPAI provider guidelines
• European Commission — GPAI obligations FAQ
• Regulation (EU) 2024/1689

• Practical EU AI Act guide
• High-risk classification and 2027 timeline
• Article 50 transparency obligations
• EU AI Act FAQ for enterprise teams
• Sovereign vLLM deployment
• Sovereign AI FAQ