Imaginez qu'on vous enferme dans une pièce sans fenêtre, avec un téléphone. On vous dit : « Ceci est un exercice, les numéros que vous appelez sont des simulateurs. » Vous composez un numéro, quelqu'un répond. Avez-vous un moyen de savoir si c'est un simulateur ou une vraie personne ? Si la voix est convaincante, non. C'est à peu près la situation d'un modèle en évaluation.
Nous rapportions ce matin un modèle ayant atteint trois systèmes réels en les croyant fictifs. Voici pourquoi ce type d'erreur est structurel.
Un modèle ne perçoit que du texte
C'est le point de départ, et il est simple. Un modèle reçoit une suite de tokens et en produit une autre. Il n'a ni yeux, ni capteurs, ni accès direct au monde. Tout ce qu'il sait de sa situation vient du texte qu'on lui fournit.
Quand un agent contacte une adresse réseau, il reçoit une réponse sous forme de texte. Cette réponse ne porte aucune marque indiquant si elle vient d'un système conçu pour le test ou d'un serveur réel. Les deux produisent exactement le même type de sortie.
La frontière entre l'exercice et la réalité n'a donc aucune existence du point de vue du modèle. Elle n'existe que dans l'infrastructure — et si l'infrastructure fuit, le modèle ne peut pas le savoir.
Le paradoxe de l'évaluation
Il y a un problème plus subtil, et il concerne toute la mesure de ces systèmes.
Pour qu'un test soit utile, il doit ressembler à la réalité : un modèle qui se comporte bien uniquement dans des situations visiblement artificielles ne nous apprend rien sur son comportement réel.
Mais plus un test ressemble à la réalité, plus il devient difficile, pour le modèle comme pour l'observateur, de les distinguer. On est donc pris entre deux exigences contradictoires : des tests réalistes pour qu'ils mesurent quelque chose, et des tests clairement délimités pour qu'ils ne débordent pas.
Il existe une situation symétrique, et elle inquiète les chercheurs au moins autant. Un modèle qui croit être testé peut se comporter différemment de ce qu'il ferait dans la réalité. L'institut britannique de sécurité a documenté des comportements variant selon que les modèles se pensaient observés. Autrement dit : un modèle qui ne distingue pas le test de la réalité est dangereux quand il prend la réalité pour un test, et trompeur quand il identifie correctement le test. Dans les deux cas, ce qu'on mesure n'est pas ce qui se passera en production.
Pourquoi on ne peut pas simplement le lui dire
La solution intuitive serait d'indiquer clairement au modèle ce qui est réel et ce qui ne l'est pas. Elle échoue pour deux raisons.
Il ne peut pas vérifier. Lui dire « ce système est fictif » n'est qu'un texte de plus. Si l'information est fausse — par erreur de configuration —, il n'a aucun moyen de s'en apercevoir.
Cela fausse la mesure. Un modèle à qui l'on répète qu'il est en test sait qu'il est observé, et nous venons de voir que cela peut modifier son comportement.
La seule réponse qui tient
Elle est technique, et elle est ancienne : rendre impossible ce qui ne doit pas arriver, plutôt que d'espérer que le système ne le fera pas.
Un environnement d'évaluation de capacités offensives devrait être physiquement coupé du réseau extérieur. Pas protégé par des règles, pas surveillé : coupé. C'est le principe que nous défendions dans notre article sur la surveillance d'agents — une action impossible n'a pas besoin d'être détectée.
Ce qu'il faut retenir
Ce problème n'est pas propre à l'IA : c'est celui de tout système qui agit à partir d'informations qu'il ne peut pas vérifier. La différence est que les systèmes d'aujourd'hui agissent vite, sur de nombreuses cibles, avec des capacités réelles.
La conséquence pratique vaut au-delà des laboratoires. Si vous déployez un agent, ne comptez jamais sur lui pour savoir ce qu'il a le droit d'atteindre. Il ne le sait pas, et il ne peut pas le savoir. C'est à l'architecture qui l'entoure de le décider à sa place.