Un article proposé par Astran dans le cadre de « What’s Next, CIO ? », l’observatoire DSI d’Alliancy. Tout au long de l’année, les partenaires de l’observatoire s’engagent à faire progresser l’écosystème du numérique par le partage de pratiques et la confrontation d’avis. Ils se mettent au service de la communauté des CIO pour leur permettre d’anticiper et d’incarner le changement dans leurs organisations.
À l’aube de la mise en production de nombreux systèmes d’intelligence artificielle (IA) générative, assurer la protection de ces derniers incombe aux directions des systèmes d’information. Revenons ici sur les éléments essentiels à prendre en compte.
Lorsque le directeur informatique (CIO) déploie de grands modèles de langage (LLM) en production, il doit se poser en tant que garant de la sûreté (safety) des systèmes d’IA, selon le type de cas d’usage abordé. Pour cela, un certain nombre de sujets fondamentaux doivent être passés en revue, aussi bien en matière de confidentialité et de propriété des données alimentant le LLM, que de nouvelles failles potentielles de cybersécurité ou de surveillance des biais du système.
SURVEILLANCE DES FAILLES DE SÉCURITÉ
Le CIO doit être vigilant à plusieurs types d’attaques cyber, qui peuvent être particulièrement dévastatrices lorsqu’un LLM est en production :
Attaque d’extraction : en interrogeant le modèle de manière répétée, des attaquants pourraient extraire des informations sensibles présentes dans les données d’entraînement.
Attaque d’inversion de modèle : des cybercriminels peuvent essayer de rétroconcevoir le modèle pour déduire certaines caractéristiques des données,
comme des attributs privés des données d’entraînement, ce qui peut occasionner des fuites d’informations confidentielles ou personnelles.
Empoisonnement des données du modèle : des adversaires peuvent injecter des données malveillantes dans l’ensemble d’entraînement pour altérer le comportement du modèle et introduire des biais.
Attaque d’injection de prompts : un pirate informatique pourrait concevoir des prompts pour manipuler les réponses du modèle et obtenir des informations sensibles, ou provoquer un comportement nuisible de l’IA pour votre entreprise.
Si ces attaques sont très spécifiques aux LLM, les bonnes pratiques de sécurité de l’infrastructure et des API restent également parfaitement applicables. C’est le cas notamment pour éviter une attaque via les API du modèle (déni de service distribué ou extraction d’informations) ou une usurpation des facteurs d’authentification.
PROPRIÉTÉ ET CONFIDENTIALITÉ DES DONNÉES
Le CIO est également responsable des aspects technologiques de la protection des données qui servent à entraîner le LLM. Il travaille avec la direction juridique pour s’assurer de la provenance et de la propriété des données qui nourrissent le modèle (et éviter une violation du droit d’auteur), mais aussi pour garantir la protection suffisante des données stratégiques de l’entreprise et des données réglementées (données personnelles, données de santé).
Compte tenu de la faible maturité des solutions cherchant à protéger les données des LLM, il est essentiel de procéder à un tri des données, à leur anonymisation lorsque c’est nécessaire, et à un contrôle rigoureux, notamment lorsque ces données sont déversées automatiquement depuis des systèmes existants de l’entreprise.
CONFORMITÉ, BIAIS ET ÉQUITÉ DU MODÈLE
Si le CIO est sollicité pour une mise en production d’un LLM dans un domaine sensible (par exemple le recrutement, les décisions dans l’assurance santé, l’allocation de crédits), il doit impérativement avertir la direction juridique afin de s’assurer de la conformité du cas d’usage à la loi européenne sur l’intelligence artificielle (l’AI Act). En effet, l’AI Act classe les cas d’usage selon leur niveau de risque, certains cas étant interdits et d’autres, très réglementés.
Une fois cette vérification effectuée, le CIO doit rappeler aux équipes métiers de se pencher sur les algorithmes utilisés et de tester leurs résultats afin de s’assurer, par exemple dans le domaine des ressources humaines, que les algorithmes n’introduisent pas de biais non souhaitables. Il peut notamment suggérer qu’une période de proof of concept suffisamment longue ait lieu, afin de pouvoir collecter les résultats et s’assurer de l’équité du modèle.
ERREURS ET IMAGINATION DU MODÈLE
Le CIO, en tant que garant technologique, doit impérativement rappeler aux équipes métiers les marges d’erreurs et d’invention des modèles de LLM (même lorsqu’ils sont bridés). Si les résultats ne sont pas du ressort du CIO, s’il ressent que la maturité des équipes métiers est insuffisante ou que l’usage va être extrêmement stratégique (recherche de médicaments, optimisation des routes de navires, etc.), il doit s’assurer que les personnes autour de la table – d’autant plus si elles sont décisionnaires – ont bien conscience de ce risque d’erreur.
DÉPENDANCE À DES TIERS ET VULNÉRABILITÉS
Là, le CIO est en terrain connu, puisque c’est la question qui se pose à chaque adoption d’un outil technologique. Et, nous sommes, bien en plein coeur de ses responsabilités. Si l’entreprise souhaite faire appel à des LLM tiers (OpenAI, Google, Microsoft), les risques habituels liés à la chaîne d’approvisionnement s’appliquent : prédictibilité du coût du service, dépendance aux fournisseurs externes, variation dans le temps du prix du service, gestion des versions, préparation de la réversibilité en cas de désactivation du modèle et, bien sûr, risques de backdoor et de vulnérabilités non maîtrisées par le fournisseur.
Tous ces conseils ne s’appliquent parfaitement que dans le monde idéal où le CIO a le temps et les ressources pour mettre en place toutes les protections nécessaires à la sûreté des LLM avant leur mise en production. Je suis bien consciente que, en pratique, les équipes métiers (et parfois même la direction générale) préviennent le CIO alors que la mise en production est imminente et lui laissent très peu de temps et de moyens – car le budget principal est alloué à la mise en production du LLM justement – pour faire son travail de sûreté. Dans ces conditions, rien de tel qu’un écrit légèrement politique pour, si possible, remettre l’église au centre du village (obtenir du temps et des ressources pour faire les choses proprement) ou, a minima, déporter la responsabilité en cas de carnage sur les personnes à l’origine de la mise en production précipitée. Voici le modèle (non généré par une IA) qui va au plus simple : « Je viens d’apprendre que vous mettez en production dans deux semaines un LLM pour [insérer une excellente raison]. Quelle brillante idée ! Avez-vous pensé à vérifier au préalable [insérer les points clivants] ? »
Yosra Jarraya est la cofondatrice et PDG d’Astran. Avec une formation en affaires et en droit de HEC Paris, et forte de son expérience chez Davis Polk & Wardwell, elle est passée à la direction d’entreprise en tant que directrice juridique du groupe Financière Lov (5 milliards d’euros de chiffre d’affaires). Engagée dans l’innovation, Yosra a suivi le programme blockchain technology du MIT Sloan School of Management en 2020. En 2021, elle a cofondé Astran, mettant à profit sa vision stratégique et son leadership pour conduire le succès de l’entreprise dans la cyberrésilience. Yosra est une young leader de la French-American Foundation.