AI Act, article 15 : comment mesurer l’exactitude d’un agent
Un seul pourcentage peut-il prouver que votre agent est exact ? Pour un agent qui a le droit de dire « je ne sais pas », l’exactitude tient en plusieurs chiffres.
EN 30 SECONDES
Une suite d’évaluations est un jeu fixe de cas de test, noté de la même façon avant chaque mise en production. Pour l’article 15, je m’en servirais pour mesurer plusieurs chiffres d’exactitude et conditionner la mise en production à des seuils fixés d’avance. On finit sur l’ordre de construction : l’enregistrement d’audit d’abord.
À RETENIR · 3
- Pour un agent qui a le droit de dire « je ne sais pas », l’exactitude tient en plusieurs chiffres : juste quand il se dit sûr, abstention à bon escient, tenue face aux attaques.
- Mesurez-les sur un jeu de test fixe avant la mise en production, avec des seuils fixés par écrit à l’avance, puis en production (article 72, pour les fournisseurs de systèmes à haut risque).
- Les tests étayent l’article 15 sans le couvrir entièrement. Construisez d’abord l’enregistrement d’audit ; journalisation, contrôle humain et évaluations demandent encore des responsables nommés et une analyse des risques.
Sur cette page
Article 15 : comment mesurer l’exactitude
EN BREF Pour un agent qui a le droit de dire « je ne sais pas », l’exactitude tient en plusieurs chiffres, pas en un seul pourcentage.
LES MOTS À CONNAÎTRE
- Suite d’évaluations
- Un jeu fixe de cas de test, noté de la même façon avant chaque mise en production, pour comparer une version à la précédente.
- Red team
- Des personnes qui attaquent un système exprès, pour le faire échouer ou mentir avant que de vrais utilisateurs s’en servent.
- Surveillance après commercialisation
- Le suivi d’un système une fois en service, et le fait d’agir sur ce qu’on constate. C’est l’objet de l’article 72.
L’article 15 couvre l’exactitude, la robustesse et la cybersécurité. Il demande de déclarer vos métriques d’exactitude. J’en déclarerais trois : la part de réponses justes quand l’agent se dit sûr, la part d’abstentions quand il le faut, et sa tenue face à une Red team Des personnes qui attaquent un système exprès, pour le faire échouer ou mentir avant que de vrais utilisateurs s’en servent. Voir le glossaire.
Mesurez-les avec une Suite d’évaluations Un jeu fixe de cas de test, noté de la même façon avant chaque mise en production, pour comparer une version à la précédente. Voir le glossaire, sur un jeu de test fixe, avant la mise en production. Fixez les seuils d’abord : si l’un n’est pas atteint, la version attend.
ÉTAPE PAR ÉTAPE
Étape 1. Déclarer. Déclarer plusieurs axes, pas un seul chiffre.
- Déclarer Déclarer plusieurs axes, pas un seul chiffre.
- Mesurer Un jeu de référence fixe, y compris des cas de red team, noté de la même façon à chaque passage.
- Bloquer Les seuils sont fixés avant la mesure. Un score en dessous bloque la mise en production.
- Continuer à mesurer En production, alerter quand une métrique s’écarte de sa référence de lancement.
Puis continuez à mesurer en production : cela fait partie de la Surveillance après commercialisation Le suivi d’un système une fois en service, et le fait d’agir sur ce qu’on constate. C’est l’objet de l’article 72. Voir le glossaire de l’article 72, qui vise les fournisseurs de systèmes à haut risque. Ce qu’il vous impose avant 2027 relève de votre avocat.
Écrivez les seuils avant de voir le score.
EN CLAIR
Vous fournissez la suite et les résultats du dernier passage, pas un adjectif comme « exact ».
ATTENTION
Les évaluations et leurs seuils apportent des éléments pour l’article 15. Elles ne couvrent pas tout : l’exactitude, la robustesse et la cybersécurité demandent quand même une analyse plus large du système.
Deux billets vont plus loin. Le mécanisme : citations vérifiées et abstention en RAG. Les chiffres : les tests qui bloquent un lancement.
Dans la section suivante : Alors, avec tout cela sur la liste, que construire en premier ?
Quatre chantiers à lancer d’abord
EN BREF Commencez par l’enregistrement d’audit : trois autres articles s’appuient dessus.
Journaux, contrôle humain et tests demandent encore des responsables nommés par écrit et une analyse des risques. Il faut aussi une revue au regard des règles applicables.
Je construirais tout cela avec les équipes juridique, conformité et opérations. Il faut du code qu’on peut maintenir, et une lecture juste des règles. Cette checklist n’est qu’une page d’un ensemble plus large : comment je construis l’IA pour la finance régulée.
OBJET OBTENU
L’enregistrement d’abord
FAQ
Pour cette checklist, tout dépend : votre système est-il à haut risque ? Il peut l’être par un usage de l’annexe III (article 6(2), avec des exceptions), ou comme produit, ou composant de sécurité, que l’annexe I soumet à un contrôle par un tiers (article 6(1)). Laquelle de ces voies, ou aucune : c’est à un avocat qualifié de trancher.
D’autres parties du règlement, comme la transparence de l’article 50, peuvent s’appliquer quand même. Les deux voies du haut risque ont des dates différentes. S’y mettre tôt est une assurance peu coûteuse.
Un enregistrement par action. Il relie les versions du modèle et du prompt, les sources trouvées, la décision et la revue humaine, s’il y en a une. Il peut servir à la journalisation et à la documentation.
Ce qu’il doit couvrir, combien de temps le garder et les autres contrôles : tout cela reste à trancher système par système.
Ce sont des briques utiles. Mais revoyez avec les bons responsables la finalité, l’analyse des risques, la gouvernance des données, le contrôle humain, la sécurité, la documentation et l’exploitation.
Cet article n’est pas une évaluation complète de la conformité.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Vous savez quels chiffres d’exactitude déclarer pour un agent qui peut s’abstenir, et pourquoi un seul pourcentage les cache.
- Vous connaissez l’ordre de construction : enregistrement d’audit, abstention et validation humaine, évaluations bloquantes, versionnage.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Le rapport de votre agent n’affiche qu’un chiffre : la part de réponses justes. Il ne s’abstient jamais. Que manque-t-il à ce rapport ?
Les autres axes : la part d’abstentions quand il le faut, et sa tenue face à une red team. Un seul pourcentage peut cacher des réponses fausses données avec assurance.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.