Les questions-réponses de la CNIL sur l’utilisation d’un système d’IA générative

Les systèmes d’IA générative génèrent automatiquement des contenus dont la qualité a récemment progressé de manière spectaculaire : ils sont capables de créer des productions diversifiées, personnalisées et réalistes. Schématiquement, l’IA générative permet trois catégories de tâches :

• La génération de contenu à partir d’une instruction générale (telle que la création d’image, de texte ou de code informatique),
• Le retraitement de contenus préexistants (tel que la correction ou la traduction de textes),
• L’analyse de données (telle que le tri ou la synthèse de documents).

Son utilisation a généralement pour objectif d’accroître la créativité et la productivité des personnes qui l’utilisent, ou servir à construire d’autres systèmes.

Les modèles génératifs ne sont pas des bases de connaissance : ils obéissent à une logique probabiliste, ce qui signifie qu’ils ne génèrent que le résultat qui sera statistiquement le plus probable compte tenu des données sur lesquelles ils ont été entraînés. Ces systèmes peuvent générer des résultats inexacts qui peuvent, pourtant, paraître plausibles (on parle alors souvent d’hallucinations). Cela pourra survenir lorsqu’ils sont interrogés à propos d’informations qui ne sont pas présentes dans leurs données d’entraînement. C’est par exemple le cas sur des évènements postérieurs à leur développement, ces systèmes n’étant pas toujours reliés à des bases de connaissances actualisées. 

Une confiance excessive dans les résultats produits par un système d'IA générative sans une vérification appropriée peut donc conduire à des décisions erronées ou à des conclusions incorrectes.

Ce fonctionnement complique la compréhension et l’explicabilité de ces systèmes (on parle alors d’effet « boîte noire »). Pour les fournisseurs de ces systèmes, cela complexifie la détection et la prévention d’éventuels biais. Pour leurs utilisateurs, cela pose de sérieux risques de confiance dans les résultats.

Enfin, les capacités de ces systèmes peuvent conduire à des usages abusifs qu’il convient d’anticiper et de prévenir, tels que la désinformation à travers la production d’hyper-trucages (ou deepfakes), la génération de codes malveillants, ou encore la fourniture d’informations permettant des activités illégales, dangereuses ou malveillantes (telles que la conception d’explosifs).

La première question à se poser porte sur le type de modèle ou de système d’IA générative :

• utiliser un système ou un modèle sur étagère
  
  Qu’il soit dit « propriétaire » (c’est-à-dire commercialisé par son fournisseur) ou en source ouverte (open source), un système ou modèle sur étagère peut être plus ou moins généraliste. Il peut par conséquent s’adapter plus ou moins bien à des tâches spécifiques. Dans certains cas, il est possible de l’orienter vers une tâche ou un contexte spécifique, par exemple au moyen de consignes préalables (ou pre-prompt), avant de générer la réponse principale. Ces consignes peuvent être intégrées au système ou fournies par l’utilisateur, et ne nécessitent pas de ressources particulières.
  
  ou
   
• développer son propre modèle d’IA générative
  
  Enfin, il est aussi possible de ne pas utiliser un modèle d’IA pré-entraîné mais d’entraîner son propre modèle, avant de l’intégrer à son système. Aujourd’hui, seul un nombre très limité d’acteurs est en mesure de réaliser ces opérations (compte tenu des ressources et compétences requises).
  
  Ensuite, et quel que soit le type de modèle ou de système choisi, il est possible d’en améliorer les performances en recourant en options suivantes :
   
• connecter le système à une base de connaissance (RAG)
  
  La génération augmentée de récupération (Retrieval Augmented Generation ou RAG) consiste à intégrer un mécanisme de recherche d'informations dans une base de données vectorisée (ou embedding). Elle permet de produire des réponses enrichies par des données externes, potentiellement plus spécifiques et plus faciles à actualiser que le modèle lui-même. Cette méthode requiert davantage de ressources et de compétences que le recours à un simple système ou modèle sur étagère, mais se montre plus facile à adapter et permet davantage de traçabilité des informations contenues dans les réponses.
  
  et/ou
   
• ajuster un modèle pré-entraîné sur des données spécifique (fine-tuning)
  
  Le fine-tuning consiste à modifier les paramètres (poids) d’un modèle tout en conservant son architecture principale (par exemple celle d’un grand modèle de langue pré-entraîné dans certaines langues). Cette méthode permet d'améliorer ses performances dans un domaine donné ou pour des requêtes spécifiques. Elle requiert des ressources importantes, notamment en termes de capacités de calcul.

Il est recommandé de partir de besoins concrets pour choisir le système le plus adapté et de tenir compte des risques encourus, non seulement du fait des usages poursuivis mais aussi des limitations du système envisagé. Par exemple, faciliter la rédaction de certains contenus en mettant un agent conversationnel à la disposition de ses salariés présentera moins de risques que l’utilisation d’un système pour aider à la prise de décision à l’égard de clients, candidats ou citoyens. Le système, l’approche choisie, et le mode de déploiement choisis devraient ainsi faire l’objet d’un plus haut niveau d’exigence dans le second cas.

En fonction des usages envisagés et de leur sensibilité, il convient de vérifier :

• sa sécurité générale, par exemple s’assurer que l’outil est développé pour refuser de répondre à des requêtes malveillantes, toxiques ou illicites ;
   
• sa pertinence pour le besoin spécifiquement identifié, par exemple en privilégiant des systèmes limitant les hallucinations, en citant leurs sources, en filtrant les sorties, ou ayant été entraînés ou ajustés (fine-tunés) sur une base de données de qualité et spécifique ;
   
• sa robustesse, par exemple en privilégiant les systèmes déjà testés et éprouvés pour les tâches envisagées ;
   
• L’absence de biais éventuels, par exemple de biais discriminatoires qui pourraient notamment résulter d’un manque de diversité des données d’entraînement ;
   
• sa conformité aux règles applicables, en prenant connaissance de sa licence d’utilisation ou des informations sur les données d’entrainement, qu’il s’agisse d’un modèle propriétaire ou en source ouverte.

Pour cela, le plus simple est généralement d’avoir accès à la documentation du système et de demander, le cas échéant, des évaluations externes. Dans ce dernier cas, si nécessaire et si réalisable, il peut être pertinent de conduire ou commander une évaluation sur mesure pour l’usage envisagé.

Les systèmes d’IA générative peuvent être fournis « sur site » (« on premise »), sur une infrastructure cloud hébergée ou à la requête via des API (Application Programming Interface). Le choix d’un mode de déploiement dépend du cas d’usage et des données utilisées en entrée.

Pour des usages non confidentiels, l’utilisation d’un service grand public auquel l’accès est permis grâce à des adresses électroniques professionnelles dédiées pourra être envisagée avec des garanties appropriées (à condition d’éviter la création de compte avec des adresses électroniques personnelles et, le cas échéant, en désactivant la possibilité pour le fournisseur du système de réutiliser les données d’usage).

Si l’utilisation envisagée consiste à fournir des données personnelles (données des clients ou des collaborateurs) ou de la documentation sensible ou stratégique (par exemple pour le RAG), il semble généralement plus opportun et plus sécurisé de privilégier le déploiement de solutions « sur site » (on premise) qui présentent l’avantage de limiter les risques d’extraction de données auprès d’un tiers (notamment détaillés dans les recommandations de sécurité de l’ANSSI pour un système d’IA générative).

Néanmoins, compte tenu du coût que représente l’installation et l’opération d’un système « sur site », il sera souvent plus aisé de recourir à un système hébergé dans une infrastructure distante (cloud ou off premise). Dans ce cas, il sera nécessaire de sécuriser le recours à une infrastructure externe par le biais d’un contrat de sous-traitance avec l’hébergeur du système et, le cas échéant, avec le fournisseur du système d’IA. Ce contrat devra bien préciser les périmètres de responsabilité et les accès autorisés aux données traitées. A cet égard, rien n’interdit à des entreprises de petite taille ou à collectivités territoriales disposant de ressources limitées de recourir à une infrastructure mutualisée, dès lors que les transferts de données sont encadrés et leur sécurité assurée.

De plus, si les données personnelles sont susceptibles d’être transférées en dehors de l’Union européenne (par exemple parce que l’infrastructure d’hébergement est située hors de l’UE ou qu’elle est opérée par un fournisseur non-européen), l’entité utilisatrice devra, en complément, encadrer leur traitement par leur destinataire.

Enfin, s’il est envisagé d’utiliser un système sous forme d’API, il faut souligner que la maîtrise du système est alors quasi exclusivement dans les mains du fournisseur. Il convient donc d’être particulièrement vigilant sur les données soumises au système d’IA, en évitant autant que possible la saisie de données personnelles. Il faut également apporter une attention particulière aux conditions contractuelles et notamment aux questions de transferts de données en dehors de l’UE.

La mise en œuvre de ce type de système doit être précédée d'une analyse des risques et d'une stratégie de gouvernance claire. En particulier, l’organisme décidant de déployer un système doit veiller à sa conformité au RGPD.

Quelle que soit l’utilisation envisagée, celui-ci doit notamment :

• s’interroger sur son rôle et celui du fournisseur vis-à-vis des traitements de données personnelles, le cas échéant en passant un contrat de sous-traitance ou un accord de responsabilité conjointe avec ce dernier, voire en encadrant le transfert de données en dehors de l’Union européenne comme précédemment évoqué ;
   
• veiller à la sécurité des données qu’il fournit dans le cadre du développement (par exemple pour le développement d’un modèle ajusté sur mesure) ou dans le cadre du déploiement (par exemple en décidant de s’opposer à la réutilisation des données d’usage par le fournisseur du système, voire à l’enregistrement de l’historique).
  
  Pour en savoir plus : voir les recommandations de sécurité de l’ANSSI pour un système d’IA générative.

Plus généralement, il est recommandé à tout organisme d’encadrer l’utilisation d’un système d’IA générative par des politiques ou chartes internes, définissant clairement les usages autorisés et les usages interdits.

En fonction du mode de déploiement retenu, il conviendra en particulier d’interdire la fourniture de certaines données confidentielles (par exemple couvertes par le secret industriel et commercial) ou personnelles. 

Par exemple, lorsque les données sont susceptibles d’être réutilisées par le fournisseur (conformément à ses conditions générales d’utilisation), l’organisme utilisateur devra mener une analyse au cas par cas pour déterminer s’il doit ou non interdire la fourniture de toute donnée personnelle, ou seulement certaines catégories.

À l’inverse, de telles interdictions ne seront pas nécessaires dans le cas d’un déploiement sur site (on premise) où aucune réutilisation des données par le fournisseur n’est possible.

Un cas intermédiaire pourra consister à ne permettre l’utilisation de ces systèmes que sur la base de données librement accessibles. Attention toutefois, la réutilisation de ces données librement accessibles par le fournisseur du système d’IA n’est pas pour autant possible dans tous les cas. Ce dernier devra le déterminer au terme d’une analyse dédiée.

Outre le besoin d’intelligibilité et d’accessibilité de ces documents, il est recommandé de former les utilisateurs de façon adaptée et de mener des contrôles réguliers.

Dans le cas général, c’est l’organisme utilisateur qui engagera sa responsabilité légale en cas de mauvaise utilisation de l’IA par son personnel. Il est donc recommandé de familiariser les utilisateurs finaux avec le fonctionnement et les limites de ces systèmes (la manière dont sont produites les sorties, les éventuels transferts de données), ainsi que les usages autorisés et les usages interdits.

Les utilisateurs finaux devraient être responsabilisés quant à l’usage qu’ils feront de ces outils, en les incitant à vérifier les données fournies en entrée et la qualité des sorties (par exemple par des formations obligatoires préalables à l’utilisation de ces systèmes).

S’agissant des données fournies en entrée du système (dans le prompt ou invite), les utilisateurs finaux ne devraient soumettre que des informations qu’ils sont autorisés à partager. Par exemple, ne jamais partager d’informations confidentielles telles que des données personnelles, des données de l’entreprise ou de l’administration (en particulier lorsqu’elles sont couvertes par un secret comme le secret des affaires ou des obligations de déontologie) lors de l’utilisation d’un service grand public. L’organisme pourrait même prévoir des modèles d’entrée ou « prompts types » directement accessibles dans l’outil pour inciter les utilisateurs finaux à réaliser des tâches bien identifiées et éprouvées.

S’agissant des sorties générées par le système, les utilisateurs finaux devraient toujours porter un regard critique et vérifier :

• qu’elles sont exactes ou de bonne qualité (en particulier en l’absence de sources, par exemple à travers des recherches contrefactuelles) ;
   
• qu’il ne s’agit pas d’un plagiat (par exemple, en cas de soupçon élevé de régurgitation d’une œuvre protégée, en essayant de retrouver l’œuvre source) ;
   
• qu’elles n’engendrent pas de biais susceptibles de mener à des discriminations (par exemple en reproduisant un stéréotype).

Ils devraient enfin être alertés sur le risque de perte de confiance ou de compétence associé à une utilisation excessive du système (également appelée « biais d’automatisation »). Afin d’éviter toute perte de contrôle humain, une bonne pratique consiste à ne jamais reproduire telles quelles les sorties de ces systèmes y compris lorsqu’ils intègrent des filtres censés prévenir la génération de contenus inappropriés (puisque ces systèmes ne sont jamais infaillibles).

À cet égard, l’intégration de briques d’IA générative dans un système d’information (SI) devrait être pensée avec des éléments de design informant clairement les utilisateurs de l’origine de la proposition, leur rappelant qu’il leur revient de ne pas prendre « telle quelle » la proposition. Par exemple, le système peut proposer pour chaque question au moins deux réponses, ce qui permet à l’opérateur humain de sélectionner les éléments pertinents de chaque réponse pour consolider la sienne.

Le délégué à la protection des données (DPO) peut utilement jouer un rôle à cet égard dès lors qu’il est déjà concerné par les enjeux de protection des données afférant à ces systèmes, le cas échéant en articulation avec le responsable de la sécurité des systèmes d’information (RSSI).

Cette désignation peut également permettre de proposer aux utilisateurs finaux un point de contact pour remonter des problèmes ou des difficultés d’ordre éthique. Si les problèmes le justifient, le référent devrait pouvoir alerter l’organisme sur les risques pour envisager une évolution du système ou demander au fournisseur du système des modifications lorsqu’il est le seul à pouvoir les prendre en compte.

En fonction de la sensibilité des usages, il peut de plus être pertinent d’envisager des contrôles réguliers pour s’assurer du bon respect des règles et bonnes pratiques préconisées. En tout état de cause, lors des premiers mois et années de l’utilisation des IA, il est recommandé de recueillir régulièrement l’avis des utilisateurs finaux sur l’utilité et les limites du système. Cette enquête peut aussi être étendue aux éventuels interlocuteurs de l’organisme susceptibles d’être impactés par l’usage de l’IA.

Enfin, dans des cas d’usages particulièrement sensibles, il est recommandé d’envisager la création d’un comité éthique ou la désignation d’un référent pour garantir le respect des règles et bonnes pratiques identifiées. En effet, bénéficier d’un regard externe aux équipes opérationnelles permet d’identifier certains risques qui peuvent être ignorés ou minimisés sinon (biais, effets indésirables, etc.). Ce comité ou ce référent devrait donner un avis formel en amont du déploiement du système d’IA ou d’une nouvelle utilisation et être régulièrement informé, par exemple à l’occasion d’un bilan annuel. 

En ce qui concerne la conformité au RGPD, la CNIL a publié des recommandations sur la constitution de bases de données et l’entraînement de systèmes d’IA. La plupart des systèmes d’IA générative ont été configurés en utilisant des données personnelles : en tant qu’utilisateur ou intégrateur d’un système d’IA générative, il vous revient donc d’interroger le fournisseur sur la conformité de son système au RGPD et le respect de ces recommandations.

Ces recommandations s’appliquent également à tout déployeur de système d’IA qui traiterait des données personnelles dans le cadre de son développement, de sa maintenance ou de son amélioration. 

Par exemple, elles s’appliquent :

• au déployeur qui affine (« fine-tunes ») le système avec ses propres données, celui-ci en devenant alors responsable, y compris en tant que fournisseur au titre du règlement sur l’IA, mais seulement pour ce qui concerne cet affinage (fine-tuning). 
   
• le déployeur qui choisit de connecter le système à sa propre base de connaissance (RAG) sera lui aussi responsable de son traitement lorsqu’elle contient des données personnelles.

D’autres recommandations seront publiées dans les prochains mois par la CNIL. Dans l’attente de leur publication, il est recommandé d’associer le délégué à la protection des données (DPO), et le cas échéant, de réaliser une analyse d’impact relative à la protection des données (AIPD).

Le règlement sur l’intelligence artificielle entre en vigueur à compter du 1er août 2024. Il s’intéresse aux risques que les systèmes d’IA font peser pour la santé, la sécurité, et les droits fondamentaux des personnes affectées. Le règlement classe les systèmes en quatre niveaux de risque en établissant des règles différentes pour chacun d'entre eux (allant de l’interdiction pure et simple à des exigences de transparence lors de leur utilisation). 

L’utilisation de systèmes d’IA générative, lorsqu’ils ne sont pas intégrés à un système à haut-risque (qui font alors l’objet d’exigences supplémentaires), est encadrée au titre des systèmes d’IA à usage général justifiant des exigences de transparence accrues (Chapitre IV), ainsi que les modèles sous-jacents au titre des modèles d’IA à usage général (Chapitre V).

Le règlement sur l’IA prévoit notamment que les organismes qui déploient de tels systèmes soient transparents avec les utilisateurs quant au fait qu’ils y ont recours. Les systèmes conçus pour agir directement avec des personnes doivent ainsi être développés de manière à ce que ces dernières soient informées de ce qu’elles interagissent avec un système d’IA. Les utilisateurs de ces systèmes doivent quant à eux indiquer au public que leurs hyper-trucages (deepfakes) ou les textes qu’ils publient ont été générés par ce moyen.