GPAI Obligations: What Foundation Model Providers Owe Their Users

When the EU AI Act passed, most of the attention went to high-risk systems and the August 2026 enforcement deadline. The provisions covering General-Purpose AI — the foundation models that everything else is built on — got less press but went live earlier. GPAI obligations activated in August 2025 and have been quietly reshaping the foundation model market for nine months.

If you're integrating any frontier model into a product — Claude, GPT, Gemini, Llama, Mistral, anything — GPAI compliance affects you. Not because you're a GPAI provider (most likely you're not), but because what your vendor owes you under GPAI is what you depend on for your own compliance.

This post is the practical guide to what GPAI providers must do, what they must give to downstream users, and how the obligations cascade through the value chain.

What GPAI Is

The AI Act defines a General-Purpose AI model as an AI model that "displays significant generality and is capable of competently performing a wide range of distinct tasks." Practically, this catches: large language models, multimodal foundation models, large image/video/audio generation models, and any model that can be repurposed across many downstream applications.

It does not catch: narrow models trained for a single specific task (a credit scoring model, a fraud detection classifier, a specific recommendation system), even if they're large. The distinguishing feature is generality.

The definition is intentionally functional, not parameter-count based. A 7B-parameter model fine-tuned for general use might be GPAI; a 70B-parameter model trained narrowly for one task might not be. The market reality is that almost every frontier-scale LLM and multimodal foundation model qualifies as GPAI.

The Four Core Obligations

Every GPAI provider — regardless of model size — owes these four things.

1. Technical documentation. GPAI providers must produce and maintain technical documentation of the model. This includes information about the model's training (architecture, training methodology at a high level), capabilities and limitations, evaluation results, computational resources used, energy consumption, and intended uses. This documentation must be available to the European AI Office on request and, in summary form, to downstream providers.

2. Information for downstream providers. GPAI providers must publish or make available to downstream providers using the model: the model's capabilities and limitations, the intended uses (and uses that should be avoided), how to integrate the model safely, the type and nature of training data (in summary), and known risks. This is what downstream providers reference for their own compliance.

3. Copyright compliance and training data transparency. GPAI providers must implement a policy to comply with EU copyright law (including the text and data mining provisions of the Copyright in the Digital Single Market Directive) and publish a "sufficiently detailed summary" of the content used to train the model. The summary template is being developed by the European AI Office; early templates require descriptions of categories of training data, indicative sizes, and high-level provenance information.

4. Text and data mining opt-out compliance. EU copyright law allows rightsholders to opt out of having their content used for text and data mining (training, in practice). GPAI providers must implement technical measures to respect those opt-outs going forward, including for content scraped from the open web that has opt-out signals (typically via robots.txt or similar mechanisms).

These four apply to all GPAI providers. There's a second, heavier set of obligations for the largest models.

Systemic Risk GPAI

A subset of GPAI models — those that present "systemic risk" — face additional obligations. A model is presumed to have systemic risk if its training used more than 10^25 floating-point operations. This is a compute threshold, not a parameter threshold, and it currently catches roughly the top dozen frontier models from the major labs.

The systemic risk GPAI obligations are substantially heavier:

Systematic risk assessment. Providers must perform model evaluations, including adversarial testing (red-teaming), assess foreseeable systemic risks, and document the results. The risks contemplated include: misuse for cyberattacks, weapons design, large-scale disinformation, and risks to fundamental rights from the model's behavior at scale.

Incident reporting. Serious incidents involving systemic risk GPAI models must be reported to the European AI Office and relevant national authorities. "Serious incident" is defined broadly — anything that could cause harm to health, safety, fundamental rights, or critical infrastructure.

Cybersecurity protection. Providers must maintain cybersecurity protections against unauthorized access, modification, or use of the model. This explicitly contemplates state-level adversaries — the security posture expected is closer to that of intelligence-relevant infrastructure than of typical consumer software.

Energy consumption reporting. The infrastructure used to train and run systemic risk GPAI models must be reported, including energy consumption and the source of that energy. This feeds into broader EU climate and environmental policy.

The labs hit by these obligations have spent the last year building the compliance infrastructure: dedicated risk assessment teams, formalized red-teaming programs, incident response processes that include EU notification, security postures aligned with the cybersecurity expectations. This is genuinely heavy work and one of the few cases in regulation where the obligated parties are well-resourced enough to actually do the work in full.

The Open-Source Carve-Out and Its Limits

The AI Act has a carve-out for genuinely open-source GPAI: models released under a license that allows free use, modification, and distribution, with weights, source code, and documentation publicly available, and where the model isn't monetized.

Open-source GPAI that meets the carve-out is exempt from some — but not all — provider obligations:

• The basic technical documentation and information-for-downstream obligations still apply.

• The copyright compliance and TDM opt-out obligations still apply.

• Some of the heavier provider obligations are relaxed.

Critically, open-source models that meet the systemic risk threshold are NOT exempt from systemic risk obligations. A 70B+ open-weight model trained with sufficient compute still gets the full systemic risk obligations, regardless of license. This catches some of the larger Llama and Mistral releases.

The interpretation of "monetized" is still evolving. A model released under an open license but with a commercial API offering from the same provider may or may not qualify for the carve-out depending on the legal analysis. Companies releasing models commercially are not in the carve-out even if the weights are available.

What This Means for Downstream Users

If you build on top of a GPAI model, the provider's compliance cascades to you in several specific ways.

Their documentation feeds yours. Your downstream high-risk classification, your technical documentation, your risk assessment all reference information that your GPAI vendor is obligated to provide. If they provide it well, your compliance is easier. If they provide it poorly, your compliance is weaker — and you may be relying on documents that don't actually meet the standard.

Their published training data summary affects you. When regulators ask about your data lineage, you can reference your vendor's published training data summary. If their summary is sparse or vague, you have less to point to.

Their intended-use documentation affects your classification. Your vendor's documentation about what the model is intended for, what uses are appropriate, what uses to avoid — this is what you reference when arguing that your specific deployment is appropriate. If your vendor's documentation says "this model should not be used for autonomous safety-critical decisions," and you're using it for autonomous safety-critical decisions, you have a problem.

Their incident reporting practice affects yours. If you experience a downstream incident that may have been caused by model behavior, your vendor's incident handling matters. A vendor with mature processes investigates, communicates clearly, and helps you understand the root cause. A vendor without these processes leaves you reconstructing the incident on your own.

Their security posture affects yours. If your vendor's model gets compromised or has a security incident, the cascading effects on your product can be severe. Your vendor's cybersecurity obligations (under the systemic risk rules) provide some assurance — but only for vendors actually subject to those rules.

How to Evaluate a GPAI Vendor

The procurement questions for foundation model vendors should include GPAI compliance specifically. The conversation looks different from typical software vendor evaluation.

Documentation completeness. Have they published the technical documentation that GPAI obligations require? Is the intended-use documentation specific enough to be useful for your classification? Are the limitations clearly described?

Training data transparency. Have they published the training data summary? Does it meet the European AI Office's standards (which are still evolving)? Is it specific enough that you can defend downstream data lineage claims?

Systemic risk posture (where applicable). For the top-tier models, has the vendor done evaluations? Are they participating in industry red-teaming? Do they have an incident reporting process? Do they have a cybersecurity posture appropriate to the systemic risk designation?

Downstream support. What information does the vendor give you specifically? Is there an API for downstream compliance information? Is there a contractual commitment to notify you of material changes?

Change management. Models change. New versions ship. Behavior shifts. How does the vendor communicate these changes? Are they early enough that you can update your compliance posture before the change takes effect? Or do you find out after the fact?

A vendor that can answer all these clearly is a vendor whose compliance you can rely on for your downstream compliance. A vendor that hedges on any of them is a vendor you should be wary of integrating into high-risk applications.

The Quiet Reshaping of the Foundation Model Market

GPAI obligations have been quietly reshaping which models actually compete in the EU. Some specific dynamics that have played out over the last nine months:

Tier-one model providers (OpenAI, Anthropic, Google, Meta for Llama, Mistral) have built dedicated GPAI compliance teams. The work is real, expensive, and ongoing. The labs that took compliance seriously from the start have a significant operational advantage now.

Some smaller model providers have effectively withdrawn from EU markets rather than build full GPAI compliance for models that don't have enough EU customers to justify the work. The first wave of regulatory market segmentation has happened quietly.

Open-weight models have become more important in EU enterprise deployments specifically because the compliance posture is more verifiable — you can audit what you can read. The trade-off in raw capability is acceptable for many use cases when the compliance benefit is real.

Foundation model contracts have changed shape. AI-specific addenda are now standard. DPA-style information-flow commitments are common. Notification obligations for model changes are negotiable. This is a sign of a maturing market.

What's Coming

The GPAI rules are not static. Several developments are worth watching:

The training data summary template, still being finalized by the European AI Office, will set the bar for how detailed these disclosures need to be. Early drafts have been more demanding than the labs initially expected.

The 10^25 FLOPs threshold for systemic risk is going to be revisited. The number was set when 10^25 was the frontier; it's now mid-range. Expect the threshold to be adjusted upward over time as compute scales — or for new sub-tiers to be created.

Enforcement is starting. The European AI Office has been opening technical dialogues with major GPAI providers throughout 2026. The first formal enforcement actions are expected in late 2026 once the August transition completes.

Sector-specific guidance is being developed. The general GPAI rules apply uniformly, but the interpretation of what counts as "appropriate" varies by sector. Healthcare, financial services, and law enforcement will see sector-specific guidance over the next year.

The Takeaway

GPAI is the layer of the AI regulation that gets the least public attention and affects everyone integrating foundation models. The obligations on your vendor cascade to you. Their compliance is what you build your compliance on top of.

If you're building products on foundation models, your procurement evaluation needs to include GPAI compliance specifically. Demand the documentation. Demand the change notifications. Demand the contractual commitments. Vendors that can't deliver on GPAI compliance are vendors that weaken your downstream compliance posture.

The market is sorting itself out. The labs that took GPAI obligations seriously from the start are now the safer integration partners. The labs that hedged are starting to look risky.

Pay attention to this layer. It is more important than the marketing makes it sound.

Frequently Asked Questions

What is GPAI under the EU AI Act?

GPAI stands for General-Purpose AI — AI models that can perform a wide range of tasks across many domains and be integrated into many downstream systems. Foundation models like GPT-5.5, Claude 4.6, Gemini 3.1, Llama, Mistral, and similar models are GPAI. The EU AI Act has a specific set of obligations for GPAI providers that activated in August 2025, separate from the obligations on high-risk system providers.

What does a GPAI provider have to do?

Four core obligations. First, produce and maintain technical documentation about the model. Second, share information with downstream providers using the model. Third, comply with EU copyright law in training data, including publishing a sufficiently detailed summary of training content. Fourth, implement a policy to respect text-and-data-mining opt-outs. Models classified as having 'systemic risk' (very large compute thresholds) have additional obligations around evaluation, risk assessment, incident reporting, and cybersecurity.

What is 'systemic risk' GPAI?

GPAI models that exceed a compute threshold (currently 10^25 floating-point operations during training, though the Commission can adjust this) are designated as having systemic risk. These models — GPT-5.5, Claude Opus 4.6, Gemini 3.1 Ultra, and a small number of others — have additional obligations: systematic evaluation of model risks, adversarial testing, incident reporting to the European AI Office, cybersecurity protection against state-level actors, and detailed risk assessments.

How does GPAI compliance affect me if I just use a foundation model?

Significantly. The information your GPAI vendor is required to provide to downstream users is what you use to satisfy your own compliance obligations. Their technical documentation feeds yours. Their published training data summary affects your data lineage analysis. Their intended-use documentation affects your high-risk classification. If your vendor's GPAI compliance is weak, your downstream compliance is weaker. Demand strong documentation from vendors.

Are open-source models exempt from GPAI obligations?

Partially. The EU AI Act has carve-outs for open-source GPAI that genuinely is open (free, including weights, source code, training data information, and license permitting use, modification, and distribution). Open-source GPAI is exempt from some — but not all — provider obligations. Open-source models that meet the systemic risk threshold are still subject to systemic risk obligations regardless of license. The 'open-source' exemption is narrower than companies often assume.