AI Act and CLOUD Act: which rules, whose access to our data?

AI Act and CLOUD Act: what each covers

“AI Act compliant”, “hosted in Switzerland”, “encrypted”: these claims answer different questions. When choosing an assistant or cloud storage, it helps to distinguish the rules governing its use from those allowing authorities to request data.

The AI Act regulates AI systems and models in the European market. The US CLOUD Act concerns legal access to data held by certain providers, including data stored abroad. Compliance with the first does not mean being outside the second. Neither law alone establishes that a service is confidential.

This account is current as of 2 October 2026. The European timeline includes the amending regulation adopted in 2026. We separate rules from examples and purchasing considerations: the latter are our practical analysis, rather than a legal assessment of any particular provider.

AI Act: what applies already and what was postponed

The AI Act entered into force on 1 August 2024 and applies progressively. The AI Omnibus, Regulation (EU) 2026/1744 of 8 July 2026, entered into force on 27 July 2026. Among other changes, it revised high-risk system deadlines. Reusing a table published in 2024 can therefore produce dates that are now wrong.

This table summarises major milestones. It does not replace transitional provisions: some models or systems already on the market have particular rules. Postponing high-risk obligations does not postpone the entire regulation.

Obligations according to your role

The regulation distinguishes roles. Article 2(10) excludes deployer obligations for a natural person using a system in a strictly personal, non-professional activity. Preparing a shopping list therefore does not make you the compliance officer for a model.

If you offer a service to others, use AI at work or market a system under your own name, identify your role before looking up the applicable obligations. The answer depends on the activity, its audience and the responsibility you take on.

For a content creator, we recommend documenting the tools used, human checks and publication decisions. This record is useful even where a particular obligation does not apply. It helps explain an error, respond to someone depicted and correct material without reconstructing the entire workflow.

How is the risk level determined?

Classification depends partly on the use and context of a system. The regulation distinguishes prohibited practices, certain high-risk uses and targeted obligations. A model’s power or the presence of AI in a product name cannot determine its entire legal regime.

Rewording a letter and screening job applications may use similar techniques, with very different consequences. Examine the system’s purpose, the decisions it contributes to and the people affected. The provider’s name is not enough to determine its category.

General-purpose model providers also have particular obligations, including documentation and transparency. These do not promise that a generated answer will be correct. A neatly structured response with citations can still be wrong; a regulated model can still make mistakes. For readers, checking claims remains separate from the provider’s compliance.

Transparency requirements for content

Article 50 distinguishes provider-side technical marking from certain disclosures to the public. It covers disclosure of deepfakes. Certain artistic or fictional works can use disclosure appropriate to the work. Not every generated visual is therefore automatically a deepfake.

Generated text published to inform the public on matters of public interest is also covered, with an exception where it has undergone human review or editorial control and someone holds editorial responsibility for publication. That is not a general exemption for anyone briefly reading an output.

For a publication such as SecuFocus, a sensible editorial choice is to identify generated illustrations, avoid presenting fictional scenes as evidence of testing and check article sources. Adding an AI label does not turn an unchecked claim into reliable information. Conversely, the absence of a detectable marker does not prove that an image is authentic.

Distinguish the nature of the content from its context too. An abstract server illustration has a different effect from a fabricated photograph placing an identifiable person in an event that never happened. Disclosure should help people understand what they are seeing.

What concerns users in Switzerland

The Swiss Federal Office of Justice describes work towards a consultation draft by the end of 2026. This includes preparing ratification of the Council of Europe’s AI convention. That convention and the European Union’s AI Act are different instruments. An announced draft should not be described as an already applicable law.

This does not leave AI in a Swiss legal vacuum. The FDPIC states that the Federal Act on Data Protection already applies to personal-data processing involving AI. Sending a file containing other people’s information to an assistant remains a data protection issue even without a new Swiss law dedicated to AI.

The AI Act also has territorial criteria that can cover actors established outside the EU, including those placing systems or models on the European market, or certain cases where outputs are used in the Union. A Swiss headquarters is therefore not a general exemption. Those criteria require analysis of the activity; they do not mean that a Swiss consumer using a chatbot personally automatically faces every obligation in the regulation.

For personal choices, separate two checks: the information you are willing to give the service and what you will do with its responses. The first concerns data. The second concerns consequences, affected people and your responsibility for publication.

CLOUD Act: requests beyond the storage location

The CLOUD Act dates from 2018. The rule codified in 18 USC § 2713 requires covered providers to preserve or disclose data in their possession, custody or control under applicable procedures, even when that data is outside the United States.

Control is therefore an important word. Examine jurisdiction over the provider and its actual ability to produce the data. A Swiss data-centre address does not answer those questions. Conversely, using American software does not automatically make all of a user’s information obtainable through this route.

Consider a hypothetical example: your documents are stored in a provider’s Swiss region. The relevant operator is subject to US jurisdiction and controls the requested data. Swiss storage alone does not rule out a demand under the US framework. Now change the assumption: the provider holds only encrypted content and cannot decrypt it. The content-access implications change, even though a request can still concern what it holds.

Request and challenge procedures

The CLOUD Act is not a universal administrator account handed to an agency. Access relies on applicable legal procedures; requirements and instruments vary with the information sought. Communication contents, subscriber details and other records should not be described as though they always follow the same mechanism.

There are opportunities to challenge demands, but they are conditional. The mechanism in 18 USC § 2703(h) addresses certain conflicts involving the law of a qualifying foreign government and the customer’s status. It does not provide a general veto whenever a file belongs to a European or Swiss person.

When evaluating a service, ask how the operator reviews requests, limits their scope and publishes statistics. Saying it obeys the law conveys little detail. A transparency report provides evidence, but its scope, period and disclosure restrictions matter. The absence of a publicised request does not demonstrate that access is impossible.

International agreements under the CLOUD Act

The framework also includes executive agreements with partners. Subject to conditions, these allow direct requests under the requesting country’s law by removing certain legal barriers. This route is distinct from the reach of US demands for data controlled abroad.

Avoid a common mistake: my country has not signed an agreement, so the CLOUD Act cannot affect my data. An agreement and the reach of US legal process are not the same condition. We do not provide a supposedly exhaustive agreement list here: their status needs checking in the texts applicable to a particular situation.

Nor should CLOUD Act become shorthand for all surveillance. Intelligence powers, including those under the FISA framework, are a different subject. Rules governing commercial data transfers are another. Combining these frameworks can sound alarming without helping anyone make a better service choice.

Conflicts with the GDPR and Swiss data protection law

In its final Article 48 GDPR guidelines, adopted on 4 June 2025, the European Data Protection Board explains that a foreign decision does not automatically become enforceable in the EU. A disclosure requires both an Article 6 legal basis and compliance with Chapter V transfer rules. An international agreement may provide a framework; other grounds require examination of their conditions.

This rules out two opposite shortcuts. Saying a US demand alone authorises everything in Europe goes too far. Saying the GDPR necessarily blocks every response does too. Concurrent rules create a legal issue to resolve, not a technical barrier making files unreadable.

These guidelines concern the GDPR, rather than automatically applying it to every Swiss situation. For professional activities or specially protected information, examine applicable law, contractual commitments and the actual architecture. The practical lesson for consumers is narrower: do not infer confidentiality from a compliant badge without asking who can read the data.

What encryption can technically restrict

Protection depends on the ability to decrypt. A provider managing keys and using them to run your service is in a different position from storage receiving files encrypted on your device. CNIL explains this distinction in its analysis of public-cloud encryption.

If the operator can decrypt the content on its own, the “encrypted” label does not prevent its access. A customer-supplied key may also be accessible to the service, depending on the architecture. Examine in-memory processing, account recovery and backup copies to understand where the content becomes readable.

Well-designed end-to-end encryption can reduce the intelligible content available at the provider. Metadata may remain, and it does not protect a compromised device or copies supplied to a recipient. It does not create legal immunity either: other procedures and information sources may exist. Technology reduces certain access capabilities; it does not determine every obligation by itself.

• Encrypt your data in five practical situations↗

AI assistant, family archive and local model: three cases

You ask an AI service to summarise a personal file. The immediate questions are what you send, to whom and for how long it will be retained. An AI Act compliance statement does not tell you whether data will be used for training or who can inspect the file. Remove unnecessary information, check the service terms and use a fictional document when real content is unnecessary.

You upload a family archive to cloud storage advertised as being in Switzerland. Location is useful but incomplete information. Ask which entity provides the service, who operates the infrastructure and who holds the keys. If the service receives only an archive encrypted by you, sharing and recovery arrangements also matter alongside country selection.

You run a model on a computer at home. If processing actually stays local, you reduce transfers to a remote provider. Still check extensions, connectors and features that call external APIs. A local installation does not make every use of someone else’s data or every publication permissible.

• Use generative AI responsibly↗
• Self-hosting vs cloud: the technical tradeoffs↗

Answers to obtain before entrusting sensitive data

Keep the answers below with the terms you consulted and their date. Revisit them if the service adds an AI feature, changes a processor or modifies account recovery: these changes may affect data access.

• Which company supplies the service, and which operators or subcontractors can access the data?
• Where are content, backups and technical logs stored and processed?
• Who can decrypt, in what circumstances, and how does account recovery work?
• Can documents or conversations be used for training? Which settings and commitments apply to my exact plan?
• What procedure governs authority requests, challenges and notification to users?
• Can I export content, close the account and understand when copies are deleted?

Choose a service and follow legal changes

When choosing a service, first limit the data you entrust to it and establish who can technically read it. A compliance claim alone does not tell you whether it suits a document you want to keep confidential.

To follow the AI Act, check the consolidated text and its date, then the guidance relevant to your use. A proposal or political agreement does not have the same status as a regulation in force. For the CLOUD Act, examine jurisdiction, control over data, procedure and encryption separately.

This article provides general information and may contain errors or become incomplete as law changes. Decisions involving professional activities, protected secrets or proceedings require examination of your circumstances and contracts. The sources below support the documentary points; our examples remain hypothetical.