Surveillance après commercialisation EU AI Act (Art. 72) : obligations des fournisseurs de systèmes IA à haut risque

La conformité ne s'arrête pas à la mise sur le marché. L'Art. 72 impose aux fournisseurs de systèmes IA à haut risque de maintenir un système actif de surveillance après commercialisation, de collecter des données de performance et de signaler les incidents graves. Voici ce que vous devez faire — et quand.

Qu'est-ce que la surveillance après commercialisation ?

L'évaluation de la conformité et le marquage CE constituent le ticket d'entrée sur le marché européen pour un système IA à haut risque — pas la ligne d'arrivée. L'Article 72 de l'EU AI Act impose une obligation continue : les fournisseurs doivent établir et exploiter un système de surveillance après commercialisation (SAC) qui collecte, analyse et traite activement les données de performance réelles tout au long de la durée de vie opérationnelle du système.

La justification est simple. Un système IA validé sur un jeu de données fixe peut dériver au fur et à mesure que les entrées réelles évoluent, que la population d'utilisateurs change, ou que l'environnement dans lequel il opère se transforme. Les instantanés statiques de conformité ne peuvent pas saisir cette réalité. La SAC est le mécanisme qui transforme la conformité en un processus continu plutôt qu'en un événement unique.

Le système SAC doit être proportionné à la nature et aux risques du système IA à haut risque concerné. Un modèle de scoring de crédit déployé à grande échelle auprès de millions de consommateurs nécessitera une surveillance plus intensive qu'un outil étroit de classification de documents utilisé en interne par une entreprise réglementée.

Qui doit établir un système SAC ?

Obligatoire pour :

• Les fournisseurs de systèmes IA à haut risque standalone de l'Annexe III — systèmes listés à l'Annexe III qui ne sont pas des composants de sécurité d'un produit (ex. IA utilisée dans les décisions d'emploi, l'accès à l'éducation, les forces de l'ordre, l'évaluation de la solvabilité, la gestion des infrastructures critiques)
• Les fournisseurs de systèmes IA intégrés dans des produits de l'Annexe I — composants de sécurité IA intégrés dans des produits couverts par la législation d'harmonisation européenne existante (dispositifs médicaux, machines, véhicules)

Non requis pour :

• Les fournisseurs de systèmes IA à risque minimal (pas d'obligation formelle de SAC, bien que les bonnes pratiques s'appliquent)
• Les fournisseurs de systèmes IA à transparence uniquement (les obligations de l'Art. 50 ne s'étendent pas à la SAC)
• Les fournisseurs de modèles GPAI — ceux-ci sont soumis à un régime distinct au titre des Art. 61–62, qui comprend le signalement d'incidents pour les modèles à risque systémique mais est structuré différemment de la SAC de l'Art. 72

Le rôle du déployeur est de soutien mais pas optionnel. Les déployeurs doivent exploiter le système IA conformément aux instructions du fournisseur, activer et conserver la fonctionnalité de journalisation intégrée dans le système, et — de manière critique — signaler tout incident grave dont ils ont connaissance au fournisseur sans délai injustifié. Un déployeur qui observe un incident grave et omet de notifier le fournisseur n'est pas conforme.

Le plan de surveillance après commercialisation (Annexe IV, Point 12)

Le plan SAC est un composant obligatoire de la documentation technique (Annexe IV). Il ne peut pas être un document générique : il doit être spécifique au système, à son contexte de déploiement et à ses risques identifiés. Au minimum, il doit définir :

1. Collecte de données — quelles métriques de performance sont capturées (précision, taux d'erreur, résultats de décision), comment les données sont collectées (télémétrie automatisée, rapports des déployeurs, feedback des utilisateurs), et à quelle fréquence
2. Boucles de retour — le mécanisme par lequel les déployeurs peuvent signaler les problèmes de performance, anomalies ou incidents au fournisseur de manière structurée et rapide
3. Indicateurs de performance — les mesures de performance attendues établies lors de l'évaluation de conformité, utilisées comme lignes de base pour détecter la dérive
4. Seuils de déclenchement — les niveaux auxquels une dérive de performance déclenche une révision du modèle, une reclassification du risque ou une action corrective
5. Périodes de conservation des données — la durée pendant laquelle les données de surveillance sont conservées (minimum 10 ans après la mise sur le marché)

Surveillance continue : que surveiller

En pratique, la SAC pour les systèmes IA à haut risque doit surveiller au minimum :

Dérive de performance

Les métriques de performance du système en production par rapport aux métriques de performance établies lors du déploiement initial. Pour un modèle de décision de crédit, cela inclut les taux de faux positifs/négatifs, les mesures de calibration et les métriques de discrimination. Les baisses significatives peuvent indiquer une dérive du concept ou une dégradation du modèle.

Dérive des données d'entrée

Les distributions des données d'entrée reçues par le système par rapport aux distributions de données d'entraînement. Si la population qui utilise le système change substantiellement (ex. différentes données démographiques, différents contextes), les performances peuvent se dégrader pour des sous-groupes même si les métriques globales restent stables.

Incidents et quasi-accidents

Tout résultat indésirable — qu'il atteigne le seuil d'incident grave ou non — doit être consigné. Les quasi-accidents sont particulièrement importants : ils révèlent des modes de défaillance avant qu'ils ne causent des préjudices réels.

Comportements inattendus

Des sorties qui s'écartent systématiquement de la finalité prévue du système, ou qui révèlent des capacités ou biais non identifiés lors des tests initiaux. Les déployeurs sont souvent les premiers à observer ces comportements en exploitation réelle.

Signalement d'incidents graves (Art. 73)

Le signalement d'incidents graves est une obligation distincte de la SAC mais étroitement liée à elle. L'Art. 73 impose :

Sur les fournisseurs :

• Signaler les incidents graves à l'autorité nationale de surveillance du marché compétente dans les 15 jours suivant la prise de connaissance
• Pour les risques pour la sécurité publique : dans les 24 heures
• Le rapport doit inclure : description de l'incident, systèmes concernés, préjudice causé ou potentiel, mesures prises ou prévues

Sur les déployeurs :

• Signaler les incidents graves au fournisseur sans délai injustifié
• Si le déploiement implique une utilisation par des services d'urgence publics : signaler directement à l'autorité de surveillance du marché
• Tenir des registres de tous les incidents signalés

Ce qui déclenche une obligation de signalement :

• Décès ou blessure corporelle grave
• Dommages graves aux biens ou à l'environnement
• Violation grave des droits fondamentaux
• Atteinte grave à la sécurité publique
• Quasi-accidents susceptibles d'entraîner l'un des éléments ci-dessus

Un lien causal établi entre le système IA et le préjudice n'est pas requis. Un soupçon raisonnable que le système IA a contribué ou aurait pu contribuer à l'incident est suffisant.

Modifications substantielles et réévaluation

Tous les systèmes IA évoluent après le déploiement initial. Certaines évolutions ne déclenchent pas de nouvelles obligations ; d'autres le font.

Les corrections de bugs mineures, les correctifs de sécurité et les améliorations de performance qui n'altèrent pas la logique fondamentale du système ne constituent pas une modification substantielle. Elles doivent être documentées dans le dossier technique mais ne nécessitent pas de réévaluation.

Les modifications substantielles déclenchent une nouvelle évaluation de la conformité. Une modification est substantielle si elle :

• Change la finalité prévue du système
• Altère significativement les performances (ex. de nouveaux cas d'usage, nouvelles sorties, impact élargi sur les personnes concernées)
• Modifie les mesures de gestion des risques de manière à réduire les garanties établies lors de l'évaluation initiale
• Change les données d'entraînement d'une manière affectant la robustesse ou l'exactitude

Le seuil de modification substantielle est intentionnellement laissé à l'appréciation du fournisseur dans des cas limites. L'approche sûre consiste à documenter l'évaluation de chaque modification significative et à conserver cette documentation avec le dossier technique.

Intégration avec d'autres obligations de l'AI Act

La SAC ne fonctionne pas en vase clos. Elle s'interface directement avec :

• Documentation technique (Annexe IV) — le plan SAC est un composant obligatoire du dossier technique
• Système de gestion des risques (Art. 9) — les résultats de la SAC doivent alimenter les révisions continues du système de gestion des risques
• Journalisation (Art. 12) — la fonctionnalité de journalisation automatique du système fournit les données brutes pour la SAC
• Signalement d'incidents (Art. 73) — la SAC identifie les incidents ; Art. 73 impose des délais et des destinataires de signalement spécifiques
• Obligations de modification substantielle — la SAC documente les changements de performance qui peuvent déclencher une révision de la nécessité d'une réévaluation

Les fournisseurs doivent concevoir leur système SAC pour intégrer ces connexions — pas comme une liste de contrôle de conformité autonome, mais comme un système de gestion opérationnel qui alimente et est alimenté par toutes les autres activités de conformité de l'AI Act.