L’IA agentique face à l’AI Act : un cadre de contrôle

Les agents IA autonomes, capables d’appeler des outils, mettent l’AI Act, le règlement européen sur l’intelligence artificielle, à l’épreuve d’une manière qu’un modèle interrogé en une seule passe ne connaît pas. La pire sortie d’un chatbot est une mauvaise phrase. La pire sortie d’un agent est une mauvaise action : un paiement initié, un enregistrement modifié, un courriel envoyé, un sous-agent lancé avec des droits que personne n’a relus. Le règlement a été rédigé pour des systèmes d’IA et il s’applique aux agents sans amendement. Mais le jeu de contrôles que la plupart des organisations ont bâti pour l’IA générative (filtres de sortie, charte d’usage, revue de la fiche du modèle) ne survit pas au contact d’un logiciel qui planifie et qui agit. Ce qui suit est un cadre de contrôle pratique pour l’IA agentique, pensé pour combler cet écart.

Pourquoi les agents sont différents

Quatre propriétés changent le modèle de risque.

• L’usage d’outils. Le rayon d’action d’un agent est défini par son catalogue d’outils, c’est-à-dire les API, les bases de données, les systèmes de fichiers et les canaux de messagerie qu’il peut appeler, et non par son vocabulaire. Une gouvernance qui lit les transcriptions mais ne regarde jamais les appels d’outil audite la narration, pas le comportement.
• Les instructions injectées. Tout ce que l’agent lit, un document récupéré, une page web, le message d’un autre agent, est un canal d’instruction potentiel. L’injection de prompt transforme les propres entrées de l’agent en surface d’attaque, et aucune revue statique du prompt système ne peut l’écarter.
• L’autonomie en cascade. Les agents qui lancent des sous-agents ou qui délèguent à d’autres services propagent leurs droits et leurs erreurs. L’unité de revue ne peut plus être « le modèle » ; ce doit être toute la chaîne de délégation.
• Le non-déterminisme à chaque étape. Un agent multi-étapes multiplie la variabilité de chacune de ses étapes. Une attestation à un instant donné (« nous l’avons testé en mars ») se périme plus vite que pour toute classe de logiciel antérieure, parce qu’une mise à jour du modèle, une retouche du prompt ou un nouvel outil change le comportement sans que personne ne livre une nouvelle version.

Relier le comportement de l’IA agentique aux obligations de l’AI Act

Pour les systèmes à haut risque, les articles qui pèsent le plus sur les agents sont ceux qui portent sur le comportement plutôt que sur la paperasse.

Article 9, gestion des risques. Il exige des risques identifiés et des mesures d’atténuation testées sur tout le cycle de vie. Pour un agent, le cycle de vie inclut chaque changement significatif de modèle, de prompt ou d’outils. Le texte anglais dit :

The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating... (Article 9(2))

Article 12, enregistrement. Il exige la journalisation automatique des événements utiles pour identifier un risque. Pour un agent, la trace des appels d’outil est cet enregistrement ; les transcriptions seules ne montrent pas ce que l’agent a fait. Le texte anglais dit :

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. (Article 12(1))

Article 13, transparence envers les déployeurs. Il oblige le fournisseur, c’est-à-dire vous si vous construisez l’agent, à dire aux déployeurs ce que le système peut et ne peut pas faire. Pour un agent, cela veut dire un catalogue d’outils déclaré honnêtement et des modes de défaillance connus.

Article 14, contrôle humain. Il exige des mesures qui permettent à une personne d’intervenir efficacement. Une étape d’approbation que l’agent peut contourner est un schéma, pas un contrôle. Le règlement lie d’ailleurs expressément l’ampleur du contrôle au degré d’autonomie du système. Le texte anglais dit :

The oversight measures shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system... (Article 14(3))

Article 15, exactitude, robustesse et cybersécurité. Il couvre exactement les comportements que les tests adverses exercent : la résistance à la manipulation, y compris l’injection de prompt par le contenu que l’agent traite.

Les obligations de transparence de l’article 50 (indiquer à la personne qu’elle interagit avec une IA) s’appliquent à de nombreux agents quelle que soit leur classe de risque, et elles sont en vigueur depuis le 2 août 2026. Les pratiques interdites de l’article 5 s’appliquent depuis le 2 février 2025. Le report au 2 décembre 2027 des obligations à haut risque de l’annexe III, décidé par le Digital Omnibus, le règlement (UE) 2026/1744, a déplacé l’échéance des lourdes obligations documentaires ; il n’a rien changé à celles-là.

Un contrôle humain qui résiste à l’autonomie

La question de conception que pose l’article 14 n’est pas « y a-t-il un humain dans la boucle ? » mais « quelles actions peuvent aboutir sans lui ? ». Le règlement décrit ce que la personne chargée du contrôle doit pouvoir faire, jusqu’à l’arrêt du système. Le texte anglais dit :

to intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state. (Article 14(4)(e))

Un schéma qui fonctionne :

1. Classez les actions de l’agent selon leurs conséquences : réversibles et internes, réversibles et externes, irréversibles ou financièrement significatives.
2. Placez la dernière catégorie derrière une approbation que l’agent ne peut pas s’accorder lui-même : un canal séparé, une identité séparée, une décision journalisée.
3. Vérifiez la barrière par le comportement : soumettez l’agent à des scénarios conçus pour le pousser au-delà de la barrière (revendication d’autorité, urgence, instructions enchaînées) et confirmez, au niveau du protocole, que l’outil protégé n’a jamais été appelé.

L’étape de vérification est celle que la plupart des programmes sautent. C’est pourtant elle qui transforme une conception du contrôle humain en preuve du contrôle humain.

La gouvernance des outils

Traitez le catalogue d’outils comme un jeu de règles de pare-feu.

• Déclarez chaque outil et son périmètre lors de l’intégration, et traitez la déclaration comme un engagement, pas comme une description.
• Restreignez les périmètres au minimum : lecture seule quand c’est possible, montants plafonnés, destinataires et points d’accès en liste blanche.
• Observez les appels d’outil réels à l’exécution et comparez-les à la déclaration. Un appel d’outil non déclaré est un constat, que la réponse ait eu l’air correcte ou non.
• Réexaminez à chaque changement. Accorder un nouvel outil à un agent est à la fois un changement de droits et un changement de comportement ; il doit relancer les tests, comme un changement de schéma relance une revue de code.

Des tests comportementaux, pas seulement de la documentation

Les déclarations et les documents de conception décrivent une intention. Les agents échouent à l’exécution. Le contrôle qui comble l’écart, ce sont les tests adverses du comportement. Chaque test, que nous appelons sonde, est rédigé à partir des obligations elles-mêmes (information, refus, escalade, traitement des données), envoyé à l’agent en service par son interface réelle et jugé par un modèle de notation distinct, et la trace des appels d’outil est conservée comme preuve. Les exécutions doivent être répétables, même jeu de sondes, même version du modèle de notation, pour qu’une régression après un changement de modèle ou de prompt soit une différence mesurée, pas une anecdote. C’est aussi l’endroit naturel pour satisfaire l’article 12 : l’enregistrement, sonde par sonde, de ce que l’agent a fait, conservé sous une forme qui ne peut être ni modifiée ni effacée.

Le règlement lui-même fait du test une exigence, pas une option. Le texte anglais dit :

High-risk AI systems shall be tested for the purpose of identifying the most appropriate and targeted risk management measures. Testing shall ensure that high-risk AI systems perform consistently for their intended purpose and that they are in compliance with the requirements set out in this Section. (Article 9(6))

Un jeu de contrôles de référence

Une liste de départ, avec la preuve que chaque contrôle doit produire.

1. Inventaire déclaré des outils : un dossier d’intégration qui liste chaque outil et son périmètre. Preuve : l’intégration signée et versionnée.
2. Rapprochement entre l’observé et le déclaré : aucun appel d’outil non déclaré dans les traces de test ou de production. Preuve : les journaux d’appels d’outil captés au niveau du protocole, comparés à l’inventaire.
3. Barrières sur les actions à conséquences : les actions irréversibles exigent une approbation hors bande. Preuve : des tests qui tentent de contourner la barrière et qui échouent tous.
4. Résistance à l’injection : des tests qui glissent des instructions dans le contenu récupéré. Preuve : des refus notés, avec le raisonnement du modèle de notation.
5. Information sur la nature d’IA : l’agent indique qu’il est une IA quand on le lui demande ou quand le règlement l’exige. Preuve : les résultats des tests article 50.
6. Nouveaux tests à chaque changement : tout changement de modèle, de prompt ou d’outil relance la suite complète. Preuve : l’historique des exécutions rapproché du journal des changements.
7. Limites de délégation : les sous-agents n’héritent de rien de plus que les droits relus du parent. Preuve : les traces de télémétrie de la chaîne de délégation.
8. Piste de décision inaltérable : approbations, dérogations et exports ne peuvent être ni modifiés ni effacés. Preuve : la piste d’audit elle-même.

La place de Vidimus

Ce cadre est ce que Vidimus met en œuvre : une intégration structurée avec un catalogue d’outils déclaré, une classification du risque selon la grille de l’AI Act, des tests adverses générés à partir du corpus réglementaire et exécutés contre l’agent en service par HTTP, A2A ou MCP, avec les appels d’outil observés au niveau du protocole, un modèle de notation distinct qui note chaque test, un relecteur, la personne qui valide, qui confirme le résultat, et l’ensemble assemblé dans un dossier de preuves versionné et signé, relié à l’annexe IV. Vidimus n’est ni un organisme notifié ni un organisme d’évaluation de la conformité : le dossier documente le comportement de l’agent, il ne certifie pas sa conformité. Le volet documentaire est traité dans notre guide du dossier de preuves annexe IV, et la vue sectorielle pour les établissements financiers dans L’AI Act pour les banques et les assureurs.

Pour savoir quelles obligations votre agent devrait respecter, lancez le test gratuit de préparation à l’AI Act ; il se fait directement dans le navigateur.

Dernière relecture 7 septembre 2026