EUAIACTpar DEMETER FORMATION CONSEIL
Ressources

Agents IA et AI Act : qualifier les systèmes agentiques et garder le contrôle.

Un agent IA peut planifier, utiliser des outils, consulter des données et déclencher des actions avec une intervention humaine limitée. « Agentique » n’est pas une catégorie juridique autonome de l’AI Act. Les obligations dépendent du système, de la finalité, du rôle et des conséquences de ses actions. La gouvernance doit donc regarder ce que l’agent peut réellement lire, décider et modifier, y compris lorsqu’il enchaîne plusieurs services sans intervention visible.

Lire le dossier
Version suivie

Texte officiel consolidé

Mise à jour 18 septembre 2026

AuteurDimitri Jorand — direction générale, responsable pédagogique et qualité
RelectureAlexis Jorand — direction générale et relecture éditoriale
Dernière mise à jour18 septembre 2026
Source principaleRèglement (UE) 2024/1689 — texte officiel
Réponse courte

L’essentiel en une minute

Un agent IA se qualifie selon la définition du système d’IA, sa finalité et son usage. Son autonomie augmente les exigences de maîtrise : permissions minimales, validation avant action sensible, journalisation, limites, supervision, tests et arrêt sûr. Le haut risque dépend des conditions de l’article 6, pas du mot « agent ». L’organisation doit réévaluer le dispositif dès qu’un nouvel outil ou pouvoir d’action lui est accordé.

Cluster éditorial : IA générative et systèmes agentiques · Intention : Comprendre les obligations AI Act pour les agents IA
En bref

L’essentiel à retenir

  1. 01

    Pas de catégorie juridique « agentique » autonome

  2. 02

    Qualification par finalité et action

  3. 03

    Permissions et validations graduées

  4. 04

    Traçabilité des plans, outils et effets

01

Décrire l’agent comme un système complet

Cartographiez le modèle, les instructions, la mémoire, les outils, les connecteurs, les données, les règles d’orchestration et les systèmes sur lesquels l’agent peut agir. Décrivez les déclencheurs, les étapes qu’il choisit, les validations humaines et les effets possibles. La qualification porte sur cet ensemble, pas seulement sur le modèle de langage.

Distinguez la suggestion, la préparation et l’exécution. Un agent qui propose un email n’a pas le même pouvoir qu’un agent qui l’envoie. Un agent qui lit un CRM diffère d’un agent qui modifie des dossiers ou accorde un avantage. Pour chaque action, notez la personne affectée, la réversibilité, la valeur engagée et le contrôle disponible.

Articles 3 et 6
02

Limiter les permissions et les chemins d’action

Appliquez le moindre privilège par outil, environnement et type de donnée. Séparez lecture et écriture. Exigez une validation avant un paiement, un message externe, une décision RH, une suppression ou une modification difficilement réversible. Fixez des limites de volume, de temps et de coût, puis testez l’arrêt lorsque l’agent dépasse son mandat.

Ne comptez pas uniquement sur une instruction en langage naturel. Combinez règles techniques, listes d’actions autorisées, contrôle des paramètres, authentification et environnements isolés. Les connecteurs doivent hériter d’autorisations adaptées, pas des droits complets du compte d’un administrateur. Préparez une voie manuelle lorsque l’agent est indisponible ou incertain.

Articles 9, 14 et 15
03

Tester les comportements émergents et les attaques

Construisez des scénarios avec objectifs ambigus, données contradictoires, outil indisponible, instruction malveillante dans un document, résultat partiel et tentative d’exfiltration. Vérifiez si l’agent demande une clarification, respecte les limites et produit une trace intelligible. Testez aussi les chaînes longues, car une petite erreur peut s’amplifier à chaque étape.

Évaluez la réussite métier et les effets indésirables : actions annulées, validations refusées, données exposées, coûts, latence, boucles et écarts entre populations. Conservez les versions du modèle, des outils et des scénarios. Une mise à jour d’un connecteur peut changer le comportement même si le modèle principal reste identique.

Articles 9 et 15
04

Rendre la supervision et la preuve possibles

La supervision doit intervenir au bon moment. Une approbation après l’action ne protège pas contre un effet irréversible. Présentez à la personne le contexte, le plan, les données utilisées et les conséquences. Elle doit pouvoir corriger, refuser ou arrêter, avec assez de temps et de compétence pour exercer ce pouvoir.

Journalisez la demande, le plan, les appels d’outils, les validations, les erreurs, l’action finale et la version, en limitant les données inutiles. Définissez les alertes et la procédure d’incident. Revoyez la qualification lorsqu’un agent reçoit un nouvel outil, une mémoire plus large, davantage d’autonomie ou une finalité qui affecte directement des personnes.

Articles 12, 14, 26 et 72

Questions fréquentes

Non. La classification dépend de la finalité et des conditions de l’article 6.

Pas nécessairement. La validation doit être proportionnée à l’impact, à la réversibilité et au risque.

Les éléments nécessaires pour reconstruire le plan, les outils utilisés, les validations, la version et l’effet.

Non. Il faut aussi des contrôles techniques, des permissions limitées, des tests et un arrêt sûr.

Transformez le règlement en plan d’action.

Cartographiez vos usages, qualifiez vos risques et priorisez vos preuves.