De nombreuses entreprises suisses font tourner discrètement des agents IA qui touchent des données personnelles de résidents UE — qualification des demandes entrantes, traitement des tickets de support client, tri de candidatures. La plupart n’ont guère vérifié si tout cela était défendable au regard du RGPD.
C’est une lacune qu’il est possible de combler, à condition de savoir quelles questions poser avant le déploiement — et non après avoir reçu un courrier d’une autorité de contrôle.
Cet article met en regard les principales obligations RGPD et les déploiements d’agents les plus courants dans les entreprises suisses, et montre à quoi ressemble concrètement un système “conçu pour être conforme”.
Pourquoi “entreprise suisse” ne signifie pas “le RGPD ne s’applique pas”
La Suisse n’est pas dans l’UE. Mais le champ d’application territorial du RGPD (article 3) s’étend à toute organisation qui traite des données personnelles de personnes situées dans l’UE dans le cadre de l’offre de biens ou de services, ou du suivi de comportements. Si votre agent gère des demandes de prospects allemands ou français, traite des commandes de clients italiens, ou mène des actions d’outreach vers un marché UE, le RGPD s’applique — quel que soit le lieu où se trouvent vos serveurs.
La nLPD suisse s’applique en parallèle et vise spécifiquement les résidents en Suisse. nLPD et RGPD partagent les principes de minimisation des données et de limitation des finalités, mais il existe une différence structurelle importante : la nLPD n’exige pas des responsables du secteur privé qu’ils identifient une base légale spécifique pour chaque activité de traitement — le traitement est généralement licite sauf s’il porte atteinte aux droits de la personnalité. Concevoir dans le respect du RGPD couvre donc la plupart des obligations nLPD, mais une revue nLPD dédiée est conseillée en complément. Les spécificités de la nLPD sont traitées dans l’article complémentaire sur la protection des données en Suisse.
Pour l’instant : partez du principe que le RGPD s’applique à votre agent dès qu’il touche des données de personnes situées dans l’UE. La question est de savoir ce que cela signifie opérationnellement.
Ce que “traiter des données personnelles” signifie au sein d’un agent
Un agent IA traite des données personnelles dès qu’il lit des e-mails, des enregistrements CRM ou des transcriptions de conversations contenant des noms et des identifiants ; génère des sorties faisant référence à des personnes physiques ; stocke des données en mémoire, dans des vector stores ou dans des logs ; ou appelle des API tierces qui reçoivent ces données.
Chacune de ces actions constitue un “traitement” au sens de l’article 4(2) du RGPD. Le règlement ne distingue pas si cela se produit intentionnellement ou incidemment — un agent de support qui enregistre chaque conversation est soumis aux mêmes règles qu’une base de données maintenue manuellement.
La plupart des déploiements d’agents en touchent au moins trois simultanément. Ce n’est pas une raison d’éviter les agents. C’est une raison de les concevoir délibérément.
Les quatre obligations les plus importantes pour les déploiements d’agents IA
1. Base légale — savoir pourquoi vous êtes autorisé à traiter
Chaque opération de traitement nécessite une base légale au titre de l’article 6. Pour les agents IA en contexte professionnel, trois bases sont pertinentes :
- Intérêts légitimes (art. 6(1)(f)) — la base la plus courante pour les cas d’usage B2B. Requiert une analyse d’intérêts légitimes (LIA) mettant en balance vos intérêts et les droits de la personne concernée. Généralement défendable pour les actions d’outreach commercial B2B et les agents d’opérations internes.
- Exécution d’un contrat (art. 6(1)(b)) — lorsque le traitement est nécessaire à la fourniture d’un service contractualisé (par exemple, un agent de commandes traitant l’adresse d’un client pour exécuter un achat).
- Consentement (art. 6(1)(a)) — nécessaire pour le marketing B2C soumis à l’ePrivacy, et pour les cas d’usage particulièrement sensibles. Doit être libre, spécifique et révocable.
L’erreur classique consiste à utiliser une base unique et vague (“intérêts légitimes”) pour toutes les activités de traitement sans conduire la LIA. Cela ne résiste pas à un contrôle. Chaque workflow d’agent avec des entrées et sorties de données distinctes devrait avoir sa base légale documentée séparément.
2. Contrats de sous-traitance avec chaque fournisseur IA de la chaîne
Lorsque votre agent envoie des données personnelles à une API LLM — OpenAI, Anthropic, Google ou tout autre — ce fournisseur devient un sous-traitant au sens de l’article 28. Vous êtes tenu de disposer d’un accord de traitement des données (DPA) signé avec lui avant tout flux de données personnelles.
La plupart des grands fournisseurs LLM proposent un DPA, mais vous devez souvent le demander activement ou souscrire au bon niveau de service. Les conditions générales d’utilisation de l’API grand public ne sont généralement pas suffisantes. Vérifiez que le DPA couvre vos catégories de données, inclut les listes de sous-traitants ultérieurs et que la politique de conservation des entrées du fournisseur est alignée sur la vôtre.
Cela s’étend à toute la chaîne de sous-traitance. Les plateformes d’orchestration, les bases de données vectorielles tierces et les services de tool-calling managés nécessitent chacun un DPA s’ils reçoivent des données personnelles — ou une justification documentée pour laquelle ils n’en ont pas besoin (généralement parce que vous avez anonymisé les données en amont).
3. Résidence des données — où vivent réellement les données de votre agent
La Suisse et l’UE bénéficient d’une décision d’adéquation (confirmée en dernier lieu le 15 janvier 2024) qui permet le flux libre de données depuis l’UE/EEE vers la Suisse sans garanties supplémentaires. Les transferts entre les deux sont généralement sans problème. Mais si votre infrastructure d’agent tourne sur des services cloud américains ou fait appel à des API LLM américaines, vous effectuez des transferts internationaux vers un pays tiers — et chacun nécessite un mécanisme de transfert, généralement des Clauses Contractuelles Types (CCT) intégrées dans le DPA.
Les étapes pratiques : cartographiez où les données personnelles circulent de l’ingestion à chaque appel d’API et couche de stockage ; confirmez que chaque passage transfrontalier est couvert par une décision d’adéquation, des CCT ou des Règles d’Entreprise Contraignantes ; et documentez-le. Si une autorité de contrôle vous demande de démontrer votre conformité, cette carte de flux de données est la première chose qu’elle voudra voir.
Héberger l’infrastructure d’agent en Suisse ou dans l’UE supprime la majeure partie de cette complexité — l’une des raisons pour lesquelles les clients ayant des exigences de traitement de données sensibles préfèrent souvent les déploiements suisses ou en région UE aux options américaines par défaut.
4. AIPD — quand une évaluation formelle des risques est nécessaire
Une Analyse d’Impact relative à la Protection des Données (AIPD) est requise en vertu de l’article 35 chaque fois que le traitement “est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques”. Pour les déploiements d’agents IA, les déclencheurs incluent :
- Décisions automatisées ayant des effets significatifs sur les personnes (article 22) — un agent de présélection de candidatures qui classe ou rejette des candidats, ou tout agent lié au crédit
- Données de catégorie particulière à grande échelle (santé, biométrie, opinions politiques)
- Surveillance systématique du comportement des personnes
- Traitement de données personnelles à grande échelle
Menée correctement, une AIPD vous oblige à articuler des risques précis et les mesures qui les atténuent. La question de l’article 22 mérite une attention particulière. Lorsqu’une décision automatisée produit des effets juridiques ou des effets similaires significatifs sur une personne, celle-ci a généralement le droit de ne pas faire l’objet d’un traitement entièrement automatisé. En vertu de l’article 22(3), même lorsque des exceptions s’appliquent — nécessité contractuelle, autorisation légale ou consentement explicite — des garanties appropriées sont obligatoires, notamment le droit pour la personne d’obtenir une intervention humaine, d’exprimer son point de vue et de contester la décision. Dans la plupart des contextes de déploiement, intégrer une étape de révision humaine est la façon la plus simple de satisfaire à cette exigence.
Qui est responsable : responsable du traitement, sous-traitant ou les deux ?
Si vous déployez un agent pour vos propres opérations, vous êtes le responsable du traitement — vous déterminez les finalités et les moyens du traitement. Les fournisseurs LLM et les autres services que vous appelez sont vos sous-traitants.
Si vous êtes un prestataire de services déployant un agent pour le compte d’un client, la répartition responsable/sous-traitant dépend de la structure contractuelle. Cela importe car les responsables du traitement portent la responsabilité RGPD principale — répondre aux demandes d’exercice de droits, notifier les autorités de contrôle en cas de violation. Formalisez-le par écrit. Un accord de co-responsabilité au titre de l’article 26 est fréquemment négligé dans les projets d’agents et entraîne ses propres obligations.
À quoi ressemble une architecture d’agent conforme
Une bonne conformité RGPD pour un agent IA ne repose pas principalement sur des documents juridiques. Elle est intégrée dans la conception du système :
- Minimisez les données à l’ingestion. Supprimez ou pseudonymisez les identifiants personnels avant qu’ils n’atteignent le LLM, dans la mesure où le cas d’usage le permet. Un agent de triage de support n’a souvent pas besoin du nom complet d’un client pour classer un ticket.
- Journalisez de façon ciblée. Les frameworks d’agents qui enregistrent chaque prompt et chaque réponse par défaut créent des risques de conservation. Configurez des fenêtres de conservation et décidez en amont quels logs sont opérationnellement nécessaires.
- Documentez les flux de données avant de construire. Un diagramme d’une page montrant ce qui entre dans l’agent, quelles API il appelle, ce qu’il stocke et où vont les sorties constitue à la fois un document de conception et le fondement de votre registre des activités de traitement au titre de l’article 30.
- Intégrez des points de contrôle humain partout où la sortie de l’agent affecte significativement une personne. C’est particulièrement important pour les cas d’usage en recrutement, crédit et santé.
La conformité RGPD s’inscrit dans le cadre plus large de la gouvernance des agents IA — comment vous supervisez les agents en production, gérez les mises à jour de modèles et traitez les défaillances. Les contrôles de sécurité qui préviennent l’exfiltration de données ou le prompt injection sont également directement pertinents ; voir l’article connexe sur les risques de sécurité des agents IA.
Le RGPD n’est pas la seule réglementation en jeu
L’EU AI Act ajoute un cadre de risque à niveaux affectant certains déploiements indépendamment du droit à la protection des données — en particulier les systèmes utilisés dans le recrutement, le crédit ou les forces de l’ordre. Pour une analyse opérationnelle de ce que cela signifie, l’article sur l’EU AI Act et les agents IA couvre la logique de classification et le calendrier de conformité.
Les projets d’agents IA conçus avec une structure réglementaire dès le départ sont plus rapides à déployer, plus faciles à auditer et bien moins susceptibles de nécessiter des corrections coûteuses par la suite.
Ce qu’un déploiement défendable requiert concrètement
Le niveau RGPD minimum pour un agent IA touchant des données personnelles UE :
- Une base légale documentée pour chaque activité de traitement distincte
- Un DPA signé avec chaque fournisseur IA et sous-traitant ultérieur qui reçoit des données personnelles
- Une carte des flux de données couvrant l’ingestion, le traitement, le stockage et le transfert
- Une AIPD lorsque le traitement est à haut risque (décisions automatisées, données de catégorie particulière, grande échelle)
- Une politique de conservation appliquée aux logs, à la mémoire et aux sorties
- Une révision humaine intégrée dans tout workflow comportant des décisions significatives au niveau individuel
Rien de tout cela n’est extraordinaire. Cela suppose en revanche de traiter la conformité comme une phase de conception — et non comme une vérification post-lancement.
Prêt à construire un agent que votre service juridique peut valider ?
Orange ITS développe des agents IA sur mesure pour les entreprises suisses et européennes — l’architecture de conformité fait partie de chaque projet, ce n’est pas un supplément optionnel. Si vous évaluez un déploiement et souhaitez une vision claire des expositions RGPD, réservez un appel de 30 minutes avec notre équipe. Nous cartographierons votre cas d’usage par rapport aux obligations pertinentes et vous dirons honnêtement ce qui doit être en place avant la mise en production.