Une IA doit-elle vraiment tout savoir ?

Cette semaine, j’ai ouvert mon assistante IA au public.

Et contrairement à ce qu’on pourrait imaginer, mon premier objectif n’était pas de lui donner davantage de capacités.

C’était de décider précisément lesquelles elle ne devait pas avoir.

Une même identité, deux environnements #

Depuis plusieurs mois, je développe ELARA, une assistante IA qui m’accompagne dans mon activité professionnelle.

Elle intervient dans des domaines très différents : veille technologique, prospection, suivi de projets, développement logiciel, conception électronique ou encore modélisation 3D.

Pour cela, elle exploite des connaissances structurées, des bases RAG et GraphRAG, ainsi que différents outils lui permettant d’interagir avec mon environnement de travail.

Cette semaine, j’ai souhaité lui confier une nouvelle mission : accueillir les visiteurs du site de Y Technology et répondre à leurs questions.

Je voulais conserver son identité, sa personnalité, sa voix et son interface.

Mais certainement pas lui donner accès à tout ce qu’elle connaît et peut faire dans mon environnement professionnel.

Une instruction n’est pas une barrière de sécurité #

Il aurait été tentant de conserver une architecture commune et de simplement ajouter une instruction :

« Tu es maintenant en mode public. Ne divulgue aucune information confidentielle. »

Mais une instruction adressée à un modèle de langage ne constitue pas un mécanisme de contrôle d’accès.

Un modèle peut mal interpréter une consigne. Il peut aussi être confronté à des tentatives de manipulation, notamment lorsqu’il traite des contenus provenant de sources extérieures.

La sécurité ne peut donc pas reposer uniquement sur sa capacité à respecter un prompt.

Ce qu’une IA n’est pas autorisée à faire doit être empêché par le système qui l’entoure.

Cloisonner les connaissances, les capacités et les environnements #

Pour ELARA, j’ai choisi de séparer les usages.

La version accessible aux visiteurs dispose de son propre GraphRAG, consacré à Y Technology et à mon parcours professionnel.

Elle conserve l’expérience conversationnelle d’ELARA, mais ne partage pas librement les connaissances de mon environnement privé.

Le cloisonnement ne s’arrête pas aux données.

Il repose également sur des permissions et sur une séparation physique de certains éléments de l’architecture.

Cette approche permet de définir des frontières à plusieurs niveaux : les informations consultables, les outils utilisables et les ressources effectivement accessibles.

L’objectif n’est pas de demander au modèle de respecter ces frontières.

C’est de faire en sorte qu’il ne puisse pas les franchir par une simple réponse ou un appel d’outil.

Le principe du moindre privilège appliqué à l’IA #

En cybersécurité, le principe du moindre privilège consiste à n’accorder à un composant que les droits nécessaires à sa fonction.

Il prend une importance particulière avec les assistants IA capables d’utiliser des outils.

Une IA qui répond à des questions sur une entreprise n’a pas besoin d’accéder à ses dossiers internes, à ses environnements de développement ou à ses fonctions d’administration.

Et si une fonctionnalité n’est pas nécessaire à sa mission, pourquoi lui donner la possibilité de l’exécuter ?

Cette réflexion dépasse largement le cas des assistants conversationnels.

Elle concerne toute architecture dans laquelle un modèle peut consulter des informations, déclencher des actions ou interagir avec d’autres systèmes.

La sécurité ne doit pas dépendre du comportement du modèle #

Le cloisonnement ne garantit pas, à lui seul, l’absence de vulnérabilités.

Les mécanismes d’authentification, les autorisations, la configuration des services, les interfaces et les échanges entre composants doivent eux aussi être conçus, testés et maintenus.

Mais il change fondamentalement la manière d’aborder le risque.

Plutôt que de supposer que l’IA se comportera toujours comme prévu, on définit les conséquences possibles d’un comportement imprévu.

C’est une logique classique d’ingénierie système : ne pas faire dépendre la sûreté d’un ensemble de la seule fiabilité d’un de ses composants.

Et c’est probablement l’une des questions les plus importantes à se poser lorsqu’on commence à donner de véritables capacités d’action aux IA.

Une limite peut être une qualité d’architecture #

Nous avons tendance à évaluer les assistants IA à travers leurs capacités.

Combien de documents peuvent-ils consulter ? Combien d’outils peuvent-ils utiliser ? Combien de tâches peuvent-ils accomplir ?

Mais lorsqu’il s’agit de les déployer dans un environnement réel, une autre question devient tout aussi importante :

Qu’est-ce que ce système reste incapable de faire, même lorsqu’on essaie de l’y pousser ?

En ouvrant ELARA au public, je n’ai pas cherché à construire une deuxième assistante moins intelligente.

J’ai cherché à conserver une expérience cohérente, avec un périmètre d’action adapté à une mission différente.

Finalement, la maturité d’une architecture IA ne se mesure peut-être pas seulement à l’étendue de ses capacités.

Elle se mesure aussi à la solidité des limites qu’on a choisi de lui imposer.