EU AI Act Art.26 Deployer Obligations + CLOUD Act: The Compliance Gap SaaS Developers Miss (2026)

Post #1589 in the sota.io EU Cyber Compliance Series — EU AI Act CLOUD Act Compliance Gap #3/5

In the first post of this series we showed how the US CLOUD Act creates hidden compliance gaps in EU AI Act provider obligations — specifically Art.9 risk management and Art.10 data governance. In the second post we examined how CLOUD Act undermines Art.12 record-keeping integrity and Art.13 transparency to deployers.

This post focuses on the other side of the relationship: the deployer. If you are a SaaS company that has integrated an AI model into your product — using AWS Bedrock, Azure OpenAI Service, Google Cloud Vertex AI, or any US-hosted AI API — you are a deployer under the EU AI Act. And you have a set of documented obligations under Art.26 that the CLOUD Act quietly undermines.

The August 2026 deadline is 55 days away. This is what you need to understand before your compliance posture is tested.

Who Is a Deployer Under the EU AI Act?

The EU AI Act draws a distinction between providers (the entities that develop, train, or place an AI system on the market) and deployers (the entities that put a provider's AI system into service for a specific real-world purpose).

If you have:

• Integrated GPT-4 via Azure OpenAI Service into your recruitment platform's CV screening tool
• Used AWS Bedrock to power the credit-scoring module of your lending SaaS
• Built a medical triage assistant on top of Google Cloud Vertex AI
• Deployed a biometric identification system using a third-party model from a US AI vendor

Then you are a deployer. Microsoft, Amazon, Google, and the AI vendor are (some of the) providers. The distinction matters enormously, because Art.26 assigns deployers their own independent set of obligations — separate from, and in addition to, any obligations that flow through the provider's instructions for use.

What Art.26 Requires: The Core Deployer Obligations

Article 26 of the EU AI Act establishes that deployers of high-risk AI systems must:

Use in accordance with instructions: Deployers must take appropriate technical and organisational measures to ensure they use high-risk AI systems in accordance with the instructions for use supplied by the provider. This includes maintaining the conditions under which the system was designed to operate.

Human oversight: Deployers must ensure that the natural persons designated for human oversight have the necessary competence, authority, and resources to carry out that task. Where human oversight is built into the system, deployers must enable it and not suppress it.

Notify providers and distributors of risks: If a deployer identifies a risk, an incident, or a serious malfunction, they must notify the provider or distributor without undue delay.

Worker notification: Where high-risk AI systems are used in the context of employment, deployers must inform workers' representatives and the affected workers before putting the system into use. This is one of the most practically significant requirements for HR-tech deployers.

Fundamental Rights Impact Assessment: For certain categories of deployer — specifically public authorities and private bodies using high-risk AI systems in the context of Annex III points 1 through 8 — deployers must conduct a Fundamental Rights Impact Assessment (FRIA) under Art.27 before deploying the system. The FRIA must document the assessment of impacts on fundamental rights, the consultation with relevant parties, and the risk mitigation measures adopted.

The CLOUD Act Undermines Every One of These Obligations

Each of the Art.26 deployer obligations requires you to generate, store, and maintain documentation. The worker notification obligation requires records of notice. The FRIA under Art.27 is a written document. The human oversight assessment is a process record. The technical and organisational measures are documented policies.

If any of this documentation is stored on AWS, Azure, or GCP — and your AI application logs, model call records, and oversight audit trails are kept in the same infrastructure — then every piece of your Art.26 compliance posture is subject to CLOUD Act compelled disclosure.

The CLOUD Act Reach to Deployers

The CLOUD Act (18 U.S.C. § 2713) requires US-incorporated companies to produce stored data on demand from US law enforcement and intelligence agencies, regardless of where that data is physically stored. For deployers, the exposure point is threefold.

Exposure 1: Your compliance documentation itself

You have written a FRIA under Art.27 assessing the human rights impact of your credit-scoring AI on European loan applicants. You have stored this document in an S3 bucket in eu-central-1. AWS is a US company. A US federal agency can compel AWS to produce that document. The agency does not need to notify you. The agency does not need to obtain mutual legal assistance from German authorities. A gag order may prohibit AWS from telling you the order was served.

Your FRIA now has a gap: it documents who you consulted during the assessment, the risks you identified, and the mitigations you adopted. It does not document that a US government agency may have accessed the document, extracted information about your AI system's operations, and used that information in ways you are unaware of and cannot account for.

Exposure 2: Your model inference logs

Art.26 requires deployers to maintain records of the AI system's operation. For high-risk AI systems subject to the obligation to log under Art.12 (which providers must enable and deployers must maintain), your inference logs sit in the AI provider's infrastructure — and the deployer-accessible copies you keep for your own compliance records are in your cloud storage.

When your HR AI system processes a CV and reaches a scoring decision, that event is logged. The log contains the input features, the model output, and the timestamp. If you're running on AWS, Azure, or GCP, those logs are under CLOUD Act reach. The operational decisions your AI system makes about EU job applicants — decisions that have direct legal consequences for them — are accessible to US government agencies without the knowledge of those applicants, without notification to you, and without oversight from EU data protection authorities.

Exposure 3: Your AI vendor's model outputs via API

A subtler but equally significant exposure: when you call AWS Bedrock, Azure OpenAI, or Vertex AI, the API call payload and response are processed by US cloud infrastructure. Even if you delete your copy of the log, the cloud provider retains infrastructure-level records of the call. Those records are subject to CLOUD Act.

For a medical triage assistant, this means patient symptom descriptions and AI-generated clinical suggestions are in the CLOUD Act jurisdiction of a US federal agency. For a credit-scoring system, it means the applicant's financial data and the model's risk assessment are accessible. For a biometric identification system, it means the biometric template and the match result are reachable.

The Worker Notification Gap

The worker notification obligation under Art.26 is the most concrete and immediately actionable of the Art.26 requirements. Before deploying a high-risk AI system in an employment context, you must notify workers and their representatives.

The CLOUD Act creates a structural problem with this obligation: the information you provide in the notification is necessarily incomplete.

A complete worker notification for an EU AI Act high-risk system would state, among other things:

• The AI system's purpose and how decisions are made
• The right to contest AI-driven decisions and obtain human review
• The data that is processed and how it is protected
• Who can access the AI system's records and under what conditions

If your AI system runs on AWS Bedrock or Azure OpenAI, the honest answer to "who can access the AI system's records" includes US federal agencies under the CLOUD Act. That answer is not in your worker notification. It is not in your privacy notice. It cannot be in your FRIA, because you do not know when or whether CLOUD Act orders are served — and those orders may be subject to gag provisions that prevent your cloud provider from telling you.

The EU General Data Protection Regulation requires transparency about data access. The EU AI Act's worker notification obligation requires disclosure of the system's operation. The CLOUD Act creates a class of access that neither you nor your workers can be informed about.

Art.27 FRIA: The Document That Proves Your Compliance — and Your Exposure

The Fundamental Rights Impact Assessment required under Art.27 is the deployer's primary compliance artefact. It is the document you produce to demonstrate that you have assessed the rights impacts of your AI deployment on affected persons — EU residents, in most cases.

The FRIA must assess impacts on:

• The right to human dignity
• The right to privacy and data protection
• The right to non-discrimination
• The rights of the child
• The right to effective judicial remedy and fair trial

If you store your FRIA in US-headquartered cloud infrastructure, you have created a document that (a) describes the potential human rights harms your AI system could inflict on EU residents, and (b) is accessible to US government agencies without EU oversight.

This is not a theoretical concern for public authorities deploying AI systems used in law enforcement or border control contexts. It is a concrete compliance problem for any SaaS company that processes EU residents' data in high-risk AI contexts — which includes recruitment, credit assessment, medical triage, and educational assessment.

Your FRIA is designed to be a transparency instrument for EU supervisory authorities. It should not simultaneously be an accessible intelligence document for US federal agencies.

The Human Oversight Documentation Problem

Art.26 requires deployers to ensure that natural persons responsible for human oversight have the competence and authority to perform the oversight function. This creates an obligation to document: who performs oversight, what their qualifications are, what decisions they can override, and how overrides are recorded.

This oversight documentation is operational infrastructure. It is stored in your HR systems, your incident management platform, your change management records. For most SaaS companies, that means it is in Okta, ServiceNow, Jira, Workday, or another US-headquartered platform — all of which are subject to the CLOUD Act.

A EU AI Act supervisory authority auditing your deployer compliance will ask to see your human oversight records. You can produce them. What you cannot tell the auditor is whether those records have also been accessed by US government agencies, when, and what information was extracted — because you may not have been notified, and the order may be subject to gag provisions.

Developer-Actionable Compliance Checklist: Closing the CLOUD Act Gap

The following checklist addresses the CLOUD Act exposure in EU AI Act Art.26 deployer obligations. Each item identifies the specific obligation, the CLOUD Act risk, and the EU-native mitigation.

Documentation Storage

• FRIA (Art.27): Store on EU-native infrastructure only — self-hosted on Hetzner Germany, or EU-incorporated SaaS with no US-parent. Avoid AWS S3, Azure Blob, GCP Cloud Storage.
• Oversight records: HR and incident management systems should be EU-native if they contain AI governance records (Personio, Factorial, EasyProject instead of Workday, ServiceNow on AWS).
• Worker notification records: If using a US-hosted HR platform, maintain a separate EU-native record of AI-related notifications.

AI Model Selection

• Prefer EU-native AI APIs: Mistral AI (France), Aleph Alpha (Germany), and similar EU-incorporated providers are not subject to the CLOUD Act. For inference, use EU-native endpoints.
• Audit your model stack: List every AI model and API your high-risk AI system calls. Map each provider to its incorporation jurisdiction. Flag all US-incorporated providers.
• Contractual protections are insufficient: Microsoft's EU Data Boundary, Google's data residency commitments, and AWS region locking do not protect against CLOUD Act obligations. Physical location is irrelevant. Contractual commitments do not override US federal law.

Inference Infrastructure

• Self-hosted models where possible: For high-risk AI systems in employment, credit, medical, or law enforcement contexts, self-hosting open-weight models (Llama 3, Mistral, Qwen) on EU-native compute eliminates CLOUD Act inference log exposure.
• EU-native PaaS for model serving: Deploy self-hosted models on EU-native PaaS infrastructure (e.g., sota.io, Hetzner Cloud) to maintain clean EU jurisdiction over inference logs.
• Encryption for inference logs: If US-hosted infrastructure is unavoidable in the short term, encrypt inference logs with keys managed in EU-native key management systems. This does not eliminate CLOUD Act reach but limits the usability of any compelled disclosure.

Worker and User Notifications

• Accurate description of data access: Worker notifications and user privacy notices should accurately describe the jurisdiction of cloud providers used. If US-hosted, acknowledge that US law may compel data access without EU-level oversight procedures.
• FRIA cross-reference: Your FRIA should explicitly evaluate CLOUD Act exposure as a risk factor affecting the AI system's data protection posture.

Incident and Override Records

• EU-native incident management: Incidents involving high-risk AI decisions, human overrides, and appeals should be logged in EU-native systems, not US-hosted ITSM platforms.
• Supervisory access documentation: Maintain clear documentation of which parties can access AI system records — including honest acknowledgment of US law enforcement access via CLOUD Act where applicable.

The Structural Argument: Transparency Requires Control

The fundamental problem with CLOUD Act + EU AI Act deployer obligations is not technical — it is structural. EU AI Act deployer obligations are designed to create an accountability chain: you document your measures, you notify affected parties, you conduct impact assessments, and EU supervisory authorities can audit the chain.

The CLOUD Act introduces an undisclosed actor into that chain. US government agencies can access the chain's documentation without notifying the chain's participants. The accountability chain breaks at exactly the point where it is most important: when public interest oversight demands access.

EU-native infrastructure solves this problem not by making compliance easier, but by making transparency honest. When your FRIA, oversight records, and inference logs are on infrastructure that is jurisdictionally immune to the CLOUD Act — EU-incorporated, EU-operated, no US parent — you can tell your workers, your users, and your supervisory authority exactly who can access your AI system's records, and answer that question completely.

That completeness is what Art.26 compliance actually requires.

Summary: The Three Art.26 + CLOUD Act Gaps

What Is Next in This Series

This series examines the EU AI Act + CLOUD Act compliance intersection from the perspective of developers building and deploying AI systems in the EU:

• Post #1 read →: The hidden compliance gap — Art.9/10 provider obligations
• Post #2 read →: Art.12/13 audit trail and transparency obligations
• Post #3 (this post): Art.26/27 deployer obligations and FRIA exposure
• Post #4 (next): EU AI Act conformity assessment (Art.43) + CLOUD Act: what notified body auditors will find
• Post #5 (finale): Building a CLOUD Act-resistant EU AI Act compliance architecture — complete developer checklist

The August 2026 deadline leaves 55 days. Closing the CLOUD Act gap now is substantially easier than explaining it to your notified body auditor when your conformity assessment is due.