Plan de surveillance après commercialisation des agents IA | Article 72

Commencez par la classification, pas par les étiquettes¶

Les agents IA ne constituent pas une catégorie juridique distincte au sens du règlement sur l'IA. Le déclencheur de l'article 72 n'est pas le mot agent. Le déclencheur est la classification du système comme à haut risque, ou son intégration dans un système à haut risque.

Un assistant interne qui rédige des comptes rendus de réunion n'est pas traité de la même manière qu'un agent utilisé pour l'octroi de crédit, le tri des sinistres, le recrutement, la vérification d'identité, l'aide à la décision dans le secteur public ou d'autres cas d'usage relevant de l'annexe III. Si vous n'avez pas encore effectué ce travail de classification, commencez par Classifier les systèmes d'IA à haut risque en vertu du règlement européen sur l'IA et Conformité des agents IA au règlement européen sur l'IA. Dès qu'un système entre dans le champ d'application, la surveillance après commercialisation fait partie du modèle opérationnel et cesse d'être une bonne pratique facultative.

Ce que l'article 72 exige réellement¶

L'article 72 impose aux fournisseurs de systèmes d'IA à haut risque d'établir et de documenter un système de surveillance après commercialisation proportionné à la nature de la technologie d'IA et aux risques du système. Cette surveillance doit rester active pendant toute la durée de vie du système.

En pratique, cette obligation comporte cinq volets. Vous devez collecter, documenter et analyser de manière active et systématique les données pertinentes postérieures au déploiement ; évaluer la conformité continue aux exigences du chapitre III, section 2 ; inclure, le cas échéant, les interactions avec d'autres systèmes d'IA ; fonder le système de surveillance sur un plan de surveillance après commercialisation ; et conserver ce plan dans le dossier de documentation de l'annexe IV. Les processus sectoriels existants de surveillance après commercialisation peuvent être réutilisés lorsque le droit de l'Union impose déjà une gouvernance équivalente, mais uniquement si le résultat intégré garantit le même niveau de protection.

• Collectez les données pertinentes postérieures au déploiement de façon systématique, et non au cas par cas.
• Examinez ces données au regard des exigences de conformité continue, et pas seulement des indicateurs produit.
• Capturez les interactions avec d'autres systèmes d'IA et outils externes lorsqu'elles comptent.
• Documentez le plan dans l'annexe IV afin qu'un examinateur puisse vérifier comment la surveillance fonctionne réellement.
• Intégrez les processus sectoriels existants uniquement lorsque le niveau de protection reste équivalent.

Un tableau de bord n'est pas un plan¶

Le mode d'échec le plus fréquent consiste à confondre observabilité et conformité. Un tableau de bord peut indiquer la latence, le taux de réussite, le coût ou la consommation de jetons. Un plan de surveillance après commercialisation doit indiquer à un examinateur quels risques sont surveillés, quels signaux prouvent que les contrôles fonctionnent toujours, quels seuils déclenchent une escalade, qui examine quoi, et comment les mesures correctives sont documentées.

C'est pourquoi la surveillance après commercialisation est étroitement liée à la Checklist de l'article 17 du règlement européen sur l'IA, aux Pistes d'audit des agents IA : des journaux aux preuves et à votre dossier de preuves sous-jacent. Si vous ne pouvez pas montrer comment la télémétrie devient une preuve examinée, vous ne disposez pas encore d'un modèle opérationnel conforme à l'article 72.

• Quels risques sont surveillés : rattachés au registre des risques de l'article 9.
• Quels signaux comptent : pas seulement les sorties, mais aussi les appels d'outils, les approbations, les dérogations et les effets en aval.
• Quels seuils comptent : ce qui est informatif, ce qui exige une revue le jour même et ce qui gèle la production.
• Quels enregistrements résistent à un audit : incidents, justification des examinateurs, mesures correctives et exports de preuves liés aux versions.

Pourquoi l'article 72 compte davantage pour les agents IA¶

Les systèmes de prédiction statiques peuvent échouer silencieusement. Les agents échouent d'un système à l'autre. Ils récupèrent des données, appellent des outils, déclenchent des Processus, transmettent du travail à d'autres modèles et opèrent avec différents niveaux d'autonomie. La surveillance des agents doit donc se situer au niveau du flux de travail, et pas seulement au niveau du modèle.

La logique de la surveillance après commercialisation est particulièrement pertinente pour les systèmes agentiques, même lorsque le modèle lui-même n'est pas réentraîné en continu. Un risque émergent peut provenir de modifications de prompts, de mises à jour de politiques, de remplacements de modèle, d'un élargissement de l'accès aux outils, de changements dans la récupération d'informations, d'une dérive des intégrations ou de modifications de Processus côté déployeur. Le système peut devenir plus risqué sans qu'un cycle d'entraînement classique ait jamais lieu.

• Exécution des outils : actions échouées, nouvelles tentatives, effets de bord et tentatives non autorisées.
• Signaux de contrôle des politiques : refus, quasi-refus, files d'approbation et motifs de dérogation.
• Comportement inter-systèmes : ce qui se passe lorsque l'agent s'appuie sur d'autres services d'IA ou des automatisations externes.
• Résultats touchant aux droits : disparités, réclamations, recours et effets en aval significativement préjudiciables.

Ce que doit contenir un plan défendable au titre de l'article 72¶

Un plan défendable n'est pas long pour paraître sérieux. Il est suffisamment précis pour qu'un examinateur comprenne comment vous détectez les dégradations, qui enquête sur les anomalies et comment les preuves alimentent en retour la conformité et la gestion des changements.

Pour les agents IA, le plan devrait généralement inclure au moins les éléments suivants. C'est aussi à ce stade que de nombreuses équipes associent l'exigence légale au Modèle de plan de surveillance après commercialisation, au Manuel de procédure de supervision humaine et à la Liste de contrôle du dossier de preuves, afin que le processus soit utilisable par les équipes d'ingénierie et d'exploitation, et pas seulement par les juristes.

• Identification du système et destination : nom exact du système, version, entité fournisseur, périmètre de la version, contexte de déploiement, utilisateurs concernés, limites et logique de classification à haut risque.
• Objectifs de surveillance rattachés au registre des risques : chaque risque significatif doit avoir au moins un signal surveillé, un responsable et un circuit d'escalade.
• Sources de données et méthodes de collecte : journaux d'exécution, traces d'outils, événements d'approbation, enregistrements de dérogation, réclamations, échantillons de sorties, tickets d'incident et enregistrements de modification des intégrations.
• Métriques, seuils et niveaux de gravité : taux d'échec des tâches, taux d'erreur des outils, taux d'hallucination ou d'actions non étayées le cas échéant, fréquence des dérogations, indicateurs de disparité, événements de retour arrière et logique de conséquence déclenchée par les seuils.
• Politique d'échantillonnage et cadence de revue : télémétrie permanente, revue à 100 % des actions critiques, échantillonnage de référence pour les sorties à moindre risque, et revue renforcée après les mises en production, les remplacements de modèle ou les incidents.
• Données de supervision et d'intervention humaines : ce qui a été escaladé, qui l'a examiné, quel contexte la personne a vu, ce qu'elle a modifié, et si le même schéma d'échec se répète.
• Gestion des incidents et lien avec l'article 73 : qui enquête, ce qui devient un incident, quels délais de notification aux autorités s'appliquent, et comment le point de départ du délai de notification est identifié et étayé.
• Mesures correctives et gestion des changements : qui peut suspendre, désactiver, revenir en arrière ou retirer le système, et comment les constats issus de la surveillance après commercialisation alimentent la gestion des risques de l'article 9 et la gestion de la qualité de l'article 17.
• Conservation des preuves et préparation à l'audit : comment les journaux, notes des examinateurs, incidents et mesures correctives sont conservés, protégés, liés aux versions et exportés en vue d'un examen réglementaire.

Quand la surveillance devient une notification au titre de l'article 73¶

Votre plan de surveillance doit indiquer clairement quand une alerte devient un incident, qui est responsable du tri et quand la notification au titre de l'article 73 est déclenchée. Ce délai ne doit pas être laissé à l'improvisation.

Dans le cadre actuel de l'article 73, la limite maximale est de 15 jours après que le fournisseur ou le déployeur a eu connaissance d'un incident grave. La limite maximale est de 2 jours en cas d'infraction de grande ampleur aux obligations destinées à protéger les droits fondamentaux ou de perturbation grave et irréversible d'infrastructures critiques, et de 10 jours en cas de décès d'une personne, dès lors que le lien de causalité ou une suspicion raisonnable de causalité est établi. Le point opérationnel clé est simple : vos seuils et règles d'escalade doivent faire remonter ces scénarios assez vite pour que la notification reste possible.

• Le décès ou une atteinte grave à la santé exige le tri le plus rapide et un circuit de décision sur la causalité clairement étayé.
• Une perturbation grave et irréversible d'infrastructures critiques doit contourner les files de revue interne lentes.
• Les atteintes aux droits fondamentaux ne sont pas des questions juridiques abstraites ; elles nécessitent des déclencheurs opérationnels liés aux réclamations, aux dérogations, aux recours et aux résultats préjudiciables en aval.
• Les mesures correctives au titre de l'article 20 doivent être intégrées au même Processus afin que l'atténuation n'attende pas la finalisation des formalités de notification.

Les fournisseurs sont responsables de l'article 72, mais les déployeurs l'alimentent¶

L'article 72 est une obligation du fournisseur, mais celui-ci ne maîtrise souvent pas l'ensemble du contexte opérationnel. Les déployeurs peuvent détenir les registres de réclamations, les notes de revue humaine, les tickets d'incident de première ligne ou les données de résultats en aval qui donnent tout son sens à la surveillance.

Pour les systèmes agentiques, les contrats entre fournisseur et déployeur doivent préciser quelles données le déployeur doit restituer, à quelle vitesse les incidents graves et les quasi-incidents sont escaladés, comment les enregistrements de dérogation sont conservés et comment les modifications de Processus ou d'intégration sont communiquées. Si vous ne concevez pas cette interface, le plan paraît complet sur le papier et échoue en production.

• Obligations de restitution des données pour les réclamations, dérogations, recours et métriques de résultats.
• Canaux de signalement des incidents avec des contacts nommés et une cartographie des juridictions.
• Notifications de changement lorsque le déployeur modifie les prompts, les outils, les Processus ou les contrôles environnants.
• Règles de conservation et d'export afin que les preuves de surveillance après commercialisation ne se fragmentent pas entre les systèmes.

Le modèle et le calendrier : la situation en juillet 2026¶

L'article 72 décrit un système de surveillance documenté fondé sur un plan et renvoie à un modèle de plan de la Commission. L'Omnibus numérique sur l'IA, adopté en juin 2026, modifie certaines parties du cadre de mise en œuvre. Vérifiez toute orientation de la Commission avant de figer le format final du plan.

Les obligations relatives aux systèmes à haut risque s'appliquent à partir du 2 décembre 2027 pour les systèmes autonomes relevant de l'annexe III et du 2 août 2028 pour les systèmes intégrés à des produits relevant de l'annexe I. Tenez le plan à jour dès maintenant à partir des limites du système, des risques, des signaux, des responsabilités et du modèle opérationnel, et consignez la source juridique et la date d'effet retenues pour chaque décision de calendrier.

• Texte actuel de l'article 72 : Synthèse de l'article 72 par l'AI Act Service Desk
• Délais actuels pour les incidents graves : Synthèse de l'article 73 par l'AI Act Service Desk
• FAQ de la Commission sur le calendrier de mise en œuvre : Navigating the AI Act
• FAQ de la Commission sur la normalisation : Understanding the standardisation of the AI Act
• Proposition de la Commission à l'examen : COM(2025) 811 final

Erreurs courantes qui font échouer les plans de l'article 72 lors de l'examen¶

Les échecs sont généralement opérationnels, pas théoriques. Les équipes rédigent le plan comme s'il s'agissait d'une note interne, alors que les régulateurs et les auditeurs le traiteront comme la preuve d'une capacité opérationnelle en service.

Si vous voulez un test pratique, demandez-vous si un tiers pourrait, en lisant votre plan, déterminer comment le système est surveillé, qui enquête sur les anomalies, comment les changements en production affectent l'échantillonnage, et ce qui est notifié ou fait l'objet d'un retour arrière lorsque les seuils sont franchis.

• Traiter la surveillance après commercialisation comme un tableau de bord plutôt que comme une procédure opérationnelle.
• Surveiller uniquement la qualité du modèle en ignorant l'utilisation des outils, les approbations, les dérogations et les effets en aval.
• Lister des métriques sans seuils, sans responsables nommés, sans logique de gravité ni délais de réponse.
• Oublier les interactions avec d'autres systèmes d'IA dans les Processus agentiques.
• Conserver les journaux bruts sans les décisions relatives aux incidents, la justification des examinateurs ni les preuves de mesures correctives.
• Déconnecter la surveillance de la gestion des changements, de sorte que chaque mise en production réinitialise le risque sans revue renforcée.
• Supposer que la documentation de l'éditeur du modèle remplace la surveillance au niveau du système qui incombe au fournisseur.