EU AI Act GPAI Obligations: The 57-Day Sprint for SaaS Teams Using Foundation Models

Post #4 in the sota.io EU AI Act Final Countdown Series

If you build SaaS on top of foundation model APIs — OpenAI, Anthropic, Google Gemini, Mistral, or any GPAI model — August 2, 2026 creates a two-level compliance situation. You are simultaneously a downstream deployer of a GPAI model and potentially a provider of a GPAI-powered AI system to your own customers. Both roles carry distinct obligations under the EU AI Act (Regulation 2024/1689), and many SaaS teams do not realise they exist in both positions at once.

This post covers GPAI obligations specifically. Post #1 covered the overall deadline picture. Post #2 covered Art.50 transparency. Post #3 covered high-risk classification. This post explains the GPAI layer: what foundation model providers must give you, what you owe your customers, and how to close both gaps before the deadline.

What Is a GPAI Model Under the EU AI Act?

Article 3(63) of the EU AI Act defines a general-purpose AI model as an AI model trained with large amounts of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks.

In practice, this definition covers every major foundation model that SaaS teams currently access via API: GPT-4 and its successors, Claude 3 and 4, Gemini, Llama 3, Mistral Large, and comparable systems. The key characteristics are training scale and task generality — not whether the model is open or closed, hosted or self-hosted.

The EU AI Act creates two sub-categories:

All GPAI models (Art.53): General obligations apply to all providers of GPAI models placed on the EU market, regardless of training scale. These include technical documentation, cooperation with the AI Office, and copyright compliance measures.

GPAI models with systemic risk (Art.55): An additional layer of obligations applies to models whose training required more than 10^25 floating-point operations — the systemic risk threshold set in Title V of the EU AI Act. As of mid-2026, this threshold captures GPT-4, Claude 3 Opus and later, Gemini Ultra, and equivalent frontier models. Providers of these models face adversarial testing requirements, incident reporting, and cybersecurity obligations.

The Chain of Obligation: Who Owes What to Whom

The GPAI section of the EU AI Act creates a vertical obligation chain:

Foundation Model Provider (e.g. OpenAI, Anthropic)
    ↓ must provide: technical documentation, copyright summaries, systemic risk measures
SaaS Developer (you)
    ↓ must provide: transparency disclosures, downstream documentation, user rights
End Users

As a SaaS developer, you sit in the middle. You receive obligations from the GPAI model provider that you need to verify are being fulfilled. You create obligations toward your users that you need to implement yourself. Neither set of obligations is automatically satisfied by the other.

What GPAI Model Providers Must Give You (Art.53)

Article 53 of the EU AI Act establishes what every provider of a GPAI model must make available to downstream deployers like you. Understanding these requirements matters for two reasons: first, you need to verify your API provider is compliant; second, in the event of an enforcement inquiry, regulators may ask you to demonstrate that your foundation model was lawfully placed on the EU market.

Technical documentation: GPAI model providers must maintain and make available technical documentation covering the model's training approach, data sources, capabilities, limitations, and known failure modes. This documentation should be available to you as a deployer — in practice, this means model cards, system cards, and usage documentation. Evaluate whether your current provider's documentation meets this standard.

Training data copyright compliance: Providers must implement policies to comply with EU copyright law, including Directive 2019/790 on copyright in the digital single market. They must also make available sufficiently detailed summaries of the training data used, to enable rightsholders to exercise their rights. If you have received no information about training data provenance from your API provider, this is a gap to flag.

Cooperation with the AI Office: GPAI model providers must cooperate with the European AI Office, provide access to the model for evaluation purposes upon request, and designate an authorised representative in the EU if they are not established there. This is a provider obligation, not yours — but verifying it is part of your due diligence.

Systemic Risk Models: What Art.55 Means for Your API Contracts

If you integrate a GPAI model that exceeds the systemic risk threshold (10^25 training FLOPs, as defined in the GPAI chapter of the EU AI Act), the provider faces additional obligations under Art.55. These directly affect the API relationships you depend on.

Adversarial testing: Systemic risk model providers must conduct adversarial testing (red-teaming) of the model before and after significant updates, and report serious incidents to the AI Office within 24 hours of becoming aware. This obligation creates a dependency: if your SaaS relies on a systemic risk model, your own incident response plan should account for the possibility that your API provider reports a serious incident that affects your product.

Cybersecurity measures: Systemic risk model providers must implement appropriate cybersecurity protections for the model and its infrastructure. You cannot substitute your own cybersecurity for the provider's — but you should verify what cybersecurity documentation your provider publishes.

Practical implication for API contracts: Review your API terms of service with any systemic risk model provider. Look for:

• Incident notification clauses — will they tell you if there is a serious incident?
• EU-specific terms that acknowledge the Art.55 obligations
• Designated EU representative information (required for non-EU providers)

If your current API agreement does not address any of these points, raise them with your provider's enterprise or legal team. The AI Office has indicated it will scrutinise provider compliance with Art.53 and Art.55 from August 2026 onward.

Your Obligations as a GPAI Deployer: Art.50 Revisited

Post #2 in this series covered Art.50 transparency in detail. GPAI integration adds one specific layer that deserves emphasis here.

Article 50(2) of the EU AI Act creates an obligation to label AI-generated content — text, images, audio, video — in a machine-readable format. This obligation applies to providers of systems that generate synthetic content, which means you as the SaaS developer are responsible for implementing it, not the foundation model provider.

This matters because many teams assume that labelling AI content is the model provider's problem. It is not. If your SaaS generates text, images, or audio using a GPAI API and delivers that content to users, you must:

1. Ensure the content is marked as AI-generated in a machine-readable format (C2PA or equivalent)
2. Ensure users are informed that they are interacting with an AI when using chatbot or dialogue interfaces
3. Retain records of the disclosure mechanisms for potential regulatory inspection

The model provider's API may or may not include watermarking or provenance metadata. Regardless, you are responsible for the disclosure at the point of delivery to your users.

If You Are Both a Deployer and a Provider

Many SaaS teams occupy a more complex position: they consume a foundation model API and build a product that is itself a GPAI-powered system offered to other businesses or developers. If your product exposes AI generation capabilities to customers who then build on top of them, you may be classified as a GPAI model provider under the AI Act — even if you are not training a model.

The key distinction under the EU AI Act is whether you substantially modify the GPAI model. Fine-tuning, system-prompt engineering, and RAG architectures that preserve the model's general-purpose capabilities generally do not constitute substantial modification. If you have added domain-specific training, built a specialised model from a base, or otherwise created a distinct model capability, the position is more complex.

Practical test: If customers of your SaaS can use it to generate content in arbitrary domains — writing, coding, analysis, summarisation — without significant task-specific constraints from your product's design, you may be treated as a GPAI model provider for those capabilities. Seek legal review if this applies to your architecture.

The GPAI Compliance Sprint: 8-Week Action Plan

With 57 days to August 2, the GPAI obligations divide into three priority bands:

Weeks 1–2: Provider Due Diligence

Action 1 — Audit your API providers. For each foundation model API you use, collect:

• Model card and system card documentation
• Any published EU AI Act compliance statement or SOC 2 equivalent
• Confirmation of EU representative designation (for non-EU providers)
• Any training data provenance summaries

Action 2 — Check for systemic risk classification. If you use GPT-4+, Claude 3 Opus+, Gemini Ultra, or comparable frontier models, confirm whether the provider has acknowledged systemic risk status and what Art.55 measures they have implemented.

Action 3 — Review API terms. Flag any contract gaps around incident notification, EU data processing, and regulatory cooperation obligations.

Weeks 3–4: Content Labelling Implementation

Action 4 — Implement AI content disclosure. For every endpoint in your product that returns AI-generated text, images, or audio to users, add a disclosure mechanism. Options include:

• C2PA provenance metadata for images and video
• X-AI-Generated: true response headers for API consumers
• In-UI disclosure banners for chatbot interfaces
• Metadata fields in API response bodies for downstream developers

Action 5 — Chatbot disclosure audit. If your product includes any conversational AI interface, ensure the system prompt includes an instruction to self-identify as AI when sincerely asked. Log that the instruction exists and when it was added.

Weeks 5–8: Documentation and Audit Readiness

Action 6 — Create a GPAI dependency register. Document each foundation model API dependency: provider, model version, intended use within your product, and compliance documentation held. This register is the first document a regulator will request.

Action 7 — Map your own provider status. Determine whether your product qualifies as a GPAI provider for your customers. If yes, identify which Art.53 obligations apply and create a documentation plan.

Action 8 — Incident response integration. Update your incident response plan to include GPAI-specific scenarios: model provider outage, model provider serious incident report (which may affect your product), and AI-generated content causing harm to a user.

The Enforcement Reality Post-August 2

National competent authorities (NCAs) across the EU will begin accepting complaints and conducting investigations from August 2, 2026. The AI Office, which has oversight of GPAI providers directly, has signalled it will focus initial enforcement on:

• GPAI model providers that have not published required technical documentation
• Systems generating content without appropriate disclosure
• Providers of systemic risk models that cannot demonstrate adversarial testing was conducted

As a downstream deployer, your enforcement exposure is lower than the foundation model provider's — but it is not zero. If an NCA investigates a complaint about AI-generated content in your product, your ability to demonstrate that you implemented Art.50 disclosure and conducted provider due diligence will determine whether the investigation extends beyond the initial review.

What sota.io Covers in the Final Post

Post #5 in this series will provide the complete compliance checklist — a structured audit template covering all August 2, 2026 obligations across Art.50, Annex III high-risk, and GPAI deployer requirements. The checklist is designed to be used as both a self-assessment tool and the basis for documentation you would present to an NCA if asked.

August 2, 2026 is 57 days away. The GPAI obligations are the most frequently overlooked track of the three — most SaaS teams focus on high-risk classification and miss the foundation model compliance layer entirely. The provider due diligence steps (Weeks 1–2 above) can be completed in a single sprint with no engineering work. Start there.