Risques Réglementaires des AI Agents Non Contrôlés

Les risques réglementaires des AI agents représentent aujourd'hui l'angle mort le plus dangereux de la conformité cyber. En 2026, des centaines d'entreprises françaises déploient des agents autonomes — systèmes capables de percevoir leur environnement, de raisonner et d'agir sans supervision humaine continue — sans avoir mesuré les implications légales. Un agent de recrutement automatisé qui filtre les CV sans supervision humaine, un système de trading algorithmique basé sur un LLM, ou un agent de gestion des incidents qui déclenche des isolements réseau de manière autonome : tous tombent potentiellement dans le périmètre de l'AI Act 2026 et de ses exigences pour les systèmes à haut risque. L'Règlement (UE) 2024/1689 sur l'IA est entré en vigueur le 1er août 2024. Les interdictions s'appliquent depuis le 2 février 2025, les obligations sur les systèmes à haut risque depuis le 2 août 2026. Le calendrier est là. La question n'est plus de savoir si votre organisation doit se conformer, mais combien de temps elle a pour combler ses lacunes — et quelles sont les sanctions qui l'attendent si elle ne le fait pas.

Qu'est-ce qu'un agent IA au sens réglementaire ?

La confusion terminologique est le premier obstacle. Un « agent IA » au sens réglementaire n'est pas simplement un chatbot ou un modèle de langage. C'est un système autonome capable d'agir sur son environnement pour atteindre des objectifs définis, souvent sans validation humaine de chaque action individuelle. AutoGPT, CrewAI, les pipelines LangChain en mode agentic, les systèmes de RPA augmentés par LLM, les plateformes de trading algorithmique basées sur des modèles génératifs : autant de systèmes qui dépassent le simple statut d'outil d'assistance.

L'AI Act distingue plusieurs catégories. Les systèmes d'IA interdits (Art. 5) incluent les systèmes de notation sociale, la manipulation psychologique inconsciente, le scraping biométrique non ciblé. Les systèmes à haut risque (Art. 6, Annexe III) couvrent huit domaines : infrastructures critiques, éducation, emploi et gestion RH, accès aux services essentiels, répression, migration et asile, administration de la justice, démocratie. Si votre agent IA opère dans l'un de ces domaines — et c'est souvent le cas pour les agents métier déployés en entreprise — vous êtes soumis aux exigences des articles 9 à 17.

Concrètement, un agent de recrutement automatisé qui filtre, classe et shortliste des candidats sans revue humaine systématique tombe dans la catégorie « emploi et gestion RH » de l'Annexe III. Un agent SOC qui isole automatiquement des postes sur la base d'alertes IA peut toucher aux infrastructures critiques si l'organisation est opérateur NIS2. Un agent financier qui ajuste les limites de crédit client en temps réel relève de l'accès aux services essentiels. La liste est longue, et beaucoup d'organisations ont déployé ces systèmes sans avoir fait cette analyse.

Les obligations spécifiques pour les systèmes à haut risque

Pour les agents IA classés à haut risque, l'AI Act impose un programme de conformité substantiel. Pas des recommandations — des obligations légales, auditables, avec responsabilité des fournisseurs et des déployeurs.

Article 9 — Système de gestion des risques : un processus continu d'identification, d'analyse et d'atténuation des risques tout au long du cycle de vie du système. Ce n'est pas un document statique — c'est un processus vivant avec revues périodiques. Pour les organisations qui déploient des agents IA tiers (et non des systèmes développés en interne), cela signifie obtenir la documentation de gestion des risques du fournisseur et l'intégrer dans leur propre SMSI.

Article 11 — Documentation technique : le fournisseur ou déployeur doit maintenir une documentation détaillée couvrant la description générale du système, les données d'entraînement (provenance, preprocessing, biais identifiés), les mesures de performance, les tests de robustesse et les instructions d'utilisation. Pour les agents IA basés sur des LLMs commerciaux (GPT-4o, Claude, Gemini), cette documentation est partiellement fournie par l'éditeur — mais la responsabilité du déploiement reste chez l'organisation.

Article 13 — Transparence et traçabilité : les utilisateurs humains doivent savoir qu'ils interagissent avec un système d'IA, comprendre ses capacités et ses limites, et disposer d'informations sur son fonctionnement. Pour un agent RH, cela signifie informer les candidats que leur dossier est traité par un système automatisé — avec les droits RGPD Art. 22 qui s'appliquent en parallèle.

Article 14 — Supervision humaine : c'est l'exigence la plus structurante pour les agents autonomes. Le système doit être conçu pour permettre aux superviseurs humains d'intervenir, de remplacer ou d'annuler toute décision automatique. L'agent qui agit de manière totalement autonome sans mécanisme de « human-in-the-loop » ou « human-on-the-loop » est non conforme par construction. J'ai vu des déploiements d'agents SOC où la vitesse d'action était l'argument principal pour supprimer la validation humaine — c'est exactement le type de configuration qui pose problème.

Pourquoi DORA ajoute une couche de complexité pour le secteur financier ?

Pour les banques, assureurs, gestionnaires d'actifs et autres entités couvertes par DORA (Digital Operational Resilience Act), les agents IA ne sont pas uniquement un sujet AI Act. Ils sont aussi — et simultanément — un sujet de résilience opérationnelle numérique.

L'article 4 de DORA impose un cadre de gestion des risques liés aux TIC qui couvre l'ensemble des actifs numériques, y compris les systèmes IA. Tout outil IA utilisé dans des processus métier critiques (gestion du risque, détection de fraude, notation de crédit, gestion de portefeuille) doit être identifié dans le registre des actifs TIC, faire l'objet d'une analyse de risque documentée et être couvert par des plans de continuité.

L'article 25 de DORA ajoute les tests de résilience opérationnelle numérique. Pour les entités d'importance significative, cela inclut des tests de pénétration basés sur la menace (TLPT) qui doivent couvrir les systèmes critiques — y compris les agents IA. Comment se comporte votre agent de trading si le LLM sous-jacent reçoit des données d'entrée adversariales ? Si le fournisseur du modèle connaît une interruption ? Ces questions doivent avoir des réponses documentées et testées.

La double conformité AI Act + DORA n'est pas une somme d'obligations — c'est une interaction complexe. Certaines exigences se renforcent mutuellement (la documentation technique AI Act alimente le registre DORA), d'autres créent des tensions (la vitesse d'action d'un agent IA financier vs l'obligation de supervision humaine AI Act). La gouvernance LLM en conformité AI Act et RGPD fournit un cadre de résolution de ces tensions.

NIS2 et les agents IA : quand l'automatisation touche les infrastructures critiques

NIS2 élargit considérablement le périmètre des entités soumises à des exigences de sécurité renforcée. Pour ces entités — opérateurs essentiels et importants dans les secteurs énergie, transport, santé, eau, digital — les agents IA qui participent à la gestion des systèmes tombent dans le périmètre de l'article 21.

L'article 21 de NIS2 impose des mesures de sécurité proportionnées couvrant notamment la gestion des risques liés à la chaîne d'approvisionnement (§ 2d), la sécurité dans l'acquisition des systèmes (§ 2e), et la gestion des incidents (§ 2b). Un agent IA qui gère des alertes de sécurité de manière autonome dans une centrale électrique, un hôpital ou un opérateur télécom est directement concerné par ces obligations.

La notification d'incidents pose une question spécifique pour les agents IA : si un agent prend une mauvaise décision autonome — isole le mauvais segment réseau, rate une alerte critique, ou pire, génère une action erronée suite à une attaque adversariale — cela constitue-t-il un incident NIS2 à notifier à l'ANSSI sous 24h ? La réponse courte : possiblement oui, si cela a un impact significatif sur la continuité des services. L'organisation doit avoir anticipé ce scénario dans ses procédures de réponse aux incidents.

RGPD Art. 22 : la brique souvent oubliée

Avant l'AI Act, le RGPD avait déjà posé les bases de la réglementation des décisions automatisées. L'article 22 interdit les décisions produisant des effets juridiques ou affectant significativement une personne physique, fondées uniquement sur un traitement automatisé, sauf exceptions légales explicites.

Pour un agent IA, les « effets significatifs » couvrent un spectre large : refus d'une demande de prêt, rejet d'une candidature d'emploi, calcul d'une prime d'assurance, décision de résiliation d'un contrat. Si votre agent prend ces décisions sans que l'humain ne valide au cas par cas, vous avez besoin d'une base légale spécifique (consentement explicite, nécessité contractuelle ou autorisation légale), d'une procédure de recours accessible et d'un mécanisme d'intervention humaine sur demande de la personne concernée.

Le DPO doit donc être impliqué dans la gouvernance des agents IA — pas en bout de chaîne pour valider un système déjà déployé, mais en amont, lors de la conception et avant tout déploiement. C'est ce qu'impose l'article 35 RGPD sur les analyses d'impact (DPIA), obligatoires dès lors qu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés — ce qui est fréquemment le cas pour les agents IA décisionnels.

Quelles sanctions concrètes risque-t-on en 2026 ?

Les chiffres sont connus, mais les mécanismes d'application le sont moins. L'AI Act crée un système de supervision à deux niveaux : la Commission européenne pour les modèles d'usage général (GPAI) et les autorités nationales pour les autres systèmes. En France, la désignation de l'autorité nationale compétente est en cours — la CNIL, l'ANSSI et l'Arcom sont tous des candidats potentiels selon les domaines.

Les sanctions maximales : 35 millions d'euros ou 7 % du CA mondial annuel pour l'utilisation de systèmes d'IA interdits (Art. 5) ; 15 millions ou 3 % pour le non-respect des obligations des systèmes HR ; 7,5 millions ou 1,5 % pour la fourniture d'informations incorrectes aux autorités. Ces plafonds s'appliquent par infraction — pas globalement.

Pour DORA, les sanctions sont déterminées par les autorités compétentes nationales (BCE, ACPR, AMF) et peuvent aller jusqu'à 10 millions d'euros ou 5 % du CA annuel total pour les entités financières, avec possibilité de sanctions individuelles contre les dirigeants (jusqu'à 5 millions d'euros pour les personnes physiques).

La vraie question n'est pas le montant théorique des amendes. C'est la réputation. Les premières décisions de sanction AI Act, attendues courant 2027 après les premières vagues d'inspection, seront publiques et médiatisées. Les organisations qui peuvent démontrer un programme de gouvernance IA documenté et actif seront dans une position infiniment plus confortable que celles qui n'ont rien fait.

Comment construire un programme de gouvernance des agents IA ?

Un programme de gouvernance efficace des agents IA s'articule autour de quatre piliers. Ce n'est pas une check-list à cocher une fois — c'est un processus continu qui s'intègre dans le SMSI existant.

Pilier 1 — Inventaire et classification. Cartographier tous les systèmes IA déployés dans l'organisation, y compris les outils SaaS qui intègrent des fonctionnalités IA (Salesforce Einstein, Microsoft Copilot, ServiceNow AI, etc.). Pour chaque système, appliquer la grille de classification AI Act : interdit, à haut risque, risque limité, risque minimal. Inclure les systèmes IA des prestataires et sous-traitants qui agissent pour le compte de l'organisation. Voir les implications pour les systèmes agentiques sous l'AI Act 2026.

Pilier 2 — Documentation technique. Pour chaque système à haut risque, constituer et maintenir à jour le dossier technique Art. 11 : description fonctionnelle, architecture technique, données utilisées (entraînement et production), métriques de performance, tests de robustesse réalisés, limitations identifiées et instructions d'utilisation. Ce dossier doit être disponible sur demande de l'autorité de supervision — délai de réponse typiquement fixé à 15 jours ouvrés.

Pilier 3 — Supervision humaine structurée. Définir pour chaque agent IA le modèle de supervision : human-in-the-loop (validation humaine avant chaque action), human-on-the-loop (monitoring avec possibilité d'intervention), human-in-command (configuration et objectifs définis par l'humain mais exécution autonome). L'Art. 14 AI Act impose que la supervision humaine soit effective, pas nominale. Un superviseur qui valide 500 décisions par heure sans capacité réelle de revue n'est pas conforme.

Pilier 4 — Logging et auditabilité. Les agents IA à haut risque doivent générer des logs automatiques permettant de reconstituer leur fonctionnement a posteriori (Art. 12 AI Act). Cela inclut les entrées reçues, les sorties produites, les décisions prises, et l'identité du superviseur humain s'il y a eu intervention. La durée de rétention doit être alignée avec les exigences légales applicables — généralement 5 ans pour les secteurs financiers sous DORA.

Les pièges classiques dans la mise en conformité

Après avoir accompagné plusieurs organisations dans leur mise en conformité AI Act, j'ai identifié des patterns d'erreur récurrents. Le premier : confondre le fournisseur du modèle et le déployeur. OpenAI, Anthropic ou Google sont des fournisseurs de modèles. Si votre organisation déploie ces modèles dans un contexte à haut risque, vous êtes le déployeur — avec les obligations qui vont avec. La conformité du modèle sous-jacent ne vous exonère pas de vos propres obligations.

Le deuxième piège : traiter l'AI Act comme un projet IT. C'est un sujet de gouvernance organisationnelle. Le RSSI ne peut pas le gérer seul — il faut impliquer le DPO, le DSI, la direction juridique, les métiers utilisateurs et la direction générale. La responsabilité des déployeurs (Art. 26 AI Act) remonte jusqu'aux dirigeants.

Troisième erreur fréquente : négliger les agents IA dans la chaîne d'approvisionnement. Si un prestataire utilise des agents IA pour traiter des données pour votre compte, ou si votre produit intègre des composants IA tiers, l'analyse de risque et les obligations contractuelles doivent couvrir cette chaîne. Les contrats fournisseurs doivent être revus pour inclure des clauses spécifiques AI Act (fourniture de documentation, droit d'audit, notification des changements de modèle).

Tableau de synthèse : obligations par cadre réglementaire

Quels sont les agents IA réellement interdits par l'AI Act ?

L'article 5 dresse une liste de pratiques totalement interdites depuis le 2 février 2025. Quelques exemples concrets qui concernent les agents IA en entreprise : les systèmes qui utilisent des techniques subliminales pour influencer le comportement d'une personne sans qu'elle en ait conscience, les systèmes d'inférence d'émotions sur le lieu de travail (monitoring émotionnel des salariés par IA), les systèmes de catégorisation biométrique déduisant des caractéristiques protégées (orientation sexuelle, opinions politiques).

Ces interdictions s'appliquent aussi aux systèmes développés en interne. Une organisation qui déploie un outil de monitoring des collaborateurs basé sur l'analyse des expressions faciales viole l'Art. 5 — indépendamment de ses intentions ou de la sophistication technique du système.

Questions fréquentes

Un chatbot interne basé sur ChatGPT est-il soumis à l'AI Act ?

Cela dépend de l'usage. Un chatbot d'assistance générale (FAQ interne, support RH) est probablement en risque limité ou minimal — peu d'obligations formelles. Si ce chatbot participe à des décisions de recrutement, d'évaluation des performances ou d'accès à des services essentiels, il peut basculer en haut risque. L'analyse de classification est indispensable avant déploiement, pas après.

L'AI Act s'applique-t-il aux agents IA développés avant son entrée en vigueur ?

Les systèmes à haut risque mis sur le marché avant le 2 août 2026 ont jusqu'au 2 août 2027 pour se conformer, à condition qu'ils ne subissent pas de modifications significatives. Mais « modification significative » est interprété largement — un changement de modèle sous-jacent, une extension de fonctionnalités ou un nouveau cas d'usage peuvent déclencher les obligations immédiatement. Ne pas attendre 2027 pour commencer.

Qui est responsable : le fournisseur du LLM ou l'entreprise qui le déploie ?

La responsabilité est partagée et complémentaire. Le fournisseur du modèle de base est responsable de la documentation du modèle, des tests de robustesse et des limitations identifiées. Le déployeur est responsable de l'application appropriée du modèle dans son contexte, de la supervision humaine, de la documentation du déploiement et de la conformité aux obligations sectorielles (DORA, NIS2). En cas de violation, les deux peuvent être sanctionnés.

Comment prioriser les actions face à la complexité réglementaire ?

Commencez par l'inventaire. Sans cartographie complète des agents IA déployés — y compris les usages non officiels (shadow AI) — toute priorisation est aveugle. Ensuite, classifiez. Concentrez les efforts sur les systèmes à haut risque Art. 6 et les systèmes utilisés dans des processus à fort impact humain. Enfin, documentez. La documentation technique est la première chose que demandera une autorité de contrôle.

Le shadow AI est-il un risque réglementaire distinct ?

Absolument. Un collaborateur qui utilise ChatGPT avec des données clients pour générer des rapports, sans autorisation ni encadrement, crée un risque RGPD (transfert de données hors UE sans garanties), un risque AI Act (déploiement non documenté) et un risque DORA si c'est dans une entité financière. La politique d'usage IA n'est pas qu'un document RH — c'est un outil de réduction du risque réglementaire.

Conclusion

La conformité réglementaire n'est pas une destination mais un état à maintenir. Chaque évolution du SI, chaque nouveau fournisseur peut modifier le périmètre. Documentation, audits réguliers et formation des équipes en sont les piliers.