AI Act et CLOUD Act : quelles règles, quels accès à nos données ?

AI Act et CLOUD Act : leurs champs respectifs

« Conforme à l’AI Act », « hébergé en Suisse », « chiffré » : ces mentions ne répondent pas aux mêmes questions. Pour choisir un assistant ou un espace de stockage, il faut comprendre les règles qui encadrent son usage et celles qui permettent aux autorités de demander des données.

L’AI Act encadre des systèmes et modèles d’intelligence artificielle sur le marché européen. Le CLOUD Act américain concerne notamment l’accès légal à des données détenues par certains prestataires, y compris lorsqu’elles sont stockées à l’étranger. Respecter le premier ne signifie pas échapper au second. Et aucun des deux ne permet, à lui seul, de conclure qu’un service est confidentiel.

État des lieux au 2 octobre 2026. Le calendrier européen ci-dessous tient compte du règlement modificatif adopté en 2026. Nous séparons les règles des exemples et des conseils de choix : ces derniers constituent notre analyse pratique, pas une appréciation juridique d’un fournisseur particulier.

AI Act : ce qui s’applique déjà, ce qui a été repoussé

L’AI Act est entré en vigueur le 1er août 2024. Son application est progressive. L’AI Omnibus, règlement (UE) 2026/1744 du 8 juillet 2026, est entré en vigueur le 27 juillet 2026. Il a notamment modifié les échéances des systèmes à haut risque. Reprendre aujourd’hui un tableau publié en 2024 peut donc conduire à annoncer des dates devenues fausses.

Le tableau résume les principaux jalons. Il ne remplace pas les dispositions transitoires : certains modèles ou systèmes déjà sur le marché ont des règles particulières. Le report des obligations à haut risque ne reporte pas tout le règlement.

Les obligations selon votre rôle

Le règlement distingue les rôles. Son article 2(10) écarte les obligations des déployeurs pour une personne physique utilisant un système dans une activité strictement personnelle et non professionnelle. Préparer une liste de courses ne vous transforme donc pas en responsable de conformité d’un modèle.

Si vous proposez un service à d’autres personnes, utilisez l’IA au travail ou commercialisez un système sous votre nom, identifiez votre rôle avant de chercher les obligations applicables. La réponse dépend de l’activité, du public visé et de la responsabilité que vous assumez.

Pour un créateur de contenu, nous conseillons de documenter les outils utilisés, les vérifications humaines et les choix de publication. Cette trace est utile même lorsqu’une obligation précise ne s’applique pas. Elle permet de comprendre une erreur, de répondre à une personne représentée et de corriger un contenu sans devoir reconstituer tout le travail.

Comment se détermine le niveau de risque ?

La qualification dépend notamment de l’usage et du cadre du système. Le règlement distingue les pratiques interdites, certains usages à haut risque et des obligations ciblées. La puissance d’un modèle ou la présence du mot IA sur une application ne suffisent pas à déterminer tout son régime.

Reformuler une lettre et sélectionner des candidatures peuvent mobiliser des techniques proches, avec des conséquences très différentes. Examinez l’usage du système, les décisions auxquelles il participe et les personnes concernées. Le nom du fournisseur ne suffit pas à déterminer sa catégorie.

Les fournisseurs de modèles à usage général ont également des obligations propres, notamment de documentation et de transparence. Cela ne promet pas qu’une réponse générée sera exacte. Un texte organisé et cité peut rester faux ; un modèle soumis à des règles peut toujours produire une erreur. Pour le lecteur, la vérification des affirmations reste une tâche distincte de la conformité du fournisseur.

Les obligations de transparence sur les contenus

L’article 50 distingue le marquage technique côté fournisseur et certaines informations à donner au public. Il prévoit notamment le signalement des hypertrucages, ou deepfakes. Pour certaines œuvres artistiques ou fictives, l’information peut prendre une forme adaptée à l’œuvre. Tous les visuels générés ne sont donc pas automatiquement des deepfakes.

Les textes générés pour informer sur des sujets d’intérêt public sont également visés, avec une exception lorsque le contenu a fait l’objet d’une vérification humaine ou d’un contrôle éditorial et qu’une personne assume la responsabilité de publication. Ce n’est pas une exemption générale pour toute personne qui relit rapidement une sortie.

Pour un média comme SecuFocus, le choix éditorial raisonnable est de signaler une illustration générée, de ne pas présenter une scène fictive comme la preuve d’un test et de vérifier les sources d’un article. Le simple ajout d’une mention IA ne transforme pas une affirmation invérifiée en information fiable. Inversement, l’absence d’un marqueur détectable ne prouve pas qu’une image est authentique.

Il faut aussi distinguer la nature du contenu et le contexte où il apparaît. Une représentation abstraite d’un serveur n’a pas le même effet qu’une fausse photographie montrant une personne identifiable dans une situation qui n’a jamais existé. La transparence doit aider le public à comprendre ce qu’il regarde.

Ce qui concerne les utilisateurs en Suisse

L’Office fédéral de la justice décrit un travail suisse visant un avant-projet destiné à la consultation d’ici fin 2026. Ce chantier prépare notamment la ratification de la convention du Conseil de l’Europe sur l’IA. Cette convention et l’AI Act de l’Union européenne sont deux instruments différents. Un avant-projet annoncé ne doit pas être présenté comme une loi déjà applicable.

Cela ne signifie pas que l’IA évolue dans un vide juridique en Suisse. Le PFPDT rappelle que la LPD s’applique déjà aux traitements de données personnelles utilisant l’IA. Donner un dossier contenant les informations d’autres personnes à un assistant reste une question de protection des données, même en l’absence d’une nouvelle loi suisse dédiée à l’IA.

L’AI Act comporte en outre des critères territoriaux qui peuvent viser des acteurs établis hors de l’UE, notamment lorsqu’ils mettent un système ou un modèle sur le marché européen, ou dans certains cas lorsque les sorties sont utilisées dans l’Union. Un siège suisse n’est donc pas une exemption générale. Ces critères demandent une analyse de l’activité ; ils ne signifient pas qu’un particulier suisse utilisant un chatbot pour lui-même devient automatiquement soumis à toutes les obligations du règlement.

Pour vos choix personnels, séparez deux vérifications : les informations que vous acceptez de confier au service et l’usage que vous ferez de ses réponses. La première porte sur les données. La seconde porte sur les conséquences, les personnes concernées et votre responsabilité de publication.

CLOUD Act : des demandes au-delà du lieu de stockage

Le CLOUD Act date de 2018. La règle codifiée à 18 USC § 2713 impose aux prestataires concernés de préserver ou communiquer les données relevant de leur possession, garde ou contrôle, conformément aux procédures applicables, même si ces données se trouvent hors des États-Unis.

Le mot important est donc aussi « contrôle ». Il faut examiner la juridiction applicable au prestataire et sa capacité réelle à produire les données. Une adresse de centre de données en Suisse ne répond pas à ces questions. À l’inverse, l’utilisation d’un logiciel américain ne rend pas automatiquement toutes les données de son utilisateur accessibles par cette voie.

Exemple hypothétique : vous stockez des documents dans une région suisse d’un fournisseur. L’opérateur concerné est soumis à la juridiction américaine et contrôle les données demandées. Le stockage suisse ne suffit pas, à lui seul, à écarter une demande fondée sur le cadre américain. Changez maintenant l’hypothèse : le fournisseur ne détient qu’un contenu chiffré, sans capacité à le déchiffrer. Les enjeux d’accès au contenu deviennent différents, même si une demande peut toujours viser ce qu’il détient.

Les procédures de demande et de contestation

Le CLOUD Act n’est pas un compte administrateur universel remis à une agence. L’accès repose sur les procédures légales applicables ; les conditions et instruments varient selon les données recherchées. Un contenu de communication, des informations d’abonné et d’autres enregistrements ne doivent pas être décrits comme s’ils relevaient toujours du même mécanisme.

Les possibilités de contestation existent, mais sont conditionnelles. Le mécanisme de 18 USC § 2703(h) traite notamment certains conflits avec le droit d’un gouvernement étranger qualifié et le statut du client concerné. Il ne fournit pas un veto général dès qu’un fichier appartient à une personne européenne ou suisse.

Dans l’évaluation d’un service, demandez comment l’opérateur examine les demandes, limite leur portée et publie des statistiques. Une formule « nous respectons la loi » donne peu d’information. Un rapport de transparence apporte des éléments, mais son périmètre, sa période et les restrictions de divulgation comptent. L’absence d’une demande rendue publique ne démontre pas l’impossibilité d’un accès.

Les accords entre pays prévus par le CLOUD Act

Le dispositif comprend aussi des accords exécutifs avec des partenaires. Ils permettent, sous conditions, des demandes directes selon le droit du pays demandeur, en levant certains obstacles juridiques. Cette voie est distincte de la portée des demandes américaines sur des données contrôlées à l’étranger.

Il faut éviter une erreur fréquente : « mon pays n’a pas signé un accord, donc le CLOUD Act ne peut pas concerner mes données ». L’existence d’un accord et la portée d’une procédure américaine ne sont pas la même condition. Nous ne dressons pas ici une liste d’accords supposée exhaustive : leur statut doit être contrôlé dans les textes applicables à une situation donnée.

Il faut aussi éviter de faire du CLOUD Act le nom de toutes les formes de surveillance. Les pouvoirs de renseignement, dont ceux relevant du cadre FISA, constituent un autre sujet. Les mécanismes encadrant les transferts commerciaux de données en sont encore un autre. Mélanger ces cadres peut produire un discours inquiétant sans permettre de choisir un service plus judicieusement.

Les conflits avec le RGPD et la LPD

Dans ses lignes directrices finales sur l’article 48 du RGPD, adoptées le 4 juin 2025, le Comité européen de la protection des données rappelle qu’une décision étrangère ne devient pas automatiquement exécutoire dans l’UE. Une transmission doit satisfaire à la fois une base juridique de l’article 6 et aux règles de transfert du chapitre V. Un accord international peut fournir un cadre ; d’autres fondements doivent être examinés avec leurs conditions.

Cela exclut deux raccourcis opposés. Dire « la demande américaine suffit à tout autoriser en Europe » est excessif. Dire « le RGPD bloque nécessairement toute réponse » l’est aussi. La présence de règles concurrentes crée un problème juridique à résoudre, pas une barrière technique qui rendrait les fichiers illisibles.

Ces lignes directrices concernent le RGPD, pas une application automatique de celui-ci à toute situation suisse. Pour une activité professionnelle ou des informations soumises à un secret particulier, il faut examiner le droit applicable, les engagements contractuels et l’architecture réelle. Pour un particulier, la leçon pratique est plus modeste : ne déduisez pas la confidentialité d’un bandeau « conforme » sans chercher qui peut lire les données.

Ce que le chiffrement limite techniquement

La protection dépend de la capacité à déchiffrer. Un fournisseur qui gère les clés et les utilise pour exécuter votre service n’est pas dans la même situation qu’un stockage recevant seulement des fichiers chiffrés sur votre appareil. La CNIL détaille cette différence dans son analyse du chiffrement du cloud public.

Si l’opérateur peut déchiffrer seul le contenu, la mention « chiffré » ne l’empêche pas d’y accéder. Une clé apportée par le client peut aussi être accessible au service selon l’architecture. Examinez le traitement en mémoire, la récupération du compte et les copies de secours pour comprendre où le contenu devient lisible.

Un chiffrement de bout en bout bien conçu peut réduire le contenu intelligible disponible chez le prestataire. Il peut laisser des métadonnées et ne protège pas un appareil déjà compromis ni les copies remises à un destinataire. Il ne crée pas non plus une immunité juridique : d’autres procédures et d’autres sources d’information peuvent exister. La technologie réduit certaines capacités d’accès ; elle ne décide pas seule de toutes les obligations.

• Chiffrer ses données dans cinq situations concrètes↗

Assistant IA, archive familiale et modèle local : trois cas

Vous demandez à une IA de résumer un dossier personnel. La question immédiate est ce que vous envoyez, à qui et pour quelle durée de conservation. Une déclaration de conformité à l’AI Act ne vous dit pas si les données serviront à l’entraînement ni qui pourra consulter le dossier. Retirez les informations inutiles, vérifiez les conditions du service et utilisez un document fictif si le contenu réel n’est pas nécessaire.

Vous placez une archive familiale dans un cloud avec un stockage annoncé en Suisse. La localisation est une information utile, mais incomplète. Demandez quelle entité fournit le service, qui intervient sur l’infrastructure et qui possède les clés. Si le service reçoit uniquement une archive chiffrée par vos soins, les conditions de partage et de récupération deviennent aussi importantes que le choix du pays.

Vous faites tourner un modèle sur un ordinateur à la maison. Si le traitement reste effectivement local, vous réduisez les transferts vers un fournisseur distant. Vérifiez néanmoins les extensions, les connecteurs et les fonctions qui appellent une API externe. Le caractère local de l’installation n’autorise pas pour autant tous les usages des données d’autrui ou toutes les publications.

• Utiliser l’IA générative de manière responsable↗
• Auto-hébergement ou cloud : les compromis techniques↗

Les réponses à obtenir avant de confier des données sensibles

Gardez les réponses ci-dessous avec les conditions consultées et leur date. Revenez-y si le service ajoute une fonction IA, change de sous-traitant ou modifie la récupération du compte : ces changements peuvent affecter l’accès aux données.

• Quelle société fournit le service et quels opérateurs ou sous-traitants peuvent accéder aux données ?
• Où sont stockés et traités les contenus, les sauvegardes et les journaux techniques ?
• Qui peut déchiffrer, dans quelles circonstances, et comment fonctionne la récupération du compte ?
• Les documents ou conversations peuvent-ils servir à l’entraînement ? Quels réglages et engagements s’appliquent à mon offre exacte ?
• Quelle procédure encadre les demandes d’autorités, leur contestation et l’information de l’utilisateur ?
• Puis-je exporter mes contenus, fermer le compte et comprendre les délais de suppression des copies ?

Choisir un service et suivre les évolutions du droit

Pour choisir un service, limitez d’abord les données que vous lui confiez et cherchez qui peut techniquement les lire. La conformité annoncée ne suffit pas à déterminer s’il convient à un document que vous souhaitez garder confidentiel.

Pour suivre l’AI Act, consultez le texte consolidé et sa date, puis les lignes directrices correspondant à votre usage. Une proposition ou un accord politique n’a pas le même statut qu’un règlement entré en vigueur. Pour le CLOUD Act, examinez séparément la juridiction, le contrôle des données, la procédure et le chiffrement.

Cet article fournit une information générale et peut comporter des erreurs ou devenir incomplet après une évolution du droit. Pour une décision engageant une activité professionnelle, un secret protégé ou une procédure, faites examiner votre situation et les contrats concernés. Les sources ci-dessous permettent de vérifier les points documentaires ; nos exemples restent hypothétiques.