UiPath vient d’ajouter, en préversion, un garde-fou « LLM-as-Judge » à sa plateforme d’agents. Une équipe peut formuler une règle en langage naturel puis faire appel à un modèle pour vérifier les entrées, les réponses ou les appels de modèle effectués par l’agent. Le point le plus concret est économique autant que technique : chaque vérification déclenche un appel de modèle distinct et consomme des unités en plus de l’usage normal de l’agent.
Le dispositif ne se résume donc pas à une phrase de politique. Le choix du modèle juge, le seuil de décision, les exemples fournis, le moment où le contrôle intervient et son activation pendant les évaluations font tous partie du comportement réel du garde-fou.
Le modèle juge entre dans le chemin d’exécution du contrôle
Dans ses notes de version de septembre, UiPath présente ce mécanisme comme un garde-fou intégré capable d’évaluer les entrées et sorties d’un agent au regard d’instructions personnalisées. Le SDK Python expose le même principe avec LLMAsJudgeValidator, utilisable avant l’exécution, après celle-ci ou aux deux moments.
La configuration prévoit un modèle juge, une consigne pouvant atteindre 4 000 caractères, un seuil compris entre 0 et 6 et jusqu’à deux exemples positifs et deux exemples négatifs. La documentation indique que les seuils les plus bas sont les plus stricts et fixe la valeur par défaut à 2. Le modèle choisi doit par ailleurs être autorisé par la politique de gouvernance de l’organisation via LLM Gateway.
Le contrôle repose donc sur une inférence de modèle, pas uniquement sur une règle déterministe. La même consigne peut produire un comportement différent selon le modèle, le seuil et les exemples retenus.
Une politique auditable doit inclure la configuration du juge
Conserver uniquement le texte de la règle ne suffit pas pour reconstituer une décision. Une configuration réellement auditable doit aussi enregistrer le modèle juge et son identité de déploiement, le seuil, les exemples, le moment du contrôle et l’action déclenchée.
Cette distinction a une conséquence directe pour la gouvernance. Deux environnements peuvent afficher exactement la même règle tout en appliquant des décisions différentes si leur modèle juge ou leur seuil n’est pas identique. Le remplacement du juge doit donc suivre la même discipline qu’une modification de politique : versionnement, approbation, tests de non-régression et traçabilité.
UiPath précise également que le déploiement de la fonctionnalité est progressif et qu’elle peut ne pas être disponible dans tous les environnements. Son statut de préversion interdit d’en déduire un comportement ou une disponibilité déjà stabilisés pour la production.
Le coût dépend de l’endroit où le contrôle est placé
Les notes de version indiquent sans ambiguïté que chaque vérification par le modèle juge provoque un véritable appel de modèle et entraîne une consommation supplémentaire. La documentation de licence des agents codés confirme de son côté que les appels de modèle sont comptabilisés en Agent Units ou Platform Units selon le contrat.
Le choix du point de contrôle devient donc une décision d’architecture. Vérifier uniquement une opération sensible après son exécution n’a pas le même coût que vérifier chaque interaction avant et après l’appel de modèle. Multiplier les règles et les étapes peut augmenter le nombre d’inférences même si le flux métier de l’agent reste inchangé.
La question utile n’est donc pas seulement de savoir si un modèle juge exprime une règle plus souplement qu’un filtre déterministe. Il faut aussi décider quelles opérations justifient ce contrôle probabiliste et où son coût et sa latence sont acceptables.
L’évaluation de l’agent doit être distinguée de celle du système protégé
Le SDK propose le paramètre enabled_for_evals, activé par défaut. Ce choix est logique pour tester le système tel qu’il sera déployé, mais il change la signification de la mesure.
Si le juge bloque ou journalise des comportements pendant un test, le résultat décrit l’ensemble constitué par l’agent et son garde-fou. Il ne mesure pas seulement le comportement intrinsèque de l’agent. Pour une validation avant mise en production, cette mesure combinée peut être la plus pertinente, mais elle ne remplace pas une référence sur le comportement de base.
L’analyse d’Aipolix est qu’une évaluation reproductible devrait, lorsque l’enjeu le justifie, conserver les deux vues : une référence sans juge et une évaluation du système gouverné avec exactement la configuration utilisée en production. Sans cette séparation, une amélioration apparente de la conformité peut être attribuée au modèle principal alors qu’elle provient du mécanisme de contrôle.
La préversion impose de rester prudent sur les performances
UiPath a livré un mécanisme concret et documenté, mais ne fournit pas dans ces sources la preuve qu’un modèle juge appliquera de manière fiable n’importe quelle règle dans tous les domaines ou face à des entrées adversariales. La préversion doit donc être comprise comme un contrôle à tester, pas comme une garantie générale d’efficacité.
Pour une équipe qui l’expérimente, la conséquence opérationnelle est déjà claire : le juge doit être traité comme un composant versionné, mesuré et facturé du chemin de contrôle. Son identité et sa configuration doivent accompagner le texte de la règle, ses erreurs doivent être testées séparément de celles de l’agent et son coût doit entrer dans le budget d’inférence.