Définition
Les garde-fous IA sont les limites imposées autour d’un modèle : quelles données il peut atteindre, quelles actions il peut poser, quelle sortie peut quitter le système, et quand il doit s’arrêter pour impliquer une personne. Ils s’implémentent dans le système environnant, pas dans une instruction.
Une instruction est une demande, pas un contrôle
L’erreur la plus répandue en gouvernance de l’IA consiste à écrire « ne jamais divulguer de données client » dans une instruction système et à considérer l’affaire réglée.
Les consignes placées dans une instruction sont des suggestions que le modèle suit généralement. Elles peuvent être contournées par un message utilisateur habilement formulé, s’éroder au fil d’une longue conversation, ou simplement être ignorées lors d’une génération malchanceuse. Si les conséquences d’un écart sont sérieuses, la contrainte doit résider là où le modèle ne peut pas l’atteindre.
C’est tout le principe de conception. Un garde-fou n’en est un que si le modèle ne peut pas le discuter.
Les quatre endroits où placer des garde-fous
Sur l’entrée. Ce qui atteint le modèle. Retirez ou masquez les champs sensibles avant l’envoi. Rejetez les demandes hors périmètre. Si un renseignement personnel n’a pas besoin de figurer dans l’instruction, laissez-le dehors : la façon la plus propre d’éviter de mal traiter une donnée est de ne pas l’envoyer.
Sur l’accès. Ce que le modèle peut récupérer. Des permissions appliquées à la couche de données, filtrées selon qui pose la question, de sorte qu’un système de récupération ne puisse pas physiquement renvoyer un document auquel l’utilisateur n’a pas droit. L’appliquer dans l’instruction n’est pas une application.
Sur l’action. Ce que le système peut faire. Listes d’opérations permises, plafonds de dépense et de débit, et un point d’approbation ferme sur tout ce qui est irréversible : argent, contrats, suppression, communication externe. Voir humain dans la boucle pour la conception de ces points.
Sur la sortie. Ce qui peut quitter le système. Validation du format, confrontation à un système de référence là où les faits sont vérifiables, et blocage des catégories de contenu qui ne doivent jamais être envoyées. C’est aussi là qu’on intercepte la réponse assurée mais fausse avant un client.
Un garde-fou n’est pas un document de conformité
Une politique énonçant ce que l’IA ne doit pas faire est utile et n’est pas un contrôle. Le test est simple : si quelqu’un tentait de faire faire au système la chose interdite, qu’est-ce qui l’en empêcherait physiquement ? Si la réponse est « l’instruction dit de ne pas le faire », vous avez de la documentation.
L’échec apparenté : des garde-fous qui n’existent que sur le chemin idéal. Que se passe-t-il quand la récupération ne renvoie rien, que le modèle produit une sortie malformée, que l’appel d’outil expire à mi-parcours, ou qu’un utilisateur colle quelque chose d’étrange ? Chacun de ces moments est une occasion d’improvisation pour un système mal conçu, or c’est précisément l’improvisation qu’on cherchait à empêcher.
L’approche Automathing
Nous imposons les limites dans le système autour du modèle plutôt que dans les consignes qu’on lui donne. Les permissions s’appliquent au moment de la récupération, les actions irréversibles exigent une approbation que rien ne peut contourner, et chaque exécution est journalisée assez finement pour être reconstituée. Nous testons aussi les garde-fous délibérément : tenter de faire faire au système la chose interdite fait partie de la construction, pas de l’après-coup.
Foire aux questions
Quelle différence entre garde-fous et évaluation ?
L’évaluation mesure la performance du système sur les cas attendus. Les garde-fous limitent ce qu’il peut faire quand survient l’inattendu. L’évaluation vous dit que le système est bon ; les garde-fous garantissent que lorsqu’il ne l’est pas, les conséquences restent bornées. Il faut les deux, et ils échouent différemment.
Les garde-fous rendent-ils l’IA moins utile ?
Ceux qui sont bien conçus réduisent surtout l’éventail de ce que le système peut mal faire, ce qui n’équivaut pas à réduire son utilité. Ceux qui sont mal conçus, comme les filtres de contenu trop larges et les blocages par mots-clés, nuisent effectivement, généralement parce qu’ils ont été écrits pour contraindre des sujets plutôt que des actions et des accès. Contraignez les conséquences, pas le vocabulaire.
Quel lien avec la Loi 25 et les obligations de confidentialité ?
Un lien direct. Contrôles d’accès, minimisation des données, limites de conservation et pistes de vérification sont à la fois des enjeux de garde-fous et de conformité. En pratique : décidez tôt quels renseignements personnels doivent réellement atteindre un modèle, gardez le reste dehors, et soyez en mesure de démontrer après coup ce qui a été envoyé, récupéré et renvoyé.
Un utilisateur peut-il contourner les garde-fous en reformulant ?
Il peut contourner des consignes placées dans une instruction, et c’est exactement pourquoi les limites importantes doivent être imposées ailleurs. Aucune reformulation n’obtient un document que le filtrage de permissions n’a jamais renvoyé, et aucune tournure habile ne complète un paiement que le système soumet à une approbation humaine. C’est là toute la différence entre une demande et un contrôle.