Sécurité de l'IA : quand elle bloque les usages légitimes

Les mécanismes de sécurité de l’IA sont nécessaires. Mais quand ils interprètent incorrectement le contexte d’une demande, ils peuvent aussi bloquer des usages parfaitement légitimes.

J’ai rencontré ce problème lors de la rédaction d’un article sur l’utilisation de l’IA par les cybercriminels. J’avais besoin d’un schéma pédagogique pour illustrer l’évolution de l’hameçonnage. Je souhaitais montrer comment l’IA permet de combiner volume et personnalisation, alors qu’il fallait auparavant davantage arbitrer entre les deux. L’IA utilisée pour la création du schéma a refusé ma demande pour des raisons de sécurité. Pourtant, le schéma était destiné à un article de sensibilisation et n’était aucunement une procédure d’attaque ni un moyen opérationnel de conduire un hameçonnage. J’ai finalement pu obtenir le schéma avec une autre IA (d’où l’intérêt au passage d’avoir deux IA).

Ici, le problème n’était pas tant l’existence d’une protection que sa capacité à prendre en compte le contexte. Dès lors, un mécanisme de sécurité peut-il être réellement efficace s’il distingue mal un usage malveillant d’un usage légitime ?

Politique d’usage et mécanisme de refus

Deux éléments doivent notamment être distingués : la politique d’usage et le mécanisme de refus.

La politique d’usage : elle définit ce que l’utilisateur est autorisé ou non à faire avec le service proposé. Elle peut par exemple interdire certains usages liés à la fraude, aux armes, aux attaques informatiques, à l’exploitation sexuelle des mineurs, à l’automutilation ou à d’autres activités présentant un risque important.

Le mécanisme de refus : c’est l’ensemble des moyens qui déterminent si une requête ou une réponse doit être bloquée, limitée ou adaptée. Ils peuvent notamment reposer sur le comportement appris par le modèle, des instructions de sécurité, des classifieurs ou des filtres.

Une demande peut ne pas constituer un usage interdit et pourtant être bloquée par le mécanisme chargé de prévenir les usages dangereux. Il est important de comprendre pourquoi un refus de l’IA ne signifie pas automatiquement que la demande est illégitime.

Pourquoi les IA doivent avoir des garde-fous

La production de texte, de code ou d’images par une IA peut être utilisée dans des contextes très différents. Certaines réponses peuvent en effet faciliter une fraude, une attaque informatique ou une autre activité malveillante. Il est donc nécessaire que les fournisseurs définissent des limites et empêchent certains usages. Les politiques d’usage des principaux fournisseurs convergent sur plusieurs catégories présentant des risques graves. Pour une entreprise, l’absence de toute protection poserait également un problème majeur.

Le problème avec ces garde-fous n’est pas que l’IA refuse certaines demandes. Il apparaît lorsqu’une demande est refusée sans suffisamment tenir compte de l’intention apparente, du contexte et de ce que la réponse permettrait concrètement de faire. Dans mon cas, le mécanisme de protection n’a pas permis de faire cette distinction.

Or, une même demande technique peut avoir plusieurs finalités :

Préparer une attaque
Analyser une attaque
Former des collaborateurs
Documenter un risque
Tester un dispositif de sécurité
Produire un contenu de sensibilisation

Dans mon cas, certains éléments associés à l’hameçonnage ont pu déclencher un mécanisme de protection alors que la finalité était défensive et pédagogique. Identifier le sujet traité n’est donc pas la seule difficulté. L’IA doit aussi apprécier ce que la réponse permet concrètement de faire. Un schéma qui explique que l’IA permet d’augmenter simultanément le volume et la personnalisation d’une campagne d’hameçonnage n’offre pas les mêmes capacités qu’un mode opératoire permettant de construire cette campagne.

La sécurité mise en place devrait donc chercher à mieux distinguer le thème d’une demande, son contexte, son intention apparente et son caractère réellement opérationnel. Aujourd’hui, les garde-fous suivent une logique commune : identifier les demandes ou les réponses susceptibles de présenter un risque, puis adapter le traitement en conséquence. Mais leur mise en œuvre varie selon les solutions et toutes les briques ne sont pas nécessairement placées au même endroit ou configurées de la même manière. Cela dit, le schéma ci-dessous permet d’illustrer ce fonctionnement général :

Sécurité de l’IA : mécanismes de garde-fous entre la requête utilisateur et la réponse

Le refus n’est finalement qu’une issue possible d’un mécanisme de sécurité. Selon l’évaluation de la demande et de son contexte, une réponse peut être produite normalement, adaptée ou refusée. C’est dans ce dernier cas que peut apparaître un faux positif : une demande légitime interprétée comme présentant un risque.

Le faux positif n’est pas sans conséquence

Dans le cas d’une utilisation personnelle, un refus injustifié peut être agaçant. Dans le cas d’un usage professionnel, les conséquences peuvent être plus importantes :

Interruption du travail en cours
Perte de temps
Nécessité de reformuler plusieurs fois la demande
Changement d’outil
Résultat moins pertinent
Perte de confiance dans le mécanisme de protection
Recherche de moyens permettant de contourner le blocage

Ces deux derniers points créent un paradoxe. Plus le mécanisme de protection produit de faux positifs, plus il risque d’inciter les utilisateurs à ne plus lui faire confiance et à chercher des moyens de contourner le blocage. En entreprise, cela peut devenir un facteur supplémentaire de Shadow IA (l’usage d’outils d’IA non autorisés par l’entreprise) : autant un garde-fou trop permissif constitue un risque, autant un garde-fou trop restrictif peut inciter certains utilisateurs à se tourner vers une IA non autorisée. Le risque n’est alors pas supprimé, mais déplacé.

En entreprise, la sécurité ne peut se résumer aux garde-fous du fournisseur

Pour une entreprise, chercher à contourner les garde-fous ou considérer tous les refus comme justifiés n’est pas la solution. Les garde-fous du fournisseur sont conçus pour répondre à un cadre général. Ils ne connaissent pas nécessairement les métiers de l’entreprise, ses données ou ses contraintes propres. C’est donc à l’entreprise de définir les usages autorisés, de choisir des outils adaptés et de prévoir comment traiter un refus qui bloque un besoin légitime.

Sécurité de l’IA en entreprise : articulation entre les garde-fous du fournisseur et la gouvernance interne

La présence de garde-fous chez un fournisseur ne dispense donc pas l’entreprise de définir sa propre gouvernance.

Et avec une IA locale ?

Dans le cas de l’utilisation d’une IA locale, le partage des responsabilités peut être différent. Le modèle peut intégrer une partie des comportements de sécurité. D’autres protections, comme des filtres ou des règles appliquées aux entrées et aux sorties, vont dépendre de l’environnement dans lequel le modèle est déployé. Dans ce cas, il revient à l’entreprise de mettre en place et de superviser une plus grande partie de ces protections. L’IA locale ne doit donc pas être présentée comme un moyen de contourner les garde-fous.

Passer d’un service hébergé à une IA locale ne supprime pas le besoin de sécurité. Bien au contraire. Ce changement déplace surtout la répartition des responsabilités. La politique de sécurité des systèmes d’information (PSSI) de l’entreprise doit donc intégrer cette nouvelle répartition et définir les protections adaptées avant le déploiement d’une IA locale.

Conclusion

L’expérience vécue lors de la création de mon schéma illustre l’un des deux risques entre lesquels les mécanismes de sécurité doivent trouver un équilibre :

Une IA insuffisamment protégée peut faciliter des usages dangereux
Une IA excessivement restrictive peut empêcher des usages légitimes, interrompre des processus professionnels et pousser certains utilisateurs à chercher des chemins parallèles, avec le risque d’alimenter le Shadow IA.

L’enjeu n’est finalement pas de choisir entre une IA sûre et une IA utile, mais de disposer de mécanismes qui prennent suffisamment en compte le contexte tout en organisant, côté entreprise, le traitement des refus qui bloquent un besoin légitime.

Une IA qui refuse davantage est-elle réellement plus sûre ou simplement moins utile ?