EU AI Act AI Supply Chain: When SaaS Developers Become Deployers Integrating Third-Party AI APIs

Post #1452 in the sota.io EU AI Act Compliance Series

The August 2, 2026 EU AI Act deadline is 61 days away, and one of the most common questions from SaaS developers is deceptively simple: "I'm just calling the OpenAI API — am I a provider or a deployer?"

The answer determines whether you need technical documentation (Annex IV), a quality management system (Art.17), conformity assessment (Art.43), CE marking (Art.49), EUAIDB registration (Art.71), and much more — or whether your primary obligation is limited to using the system according to the provider's instructions and maintaining human oversight.

This is the first post in a 5-part series on EU AI Act AI Supply Chain Compliance — covering vendor due diligence, contractual requirements, incident response, and a complete toolkit.

The AI Supply Chain Reality

Most SaaS developers today are not building AI from scratch. They are integrating:

• GPAI model APIs: OpenAI GPT-4o/o3, Anthropic Claude, Google Gemini, Mistral
• Managed AI services: AWS Bedrock, Azure AI Services, Google Vertex AI
• Specialized models: Cohere (text), Stability AI (images), ElevenLabs (voice), Pinecone (vector search)
• AI-powered SaaS APIs: Stripe Radar (fraud), Intercom AI, HubSpot AI

In each case, there is an upstream AI provider (OpenAI, Anthropic, etc.) and a downstream SaaS developer (you). The EU AI Act assigns legal obligations based on your position in this chain — and the assignment is not always obvious.

Art.3 Definitions: Provider vs. Deployer

EU AI Act Art.3(3) defines a provider as:

"a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge"

EU AI Act Art.3(4) defines a deployer as:

"a natural or legal person, public authority, agency or other body that uses an AI system under its own authority except where the AI system is used in the course of a personal non-professional activity"

The critical phrase in the provider definition is "develops an AI system" — and the critical phrase in the deployer definition is "uses an AI system".

When you call the OpenAI API and pass the response directly to your users, you are arguably using an AI system → deployer. But when you fine-tune, chain, or combine AI components into a new product that you market under your own name, you are arguably developing an AI system → provider.

The Provider/Deployer Decision Tree

Are you integrating a third-party AI API into your SaaS product?
│
├── YES → Does your use case fall under Annex III (high-risk)?
│         │
│         ├── YES → Do you modify the AI output, fine-tune, or chain it
│         │         into a system you market under your own name?
│         │         │
│         │         ├── YES → You are likely a PROVIDER (Art.25(1))
│         │         │         Obligations: Art.9-20, Annex IV, CE marking
│         │         │
│         │         └── NO  → You are a DEPLOYER (Art.26)
│         │                   Obligations: Art.26, human oversight, monitoring
│         │
│         └── NO  → General-purpose / non-high-risk use
│                   GPAI Art.50 transparency may still apply
│                   Voluntary compliance pathway: Art.95
│
└── NO  → Building your own model from scratch
          You are clearly a PROVIDER from day one

When Does a Deployer Become a Provider? Art.25(1)

EU AI Act Art.25(1) — "Responsibilities along the AI value chain" — is the most important article for SaaS developers in the supply chain. It specifies that a distributor, importer, deployer, or other third party shall be considered a provider of a high-risk AI system when they:

• Place it on the market or put it into service under their own name or trademark — even if the underlying model is from OpenAI or Anthropic
• Make a substantial modification to a high-risk AI system that has already been placed on the market
• Change the intended purpose of a high-risk AI system beyond what the original provider anticipated

What Counts as "Substantial Modification"?

The EU AI Act defines substantial modification as a change that affects the AI system's compliance with the requirements of Chapter III, Section 2 — or a change to the intended purpose beyond what the original provider anticipated.

In practice, substantial modification includes:

• Fine-tuning an OpenAI model on your domain-specific data for a recruitment use case
• Building a multi-step agentic pipeline where the AI makes consequential decisions
• Combining GPT-4o + your own rule engine to produce credit scoring outputs
• Re-branding an AI system under your company name and marketing it as your product

Substantial modification does NOT include:

• Changing the system prompt / instructions for use within the API
• Using the API as-is for its intended purpose (e.g., customer service chatbot in a non-Annex III context)
• Switching between models within the same provider's family

Practical Implication

If you build "TalentAI" — a recruitment screening SaaS that uses GPT-4o to analyze CVs and rank candidates — you are not just a deployer of OpenAI's API. You are the provider of a high-risk AI system under Annex III Category 4 (Employment and workers management). OpenAI is a provider of a GPAI model; you are a separate provider of a high-risk AI system built on top of it.

This means both levels have provider obligations — OpenAI for the GPAI model, you for the high-risk AI system.

Deployer Obligations Under Art.26

If you ARE classified as a deployer (not a provider) of a high-risk AI system, EU AI Act Art.26 governs your obligations:

Art.26(1) — Use According to Instructions

Use the high-risk AI system in accordance with the instructions of use provided by the provider. Do not use it for purposes or contexts that the provider has not documented.

Practical implication: If OpenAI's usage policy prohibits using GPT-4o for certain types of decisions, and you use it for those purposes anyway, you violate Art.26(1). Review the provider's intended purpose documentation carefully.

Art.26(2) — Human Oversight

Assign oversight of the high-risk AI system to natural persons with the necessary competence, authority, and resources. Implement the human oversight measures specified in the instructions of use.

Practical implication: You cannot fully automate high-risk decisions. Someone with relevant expertise must be able to review, override, or suspend AI outputs that affect individuals.

Art.26(4) — Cooperation with Provider

Cooperate with the provider and market surveillance authorities on post-market monitoring. Report serious incidents to the provider (who then reports to authorities).

Art.26(5) — Incident Reporting Chain

If you observe a serious incident or malfunctioning of the high-risk AI system, inform the provider within the timeframes required under Art.73. Your contractual arrangement with the provider must include clear escalation paths.

Art.26(6) — Suspend Use if Non-Compliant

If you have reason to believe the high-risk AI system no longer complies with EU AI Act requirements, suspend its use and inform the market surveillance authority.

Art.26(9) — Fundamental Rights Impact Assessment

For public authorities, and for deployers providing credit scoring, insurance risk assessment, or essential public services using high-risk AI: conduct a fundamental rights impact assessment before deployment.

The CLOUD Act Dimension of AI Supply Chain Compliance

Here is where the supply chain gets legally treacherous for EU SaaS developers.

When you integrate a US-based AI API (OpenAI / Anthropic / AWS Bedrock / Google), your EU AI Act compliance obligations interact directly with US CLOUD Act jurisdiction.

The dual exposure problem:

1. Your EU AI Act obligation under Art.26(4) requires you to cooperate with EU market surveillance authorities (MSAs) — giving them access to AI system data, decision logs, and technical documentation
2. The US CLOUD Act allows US federal authorities to compel OpenAI, Anthropic, or AWS to produce data held anywhere in the world — including EU AI system logs routed through US infrastructure

If an EU MSA and a US federal agency both simultaneously demand your AI system's decision logs: which jurisdiction governs?

The answer under current law is unclear. Practical mitigation:

• Route AI API calls through EU endpoints (AWS Bedrock eu-central-1, Azure AI West Europe, Mistral EU infrastructure)
• Store AI decision logs on EU-sovereign infrastructure (not in the same S3 bucket as your US production data)
• Implement data residency configuration in your AI API contract with the provider
• Document the jurisdiction of each AI system component in your Annex IV technical documentation

Python Implementation: AI Supply Chain Role Classifier

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional

class AIActRole(Enum):
    PROVIDER_HIGH_RISK = "provider_high_risk"
    PROVIDER_GPAI = "provider_gpai"
    DEPLOYER_HIGH_RISK = "deployer_high_risk"
    DEPLOYER_LIMITED_RISK = "deployer_limited_risk"
    NOT_IN_SCOPE = "not_in_scope"

class AnnexIIICategory(Enum):
    BIOMETRIC = "biometric"
    CRITICAL_INFRASTRUCTURE = "critical_infrastructure"
    EDUCATION = "education"
    EMPLOYMENT = "employment"
    ESSENTIAL_SERVICES = "essential_services"
    LAW_ENFORCEMENT = "law_enforcement"
    MIGRATION_ASYLUM = "migration_asylum"
    JUSTICE_DEMOCRACY = "justice_democracy"
    NOT_HIGH_RISK = "not_high_risk"

@dataclass
class AIIntegrationProfile:
    api_provider: str  # e.g. "openai", "anthropic", "aws_bedrock"
    api_type: str  # "gpai_model", "managed_service", "specialized_model"
    use_case_category: AnnexIIICategory
    own_brand: bool  # marketing under your own name/trademark
    fine_tuned: bool  # custom fine-tuning applied
    substantial_modification: bool  # materially changes intended purpose
    decision_type: str  # "advisory", "consequential", "automated"

@dataclass
class ComplianceRoleAssessment:
    role: AIActRole
    primary_obligations: list[str] = field(default_factory=list)
    art26_applies: bool = False
    art28_provider_trigger: bool = False
    annex_iv_required: bool = False
    conformity_assessment_required: bool = False
    cloud_act_risk: str = "low"

class AISupplyChainRoleClassifier:
    
    US_PROVIDERS = {"openai", "anthropic", "aws_bedrock", "google_vertex", "azure_openai"}
    EU_PROVIDERS = {"mistral", "aleph_alpha", "cohere_eu"}
    
    def classify(self, profile: AIIntegrationProfile) -> ComplianceRoleAssessment:
        is_high_risk = profile.use_case_category != AnnexIIICategory.NOT_HIGH_RISK
        
        # Art.25(1) provider trigger: own name OR substantial modification
        provider_trigger = (
            profile.own_brand or 
            profile.fine_tuned or 
            profile.substantial_modification
        ) and is_high_risk
        
        if provider_trigger:
            role = AIActRole.PROVIDER_HIGH_RISK
            obligations = [
                "Art.9: Risk management system",
                "Art.10: Training data governance",
                "Art.11: Technical documentation (Annex IV)",
                "Art.12: Logging & audit trails",
                "Art.13: Instructions of use",
                "Art.14: Human oversight measures",
                "Art.15: Accuracy, robustness, cybersecurity",
                "Art.17: Quality management system",
                "Art.43: Conformity assessment",
                "Art.47: EU declaration of conformity",
                "Art.49: CE marking",
                "Art.71: EUAIDB registration",
                "Art.72: Post-market monitoring plan",
                "Art.73: Serious incident reporting",
            ]
            assessment = ComplianceRoleAssessment(
                role=role,
                primary_obligations=obligations,
                art26_applies=False,
                art28_provider_trigger=True,
                annex_iv_required=True,
                conformity_assessment_required=True,
            )
        elif is_high_risk:
            role = AIActRole.DEPLOYER_HIGH_RISK
            obligations = [
                "Art.26(1): Use per provider instructions",
                "Art.26(2): Human oversight implementation",
                "Art.26(4): Post-market monitoring cooperation",
                "Art.26(5): Serious incident reporting to provider",
                "Art.26(6): Suspend non-compliant systems",
            ]
            if profile.use_case_category in {
                AnnexIIICategory.LAW_ENFORCEMENT,
                AnnexIIICategory.MIGRATION_ASYLUM,
                AnnexIIICategory.ESSENTIAL_SERVICES,
            }:
                obligations.append("Art.26(9): Fundamental rights impact assessment")
            
            assessment = ComplianceRoleAssessment(
                role=role,
                primary_obligations=obligations,
                art26_applies=True,
                art28_provider_trigger=False,
                annex_iv_required=False,
                conformity_assessment_required=False,
            )
        else:
            assessment = ComplianceRoleAssessment(
                role=AIActRole.DEPLOYER_LIMITED_RISK,
                primary_obligations=["Art.50: Transparency disclosure if chatbot/deepfake"],
                art26_applies=False,
            )
        
        # CLOUD Act risk overlay
        if profile.api_provider in self.US_PROVIDERS:
            assessment.cloud_act_risk = "high"
        elif profile.api_provider in self.EU_PROVIDERS:
            assessment.cloud_act_risk = "low"
        else:
            assessment.cloud_act_risk = "unknown"
        
        return assessment

# Example: SaaS company building CV screening tool on GPT-4o
classifier = AISupplyChainRoleClassifier()
profile = AIIntegrationProfile(
    api_provider="openai",
    api_type="gpai_model",
    use_case_category=AnnexIIICategory.EMPLOYMENT,
    own_brand=True,        # marketed as "TalentAI"
    fine_tuned=False,
    substantial_modification=True,  # custom pipeline for hiring decisions
    decision_type="consequential"
)
result = classifier.classify(profile)
print(f"Role: {result.role.value}")
print(f"CLOUD Act Risk: {result.cloud_act_risk}")
print(f"Annex IV Required: {result.annex_iv_required}")
print(f"Obligations: {len(result.primary_obligations)}")
# Role: provider_high_risk
# CLOUD Act Risk: high
# Annex IV Required: True
# Obligations: 14

35-Item EU AI Act AI Supply Chain Compliance Checklist

Role Classification (Items 1–10)

1. ☐ Identified all third-party AI APIs and services integrated in your SaaS product
2. ☐ Classified each integration by API type: GPAI model, managed service, or specialized model
3. ☐ Assessed each use case against Annex III high-risk categories
4. ☐ Determined provider vs. deployer status for each high-risk AI integration using Art.3(3)/(4)
5. ☐ Checked Art.25(1) triggers: own name/trademark, fine-tuning, substantial modification
6. ☐ Documented the intended purpose of each integrated AI component
7. ☐ Identified which AI provider's EU AI Act compliance documentation is available
8. ☐ Confirmed provider registration in EUAIDB (Art.71) where required
9. ☐ Mapped the full AI supply chain (provider → you → end user) for each feature
10. ☐ Documented which party bears primary provider obligations in each chain

Deployer Obligations — Art.26 (Items 11–22)

1. ☐ Obtained and reviewed the provider's instructions of use
2. ☐ Confirmed your use case is within the provider's documented intended purpose
3. ☐ Assigned named human oversight responsible persons per Art.26(2)
4. ☐ Implemented technical override/review capability for AI outputs
5. ☐ Documented oversight procedures in your internal compliance manual
6. ☐ Set up incident reporting channel from your system to your AI API provider
7. ☐ Established SLA for reporting serious incidents to provider (Art.26(5))
8. ☐ Implemented monitoring to detect AI system malfunctions
9. ☐ Documented conditions under which you would suspend AI system use (Art.26(6))
10. ☐ Assessed whether Art.26(9) FRIA applies (public authority / essential services)
11. ☐ Completed FRIA if required and documented findings
12. ☐ Integrated Art.26 obligations into your GDPR DPO reporting structure

Provider Obligations — Art.25(1) Triggered (Items 23–30)

1. ☐ Assessed whether Art.25(1) applies (own brand, fine-tune, substantial modification)
2. ☐ If Art.25(1) applies: completed Annex IV technical documentation
3. ☐ Established Art.9 risk management system for your AI product
4. ☐ Implemented Art.10 data governance for training data (if fine-tuned)
5. ☐ Conducted Art.43 conformity assessment (self or notified body)
6. ☐ Completed Art.47 EU declaration of conformity
7. ☐ Applied Art.49 CE marking
8. ☐ Registered in EUAIDB (Art.71)

CLOUD Act & Infrastructure (Items 31–35)

1. ☐ Identified which AI API providers are US entities subject to CLOUD Act
2. ☐ Assessed whether EU API endpoints are available (AWS eu-central-1, Azure West Europe)
3. ☐ Configured AI decision logs to reside on EU-sovereign infrastructure
4. ☐ Documented jurisdiction of each AI system component in Annex IV
5. ☐ Included CLOUD Act jurisdiction clause in AI API vendor contract

Key Takeaways for the August 2, 2026 Deadline

1. Calling an API ≠ you're automatically a deployer. If you build a high-risk AI product under your brand using an AI API, EU AI Act Art.25(1) may classify you as a provider with full provider obligations.

2. GPAI providers (OpenAI/Anthropic) have their own obligations (Art.53-55) but these do NOT cover the high-risk AI system you build on top of them.

3. Art.26 deployer obligations are simpler but still real — human oversight, incident reporting, instructions-of-use compliance.

4. US AI APIs introduce CLOUD Act double exposure — route through EU endpoints, store logs on EU infrastructure, document jurisdiction clearly.

5. Get your AI API vendor's compliance documentation now — ask for their GPAI Art.53 model card, system card, or technical documentation. If they can't provide it: red flag.

Next in this series: Post #1453 — EU AI Act Vendor Due Diligence: How to Assess OpenAI, Anthropic, and AWS Bedrock for EU AI Act Compliance Before August 2026.

This post is part of the sota.io EU AI Act Compliance Series. sota.io is an EU-native managed PaaS — deploy any language on Hetzner Germany, 100% GDPR, no CLOUD Act exposure.