EU AI Act GPAI Rules: Your Luxembourg 2026 Checklist

EU AI Act GPAI Obligations: What Luxembourg Companies Building on Foundation Models Must Do by August 2026

Learn more about AI implementation in Luxembourg in our comprehensive guide.

Most of the Luxembourg AI Act conversation has been about high-risk systems and the literacy obligation. We covered both — the 84-day high-risk roadmap and the Article 4 literacy duty. But the 2 August 2026 wave carries a third payload that almost every Luxembourg company touches and almost none has mapped: the general-purpose AI (GPAI) rules. If you build anything on top of GPT, Claude, Gemini, Mistral or Llama — and that is most of you — this one is yours.

With roughly ten weeks to 2 August, this is the planning-grade explainer. Not "the deadline is here" — the version you can still act on calmly.

What GPAI actually means

A general-purpose AI model is a foundation model that can do many things and be adapted into many systems — the large language and multimodal models everyone is building on. The AI Act treats the model as a regulated object in its own right, separate from any specific application built on it. That is the conceptual shift most Luxembourg companies have not internalised: there are obligations attached to the model layer, not only to your use case.

The Act splits GPAI into two tiers:

• All GPAI models: baseline transparency obligations on the model provider — technical documentation, information for downstream integrators, a copyright policy, and a public summary of training-data content.
• GPAI with systemic risk: the largest, highest-capability models carry an additional layer — model evaluation, adversarial testing, serious-incident tracking, and cybersecurity obligations.

The relevant question for a Luxembourg SME or mid-cap is rarely "do I train a foundation model?" — almost none do. It is "what does this make me responsible for as the company that builds on one?" That is where the real trap is.

The provider-vs-deployer trap

This is the single most-confused point in every AI Act conversation we have in a Luxembourg client room, and it is the one that decides who owns which obligation.

• A provider develops an AI system (or GPAI model) or has one developed and places it on the market or puts it into service under its own name or brand.
• A deployer uses an AI system under its own authority in the course of a professional activity.

Most Luxembourg companies assume they are deployers — they are "just using" an API. That assumption is often wrong. The moment you take a foundation model, wrap it, give it your own name, and put it in front of customers or substantially modify how it behaves, you can become a provider of an AI system in the Act's sense — with the heavier obligation set that goes with it. The label is not a formality; it determines your documentation, transparency and, for some use cases, conformity duties.

A short, honest test for which side of the line you are on:

1. Are you reselling or rebranding an AI system under your own name? That pulls you toward provider.
2. Are you substantially modifying the system or repurposing it for a use the original provider didn't intend? Same direction.
3. Are you building a downstream system on a GPAI model and putting it on the market? You likely have provider-side obligations for that system, even though you didn't build the model.
4. Are you genuinely just using a tool internally, as delivered, for its intended purpose? That is the cleaner deployer position.

Most Luxembourg companies sit on point 3 and have been planning as if they were on point 4. The fix is not panic — it is mapping it before August, not after.

What this means concretely for a Luxembourg company

Translate the legal text into the four actions that matter before 2 August:

1. Build a model inventory

List every GPAI model in production use across the company — the obvious API integrations and the shadow ones (a team using a consumer chatbot for client work is in scope). You cannot manage obligations on an inventory you do not have. This is the same governance backbone the high-risk roadmap needs, so build it once and reuse it.

2. Classify your role per system

For each AI system you operate, decide — and document — whether you are provider or deployer for that system. Not company-wide; per system. You can be a deployer of one tool and a provider of another in the same week. This document is the artefact a regulator or a customer's due-diligence team will ask for first.

3. Collect the upstream documentation

As a downstream builder you are entitled to specific technical information from the model provider. Collect it now and store it with the inventory: it is both your compliance evidence and exactly what your own customers will demand in their vendor due diligence. The major providers (OpenAI, Anthropic, Google, Mistral) publish this; the work is collecting and version-tracking it, not chasing it.

4. Set transparency where users interact with AI

Where a person interacts with your AI system, or where content is AI-generated, the Act expects that to be disclosed. For most Luxembourg companies this is a small, cheap UI and policy change — but only if it is done deliberately rather than discovered in an audit.

How this chains with the rest of your AI Act work

GPAI is not a separate project. The model inventory feeds the high-risk classification; the provider/deployer mapping feeds your CSSF outsourcing file if you are supervised (the DORA + AI Act overlap); the literacy obligation makes the whole thing operable because staff who do not understand the provider/deployer distinction will misclassify systems. Companies treating these as one governance workstream finish before August. Companies treating them as four separate fire drills do not. Your model choice also interacts with this — the trade-offs are in our best AI model for Luxembourg business comparison, because different providers ship different downstream documentation.

The honest timeline

Ten weeks is enough for the inventory, the role classification, the documentation collection and the transparency changes — for a typical Luxembourg SME or mid-cap that is a focused two-to-three-week effort, not a quarter. It is not enough if you start in late July, because the provider/deployer classification often surfaces a system you did not know you were the provider of, and that takes longer to remediate than to discover. The cost of doing this in May is a planning meeting. The cost of doing it in August is the same work done reactively, in public, with a regulator's calendar instead of yours.

How we approach this with clients

We run GPAI mapping as a single half-day workshop: inventory, per-system provider/deployer classification, the upstream-documentation checklist, and the short list of transparency changes — folded into the same governance file as the high-risk and literacy work so you have one defensible artefact, not four.

If you build on foundation models and have not yet mapped which side of the provider/deployer line each system sits on, book an AI Act GPAI readiness session. You bring your real integrations; you leave with a per-system classification and a prioritised action list dated against 2 August.

Related reading:

• EU AI Act high-risk systems: the 84-day Luxembourg roadmap
• EU AI Act August 2026 deadline: Luxembourg compliance
• EU AI Act Article 4: the AI literacy obligation in Luxembourg
• DORA + EU AI Act: Luxembourg financial compliance in 2026
• Best AI model for business in Luxembourg — 2026 comparison
• EU sovereign cloud vs. hyperscalers vs. on-prem AI: Luxembourg 2026
• AI Knowledge Hub — 20 More Resources