Integrating GPAI APIs in EU SaaS: Claude, GPT-4 & Gemini Compliance Guide 2026

Post #3 in the sota.io EU AI Act GPAI Developer Series

Most EU SaaS developers are building on top of GPAI models — Claude, GPT-4, Gemini — without a clear understanding of what the EU AI Act requires of them as deployers. The August 2026 deadline is close enough that "figure it out later" is no longer a viable strategy.

This guide walks through every compliance checkpoint a SaaS developer needs before shipping an EU product that calls a GPAI API. It is deliberately practical: the relevant articles, the decisions you must make, and the code-level patterns that satisfy them.

Your Role: Deployer, Not Provider

When you call the Anthropic, OpenAI, or Google GEMINI API to power a feature in your SaaS product, you are a deployer under the EU AI Act — not the GPAI model provider. Our previous post covered the provider/deployer distinction in detail.

The practical implication: Anthropic, OpenAI, and Google are responsible for their GPAI model obligations (training data transparency, technical documentation, copyright policy, systemic risk assessment for models above 10^25 FLOPs). You, as the SaaS developer integrating their APIs, are responsible for your application's compliance layer.

This means your obligations under the EU AI Act as a deployer are:

For most SaaS applications — a writing assistant, a support chatbot, a summarisation tool — you are not in a high-risk category. Your core obligations are Art.13 transparency, Art.50(a) disclosure (if conversational), and Art.5 prohibited practice avoidance.

Step 1: Classify Your Use Case

Before writing any compliance documentation, classify what you are actually building. The EU AI Act's risk tiers determine your obligations:

Prohibited (Art.5) — These are hard stops

Do not build these regardless of commercial interest:

• Social scoring systems that evaluate individuals based on social behaviour and affect their access to services
• Real-time biometric identification in public spaces for law enforcement purposes
• Subliminal manipulation techniques that exploit psychological weaknesses to influence behaviour against users' interests
• Emotion recognition in workplaces (with narrow exceptions for safety)

If you are using Claude/GPT-4/Gemini for content recommendations, personalisation, or engagement optimisation, review Art.5(1)(a) specifically — the line between "recommendation" and "manipulation" is defined by intent and user impact.

High-Risk (Annex III) — Significant additional obligations

High-risk AI systems require conformity assessment, technical documentation (Art.11), logging (Art.12), transparency (Art.13), human oversight (Art.14), accuracy/robustness/cybersecurity requirements (Art.15), and registration (Art.49) before deployment.

Annex III categories relevant to SaaS developers:

• Employment decisions: CV screening, interview assessment, performance evaluation, task allocation (if consequential)
• Credit/insurance scoring: If your GPAI integration influences financial product eligibility
• Education: Automated assessment determining educational access or outcomes
• Critical infrastructure: AI managing essential services (water, energy, transport, finance)
• Access to essential services: Social benefits determination, emergency dispatch prioritisation

For most B2B SaaS (project management, documentation, customer support tools), you are not in Annex III. For HR SaaS, fintech, or edtech, you likely are.

Limited Risk — Primary obligations

Most GPAI integrations fall here: chatbots, content generation, summarisation, translation, code assistance. Your obligations are:

• Art.50(a): Disclose when users interact with AI (if it could be mistaken for a human)
• Art.50(b): Label AI-generated content when technically feasible (deepfakes, synthetic media)
• Art.13: Provide meaningful transparency about your system's capabilities and limitations
• Art.5: Avoid prohibited practices

Step 2: Satisfy Art.50(a) — The Chatbot Disclosure Requirement

If your product includes any conversational AI feature — a support bot, an AI assistant, a chat interface powered by Claude/GPT-4/Gemini — Art.50(a) requires disclosure before or at first interaction.

We covered implementation patterns in depth in our Art.50(a) guide. The short version:

Minimum viable disclosure (inline, first message):

const systemPrompt = `You are a helpful assistant for ${productName}.

[REQUIRED DISCLOSURE: This is an AI assistant. You are interacting with an automated system, not a human agent. If you need to speak with a human representative, say "connect me to a human" at any time.]`;

UI-level disclosure:

// Chat widget header
<div className="ai-disclosure-banner">
  <BotIcon size={14} />
  <span>AI Assistant — automated responses</span>
</div>

Critical: The disclosure must be:

1. Before first interaction — not buried in Terms of Service
2. Clear — users must understand they are talking to AI
3. Persistent — not just a one-time dismissible toast that users forget

What counts as "interaction with an AI system that could be mistaken for a human"?

Art.50(a) specifically targets natural language interfaces. This includes:

• Chat widgets, support bots, onboarding assistants
• Voice interfaces (if applicable)
• Any feature where users write free-form text and receive conversational responses

It does not require disclosure for:

• Autocomplete suggestions (where the AI nature is obvious from UX context)
• Server-side AI processing that never presents as conversational
• Internal tooling where users are employees who understand the system

Step 3: Implement Human Oversight (Art.14)

Art.14 requires that deployers ensure humans can monitor, understand, override, and intervene in AI system operation. The practical implementation depends on your use case:

For support/service chatbots

// Human escalation pathway (mandatory for consequential outcomes)
async function handleUserMessage(
  message: string,
  sessionId: string
): Promise<ChatResponse> {
  const response = await callGPTAPI(message);
  
  // Log every interaction for audit trail
  await logInteraction({
    sessionId,
    userMessage: message,
    aiResponse: response.content,
    timestamp: new Date().toISOString(),
    modelUsed: 'gpt-4o',
    confidenceScore: response.usage?.completion_tokens
  });
  
  // Flag low-confidence or sensitive topics for human review
  if (isSensitiveTopic(message) || response.flaggedForReview) {
    await flagForHumanReview(sessionId, message, response);
    return {
      ...response,
      humanReviewPending: true,
      escalationOffered: true
    };
  }
  
  return response;
}

For automated decision systems (high-risk)

If you are in a high-risk category (employment, credit, etc.), Art.14 requires more than just an escalation button:

interface AIDecisionRecord {
  decisionId: string;
  userId: string;
  inputData: Record<string, unknown>;
  modelOutput: string;
  confidenceScore: number;
  decisionTimestamp: string;
  humanReviewRequired: boolean;
  humanReviewerId?: string;
  humanReviewOutcome?: 'approved' | 'overridden' | 'escalated';
  humanReviewTimestamp?: string;
  finalDecision: string;
}

// Every high-risk AI decision must be reviewable
async function makeHighRiskDecision(
  input: DecisionInput
): Promise<AIDecisionRecord> {
  const aiOutput = await callModel(input);
  
  const record: AIDecisionRecord = {
    decisionId: generateId(),
    userId: input.userId,
    inputData: input.data,
    modelOutput: aiOutput.content,
    confidenceScore: aiOutput.confidence,
    decisionTimestamp: new Date().toISOString(),
    humanReviewRequired: true, // Always true for high-risk
    finalDecision: 'pending_review'
  };
  
  await saveDecisionRecord(record);
  await notifyHumanReviewer(record);
  
  return record;
}

Step 4: Know What Each API Provider Has (And Has Not) Given You

Before you can represent your system's capabilities to users, you need to understand what documentation and obligations your GPAI provider has met. This matters because your Art.13 transparency obligations reference the underlying model's characteristics.

Anthropic (Claude API)

What Anthropic provides:

• Usage Policy and Acceptable Use Policy — published, publicly accessible
• Model cards for Claude models (limited technical detail, but present)
• Constitutional AI documentation (research publications)
• GPAI transparency commitments aligned with EU AI Code of Practice v1

What this means for your compliance:

• Claude is Anthropic's model — Anthropic is the GPAI provider responsible for Art.53 documentation
• You can reference Anthropic's published documentation in your own transparency notices
• Claude's refusal behaviours and content policy are documented — you can inform users of limitations

Deployer obligations when using Claude:

• You must still disclose to users that an AI system is present (Art.50(a))
• You are responsible for your prompt engineering — if your system prompt manipulates users, that is your Art.5 violation, not Anthropic's
• You cannot rely on "Anthropic handles compliance" — your deployment layer has its own obligations

// Example: Embedding model transparency in your system
const claudeConfig = {
  model: 'claude-opus-4-7',
  system: `You are ${productName}'s AI assistant...
  
  LIMITATIONS YOU MUST DISCLOSE TO USERS IF ASKED:
  - You do not have real-time internet access
  - Your knowledge has a training cutoff
  - You may make mistakes — for important decisions, users should verify with authoritative sources
  - You are an AI system, not a human`,
  max_tokens: 4096
};

OpenAI (GPT-4 / GPT-4o API)

What OpenAI provides:

• Usage Policies and Terms of Service — published
• Model specifications (GPT-4 Technical Report) — partial technical documentation
• System Card for GPT-4 — covers capabilities, limitations, safety evaluations
• OpenAI's EU AI Act compliance commitment — includes GPAI provider obligations acknowledgment

What this means for your compliance:

• OpenAI's GPT-4 models above 10^25 FLOPs training compute fall under GPAI systemic risk provisions
• OpenAI is responsible for adversarial testing documentation, cybersecurity incident reporting to the AI Office, and technical documentation for the Commission
• You are still the deployer — your application's behaviour is your responsibility

Key deployer watch-out with OpenAI:

• OpenAI's US data residency default may require additional GDPR measures if EU user data enters the API. Use OpenAI's EU data processing addendum and zero-data retention settings for production.
• This is separate from EU AI Act compliance but affects your overall EU regulatory posture

// OpenAI with GDPR-appropriate settings
import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  // No additional configuration forces EU data residency
  // Use the DPA + zero data retention policy at account level
});

// For EU user data, ensure you have:
// 1. Signed OpenAI's Data Processing Agreement
// 2. Enabled zero data retention (if available for your tier)
// 3. Documented this in your GDPR records of processing activities

Google (Gemini API)

What Google provides:

• Gemini API Terms of Service and usage policies
• Gemini model technical reports (published)
• Google Cloud's EU data residency options (GDPR-relevant)
• Google's AI Principles and responsible AI documentation

EU-specific advantage:

• Google Cloud EU regions (europe-west1, europe-west4, etc.) allow data residency in the EU
• Vertex AI (enterprise Gemini) has GDPR DPA and EU data residency built in
• Use Vertex AI rather than the consumer Gemini API for EU production workloads

# Vertex AI Gemini — EU data residency
import vertexai
from vertexai.generative_models import GenerativeModel

# Initialise with EU region
vertexai.init(project="your-project-id", location="europe-west4")

model = GenerativeModel("gemini-2.0-flash")

def generate_with_eu_residency(prompt: str) -> str:
    response = model.generate_content(prompt)
    return response.text

Step 5: Build Your Art.13 Transparency Documentation

Art.13 requires that AI systems deployed to end users provide "relevant information" about the AI system. For limited-risk GPAI integrations, this is satisfied by a clear AI Transparency Notice — not a GDPR privacy policy, but an AI-specific disclosure document.

Minimum content for a GPAI integration transparency notice:

## AI-Powered Features — Transparency Notice

**What AI does in this product:**
[Describe specifically: "Our AI assistant generates draft responses to your support tickets. 
The AI is powered by [Model Name] from [Provider]. The AI does not make final decisions — 
all responses are [editable by you / reviewed by our team] before delivery."]

**Limitations you should know:**
- The AI may generate inaccurate information ("hallucinations")
- The AI's knowledge has a training cutoff date of [date]
- The AI does not have access to your real-time data unless explicitly provided
- Responses should be verified for [domain-specific critical use cases]

**How to get human support:**
[Clear pathway to reach a human — email, in-app escalation, etc.]

**Data and the AI:**
[Brief statement on what user data is sent to the AI provider and under what terms]

**Your rights:**
Under EU AI Act Art.86, you have the right to receive an explanation of AI-assisted decisions 
that affect you significantly. Contact [email] to request an explanation.

Step 6: The Prohibited Practices Checklist (Art.5)

Before deploying any GPAI-powered feature to EU users, run this checklist. Each question is a hard stop if the answer is "yes":

Manipulation detection:

• Does your GPAI integration use techniques that exploit cognitive biases, emotional states, or psychological vulnerabilities to influence user behaviour against their own interests? → Prohibited
• Does it subliminally influence users without their awareness? → Prohibited
• Does it target vulnerable populations (children, people with disabilities) with manipulative content? → Prohibited

Social scoring:

• Does your system evaluate EU users based on their social behaviour across unrelated contexts to affect their access to services, products, or opportunities? → Prohibited

Biometric categorisation:

• Does your system infer sensitive characteristics (race, political views, religion, sexual orientation) from biometric data to make decisions? → Prohibited

Recommendation and engagement optimisation:

• Does your recommendation engine optimise for engagement metrics in ways that could be characterised as addictive design or psychological manipulation? → High risk — legal review required

Most B2B SaaS tools pass this checklist without issues. The primary risk area for GPAI integrations is engagement optimisation features (social media management tools, retention-focused recommendation engines) where the line between legitimate personalisation and prohibited manipulation requires careful assessment.

Step 7: Logging and Audit Trail Requirements

For any GPAI integration, maintain logs sufficient to:

1. Demonstrate compliance if audited by an NCA (National Competent Authority)
2. Support human oversight — reviewers need to understand what the AI produced and why
3. Enable incident response — if a compliance violation is alleged, you need the evidence

Minimum logging schema:

interface GPAIInteractionLog {
  // Identity
  logId: string;
  sessionId: string;
  userId: string; // pseudonymised for GDPR
  
  // Request
  requestTimestamp: string;
  modelProvider: 'anthropic' | 'openai' | 'google';
  modelId: string;
  systemPromptHash: string; // hash, not content — GDPR-safe
  userInputHash: string; // hash of user input — GDPR-safe
  
  // Response
  responseTimestamp: string;
  completionTokens: number;
  promptTokens: number;
  outputCategory: 'normal' | 'flagged' | 'refused';
  
  // Compliance flags
  disclosureShown: boolean;
  humanOversightAvailable: boolean;
  escalationOffered: boolean;
  
  // For high-risk only
  decisionType?: string;
  humanReviewRequired?: boolean;
  humanReviewCompleted?: boolean;
}

Retention periods:

• General GPAI interaction logs: 6 months minimum (NCA audit window)
• High-risk AI system logs: As required by sector-specific regulation (often 5-7 years for employment, credit decisions)
• Incident reports: Indefinite (required by Art.73 systemic risk incident reporting)

Note: Log the hashes of input/output, not the content itself, to avoid creating additional GDPR personal data obligations. If you need the content for quality purposes, separate it from compliance logs and apply appropriate retention policies.

Step 8: GDPR Intersection — The Dual Compliance Layer

EU AI Act compliance and GDPR compliance are separate but overlapping obligations. When your GPAI integration processes personal data, both frameworks apply:

For GDPR Art.22 (automated decision-making):

If your GPAI integration makes decisions that produce legal or similarly significant effects on EU individuals (loan decisions, CV screening, medical referrals), you must:

1. Inform users a decision was automated (in your privacy notice)
2. Provide a right to request human review
3. Explain the logic of the automated decision on request

// Art.22 GDPR compliance wrapper for significant decisions
async function makeAutomatedDecision(
  userId: string,
  context: DecisionContext
): Promise<Decision> {
  const decision = await callGPAIModel(context);
  
  // Store decision with explanation capability
  await storeDecisionWithExplanation({
    userId,
    decision: decision.outcome,
    factors: decision.reasoning, // Store for Art.22 explanation requests
    timestamp: new Date().toISOString(),
    humanReviewAvailable: true,
    reviewRequestChannel: 'privacy@yourcompany.com'
  });
  
  // Notify user if decision affects them significantly
  if (decision.isSignificant) {
    await notifyUserOfAutomatedDecision(userId, {
      decisionSummary: decision.summary,
      reviewRights: 'You have the right to request human review of this decision.',
      contactEmail: 'privacy@yourcompany.com'
    });
  }
  
  return decision;
}

Pre-Launch Compliance Checklist

Use this checklist before shipping any GPAI-powered feature to EU users:

EU AI Act GPAI Integration — Pre-Launch Checklist

CLASSIFICATION
[ ] Use case assessed against Annex III high-risk categories
[ ] Prohibited practices (Art.5) checklist completed — all items PASS
[ ] Risk tier documented (General Purpose / Limited Risk / High Risk)

ART.50(a) DISCLOSURE (if conversational)
[ ] Disclosure shown before or at first AI interaction
[ ] Disclosure is clear and unambiguous (not buried in ToS)
[ ] Human escalation pathway available and working
[ ] Disclosure text stored and version-controlled

TRANSPARENCY (Art.13)
[ ] AI Transparency Notice written and published
[ ] Model provider and model name documented
[ ] Known limitations disclosed to users
[ ] Data handling with AI provider documented

HUMAN OVERSIGHT (Art.14)
[ ] Escalation to human available for consequential outputs
[ ] Logging of AI interactions implemented
[ ] Override mechanism available for high-risk decisions
[ ] Staff trained on AI system limitations (if applicable)

GDPR INTERSECTION
[ ] GDPR lawful basis established for AI data processing
[ ] Privacy notice updated to cover AI features
[ ] DPA signed with model provider (Anthropic/OpenAI/Google)
[ ] Data minimisation applied (don't send unnecessary personal data to API)
[ ] Art.22 rights implemented if automated decision-making applies

DOCUMENTATION
[ ] Internal technical documentation of AI system maintained
[ ] Compliance assessment documented (risk level and reasoning)
[ ] Log retention policy set (minimum 6 months)
[ ] Incident response plan covers AI-related issues

PROVIDER VERIFICATION
[ ] Confirmed that Anthropic/OpenAI/Google have GPAI provider obligations covered
[ ] API DPA / data residency confirmed for EU users
[ ] Usage policy reviewed — no prohibited use cases in your implementation

The August 2026 Timeline

Key EU AI Act dates for GPAI deployers:

• Immediately (now): Prohibited practices (Art.5) enforcement active since February 2026
• August 2, 2026 (63 days): GPAI model obligations for providers and GPAI transparency for deployers fully in effect. Art.50(a) enforcement begins.
• August 2, 2027: High-risk AI system full compliance deadline (one year extension for existing systems)

What this means: If your SaaS product calls Claude, GPT-4, or Gemini APIs to serve EU users, you have until August 2, 2026 to have your transparency notice, Art.50(a) disclosure, and human oversight mechanisms in place.

For general-purpose tools (writing assistants, summarisers, code helpers), the August deadline requires primarily documentation and disclosure work — not architectural changes. For high-risk applications (HR, credit, education), the timeline is tighter given the scope of Art.26 compliance requirements.

What Happens If You Miss the Deadline

The EU AI Act's enforcement structure means NCAs in each member state can:

• Issue compliance orders requiring you to bring your system into conformity
• Impose administrative fines: up to €15 million or 3% of global annual turnover for prohibited practice violations (Art.5); up to €30 million or 6% for most serious violations
• Withdraw your product from the EU market

Realistically, for SMEs building general-purpose GPAI integrations, the near-term enforcement risk focuses on the most visible violations (chatbots without disclosure, obvious manipulation). The Art.13 documentation requirements will attract scrutiny from 2027 as NCAs build enforcement capacity.

But compliance is not only about avoiding fines — EU enterprise buyers are increasingly requesting AI Act compliance documentation as part of procurement. Having your checklist complete before August gives you a differentiator in B2B sales.

Next in the Series

• Post #4: EU AI Act GPAI Code of Practice 2026 — What SaaS Developers Must Know Before August
• Post #5: GPAI Compliance Finale — Complete Developer Toolkit for August 2026

Part 3 of 5 in the sota.io EU AI Act GPAI Developer Series. These posts provide compliance guidance for EU SaaS developers integrating GPAI models. They do not constitute legal advice — for specific compliance decisions, consult qualified EU AI Act counsel.