EU AI Act and GPAI Models: What LLM Builders and Users Must Know

If you build products using large language models — whether via OpenAI, Anthropic, Google, Meta, or an open-source alternative — the EU AI Act has obligations that directly affect you. GPAI model obligations have been in force since August 2, 2025. Most LLM application builders are unaware of what this means for their compliance position.

This guide explains how the EU AI Act treats general-purpose AI models, what obligations apply to model providers versus application builders, and what you need to do if you build on top of a third-party LLM.

What Is a GPAI Model?

The EU AI Act defines a General-Purpose AI model (GPAI model) as an AI model that:

Is trained on a large amount of data using self-supervision at scale
Displays significant generality
Is capable of competently performing a wide range of distinct tasks
Can be integrated into a variety of downstream systems or applications

In practice, this captures all large foundation models: GPT-4 and its successors, Claude, Gemini, Llama, Mistral, Falcon, and comparable models. The definition is intentionally broad.

Critically, a GPAI model is not the same as a GPAI system. A GPAI model is the underlying trained model (the weights). A GPAI system is when a GPAI model is used in an application that interacts with users. This distinction matters for who bears what obligations.

The Two Tiers of GPAI Obligations

Tier 1: All GPAI Model Providers (Title VIII, Articles 53–55)

Any provider placing a GPAI model on the EU market must:

1. Maintain technical documentation for downstream providers — not the public, but the businesses that integrate your model into their products. This documentation must include:

General description of the model and its intended use cases
Information about training methodology, data, and compute used
Performance and benchmark results
Known limitations and risks
Applicable safeguards implemented

2. Publish a summary of training data that is detailed enough for downstream providers to assess copyright compliance and data quality issues. The summary must be made publicly available.

3. Implement a copyright compliance policy — GPAI model providers must have and publish a policy for complying with EU copyright law, including respecting rights holders’ opt-outs under the Text and Data Mining exception.

4. Provide information to downstream providers — when a downstream provider integrates the GPAI model, they must receive the technical documentation necessary to comply with their own EU AI Act obligations. This is a formal requirement, not just good practice.

Tier 2: GPAI Models with Systemic Risk (Article 51)

GPAI models with systemic risk face additional, more stringent obligations. A GPAI model is presumed to have systemic risk if it was trained using a total compute of more than 10^25 FLOPs (floating-point operations).

The EU AI Office can also designate a model as having systemic risk based on other factors — including number of users, economic impact, or novel capabilities.

Additional obligations for systemic risk models:

Adversarial testing: Conduct model evaluations including red-teaming to identify and mitigate systemic risks
Incident reporting: Report serious incidents and corrective measures to the EU AI Office
Cybersecurity: Implement appropriate protection against model theft, adversarial attacks, and data poisoning
Energy efficiency: Report energy consumption of the model

Which models currently exceed the 10^25 FLOPs threshold? The most capable GPT, Gemini, and Claude models from major providers. Open-source models like Llama 3.1 405B are close to the threshold. The EU AI Office assesses this on an ongoing basis.

What “Building on a GPAI Model” Means for You

If you build a product using a GPAI model API — a chatbot, a document analyser, a code assistant, a customer service tool, a content generator — you are a downstream provider. Your compliance obligations depend on what your product does with the model.

Case 1: Your Product Is Not High-Risk

If your LLM-powered product does not fall within any Annex III high-risk category — for example, a general-purpose writing assistant or a coding tool — then Annex III obligations do not apply. You are subject to:

Article 52 transparency: If your system interacts with natural persons, they must be informed they are interacting with AI (unless obvious from context). AI-generated content must be machine-readable marked. Deepfakes must be labelled.
The GPAI model provider’s obligations (documentation, copyright policy) apply to them, not to you.

Case 2: Your Product Is High-Risk

If you build an LLM-powered product that falls within Annex III — for example, an AI interviewing tool, a loan decision assistant, or a medical triage chatbot — then you are a high-risk AI system provider and all Annex III obligations apply to your system.

This is where the GPAI intersection becomes practically important. Your Annex IV documentation must include:

Reflect the GPAI model’s characteristics in your technical file:

The EU AI Act explicitly requires that when a high-risk AI system is built on a GPAI model, the provider’s Annex IV documentation must incorporate information about the GPAI model that is relevant to the system’s compliance. This means:

Item 2 (Design specifications): Document which GPAI model you use, which version, what configuration (system prompt, temperature, context window), and what limitations of the model are relevant to your intended purpose
Item 3 (Training data): You cannot fully document the GPAI model’s training data (the provider controls this), but you must document what information the GPAI provider has shared and how you have assessed it. If the GPAI model has known training data biases, document how you have addressed them in your system design
Item 5 (Risk management): Include risks arising from GPAI model behaviour — hallucination, prompt injection, inconsistent outputs, unexpected failure modes — in your risk register
Item 7 (Accuracy and robustness): Your accuracy and robustness testing must cover GPAI-specific failure modes, not just task-level performance

Get what you need from your GPAI provider:

Your ability to complete your own Annex IV documentation depends on what your GPAI model provider discloses. The Act requires GPAI providers to give downstream providers the information they need. In practice, you should:

Request the GPAI model’s technical documentation summary from your provider
Confirm which version of the model you are using and whether there is a changelog
Obtain the provider’s statement on training data scope and limitations
Document any known limitations or failure modes the provider has communicated

For providers of proprietary models (OpenAI, Anthropic, Google), much of this information is publicly available in model cards and system cards. For open-source models, training data documentation varies widely.

Prompt Injection: A Specific Systemic Risk

For LLM-based systems, prompt injection deserves particular attention in your risk management system. Prompt injection occurs when malicious content in the input (user data, external documents, web content) manipulates the LLM into ignoring its instructions and performing unintended actions.

For high-risk AI systems, prompt injection is not merely a security issue — it is a compliance issue. If an adversarial user can manipulate your LLM-based hiring screener into ignoring its bias mitigation guidelines, or your medical triage AI into ignoring its safety guardrails, the integrity of your human oversight measures is compromised.

Your risk register should include prompt injection as an identified risk with documented mitigations:

Input validation and sanitisation
Separation of trusted instructions from untrusted data
Output monitoring and anomaly detection
Human review of high-stakes outputs
Regular red-teaming exercises

Article 52: Transparency for AI-Generated Content

Even for non-high-risk LLM applications, Article 52 transparency obligations apply:

AI interaction disclosure: Systems designed to interact with natural persons must be designed so users are informed they are communicating with AI — unless obvious from context. A customer service chatbot that could be mistaken for a human employee must disclose its AI nature.

AI-generated content labelling: Providers of AI systems that generate audio, image, video, or text content must mark the output as AI-generated in a machine-readable format. This applies to any LLM-powered content generation tool.

Deepfake labelling: AI-generated or manipulated images or video depicting real persons must be labelled as artificially generated or manipulated — with limited exceptions for parody and satire.

The GPAI Code of Practice

The EU AI Office has been developing a Code of Practice for GPAI model providers — a voluntary but practically important framework that major GPAI providers are expected to sign. Complying with the Code of Practice creates a presumption of conformity with GPAI obligations.

For downstream application builders, the Code of Practice matters because it shapes what documentation and transparency you can expect from your GPAI provider — and therefore what you can rely on in your own compliance documentation.

Practical Next Steps for LLM Application Builders

1. Classify your application: Does it fall within any Annex III high-risk category? Be specific — the question is not whether you use an LLM, but what decisions your application informs.

2. If high-risk: Start your Annex IV documentation now. Request technical documentation from your GPAI provider. Build your risk register to include GPAI-specific risks.

3. If not high-risk: Implement Article 52 transparency obligations. Ensure AI interaction disclosure and content labelling are in place.

4. Track GPAI model versions: Annex IV documentation must specify the version of the GPAI model used. When you update to a newer model version, assess whether this constitutes a substantial modification requiring a new conformity assessment.

Our free Status Quo Assessment can help you determine whether your LLM application falls within Annex III and what documentation gaps exist. For a full Annex IV roadmap applicable to GPAI-based systems, see our Technical Documentation Roadmap.