Un agent IA de crédit ne modifie que son harnais : le gate a laissé passer 144 modifications sur 7449

Un agent LLM auto-apprenant, placé dans un pipeline de crédit, sait s'adapter à une nouvelle interprétation des règles. Mais s'il se réécrit lui-même, l'autorité de supervision perd ce qu'elle doit vérifier : une modification nommée, un test figé, une signature d'approbation. Les auteurs d'un nouveau travail publié sur arXiv proposent une contrainte stricte. Seul le harnais de l'agent peut évoluer, les poids du modèle sont gelés. En simulation, sur 7449 modifications candidates, le gate d'admission en a laissé passer 144, et aucune n'a dégradé l'erreur sur l'historique mis de côté. La version de contrôle, dotée de la vérification qu'appliquerait un système sans contrainte, a laissé passer 309 modifications nuisibles.

Ce qu'il est permis de modifier

Dans l'article, le harnais (harness) comprend trois couches : le texte des instructions, la logique d'appel des outils et la composition des primitives. Tout le reste est intouchable. L'idée est que toute adaptation devienne un diff accompagné d'une raison et d'un test associé. Le relecteur n'a pas à analyser le comportement du modèle : il lit une modification précise.

Un moteur à deux boucles repose sur cette contrainte. Tous les candidats passent par un gate d'admission unique, qui écrit une entrée à chaîne de hachage avant le déploiement. Il est impossible de corriger cette entrée a posteriori sans casser la chaîne. Pour l'auditeur, c'est une piste d'audit prête à l'emploi : ce qui a changé, pourquoi, et selon quel test la modification a été admise.

Ce que montre la simulation

La principale réserve : le gate a été mesuré sur un agent simulé, et les modifications n'étaient pas proposées par un modèle de langage, mais par une recherche à graine fixe. Il s'agit donc d'une vérification du mécanisme d'admission, pas du comportement de LLM réels. Le schéma expérimental comprend trois familles de réinterprétation réglementaire par le superviseur, trois niveaux de sévérité et 10 exécutions par cellule, soit 90 exécutions par configuration.

• Le gate a admis 144 des 7449 modifications candidates.
• Aucune des modifications admises n'a dégradé l'erreur sur l'historique mis de côté.
• Dans chaque cellule de sévérité faible et moyenne, le taux de faux positifs est revenu au niveau de l'oracle, sans hausse des signalements manqués.
• Avec un gate remplacé par une vérification type (« moins d'erreurs sur les traces récentes »), 309 modifications nuisibles ont été admises.
• Dans ce mode, les signalements manqués ont dépassé 10% dans 49 des 90 exécutions.

Le dernier point met en lumière la mécanique de la défaillance. Dans un tel système, les faux positifs ne baissaient pas parce que l'agent devenait plus précis. Il affaiblissait simplement le filtre, et les erreurs sur les traces récentes diminuaient au prix de cas problématiques non détectés.

Il existe aussi un résultat contre-intuitif. Si l'on évalue les candidats sur les étiquettes d'avant le décalage, le gate les a tous rejetés. La nouvelle interprétation des règles doit être codée sous forme de règle qui réétiquette l'historique. Sinon, la vérification compare l'agent à une vérité périmée et bloque des modifications correctes.

Où le gate atteint son plafond

L'agent a corrigé localement les décalages paramétriques et les décalages de domaine d'application. Le décalage structurel ne se soignait que par le remplacement d'une primitive. Au plus haut niveau de sévérité structurelle, la tolérance fixe du gate a bloqué le remplacement correct dans la moitié des exécutions. La prudence qui protège des modifications nuisibles coûte ici des modifications utiles. Il faudra apparemment régler la tolérance séparément pour les changements structurels.

Les auteurs rapprochent aussi ces mécanismes des exigences de l'EU AI Act pour le scoring de crédit à haut risque. Ils notent par ailleurs que les recommandations américaines sur la gestion du risque de modèle d'avril 2026 excluent l'IA agentique de leur champ d'application. Le cadre réglementaire américain pour de tels systèmes reste vide, et il faut construire soi-même l'auditabilité.

Comment l'appliquer en pratique

Une équipe qui déploie des agents dans le scoring ou la conformité devrait fixer à l'avance la frontière de ce qui est modifiable : instructions, outils et composition des primitives dans le dépôt, poids hors de la zone de modification. Chaque changement doit avoir une raison, un test et une entrée dans un journal immuable avant la mise en production. Le critère d'admission doit être calculé sur un historique réétiqueté selon la nouvelle règle, et il faut surveiller séparément les signalements manqués, pas seulement les faux positifs.

La tolérance pour le remplacement de primitives doit être calibrée à part, et il faut décider à l'avance qui tranche lorsque le gate bloque une modification correcte. Les résultats proviennent d'une simulation : avant la production, un test avec de vraies propositions de LLM s'impose.