← Zurück zum Blog

AIPD en Suisse : exécution, preuve et réduction du risque Cloud Act

5. September 2026
AIPD en Suisse : exécution, preuve et réduction du risque Cloud Act

Dans les autres cas, une évaluation simplifiée reste recommandée. La première étape concrète : cartographier les flux de données et désigner un responsable IA ou un délégué à la protection des données avant tout déploiement.


En bref:

  • Si l'IA traite des données personnelles identifiables ou affecte des populations vulnérables, une évaluation d'impact est généralement requise.
  • La signature d’un DPA, la cartographie des flux, et la mise en place de mesures techniques pour atténuer les risques doivent être effectuées avant tout déploiement.
  • Une responsabilité claire doit être désignée, notamment un délégué à la protection des données, pour garantir la traçabilité et la conformité continue.
  • L’hébergement en Suisse peut réduire l’exposition au Cloud Act américain, mais des clauses contractuelles renforcées restent indispensables.
  • La plateforme Nectos facilite la production de preuves pour l’AIPD, en centralisant logs, gestion des accès et hébergement sécurisé en Suisse.

Table des matières

Panorama réglementaire applicable en Suisse pour l'évaluation d'impact de l'IA

La Suisse ne dispose pas encore d'une loi horizontale sur l'intelligence artificielle comparable au règlement européen. Elle mobilise à la place la loi sur la protection des données (LPD), complétée par des engagements internationaux qui prendront progressivement forme dans le droit interne.

La LPD reste le socle juridique le plus contraignant aujourd'hui. Ses articles 19, 21 et 22 imposent une obligation d'information sur le traitement automatisé et rendent l'analyse d'impact relative à la protection des données (AIPD) obligatoire dès qu'un traitement présente un risque élevé pour les droits de la personnalité. Un système de recrutement automatisé ou un outil de scoring client entrent typiquement dans cette catégorie.

La Suisse a signé la convention-cadre du Conseil de l'Europe sur l'intelligence artificielle, un traité international qui engage les États signataires à adapter leur droit national aux principes de respect des droits humains, de la démocratie et de l'État de droit dans l'usage de l'IA. La mise en œuvre nationale suisse est en cours ; elle façonnera vraisemblablement les futures obligations sectorielles.

Trois autres repères structurent la conformité pratique :

  • L'application extraterritoriale de l'AI Act européen peut concerner une entreprise suisse dès qu'elle propose ses systèmes d'IA sur le marché européen, indépendamment de son siège.
  • Les lignes directrices de l'EDPB (Comité européen de la protection des données) offrent une grille de lecture technique, notamment sur l'anonymisation et le traitement des données d'entraînement.
  • Les recommandations de l'OCDE documentent des approches suisses concrètes pour un usage responsable de l'IA, utiles comme référentiel de bonnes pratiques plutôt que comme obligation juridique.

L'Office fédéral de la communication (BAKOM) confirme cette approche sectorielle suisse : plutôt que de créer un texte unique, la Confédération privilégie l'adaptation des lois existantes secteur par secteur, ce qui exige de croiser plusieurs sources normatives pour chaque projet.

Quand lancer une AIPD ou une FRIA ? Les critères qui tranchent

Certains signaux déclenchent presque automatiquement une obligation d'évaluation. Un projet d'IA qui repose sur le profilage de personnes, sur des décisions automatisées produisant des effets juridiques, sur des données sensibles (santé, origine, opinions) ou sur des dispositifs de surveillance franchit généralement le seuil de risque élevé au sens de la LPD.

La distinction entre AIPD et FRIA (évaluation d'impact sur les droits fondamentaux, concept issu des pratiques liées à l'AI Act) n'est pas qu'académique. L'AIPD se concentre sur la protection des données personnelles ; la FRIA élargit le regard à l'ensemble des droits fondamentaux, incluant la non-discrimination et l'accès à des services essentiels. Un guide pratique suisse recommande d'ailleurs d'articuler les deux démarches plutôt que de les traiter séparément, dès qu'un système d'IA a un impact direct sur des personnes.

Voici une check-list en six points pour trancher rapidement en comité de gouvernance :

  1. Cartographie : le système traite-t-il des données personnelles identifiables ou pseudonymisées ?
  2. Finalité : la décision produite affecte-t-elle l'accès à un emploi, un crédit, un soin ou un service public ?
  3. Populations affectées : le système cible-t-il des personnes vulnérables (mineurs, patients, demandeurs d'asile) ?
  4. Fréquence : le traitement est-il ponctuel ou continu, à grande échelle ?
  5. Sensibilité : les données incluent-elles des catégories particulières au sens de la LPD ?
  6. Fournisseur : le système est-il opéré par un tiers situé hors de Suisse, notamment aux États-Unis ?

Conseil de pro : Si trois critères ou plus sur les six sont positifs, ne discutez plus de l'opportunité de l'évaluation. Lancez-la, même en version allégée, et documentez la décision elle-même : un comité qui a délibéré et tranché vaut mieux qu'un silence qu'un régulateur pourrait interpréter comme une négligence.

Comment mener une évaluation d'impact de l'IA étape par étape ?

Une évaluation d'impact de l'IA sérieuse suit un déroulé en cinq phases, chacune produisant un livrable vérifiable. Improviser cette séquence, ou la réduire à un questionnaire rempli en une heure, expose l'entreprise à une AIPD contestable en cas de contrôle du préposé fédéral à la protection des données.

  1. Phase 0, le cadrage. L'équipe projet définit le périmètre exact du système, identifie les parties prenantes internes (métier, juridique, IT, direction) et formule les objectifs métiers en une page. Sans cette étape, l'évaluation part souvent dans plusieurs directions à la fois.
  2. Phase 1, la cartographie des flux. Il s'agit de tracer chaque catégorie de données entrant dans le système, leur origine, leur durée de conservation estimée et leur destination, y compris les sous-traitants et hébergeurs. Un système d'IA qui s'appuie sur un fournisseur cloud américain doit apparaître explicitement ici.
  3. Phase 2, l'analyse des risques. Quatre familles de risques méritent un examen distinct : les biais algorithmiques, le déficit d'explicabilité des décisions, les failles de sécurité technique et les atteintes potentielles à la confidentialité.
  4. Phase 3, les mesures d'atténuation. Chaque risque identifié appelle une réponse concrète, technique ou organisationnelle :
    • Anonymisation ou pseudonymisation renforcée des données d'entraînement.
    • Tests de biais sur des sous-groupes démographiques avant mise en production.
    • Chiffrement des données au repos et en transit.
    • Limitation des accès par rôle et journalisation systématique des consultations.
  5. Phase 4, la documentation formelle. Le projet aboutit à un rapport AIPD (ou FRIA le cas échéant), une entrée dans le registre des traitements, un accord de traitement des données (DPA) signé avec chaque fournisseur, et un calendrier de revue périodique, généralement annuel.

Ce calendrier de revue n'est pas une formalité cosmétique. Un système d'IA évolue, ses modèles sont réentraînés, ses usages s'étendent souvent au-delà du périmètre initial. Une AIPD figée à la date de lancement perd sa valeur probante dès que le système change de nature.

Qui pilote l'évaluation ? Gouvernance et responsabilités internes

La réussite d'une évaluation d'impact tient rarement à la méthodologie seule. Elle tient à la clarté des rôles. Un projet sans responsable désigné produit presque toujours une documentation incomplète, découverte trop tard lors d'un audit ou d'une plainte.

Le délégué à la protection des données (DPO) porte une check-list de tâches à valider avant tout lancement de projet IA, comme le rappellent les guides pratiques destinés aux PME suisses :

  • Vérifier l'existence et la mise à jour du registre des traitements.
  • S'assurer qu'un DPA est signé avec chaque fournisseur technique, y compris les hébergeurs étrangers.
  • Déclencher l'AIPD dès qu'un critère de risque élevé apparaît, sans attendre la mise en production.
  • Documenter les décisions de non-évaluation, quand l'analyse préalable conclut à un risque faible.

Un modèle minimal de gouvernance répartit les responsabilités entre trois niveaux : le comité de direction valide les projets à risque élevé et arbitre les budgets de mise en conformité ; le responsable IA (souvent rattaché à la DSI) coordonne l'exécution technique ; le DPO garde un droit de veto sur toute mise en production sans AIPD validée.

Côté fournisseurs, les clauses contractuelles à exiger systématiquement incluent la localisation précise des données, un droit d'audit régulier, des engagements de sécurité alignés sur des normes reconnues et des SLA (accords de niveau de service) chiffrés en cas d'incident.

Conseil de pro : Il est recommandé d'intégrer une clause de notification d'incident dans chaque contrat fournisseur IA, avec un délai raisonnable qui permet d'informer le préposé fédéral avant que la situation ne vous échappe.

ISO/IEC 42001 et lignes directrices EDPB : quels repères techniques adopter ?

La norme ISO/IEC 42001, publiée pour encadrer les systèmes de management de l'intelligence artificielle, offre une structure utile même sans certification formelle. Elle impose une logique d'amélioration continue proche de celle déjà connue avec l'ISO 27001, ce qui facilite son adoption par des équipes conformité déjà familières de ce référentiel.

L'EDPB a publié des lignes directrices sur l'anonymisation particulièrement pertinentes pour qui entraîne ou ajuste un modèle sur des données européennes ou suisses. Un second document, en consultation sur le web scraping pour l'IA générative, précise les conditions de licéité de la collecte massive de données pour l'entraînement de modèles.

Concrètement, une entreprise suisse gagne à préparer en interne :

  • Un modèle de registre des traitements IA, distinct du registre LPD général.
  • Un gabarit de rapport AIPD réutilisable d'un projet à l'autre.
  • Une grille de critères pour choisir un outil d'audit de biais ou de journalisation, en privilégiant la traçabilité des décisions plutôt que la seule performance prédictive.

Fournisseurs américains et Cloud Act : quels risques transfrontaliers ?

Un fournisseur soumis au droit américain reste théoriquement accessible aux autorités judiciaires des États-Unis via le Cloud Act, même lorsque les données sont physiquement stockées en Europe ou en Suisse. Cette exposition ne dépend pas de la localisation du serveur, mais de la nationalité de l'entité qui l'exploite.

Lien entre le stockage en Suisse et le Cloud Act

Les entreprises suisses qui contractent avec des fournisseurs américains pour leurs outils d'IA affrontent donc un risque structurel que la seule promesse d'un hébergement européen ne suffit pas à neutraliser. Un rapport de l'AI Watch européen sur la stratégie suisse souligne d'ailleurs que l'extraterritorialité des règles étrangères impose aux acteurs suisses des mesures contractuelles et techniques renforcées dès qu'ils opèrent avec l'Union européenne ou les États-Unis.

Quatre leviers réduisent concrètement cette exposition :

  • Chiffrement au repos et en transit, avec des clés gérées par l'entreprise elle-même plutôt que par le fournisseur.
  • Séparation stricte des environnements de données sensibles et de données non critiques, pour limiter le périmètre exposé en cas de demande d'accès.
  • Clauses contractuelles de notification préalable, exigeant que le fournisseur informe le client avant toute transmission de données à une autorité étrangère, dans la mesure où la loi le permet.
  • Recours à des solutions hébergées exclusivement en Suisse, qui écartent structurellement la question de la compétence extraterritoriale américaine.

Un audit juridique préalable, avant toute signature de contrat avec un fournisseur étranger, reste la mesure la plus rentable : elle coûte quelques heures de conseil et évite des mois de remédiation après incident.

Quelles preuves documenter pour une AIPD crédible ?

Un rapport AIPD crédible ne se limite pas à un questionnaire coché. Il s'appuie sur des preuves vérifiables : localisation effective de l'hébergement, journaux d'audit horodatés, gestion granulaire des rôles d'accès, et export possible de ces journaux à des fins de contrôle légal.

Les livrables attendus d'une AIPD bien menée incluent typiquement :

  • Un registre des traitements IA à jour, incluant chaque sous-traitant.
  • Un rapport de synthèse listant les risques identifiés et leur niveau de gravité.
  • Un plan d'atténuation daté, avec responsable et échéance par action.

L'OCDE documente des cas concrets d'approches suisses responsables dans la coopération internationale, une référence utile pour calibrer le niveau d'exigence attendu d'une évaluation d'impact bien construite.

Ce que l'exécution révèle, au-delà de la théorie réglementaire

La littérature sur la conformité IA en Suisse regorge de schémas conceptuels sur les principes éthiques et les grandes orientations stratégiques. Ce qu'elle documente beaucoup moins, c'est l'exécution concrète : qui remplit le registre, qui signe le DPA avec le fournisseur américain, qui relance l'AIPD un an plus tard quand le modèle a changé.

Ce que l'exécution révèle, au-delà de la théorie réglementaire — overview diagram

L'angle mort le plus fréquent n'est pas juridique, il est organisationnel. Des entreprises suisses possèdent une AIPD parfaitement rédigée pour un système qui, six mois plus tard, ne correspond plus à la description initiale. Le modèle a été mis à jour, le fournisseur a changé de sous-traitant, personne n'a rouvert le dossier.

La priorité réelle n'est donc pas de produire le rapport le plus exhaustif possible, mais de construire un processus qui survit au changement : un calendrier de revue tenu, un DPO qui a réellement l'autorité de bloquer une mise en production, des clauses contractuelles vérifiées et non simplement copiées d'un modèle trouvé en ligne. Face à des fournisseurs américains, cette discipline compte double, car l'exposition juridique ne se voit pas tant qu'aucune demande d'accès n'a eu lieu.

— Adopt

Réduire la charge documentaire avec une infrastructure pensée pour la conformité suisse

Une bonne partie du travail d'AIPD consiste à rassembler des preuves : qui a accédé à quelles données, où sont-elles hébergées, quels rôles peuvent les consulter. Nectos a été conçu pour que ces réponses existent nativement, sans reconstruction manuelle à chaque audit.

Nectos

La plateforme héberge ses données sur des serveurs suisses, avec des journaux d'audit et une gestion des rôles par administrateur. Pour une PME, un cabinet de conseil ou un service public qui doit documenter chaque traitement, cette traçabilité native facilite la reconstitution après coup. Les logs peuvent s'exporter à des fins de conformité légale, ce qui aide un DPO chargé de produire un rapport AIPD. La question des biais dans les systèmes d'IA, notamment leur potentiel de discrimination indirecte, reste par ailleurs un chantier que l'entreprise doit traiter en amont, indépendamment de l'outil choisi.

La page sécurité de Nectos détaille les garanties de conformité et d'hébergement disponibles. Une démonstration permet de vérifier, cas par cas, si l'infrastructure correspond au périmètre de votre prochain projet IA.

Sources

Avant de finaliser une AIPD ou une FRIA, quelques sources primaires méritent d'être vérifiées directement, plutôt que reprises de seconde main :

Questions fréquentes

Une AIPD est-elle toujours obligatoire pour un projet d'IA en Suisse ?

Non, elle s'impose seulement quand le traitement présente un risque élevé au sens de la LPD ; dans les autres cas, une évaluation simplifiée documentée reste recommandée.

Quelle différence entre AIPD et FRIA ?

L'AIPD se concentre sur la protection des données personnelles au titre de la LPD, tandis que la FRIA élargit l'analyse à l'ensemble des droits fondamentaux, notion issue des pratiques liées à l'AI Act européen.

Un fournisseur d'IA américain expose-t-il automatiquement mes données ?

Pas automatiquement, mais un fournisseur soumis au droit américain reste juridiquement accessible via le Cloud Act, indépendamment de la localisation physique des serveurs, ce qui justifie des clauses contractuelles renforcées.

Qui doit porter la responsabilité de l'évaluation d'impact en interne ?

Le délégué à la protection des données pilote généralement la démarche, en coordination avec un responsable IA côté technique et une validation finale du comité de direction pour les projets à risque élevé.

Une plateforme hébergée en Suisse suffit-elle à garantir la conformité ?

L'hébergement suisse réduit l'exposition à l'extraterritorialité américaine, comme le propose Nectos avec ses serveurs suisses conformes à la nLPD, mais il ne remplace pas la documentation formelle d'une AIPD adaptée à chaque traitement.