L'AI Act ne crée pas de catégorie juridique unique appelée « agent d'IA ». Les obligations dépendent du rôle de l'organisation — fournisseur, déployeur, importateur ou distributeur —, de la finalité prévue et du niveau de risque du système dans lequel s'intègre l'agent. L'architecture agentique accroît en revanche l'exigence pratique : davantage d'autonomie, d'outils, de mémoire et de capacité d'action imposent un meilleur inventaire, des limites, des journaux, une supervision et une sécurité renforcés.
La première obligation consiste à classifier le cas d'usage
Appeler une application « agent » ne détermine pas son régime juridique. Il faut analyser ce qu'elle fait réellement : recommande-t-elle, décide-t-elle, exécute-t-elle des actions, interagit-elle avec des personnes ou pilote-t-elle un processus ? Le contexte d'utilisation compte également. Un agent qui résume la documentation interne ne s'évalue pas comme celui qui filtre des candidatures, priorise des patients ou intervient dans un service essentiel.
La classification doit répondre, dans cet ordre, aux questions suivantes :
- La solution correspond-elle à la définition d'un système d'IA au sens du règlement ?
- Une pratique interdite s'applique-t-elle à cet usage précis ?
- Le système est-il à haut risque en raison de son produit ou de l'un des domaines de l'annexe III ?
- Les obligations de transparence de l'article 50 s'appliquent-elles ?
- L'organisation est-elle fournisseur ou déployeur, ou son rôle a-t-il changé en modifiant le système ?
- Un modèle à usage général intervient-il, et quelles obligations incombent à son fournisseur ?
- Quelles autres règles restent applicables : RGPD, droit de la consommation, droit du travail, secret professionnel, cybersécurité ou réglementation sectorielle ?
Le résultat est consigné par système et par version. « Nous utilisons l'IA » ne constitue pas un inventaire suffisant.
Rôles : qui doit faire quoi
Une entreprise qui achète un agent est en général déployeur, mais elle peut devenir fournisseur si elle commercialise la solution sous son propre nom, procède à une modification substantielle ou change la finalité prévue dans les cas visés par le règlement. La répartition contractuelle ne peut pas contredire la réalité opérationnelle.
| Rôle | Contrôle habituel | Preuves principales |
|---|---|---|
| Fournisseur | Conçoit ou met le système sur le marché | Gestion des risques, données, documentation, journaux, conformité et surveillance |
| Déployeur | Utilise le système sous son autorité | Usage conforme aux instructions, supervision, surveillance, journaux et impact |
| Importateur | Introduit un système de pays tiers | Vérifications et documentation exigibles |
| Distributeur | Le met à disposition dans la chaîne | Contrôles et coopération |
Dans une architecture associant modèle, plateforme, intégrateur, outils et client final, plusieurs acteurs peuvent intervenir. Une cartographie doit indiquer qui contrôle la finalité, les données, les prompts, les permissions, les mises à jour, les incidents et le retrait.
Calendrier et prudence réglementaire
Le règlement (UE) 2024/1689 est entré en vigueur en 2024 et s'applique de façon progressive. Les interdictions et l'obligation de maîtrise de l'IA ont commencé à s'appliquer le 2 février 2025 ; les règles relatives aux modèles à usage général, entre autres, depuis le 2 août 2025 ; et une partie substantielle du dispositif prend pour référence le 2 août 2026, avec d'autres échéances ultérieures.
Le calendrier doit être vérifié par rapport au texte en vigueur et à toute modification officiellement publiée. Le projet ne doit pas s'appuyer sur des annonces, des propositions législatives ou des résumés commerciaux. Même si une date change, l'inventaire, la maîtrise de l'IA, la sécurité, la traçabilité et la gouvernance demeurent des contrôles nécessaires.
Obligations techniques des systèmes à haut risque
Lorsqu'un agent fait partie d'un système à haut risque, le fournisseur doit satisfaire à des exigences telles que la gestion continue des risques, la gouvernance des données, la documentation technique, la tenue de journaux, l'information du déployeur, la supervision humaine, l'exactitude, la robustesse et la cybersécurité.
Gestion des risques tout au long du cycle de vie
Le dossier doit identifier les risques connus et prévisibles, y compris les usages raisonnablement prévisibles. Pour les agents, cela inclut la dérive de l'objectif, l'usage abusif des outils, les actions enchaînées, les habilitations excessives, les instructions incorporées dans des documents, la mémoire contaminée et la dépendance à des tiers.
Pour chaque risque, il faut documenter le scénario, les personnes ou biens concernés, la gravité, la probabilité, les mesures, les tests et le risque résiduel. L'évaluation est mise à jour à chaque changement de modèle, d'outil, de permission, de données, de finalité ou d'environnement.
Données et connaissances
Si des données sont utilisées pour l'entraînement, la validation ou les tests, des pratiques adéquates de gouvernance et de qualité doivent s'appliquer. En RAG, il faut également gouverner les documents, les index et les permissions, même si le modèle n'est pas réentraîné.
L'inventaire doit consigner la provenance, la licéité, la représentativité, la qualité, l'actualisation et les limites. Les extraits récupérés doivent être traçables jusqu'à leur source. L'agent ne doit pas pouvoir élever son propre résultat au rang de « mémoire validée » sans contrôle.
Documentation et journaux
La documentation doit permettre de comprendre la finalité, l'architecture, les dépendances, les capacités, les limites et les contrôles. Les journaux doivent permettre de reconstituer les décisions et les actions sans stocker les données personnelles sans discernement.
Une trace utile comprend :
- Identifiant et version du système.
- Modèle, prompt et politique appliqués.
- Données ou sources récupérées.
- Outils et arguments utilisés.
- Résultat et action exécutée.
- Approbation ou intervention humaine.
- Erreurs, tentatives, coût et latence.
Supervision humaine
La supervision ne peut pas se réduire à un bouton. La personne doit comprendre les capacités et les limites du système, détecter les anomalies, interpréter le résultat, éviter toute dépendance automatique, et pouvoir l'ignorer, l'arrêter ou l'annuler.
Les actions à fort impact doivent afficher les sources, l'incertitude, les données concernées et les conséquences. Si le volume d'alertes rend l'examen impraticable, la conception n'assure pas une supervision effective.
Exactitude, robustesse et cybersécurité
Les seuils sont définis par cas d'usage. Il faut tester les entrées normales, les cas limites, les attaques, la panne d'outils, les changements de version et les conditions défavorables. Pour les actions critiques, des classes d'erreur à tolérance zéro sont établies.
La cybersécurité couvre l'injection directe et indirecte, l'empoisonnement de la mémoire, l'usurpation d'identité, les outils malveillants, l'exfiltration de données et l'exécution inattendue. Les contrôles déterministes doivent se situer hors du modèle.
Obligations du déployeur
Pour les systèmes à haut risque, l'article 26 impose d'utiliser le système conformément aux instructions, de confier la supervision à des personnes compétentes, de contrôler les données d'entrée relevant de son contrôle et de surveiller le fonctionnement. En cas de risque ou d'incident grave détecté, les communications et mesures prévues doivent être déclenchées, y compris la suspension le cas échéant.
Le déployeur a besoin d'un dossier opérationnel couvrant :
- La finalité autorisée et les usages interdits.
- Les responsables et les personnes chargées de la supervision.
- La formation et la compétence.
- Les instructions internes.
- Les données et sources autorisées.
- La surveillance, les alertes et les incidents.
- La conservation des journaux.
- L'analyse d'impact le cas échéant.
- Le suivi des fournisseurs et des changements.
La conformité du fournisseur ne légitime pas tout usage fait par le client. Modifier la population, la décision ou le niveau d'autonomie peut modifier les risques et les obligations.
Transparence et contact avec les personnes
Lorsqu'une personne interagit avec un système d'IA, l'article 50 prévoit des obligations d'information dans les cas visés, sauf si cela ressort clairement des circonstances. Des règles existent également pour les contenus synthétiques ou manipulés dans certains cas.
Dans un agent de service client, cette information doit apparaître dès le début et expliquer comment joindre une personne. Il ne suffit pas de la dissimuler dans la politique de confidentialité. Si l'agent réalise une action ayant des conséquences, son rôle, ses limites et la voie de recours doivent être communiqués.
Maîtrise de l'IA
L'article 4 impose de prendre des mesures pour garantir un niveau suffisant de maîtrise de l'IA du personnel et des autres personnes qui exploitent des systèmes pour le compte de l'organisation, en tenant compte de leurs connaissances, de leur expérience, du contexte et des personnes concernées.
Un programme utile se conçoit par rôle :
| Rôle | Compétence minimale |
|---|---|
| Direction | Risque, responsabilités et décisions d'acceptation |
| Produit/processus | Finalité, limites, impact et supervision |
| Développement | Évaluation, sécurité, données et journaux |
| Utilisateurs | Usage prévu, vérification et escalade |
| Confidentialité/conformité | Classification, droits et preuves |
| Support | Incidents, retrait et communication |
La preuve comprend le programme, la présence, l'évaluation et l'application pratique, pas seulement une vidéo générale.
Architecture de contrôle pour les agents
- Identité propre : jamais un compte administrateur partagé.
- Permission minimale : par outil, donnée, action, volume et durée.
- Politique déterministe : valide chaque action hors du modèle.
- Approbation selon l'impact : préalable pour les décisions difficiles à annuler.
- Idempotence : une nouvelle tentative ne duplique pas les opérations.
- Isolement : code et pièces jointes dans des environnements restreints.
- Provenance : sources et mémoire associées à un propriétaire et une date.
- Limites : étapes, coût, durée et périmètre.
- Journaux : reconstitution complète avec minimisation des données.
- Arrêt : mécanisme indépendant pour suspendre les actions.
Plan de mise en conformité en 60 jours
Jours 1 à 15
- Inventorier les agents, modèles, outils et responsables.
- Classifier le rôle, le risque et le calendrier.
- Arrêter les usages interdits ou sans responsable.
- Cartographier les données, actions et personnes concernées.
Jours 16 à 30
- Créer un dossier par système.
- Revoir les contrats, instructions et documentation du fournisseur.
- Définir la supervision, les usages interdits et les indicateurs.
- Réaliser une analyse RGPD et des droits fondamentaux le cas échéant.
Jours 31 à 45
- Déployer identité, permissions, politiques, journaux et arrêt.
- Construire des tests fonctionnels et adverses.
- Former chaque rôle.
- Simuler des incidents et la suspension.
Jours 46 à 60
- Fonctionner en mode miroir ou en pilote limité.
- Corriger les défaillances et calculer le risque résiduel.
- Approuver l'usage et consigner les conditions.
- Programmer la surveillance et la réévaluation.
Checklist avant mise en production
- Rôle et classification documentés.
- Finalité et usages interdits approuvés.
- Obligations vérifiées officiellement selon le calendrier.
- Données, outils et fournisseurs inventoriés.
- Gestion des risques et tests à jour.
- Supervision humaine effective.
- Identité, permissions minimales et arrêt déployés.
- Journaux permettant de reconstituer décisions et actions.
- Transparence et escalade vers une personne configurées.
- Maîtrise de l'IA attestée par rôle.
- RGPD, AIPD et réglementation sectorielle coordonnés.
Questions fréquentes
Tout agent est-il à haut risque ?
Non. Cela dépend de la finalité et du domaine. L'autonomie ne rend pas automatiquement un système à haut risque, mais elle peut accroître le risque technique et organisationnel.
Acheter un agent transfère-t-il toute la responsabilité au fournisseur ?
Non. Celui qui le déploie doit contrôler la finalité, les données, la supervision, la surveillance et l'impact. Il peut en outre devenir fournisseur s'il modifie substantiellement le système ou sa finalité dans les cas prévus par le règlement.
Un chatbot doit-il s'identifier comme IA ?
Dans les cas visés à l'article 50, les personnes doivent être informées qu'elles interagissent avec l'IA, sauf si cela est évident, et de façon claire et en temps utile.
L'AI Act remplace-t-il le RGPD ?
Non. Ce sont des cadres complémentaires. Un système peut respecter les exigences de l'AI Act et continuer d'enfreindre la protection des données s'il manque de base juridique, de minimisation ou de transparence.
Les journaux doivent-ils tout conserver ?
Non. Ils doivent permettre la traçabilité en appliquant la minimisation, la sécurité et des durées de conservation. Les prompts peuvent contenir des données personnelles ou des secrets.
Summum IA peut accompagner la classification technique, l'architecture et l'évaluation des agents, ainsi que la conception d'agents d'IA et le LLMOps associé. L'interprétation juridique et le calendrier doivent être validés avant la publication et le déploiement.