Conformité à la loi sur l'IA de l'UE pour les déploiements d'agents IA : les obligations article par article

L'échéance

Le 2 août 2026, la loi sur l'IA de l'UE (règlement (UE) 2024/1689) atteint son prochain jalon d'application. Le reste de la loi entre en vigueur — y compris les obligations pour les systèmes d'IA à haut risque, les exigences de transparence pour le contenu généré par IA et les dispositions pénales. L'amende maximale est de 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.

La loi est entrée en vigueur le 1er août 2024. Les interdictions sur les pratiques à risque inacceptable (notation sociale, manipulation subliminale, surveillance biométrique en temps réel dans les espaces publics) s'appliquent depuis le 2 février 2025. Les obligations pour les modèles d'IA à usage général et les règles de gouvernance s'appliquent depuis le 2 août 2025. Le calendrier de mise en œuvre confirme que le 2 août 2026 est la date à laquelle les mandats pour systèmes à haut risque, les obligations de transparence et le cadre pénal prennent plein effet — avec des exceptions limitées pour les systèmes de l'article 6(1), qui suivent en août 2027.

Pour les organisations qui déploient des agents IA qui prennent ou appuient des décisions sur le crédit, l'emploi, l'accès aux services essentiels ou les infrastructures critiques, le 2 août est la date de conformité. Pas une date de planification. Pas une date de révision. La date à laquelle les obligations sont exigibles.

La frontière de conformité s'étend à la couche d'action

La plupart des organisations concentrent leurs efforts de conformité IA sur le modèle — gouvernance des données d'entraînement, tests de biais, surveillance des sorties. L'analyse de conformité de Salt Security clarifie que cela est insuffisant. Le champ de la loi s'étend à ce que le modèle fait, pas seulement à ce qu'il produit.

L'article 15 (Cybersécurité) exige la protection contre les attaques adverses, l'empoisonnement de données, les attaques de confidentialité et l'évasion de modèle. L'analyse de Salt Security confirme que cette protection « doit s'étendre aux interfaces par lesquelles les systèmes d'IA interagissent avec le monde (API et serveurs MCP) ». Un agent IA qui appelle NetSuite via un module Model Context Protocol, ou qui lit des données clients depuis HubSpot via un connecteur MCP, intègre ces interfaces dans la frontière de conformité.

Les considérants 99 et 100 traitent des architectures multi-agents explicitement. Dans une chaîne d'agents IA, la frontière de conformité s'étend à chaque agent qui remplit une fonction à haut risque. Si un agent orchestrateur délègue une décision de prix à un sous-agent qui appelle un moteur RFQ, les deux agents héritent des obligations. Le périmètre de conformité est la chaîne d'appels complète, pas le point d'entrée.

Ce qui compte comme haut risque

La loi définit les systèmes d'IA à haut risque à l'article 6 et à l'annexe III. Les catégories les plus pertinentes pour les déploiements d'agents B2B :

• Emploi et gestion des travailleurs — tri des CV, décisions de promotion, allocation des tâches, surveillance des performances
• Accès aux services essentiels — scoring de crédit, tarification des assurances, déterminations d'éligibilité
• Composants de sécurité des infrastructures critiques — transport, énergie, eau
• Application de la loi et justice — bien que la plupart des déploiements B2B ne relèvent pas de cette catégorie

Un agent d'approvisionnement qui évalue les devis fournisseurs et recommande des décisions d'attribution touche au territoire de l'accès aux services essentiels si l'achat porte sur des biens régulés ou des contrats du secteur public. Un agent de devis qui tarife différemment par palier client touche au territoire du crédit et de l'assurance si la tarification affecte l'accès aux produits financiers. La classification dépend de la fonction que l'IA remplit, pas du secteur de l'entreprise qui la déploie.

Pour les systèmes qui n'atteignent pas le seuil de haut risque, les obligations de transparence s'appliquent tout de même. L'article 50 exige que les déployeurs informent les personnes lorsqu'elles interagissent avec des systèmes d'IA (chatbots, génération de contenu). Le contenu d'IA générative doit être identifiable. Ces obligations prennent effet le 2 août 2026.

Les obligations article par article

Pour les systèmes à haut risque, la loi impose des obligations spécifiques et auditable. L'analyse de Salt Security fournit la décomposition au niveau des articles. Voici ce que chaque article exige et comment il se correspond à l'infrastructure des agents.

Article 9 — Gestion des risques

Un système de gestion des risques continu et itératif tout au long du cycle de vie de l'IA. Pas une évaluation unique avant le déploiement. Le système doit identifier, analyser et atténuer les risques connus et prévisibles, y compris les risques émergeant après la mise sur le marché du système.

Ce que cela signifie pour les agents : Le registre des risques est un document vivant. Chaque nouveau module MCP, chaque nouveau connecteur, chaque nouvel enregistrement d'outil est une surface de risque qui doit être évaluée. Une couche de gouvernance qui journalise chaque appel d'outil et son résultat fournit la base de preuves pour la revue itérative des risques — sans elle, le système de gestion des risques n'a pas de données.

Article 10 — Gouvernance des données

Des jeux de données de haute qualité pour minimiser les résultats discriminatoires. Les protections contre l'accès non autorisé et l'empoisonnement de données doivent s'étendre au moment de l'inférence — lorsque les agents IA appellent activement des API et accèdent à des données externes.

Ce que cela signifie pour les agents : Les données que l'agent lit à l'exécution (depuis NetSuite, BigCommerce, catalogues fournisseurs) sont dans le périmètre. Si un catalogue fournisseur est empoisonné avec des données tarifaires incorrectes et que l'agent émet des devis à partir de celui-ci, l'obligation de gouvernance des données s'applique. La validation des entrées sur les réponses des outils MCP n'est pas un détail de qualité — c'est un contrôle de conformité.

Article 11 — Documentation technique

Un inventaire complet de tous les composants, interfaces et capacités avant la mise sur le marché. Pour un système d'agents, cela signifie documenter chaque module MCP, chaque outil qu'il enregistre, chaque système en amont auquel il se connecte et chaque chemin d'erreur qu'il gère.

Ce que cela signifie pour les agents : Le registre des modules est la documentation. Un système qui enregistre dynamiquement des modules MCP avec schémas, limites de débit et journaux d'audit produit la documentation technique comme sous-produit de son architecture. Un système de scripts ad hoc et d'appels API non enregistrés ne le fait pas.

Article 12 — Conservation des registres (journalisation)

Journalisation automatique de tous les événements. Les journaux doivent être infalsifiables et conservés pendant un minimum de 6 mois (24 mois pour les systèmes biométriques et d'application de la loi). Chaque appel d'outil, chaque décision de l'agent, chaque intervention humaine doit pouvoir être reconstruit à partir des journaux.

Ce que cela signifie pour les agents : Chaque appel d'outil MCP doit être journalisé avec horodatage, ID de l'agent, nom de l'outil, hachage de l'entrée (pas l'entrée brute — frontière PII), statut de sortie et durée. Le journal doit être à ajout seul ou infalsifiable. La rétention de 6 mois est un minimum, pas un objectif. C'est l'obligation la plus directement mappable : une architecture MCP gouvernée qui journalise chaque appel de fonction dans DynamoDB avec des champs structurés satisfait l'article 12 par construction.

Article 14 — Surveillance humaine

Le système doit permettre aux opérateurs humains de superviser, d'intervenir et d'arrêter le système en temps réel lorsqu'un comportement anormal est détecté. Il ne s'agit pas d'un tableau de bord de surveillance qui affiche des métriques a posteriori. C'est la capacité d'arrêter un agent en cours d'exécution à mi-tâche.

Ce que cela signifie pour les agents : Les instructions au niveau du prompt (« arrête », « annule ») ne constituent pas une surveillance au sens de la loi. Elles font partie du contexte conversationnel de l'IA et peuvent être ignorées en cas de perte de mémoire ou d'injection de prompt. La loi exige un mécanisme d'arrêt déterministe qui opère en dehors du processus de raisonnement de l'IA. Un kill-switch qui révoque le jeton d'authentification d'un agent, désactive un module MCP spécifique par changement de configuration ou déclenche un disjoncteur sur des patterns de comportement anormaux satisfait l'article 14. Une commande « arrête » non.

L'analyse de l'architecture de kill-switch de miniOrange définit quatre couches qui correspondent à cette obligation :

1. Révocation d'accès basée sur l'identité — jetons de session de courte durée liés à des tâches spécifiques ; révocation instantanée des identifiants
2. Disjoncteurs et détection d'anomalies — déclencheurs sur requêtes API excessives, consommation inhabituelle de jetons, boucles répétées
3. Révocation de capacité délimitée — désactiver uniquement la capacité dangereuse (par ex., retirer l'autorisation d'envoi d'e-mails mais conserver la lecture de tickets)
4. Gestion des tâches en cours — annuler les modifications incomplètes, préserver les journaux d'exécution, vérifier la stabilité du système après l'arrêt

L'incident OpenClaw documenté dans la même analyse illustre pourquoi l'arrêt au niveau du prompt échoue : un agent IA qui organisait une boîte de réception a dépassé sa limite de mémoire, perdu le contexte et est revenu à son dernier objectif mémorisé — supprimer des e-mails. Les commandes « arrête » et « annule » de l'utilisateur ont été ignorées. L'agent a continué jusqu'à ce qu'il soit terminé manuellement au niveau du système d'exploitation. La défaillance était architecturale : aucun mécanisme d'arrêt déterministe n'existait en dehors du processus de raisonnement de l'IA.

Article 15 — Cybersécurité

Robustesse technique contre les attaques adverses, l'empoisonnement de données, les attaques de confidentialité et l'évasion de modèle. La protection doit s'étendre aux interfaces par lesquelles l'IA interagit avec le monde.

Ce que cela signifie pour les agents : Chaque serveur MCP, chaque endpoint d'API, chaque connecteur est dans le périmètre. Le paysage de sécurité MCP documenté en 2026 — la faille systémique de conception STDIO affectant 150 millions de téléchargements, CVE-2026-33032 (« MCPwn », CVSS 9,8), CVE-2026-0755 (Gemini MCP, CVSS 9,8), 30 à 82 pour cent des serveurs MCP publics portant des failles exploitables — est le risque de cybersécurité que la loi cible. Seulement 8,5 pour cent des serveurs MCP utilisent OAuth. La loi n'impose pas OAuth spécifiquement, mais elle impose un niveau de cybersécurité que l'écosystème MCP actuel ne respecte pas par défaut.

Articles 72 et 73 — Surveillance post-marché et notification d'incidents

Un système de surveillance documenté dès le premier jour de déploiement. Fenêtres de notification d'incidents :

• 24 heures pour les risques pour la vie ou la sécurité
• 72 heures pour les autres incidents graves
• 15 jours pour les dysfonctionnements

Ce que cela signifie pour les agents : Le journal d'audit est la source du rapport d'incident. Lorsqu'un agent dépasse les permissions, effectue un appel non autorisé ou produit une sortie incorrecte qui affecte une décision, le journal reconstruit ce qui s'est passé. Les fenêtres de 24 et 72 heures signifient que le système de surveillance doit alerter en temps réel, pas lors d'une revue hebdomadaire.

L'écart de gouvernance

Le State of AI in the Enterprise 2026 de Deloitte a révélé qu'une entreprise sur cinq seulement dispose d'un modèle mature de gouvernance des agents IA autonomes. Quarante-sept à cinquante-trois pour cent des organisations ont vu des agents IA dépasser les permissions ou subir un incident, selon le rapport 2026 de practical-devsecops. Seulement 23 pour cent ont une stratégie formelle d'identité des agents IA.

La loi ne prescrit pas une architecture spécifique. Elle prescrit des résultats : une gestion des risques qui soit continue, une journalisation qui soit automatique et infalsifiable, une surveillance qui puisse arrêter le système de manière déterministe, une cybersécurité qui s'étende à chaque interface. L'architecture qui satisfait ces résultats est le pattern de module MCP gouverné — le même pattern qui adresse les vulnérabilités de sécurité documentées tout au long de la chronologie des brèches MCP de 2026.

Comment une architecture MCP gouvernée satisfait les obligations

La couche de gouvernance qui rend les modules MCP sûrs à exploiter en production est la même couche qui satisfait les exigences de la loi. La correspondance est directe :

Article de la loi sur l'IA de l'UE	Obligation	Contrôle de gouvernance
Article 9 (Gestion des risques)	Évaluation des risques continue et itérative	Chaque appel d'outil journalisé avec son résultat ; registre des risques mis à jour depuis les données d'audit
Article 10 (Gouvernance des données)	Protection au moment de l'inférence	Validation des entrées sur les réponses des outils MCP ; erreurs typées qui distinguent les défaillances de qualité des données des erreurs transitoires
Article 11 (Documentation technique)	Inventaire complet des composants et interfaces	Registre des modules : chaque module MCP, schéma d'outil, connexion en amont, code d'erreur documentés à l'enregistrement
Article 12 (Conservation des registres)	Journalisation automatique et infalsifiable, rétention de 6 mois	Journaux JSON structurés dans DynamoDB : horodatage, ID de l'agent, nom de l'outil, hachage d'entrée, statut de sortie, durée ; à ajout seul avec isolation de locataire par partition key
Article 14 (Surveillance humaine)	Capacité d'arrêt en temps réel	Kill-switch : révocation d'identité (jetons JWT de courte durée), disjoncteurs (limites de débit par outil par fenêtre), révocation de capacité délimitée (désactiver le module par changement de configuration), annulation en cours
Article 15 (Cybersécurité)	La protection s'étend aux API et serveurs MCP	Authentification OAuth/Cognito, limites de débit, traitement de la frontière PII (hachage SHA-256 des champs avant journalisation), contrats d'erreur typés
Articles 72-73 (Notification d'incidents)	Fenêtres de signalement de 24/72 heures	Détection d'anomalies en temps réel depuis le journal d'audit ; alertes sur dépassement de permissions, appels d'outils inattendus, violations de limite de débit

L'idée clé est que ces contrôles ne sont pas ajoutés a posteriori. Ils sont la structure du pipeline d'enregistrement, d'exécution et de journalisation des modules MCP. Un module qui enregistre ses outils avec des schémas, déclare ses limites de débit, journalise chaque appel dans un magasin à ajout seul et peut être désactivé par un changement de configuration produit les preuves de conformité comme sous-produit de son fonctionnement. Un agent ad hoc qui appelle les API directement ne le fait pas — et adapter des contrôles de conformité à un agent non gouverné est plus coûteux que de les intégrer dès le départ.

La frontière de conformité multi-agents

Les considérants 99 et 100 étendent la frontière de conformité à chaque agent d'une chaîne qui remplit une fonction à haut risque. Cela a une implication architecturale que la plupart des organisations n'ont pas encore intégrée.

Considérez un flux de travail d'approvisionnement : un agent orchestrateur reçoit un RFQ, délègue la résolution des produits à un agent de catalogue, délègue la tarification à un agent de moteur de devis et délègue l'écriture de la commande à un agent d'intégration ERP. Au sens de la loi, si l'un de ces agents remplit une fonction à haut risque (tarification qui affecte l'accès au crédit, sélection de fournisseurs qui affecte l'emploi, achat de biens régulés), chaque agent de la chaîne hérite de l'obligation.

Cela signifie que la couche de gouvernance doit être au niveau de l'orchestration, pas au niveau de l'agent individuel. La journalisation doit tracer la chaîne d'appels complète — quel agent a appelé quel module avec quels arguments et quel a été le résultat. Le registre des modules doit couvrir chaque module de chaque agent. Le kill-switch doit pouvoir arrêter la capacité d'un agent spécifique sans désactiver l'infrastructure partagée.

Le pattern d'isolation de locataire par partition_key — où chaque enregistrement d'appel de fonction MCP porte une partition key qui le délimite à un locataire et un endpoint spécifiques — fournit la structure de trail d'audit que la conformité multi-agents exige. Une requête contre le journal des appels de fonction peut reconstruire l'état complet du flux de travail : quel agent a déclenché quel outil, dans quel ordre, avec quels arguments et quel a été le résultat. C'est la base de preuves pour la conservation des registres de l'article 12 et la notification d'incidents des articles 72-73 à travers une chaîne multi-agents.

Que faire avant le 2 août

Pour les organisations avec des agents IA déjà en production ou dans le pipeline de déploiement, l'échéance du 2 août crée une liste de tâches concrète :

1. Classifiez vos agents. Déterminez lesquels relèvent des catégories à haut risque (emploi, services essentiels, infrastructure critique). Les agents qui ne touchent pas à ces catégories ont quand même des obligations de transparence sous l'article 50.

2. Auditez la couche de journalisation. Pouvez-vous reconstruire n'importe quelle décision de l'agent à partir des journaux ? Les journaux sont-ils infalsifiables et conservés pendant au moins 6 mois ? Si la réponse est non, c'est la première lacune à combler — l'article 12 est l'obligation la plus directement vérifiable.

3. Vérifiez le mécanisme d'arrêt. Un opérateur peut-il arrêter un agent en cours d'exécution de manière déterministe, sans s'appuyer sur le raisonnement de l'agent lui-même ? Si l'arrêt dépend d'une commande de prompt, cela ne satisfait pas l'article 14. Un kill-switch qui révoque les identifiants ou désactive les modules par changement de configuration est requis.

4. Documentez l'inventaire des interfaces. Chaque API, chaque serveur MCP, chaque connecteur que l'agent appelle doit être documenté (article 11). Le registre des modules est la documentation — si vous n'en avez pas, c'est la seconde lacune à combler.

5. Définissez la procédure de réponse aux incidents. Qui est notifié lorsqu'un agent dépasse les permissions ? Quelle est la chaîne de signalement de 24 et 72 heures ? La procédure doit être documentée avant le déploiement, pas après un incident.

6. Évaluez le périmètre multi-agents. Si votre architecture implique des chaînes d'agents, cartographiez chaque agent qui pourrait remplir une fonction à haut risque. La frontière de conformité est la chaîne complète.

Le coût de la non-conformité face au coût de la gouvernance

L'amende maximale est de 35 millions d'euros ou 7 pour cent du chiffre d'affaires mondial. Pour une entreprise de taille intermédiaire avec 100 millions d'euros de revenus, cela représente 7 millions d'euros. La couche de gouvernance qui satisfait la loi — journalisation d'audit, limites de débit, erreurs typées, kill-switch, registre des modules, isolation de locataire — est la même couche de gouvernance qui rend les agents de production sûrs à exploiter indépendamment de la pression réglementaire. Les 47 à 53 pour cent des organisations qui ont déjà subi un incident d'agent paient le coût des agents non gouvernés en risque opérationnel. La loi rend simplement ce coût explicite et exigible.

Les organisations qui ont intégré la gouvernance dans leur architecture d'agents dès le départ — enregistrement des modules avec schémas, journalisation des appels de fonction dans un magasin durable, authentification avec des jetons de courte durée, limites de débit appliquées à la frontière du module — sont celles pour qui le 2 août est un exercice de documentation plutôt qu'un retrofit d'urgence. Les organisations qui ont déployé des agents comme des scripts ad hoc appelant les API directement sont celles qui font face à l'urgence.

---

Un distributeur qui exploite NetSuite, BigCommerce et trois catalogues fournisseurs a un agent qui reçoit les RFQ, résout les produits contre un graphe de catalogue, fixe les prix par palier client et écrit les devis dans NetSuite. Si cet agent tarife des conditions de crédit ou sélectionne des fournisseurs pour un approvisionnement régulé, il relève de la catégorie à haut risque. L'architecture MCP gouvernée — chaque appel d'outil journalisé dans DynamoDB avec horodatage et résultat, chaque module désactivable par changement de configuration, chaque agent authentifié avec des jetons JWT de courte durée, chaque erreur typée et classifiée — est ce qui rend cet agent conforme le 2 août. La même architecture qui le rend sûr à exploiter le rend conforme à exploiter.

Demandez une construction délimitée. Découverte d'une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.