EU AI Act GPAI Provider vs Deployer: Who Bears the Compliance Burden? A 2026 Developer Guide

Post #1369 in the sota.io EU Cyber Compliance Series

The EU AI Act creates two distinct legal categories for anyone touching General-Purpose AI models: providers and deployers. Most SaaS developers building products on top of foundation model APIs are deployers. A minority — those who fine-tune, redistribute, or commercialise base models under their own brand — cross into provider territory. The obligations, penalties, and compliance timelines differ fundamentally between the two.

Getting this classification wrong costs money. A deployer who treats themselves as a pass-through with no obligations will likely face enforcement action for failing to meet Art. 50 transparency requirements. A provider who assumes their API vendor's compliance shields them entirely will miss critical model card and capability documentation requirements under Art. 53. This guide maps the boundary precisely.

Key deadline: The EU AI Act's GPAI provisions apply from 2 August 2026. Article 50 transparency obligations (chatbot disclosure, AI-generated content labelling) hit all deployers. Article 53 model documentation and capability reporting hits all GPAI model providers. You have months, not years.

The Core Distinction: What the Regulation Actually Says

The EU AI Act defines these roles across several articles. The definitions matter because they determine your entire compliance scope.

GPAI Model (Art. 3 No. 63)

A general-purpose AI model is an AI model trained on broad data using self-supervised or unsupervised learning at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks, and that can be integrated into a variety of downstream systems or applications.

In practice: GPT-4o, Claude 3.5, Gemini Pro, Llama 3, Mistral Large, and comparable foundation models are GPAI models. A narrow classifier trained for a single task (fraud detection, churn prediction) is not.

GPAI System (Art. 3 No. 66)

A general-purpose AI system is an AI system based on a GPAI model, capable of serving multiple purposes — both for direct use as well as for integration in other AI systems.

A chatbot interface powered by GPT-4o is a GPAI system. A content moderation pipeline using Claude is a GPAI system. Your entire product, if it exposes GPAI capabilities to end users, is a GPAI system.

Provider (Art. 3 No. 3)

A provider is a natural or legal person that develops an AI system or a GPAI model, or that has an AI system or GPAI model developed, and places it on the market or puts it into service under their own name or trademark, whether for payment or free of charge.

Critical nuance: The provider definition applies to whoever places the GPAI on the market. Anthropic places Claude on the market. OpenAI places GPT-4 on the market. If you access these via API, you are almost certainly not a GPAI model provider — you are a deployer.

However, if you:

• Fine-tune an open-source base model and redistribute it commercially
• Take Llama 3 or Mistral, fine-tune for a vertical, and sell API access
• Build a model under your own branding and release it as a product

...then you are a GPAI model provider and bear the full set of Art. 53 obligations.

Deployer (Art. 3 No. 4)

A deployer is a natural or legal person that uses an AI system under their own authority for professional purposes, except where the AI system is used in the course of a personal non-professional activity.

SaaS developers are almost always deployers. If you call the Claude API, the OpenAI API, or the Gemini API and expose the results to your users, you are a deployer. Your obligation set derives primarily from Art. 50 (transparency), Art. 26 (obligations on deployers), and the specific prohibitions in Art. 5.

The Obligation Matrix: Provider vs. Deployer Side by Side

What SaaS Developers Using GPAI APIs Must Actually Do

If you call the Claude, GPT-4, or Gemini API and expose the output to users, here is your specific obligation checklist for the August 2026 deadline.

1. Art. 50(a) — Chatbot Disclosure (High Priority)

Who it applies to: Any deployer operating a "chatbot" — defined as an AI system intended to engage in conversation with natural persons.

What you must do:

• Inform users, in a clear and timely manner, that they are interacting with an AI system
• The disclosure must be provided before or at the start of the interaction
• Exception: the AI system is obvious from context (e.g., a clearly branded AI writing assistant where no user could reasonably mistake it for a human)

Implementation pattern:

✅ Compliant: "Chat with our AI assistant — powered by AI"
✅ Compliant: System message disclosing AI nature + persistent UI indicator
✅ Compliant: Onboarding screen explaining AI role before first chat session
❌ Non-compliant: Chat interface with no disclosure, ambiguous agent persona
❌ Non-compliant: "Talk to Sarah" (human name, no AI disclosure) in a support context

Technical implementation:

// Minimum: clear UI label at all times
const ChatHeader = () => (
  <div className="chat-header">
    <AIBadge /> {/* Visible "AI" indicator in header */}
    <h2>AI Support Assistant</h2>
    <span className="disclosure">You are chatting with an AI system</span>
  </div>
)

// Better: Programmatic disclosure in first message
const systemPrompt = `You are a support assistant for [Company]. 
At the start of every new conversation, your first message must include 
a clear disclosure that you are an AI system. Example: 
"Hi! I'm [Company]'s AI assistant — I'm here to help with your questions."`

2. Art. 50(b) — AI-Generated Content Labelling

Who it applies to: Deployers whose systems produce synthetic images, video, audio, or text intended to resemble real persons or events.

What you must do:

• Ensure AI-generated content is marked in a machine-readable format
• The marking must persist when technically feasible during distribution
• Applies specifically to: deepfake images/video, synthetic voice cloning, AI-generated news or informational content

Scope clarification: This does NOT apply to routine AI-generated text (blog drafts, summaries, code generation) in the general case. It targets synthetic media designed to portray real people or real-world events in ways that could mislead.

What this means for common SaaS features:

Technical approach: The EU Commission is developing standards for machine-readable marking. For now, best practice is C2PA (Coalition for Content Provenance and Authenticity) metadata embedded in generated media files, plus visible UI disclosure.

3. Art. 5 — Prohibited Practice Check

Who it applies to: All deployers, regardless of what the model provider does.

Even if your model provider's terms of service prohibit prohibited-use cases, you bear independent legal liability if your deployment implements them. You cannot contract away Art. 5 obligations.

Non-exhaustive prohibited uses deployers must avoid:

❌ Subliminal manipulation: AI systems that manipulate users' decisions 
   through techniques that exploit psychological vulnerabilities, especially
   to cause harm or damage economic interests

❌ Social scoring: Using AI to evaluate persons based on social behaviour 
   and making decisions that affect them in unrelated domains or 
   disproportionately

❌ Real-time biometric identification in public spaces (with narrow 
   law enforcement exceptions)

❌ Emotion recognition in workplace or educational settings
   (some exceptions for safety purposes)

❌ Predictive policing based on profiling or personality traits

❌ Facial recognition from scraping social media or CCTV footage to 
   build databases without individual consent

For typical SaaS developers: If your product does not touch biometrics, public surveillance, criminal justice, or social scoring, Art. 5 is primarily a checklist item. Review it once, document that review, and revisit if your product scope changes.

4. High-Risk AI System Deployers — Art. 26

Who it applies to: Deployers of AI systems listed in Annex III of the EU AI Act.

Annex III high-risk categories include:

• Biometric identification and categorisation
• Critical infrastructure management
• Education and training (evaluating learners, determining access)
• Employment and workers management (CV screening, promotion decisions)
• Essential private services and public benefits
• Law enforcement
• Migration and asylum management
• Administration of justice and democratic processes

Most B2B/B2C SaaS falls outside Annex III unless you are explicitly in HR tech, EdTech assessing learners, fintech assessing creditworthiness, or similar regulated verticals.

If you are in an Annex III vertical:

High-Risk Deployer Obligations (Art. 26):
1. Technical and organisational measures appropriate to the risk
2. Human oversight ensuring meaningful intervention capability
3. Input data monitoring for relevance and representativeness
4. Logging of operation to enable ex post review
5. Information to affected persons about their rights (Art. 26(6))
6. Registration in EU database if required for your category
7. Fundamental rights impact assessment before deployment

Where Liability Transfers: The Downstream Provider Rule (Art. 25)

Art. 25 introduces a critical concept: downstream providers. A downstream provider is a provider who integrates a GPAI model into their own AI system and places that new system on the market.

This is the grey zone between pure deployer and full provider.

The Spectrum

PURE DEPLOYER                                          GPAI PROVIDER
     │                                                       │
API consumer ──── Custom wrapper ──── Fine-tune ──── Base model creator
(Art. 50 only)   (Art. 50 + maybe    (Art. 53 if     (Full Art. 53)
                  some Art. 53)       redistributed)

Art. 25 mechanics:

1. The GPAI model provider must make technical documentation available to downstream providers upon request
2. Downstream providers can rely on the original provider's documentation for the portions they have not modified
3. If a downstream provider substantially modifies the model, they become the provider of the modified system

Practical examples:

The August 2026 Compliance Checklist by Role

For Deployers (using GPAI APIs like Claude, GPT-4, Gemini)

Must complete by 2 August 2026:

• Audit all chatbot interfaces — identify every user-facing AI conversation feature
• Implement Art. 50(a) disclosure — visible, persistent indicator that users are talking to AI
• Review any synthetic media generation — if you generate images/video/audio, assess Art. 50(b) marking requirements
• Art. 5 prohibited practice review — document that none of your AI features implement prohibited uses
• Update terms of service and privacy policy — disclose AI use, AI system role, user rights
• Annex III check — if in HR, EdTech, lending, or another regulated vertical, assess Art. 26 obligations
• Maintain interaction logs — keep records of AI system interactions sufficient to investigate incidents (Art. 26(5) for high-risk; best practice for all)

Recommended (not strictly required Aug 2026 but advisable):

• Review your model provider's AI Act compliance documentation (Claude's, OpenAI's, Google's)
• Internal AI governance policy — who can ship AI features, what review is needed
• Model change management process — what happens to compliance when model version changes

For GPAI Model Providers (distributing foundation models)

Must complete by 2 August 2026:

• Technical model card — training data sources, compute used, intended purpose, known limitations
• Copyright compliance policy — policy for respecting Art. 4 opt-out instructions from rights-holders
• Copyright transparency summary — publicly available summary of training data used
• Code of Practice adherence — compliance with EU GPAI Code of Practice (formal adoption by Aug 2025, enforcement Aug 2026)
• Downstream provider information package — make technical documentation available to customers who will integrate your model
• Systemic risk assessment — if model trained with >10^25 FLOPs, additional Art. 55 obligations apply
• EU authorised representative — if provider is established outside EU but places model on EU market

The EU GPAI Code of Practice: What It Is and Why It Matters

The EU GPAI Code of Practice is a voluntary but practically mandatory framework developed under the auspices of the EU AI Office. All major GPAI model providers — including Anthropic, Google DeepMind, Meta, Mistral, and OpenAI — are participating.

Why "voluntary but mandatory": The Code of Practice is explicitly referenced in the EU AI Act as a means of demonstrating compliance with Art. 53. Providers who do not participate and cannot demonstrate an equivalent compliance basis face a higher burden of proof in enforcement.

What the Code covers (final draft):

1. Model documentation — capability evaluation, benchmark results, known limitations
2. Copyright compliance — evidence of rights management, opt-out mechanisms
3. Safety testing — red-teaming, adversarial robustness, systemic risk thresholds
4. Transparency commitments — incident disclosure, model change notifications
5. Downstream safeguards — usage policies, monitoring support for deployers

For deployers: The Code of Practice is primarily a model provider concern. However, as a deployer you should verify that your GPAI API providers are Code of Practice signatories. This provides evidence that your upstream model meets EU AI Act baseline requirements — which can matter in enforcement or due diligence contexts.

Common Misconceptions Cleared Up

"My model provider (OpenAI/Anthropic) handles EU AI Act compliance for me."

False. Your provider handles their obligations (Art. 53, Code of Practice). Your obligations under Art. 50 (disclosure, transparency) are entirely your responsibility. The provider cannot disclose on your behalf that users of your product are talking to AI.

"If I access the API, I'm just a customer — not an AI system provider."

True for GPAI model provider obligations. False for deployer obligations. You are always a deployer when you use AI in your product, and deployers have real obligations.

"Art. 50 only applies to companies that built the AI."

False. Art. 50 explicitly places obligations on deployers — specifically deployers who operate chatbots (50(a)) and deployers who generate synthetic media (50(b)).

"If I add a disclaimer in my terms of service, I'm covered."

No. Art. 50 requires disclosure at the point of interaction — before or during the AI interaction itself. A buried terms of service clause is not sufficient.

"EU AI Act doesn't apply to me — I'm not in the EU."

If your users are in the EU, the regulation applies based on where the AI system is used, not where your company is incorporated. This follows the same territorial logic as GDPR.

Enforcement: AI Office and National Authorities

The EU AI Act enforcement architecture is now operational:

• EU AI Office — responsible for GPAI model providers, especially those meeting systemic risk thresholds. Has direct investigation and sanctions powers.
• National competent authorities (NCAs) — responsible for all other AI systems deployed in their jurisdiction, including most SaaS deployers.
• Market surveillance authorities — coordinate with NCAs on product-level AI compliance.

Fines for deployers:

• Art. 50 violations (transparency failures): up to €15 million or 3% of global annual turnover, whichever is higher
• Art. 5 violations (prohibited practices): up to €35 million or 7% of global annual turnover

Fines for GPAI model providers:

• Art. 53 violations: up to €15 million or 3% global turnover
• Systemic risk violations: up to €35 million or 7%

Enforcement timeline: Market surveillance and enforcement mechanisms are active from August 2026. Early enforcement is expected to focus on egregious violations — undisclosed chatbots posing as humans, prohibited practice implementations, high-risk AI deployed without oversight mechanisms.

Putting It All Together: Your Role and Your Obligations

┌─────────────────────────────────────────────────────────────────┐
│                    DETERMINE YOUR ROLE                          │
│                                                                 │
│  Do you build, train, or redistribute a foundation model?      │
│  ├── YES → You are a GPAI Model Provider                       │
│  │         Obligations: Art. 53 + Code of Practice + Art. 50   │
│  │                                                              │
│  └── NO → You are a Deployer                                    │
│            Obligations: Art. 50 + Art. 5 + maybe Art. 26       │
│                                                                 │
│  DEPLOYER CHECKLIST:                                            │
│  □ Chatbot disclosure implemented? (Art. 50(a))                 │
│  □ Synthetic media marked? (Art. 50(b) if applicable)          │
│  □ Prohibited practices reviewed? (Art. 5)                      │
│  □ In Annex III vertical? → Art. 26 full check                  │
│  □ Documentation maintained? (logs, policies, vendor docs)      │
└─────────────────────────────────────────────────────────────────┘

What's Next in This Series

This is Post #1 of our 5-part EU AI Act GPAI Developer Series, timed to the August 2026 enforcement deadline:

• Post #1 (this post): Provider vs Deployer — who owes what
• Post #2: Building compliant chatbots — Art. 50(a) implementation patterns for SaaS
• Post #3: Integrating GPAI APIs (Claude, GPT-4, Gemini) while staying EU AI Act compliant
• Post #4: EU AI Act Code of Practice for GPAI — what SaaS developers need to know
• Post #5: GPAI Compliance Finale — the complete August 2026 developer checklist

If you are deploying GPAI features on EU-sovereign infrastructure and want a compliant, CLOUD-Act-free platform to host them, sota.io is built for exactly this: managed PaaS on Hetzner Germany, no US parent, no surveillance economy. Start in minutes.

The EU AI Act applies from 2 August 2026 for GPAI provisions. This post reflects the text as consolidated after the 2025 Omnibus amendments. For authoritative legal advice, consult a qualified EU data protection or AI regulation attorney.