sota.io
2026-05-04·13 min read·

EU AI Act GPAI Enforcement 2026: Are You a Model Provider or a Deployer? The SaaS Developer Guide

Post #829 in the sota.io EU Compliance Series

August 2, 2026. That is when the EU AI Act's obligations for General Purpose AI (GPAI) models become enforceable — 91 days from today. If your SaaS product calls the OpenAI API, uses Claude via Anthropic's SDK, queries Gemini, or integrates any other foundation model, the GPAI chapter applies to you.

The question most developers are not asking is the most important one: are you a GPAI model provider or a GPAI deployer?

The answer is not academic. Providers and deployers have fundamentally different obligations, different compliance timelines, and different fine ceilings. An EU-based SaaS startup that mistakes itself for a provider when it is actually a deployer will build an expensive compliance programme around the wrong requirements. One that mistakes itself for a deployer when it has actually become a provider faces enforcement exposure it did not anticipate.

This guide cuts through the legal text to give SaaS developers a practical classification test, a clear list of what deployers actually need to do before August 2, and the specific edge cases where API integrators accidentally cross the line into provider territory.

The Distinction the EU AI Act Actually Makes

The EU AI Act defines GPAI in Art.3(63): a model trained on large amounts of data at significant compute, designed for generality, and capable of competently performing a wide range of distinct tasks — including text, image, video, code generation and other modalities.

This definition covers the foundation models underlying every major API: GPT-4 and above (OpenAI), Claude 3+ (Anthropic), Gemini (Google), Llama 3+ (Meta, when used commercially), Mistral Large, and equivalent models.

GPAI model provider (Art.3(44)): A natural or legal person that develops a GPAI model and makes it available — for commercial purposes or otherwise. Making it available means publishing it, releasing weights, or exposing it via API to third parties outside your organisation.

Deployer (Art.3(4)): A natural or legal person that uses a high-risk AI system or a GPAI-based AI system under their own authority — but not as the provider. Using Claude's API to power your SaaS product's features makes you a deployer, not a provider.

The practical test has one question: Did you train or fine-tune the GPAI model, and do you make that model available to others?

If no: you are a deployer. If yes: you are a provider — even if you built on top of someone else's base model.

What SaaS Developers Almost Always Are: Deployers

If your architecture looks like this:

Your SaaS product → [Anthropic / OpenAI / Google API] → Claude / GPT / Gemini

You are a deployer. You did not train the model. You are not making the model available to third parties — you are making your application available to users, and that application happens to call an API internally.

This covers the vast majority of EU SaaS products that integrate AI in 2026:

In all these cases, you are a deployer. The provider is Anthropic, OpenAI, Google, or whoever operates the model.

This matters enormously for your compliance workload.

GPAI Provider Obligations: What You Do NOT Need to Do (If You Are a Deployer)

Providers face the heavy compliance burden: maintaining technical documentation (Art.53), publishing model cards with training data information, registering in the EU database, cooperating with national authorities, and — for GPAI models with systemic risk (Art.51) — undergoing model evaluations, adversarial testing, and incident reporting.

Providers must also participate in, or demonstrate alignment with, the Code of Practice for GPAI models (Art.56). The voluntary code is being developed by the AI Office and the first draft was published in November 2024. Signatory commitments include transparency on training data provenance, copyright compliance attestations, and safety evaluations. None of this applies to deployers.

The financial ceiling for provider violations reaches €15 million or 3% of total worldwide annual turnover, whichever is higher (Art.99(4)). For deployer violations, the ceiling applies to different obligations and is generally lower in practice — though deployers face Art.99(6) for certain transparency failures (€7.5M or 1.5% turnover).

GPAI Deployer Obligations: What You Actually Need to Do Before August 2, 2026

Deployer obligations under the GPAI chapter are narrower than provider obligations. Here is what you actually need:

1. Transparency to End Users Where AI Is Involved (Art.50)

Art.50 creates transparency obligations that apply to deployers of GPAI-based systems. The key requirements:

Art.50(1): If your system directly interacts with users via AI (chatbots, voice assistants, AI agents), you must inform natural persons that they are interacting with an AI system at the time of the first interaction — unless it is obvious from context.

Art.50(2): If your system generates synthetic audio, video, image, or text designed to resemble real people or events (deepfakes, synthetic voiceovers, image manipulation), you must label the output as AI-generated.

Art.50(3): If your system generates text published for the purpose of informing the public on matters of public interest (journalism, policy, public communications), that text must be machine-readable labelled as AI-generated. This catches AI-assisted content publishing tools.

Art.50(4) (for providers, but affects deployer disclosure choices): Providers must embed machine-readable metadata in AI-generated content. Deployers should use tools where this is already handled at the model level.

Practical implementation: A notice at the start of any chatbot session, a label on AI-generated document summaries, an audit trail in your system showing which outputs were AI-generated and which were human-authored.

2. Human Oversight Where It Matters (Art.26(5))

Art.26 applies to deployers of high-risk AI systems. For GPAI-based systems that fall within the high-risk categories of Annex III (HR AI systems in employment, credit scoring, critical infrastructure, education, law enforcement, etc.), deployers must:

If your GPAI integration does not fall in a high-risk category — most SaaS products do not — Art.26 obligations are lighter. A customer support chatbot powered by Claude is not high-risk AI under Annex III. An AI system making automated decisions about employee performance evaluations or credit eligibility is.

3. Log Retention (Art.26(6))

Deployers of high-risk AI systems must keep logs of operation automatically generated by the AI system. For non-high-risk GPAI deployments, there is no mandatory log retention period in the GPAI chapter — but GDPR's accountability principle (Art.5(2)) and Art.30 records of processing activities still apply to any personal data processed through the AI interaction.

4. Data Protection Impact Assessment for High-Risk Processing

If your GPAI integration processes personal data in a way that is likely to result in a high risk to individuals — for example, profiling, automated decision-making, or processing special category data — you need a DPIA under GDPR Art.35. This is a GDPR obligation, not an EU AI Act obligation, but GPAI enforcement context makes it relevant: the AI Office and national DPAs are increasingly coordinating.

The Edge Cases: When API Users Accidentally Become Providers

Several common development patterns push a deployer into provider territory. Knowing these patterns before August 2 matters.

Fine-Tuning and Re-Publishing

If you fine-tune a GPAI model on your own data and then expose that fine-tuned model to third parties — other users, other organisations, or via an API — you become a provider of a GPAI model.

This is the most common accidental provider scenario. A company fine-tunes Llama 3 on its customer support knowledge base and makes the resulting model available to partner companies. The fine-tuned model is a GPAI model. The company that fine-tuned it and made it available is the provider.

If you fine-tune for internal use only — only your application uses the fine-tuned model, no external party accesses the model weights or a model API — you remain a deployer.

Model-as-a-Service Offerings

If you build a product that exposes a foundation model (or fine-tuned version) as its primary offering — an inference API, a model endpoint service, an AI-as-a-service product — you are a provider. The fact that you are sitting on top of another provider's base model does not remove your provider status; you are providing a GPAI model to your downstream users.

Agents That Deploy Sub-Agents Using GPAI

Multi-agent architectures where your application spawns AI agents that interact with other AI systems are a grey area the AI Office is still clarifying. If your orchestrating system acts as a provider of a GPAI-based agent to end users, provider obligations apply to the orchestrating system. If your orchestrating system is an internal tool and the agents only act within your application's scope, you are likely a deployer at the orchestration layer.

Open-Weight Model Deployment

If you take an open-weight model (Llama 3, Mistral, Falcon), deploy it on your own infrastructure, and expose it to users or third parties via API, you are a provider. You did not train the base model, but you are making the GPAI model available. Providers of models that were initially released under open licences have modified obligations under Art.53(2) — documentation requirements are reduced — but provider status still attaches.

The Provider vs Deployer Decision Tree

Do you train or fine-tune the GPAI model?
└── No → Do you make a GPAI model available to external parties via API/weights?
    └── No → DEPLOYER
    └── Yes → PROVIDER (open-weight deployment, model API service)
└── Yes → Do you make the (fine-tuned) model available to external parties?
    └── No → DEPLOYER (internal fine-tuning only)
    └── Yes → PROVIDER (fine-tuned model distribution or API)

Most SaaS developers land at the first "No" branch: you call someone else's API, you do not expose the model to external parties. You are a deployer.

EU-Native AI Infrastructure: Compliance Documentation Built In

One advantage of using EU-based AI providers — beyond CLOUD Act protection and GDPR-compliant data residency — is that EU providers are themselves subject to the EU AI Act and are building compliance documentation into their model deployments.

Aleph Alpha (Luminous): German-headquartered, EU legal entity, inference in Germany. Publishes transparency documentation compatible with GPAI deployer requirements. No CLOUD Act exposure.

Mistral AI: French company, EU legal entity, inference in EU. Mistral Large and Mistral Small are available via EU-based API. Participates in the GPAI Code of Practice drafting process — compliance documentation is actively maintained.

BLOOM / BigScience: Open-weight multilingual model with EU research provenance (Inria, Hugging Face). Self-deployable on EU infrastructure. No third-party data jurisdiction issues.

NVIDIA NIM on EU Hosting: NIM microservices for inference can be deployed on EU-sovereign infrastructure (Hetzner, OVH, Scaleway dedicated GPU nodes). You run the inference, no model API call crosses a US-jurisdiction boundary.

If you call OpenAI, Anthropic, or Google APIs: your inference requests, prompts, and responses cross a US-jurisdiction legal entity. As a deployer this does not per se violate the EU AI Act (the Act is about AI safety, not data sovereignty), but combining it with GDPR Art.46 transfer obligations and CLOUD Act exposure creates a compliance stack that EU-native providers avoid by design.

Your August 2 Checklist as a Deployer

For most SaaS developers calling Claude, GPT, or Gemini APIs, the GPAI compliance workload for August 2 is manageable:

Now (May 2026):

By June 2026:

By July 2026:

By August 2, 2026:

The good news: if you are a pure deployer using GPAI APIs, the compliance work is documentation and disclosure — not model auditing, not Code of Practice participation, not systemic risk evaluation. The heavy lift is on the model providers, not on you.

What EU AI Act Enforcement Actually Looks Like for Deployers

National market surveillance authorities (MSAs) — in Germany, France, Spain, and Ireland — are being stood up now. Ireland matters most for US-entity cloud providers; Germany matters most for many SaaS companies given the volume of EU tech companies there.

The first enforcement actions are expected to target the most visible violations: consumer-facing AI products that interact with users with no disclosure, deepfake generators with no labelling, and AI systems in high-risk categories operating without oversight mechanisms. Pure internal GPAI integrations (AI that analyses internal data, not user-facing) face lower initial enforcement priority.

The risk for SaaS developers: product features shipped in 2025 or early 2026 that were not built with Art.50 transparency in mind. An AI assistant that has been live since 2025 with no "you are interacting with an AI" notice is a straightforward Art.50 violation. Adding the notice costs one sprint. The alternative is enforcement under Art.99(6).

The Bottom Line

GPAI enforcement is 91 days away. Most SaaS developers integrating foundation models are deployers — and deployer obligations are achievable before August 2 without a legal team or a six-month project.

The risk is misclassification: assuming you are a deployer when a fine-tuning workflow or model-API product has pushed you into provider territory. Check the decision tree. If you are uncertain, the AI Office's GPAI guidelines and the Code of Practice consultations are the authoritative source.

For EU-based SaaS products on EU infrastructure, the GPAI chapter is an achievable compliance milestone. Build the disclosures now. Document the classification. The clock runs to August 2.

sota.io helps EU-based developers deploy on infrastructure that is natively compliant with GDPR, the EU AI Act, and European data sovereignty requirements — without the CLOUD Act exposure of US-headquartered cloud providers. Explore sota.io →

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing