Surveillance après mise sur le marché et signalement des incidents graves

Mettre un système d’IA sur le marché n’est que la moitié du chemin. Passer l’évaluation de la conformité et apposer le marquage CE peut donner l’impression d’avoir franchi la ligne. Au titre du règlement sur l’IA (règlement (UE) 2024/1689), c’est plutôt la ligne de départ d’obligations permanentes. Le règlement impose une surveillance après mise sur le marché continue et le signalement immédiat des incidents graves, des devoirs qui ne s’éteignent pas tant que le système est en service. Un fournisseur qui traite la conformité comme un événement unique finira par l’exécution, par l’atteinte à la réputation, ou par les deux.

Ce guide couvre les deux piliers liés de la conformité continue : le système de surveillance après mise sur le marché au titre de l’article 72 et le signalement des incidents graves au titre de l’article 73. Quoi surveiller, comment construire l’infrastructure, quand et comment signaler, et qui porte quoi dans la chaîne fournisseur-déployeur.

Les articles 72 et 73 s’appliquent à compter du 2 décembre 2027 pour les systèmes de l’annexe III (reportés du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Pour les systèmes de l’annexe I, l’échéance est le 2 août 2028. L’article 50 s’applique depuis le 2 août 2026.

L’essentiel, la surveillance après mise sur le marché

• La surveillance après mise sur le marché est obligatoire pour tout fournisseur d’IA à haut risque. Elle doit être proportionnée, active et systématique pendant tout le cycle de vie du système (article 72).
• Le système de surveillance doit être documenté dans la documentation technique et intégré au système de gestion de la qualité.
• Vous devez suivre la performance, les biais, les usages, les plaintes et les journaux, et pouvoir le démontrer.
• Les incidents graves, ceux qui entraînent un décès, une atteinte grave à la santé, une perturbation d’infrastructures critiques, une violation des droits fondamentaux, ou un dommage grave à des biens ou à l’environnement, doivent être signalés à l’autorité de surveillance du marché compétente dans des délais stricts (article 73) : 15 jours en règle générale, 2 jours en cas de décès ou d’atteinte grave à la santé, 10 jours en cas de perturbation grave et irréversible d’infrastructures critiques.
• Les fournisseurs portent l’obligation première de surveillance et de signalement. Les déployeurs conservent les journaux, coopèrent avec les fournisseurs, et informent le fournisseur immédiatement lorsqu’ils ont connaissance d’un incident grave.
• Le défaut de système de surveillance ou le défaut de signalement d’un incident grave peut entraîner des amendes jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial.
• Ce n’est ni facultatif, ni cosmétique, ni un « plus ». C’est une exigence juridique opposable à compter des dates ci-dessus.

Système de surveillance après mise sur le marché (article 72)

L’article 72 impose à tout fournisseur d’un système d’IA à haut risque d’établir et de documenter un système de surveillance après mise sur le marché. Le système doit être proportionné à la nature de la technologie d’IA et aux risques du système. Il doit collecter, documenter et analyser les données pertinentes fournies par les déployeurs ou recueillies par d’autres sources, pendant toute la durée de vie du système.

Ce que signifient « proportionné, actif et systématique »

• Proportionné : la profondeur et la fréquence de la surveillance doivent coller au niveau de risque. Une IA d’évaluation de la solvabilité servant des millions de consommateurs exige une surveillance plus intensive qu’un pilote interne limité.
• Actif : le fournisseur ne peut pas se contenter d’attendre les plaintes. Il doit chercher, de façon proactive, les signes de dégradation, de mauvais usage, de glissement des biais et de risques émergents, par des pipelines automatisés, des canaux de retour des déployeurs, et des audits indépendants.
• Systématique : la surveillance suit un plan documenté, avec des indicateurs, des seuils, des fréquences et des procédures d’escalade définis. Des contrôles ponctuels ne suffisent pas.

Intégration au reste du dispositif

Le système de surveillance après mise sur le marché n’existe pas isolément. Il alimente et s’alimente de :

• Le système de gestion des risques (article 9) : les données de surveillance doivent actualiser les évaluations de risques de façon itérative tout au long du cycle de vie.
• La documentation technique (article 11) : le plan de surveillance et ses résultats forment une rubrique obligatoire de l’annexe IV.
• Le système de gestion de la qualité (article 17) : le SGQ doit inclure des procédures de surveillance après mise sur le marché, et les constats doivent déclencher des actions correctives dans les processus du SGQ.
• Le système d’enregistrement (article 12) : les journaux automatiques générés par le système fournissent les données brutes que les processus de surveillance analysent.

Si l’un de ces systèmes manque ou n’est pas relié, l’architecture de conformité a un trou.

Quoi surveiller

Le règlement ne prescrit pas une liste rigide d’indicateurs. Les articles 9, 12 et 72, lus avec les orientations de la Commission, rendent pourtant les attentes claires. Voici un cadre pratique.

Suivi de la performance (exactitude, dérive, dégradation)

Suivez en continu la qualité des sorties :

Fixez des seuils d’alerte pour chaque indicateur. Lorsque l’exactitude tombe sous une référence définie, ou que la dérive dépasse un seuil statistique (par exemple un indice de stabilité de population, PSI, supérieur à 0,2), le système de surveillance doit déclencher automatiquement une investigation.

Suivi des biais (indicateurs d’équité dans le temps)

Les tests de biais ne sont pas un exercice unique. Les distributions de population glissent, les schémas sociaux évoluent, et un modèle équitable au moment de la mise en service peut cesser de l’être en production. Suivez :

• Parité démographique : les issues favorables sont-elles réparties de façon proportionnelle entre les groupes protégés ?
• Égalisation des cotes : les taux de vrais positifs et de faux positifs sont-ils cohérents d’un groupe à l’autre ?
• Parité prédictive : la précision du système tient-elle d’un groupe à l’autre ?
• Ratio d’impact disparate : un groupe reçoit-il des issues favorables à un taux inférieur à 80 % de celui du groupe le plus favorisé ?

Lorsque le système traite des données liées à des caractéristiques protégées (ou à des variables par procuration), ventilez tous les indicateurs de performance selon ces caractéristiques. Documentez la méthode et ses limites (par exemple lorsque les caractéristiques protégées sont inférées plutôt qu’observées).

Suivi de l’usage (destination contre usage réel, détection du mauvais usage)

Le règlement rattache les obligations à la destination du système, telle qu’elle figure dans la notice d’utilisation du fournisseur. La surveillance doit détecter lorsque l’usage réel s’écarte de cette destination :

• Suivez les types d’entrées soumises. Des catégories de données pour lesquelles le système n’a pas été conçu ni validé sont-elles transmises ?
• Surveillez les contextes de déploiement. Un système conçu pour une présélection est-il utilisé pour une décision finale ?
• Détectez les entrées adverses ou les tentatives d’injection de consignes.
• Signalez les volumes ou schémas d’usage qui suggèrent une application à une échelle ou dans un domaine non couvert par l’évaluation de la conformité.

Lorsque un mauvais usage est détecté, le fournisseur doit déterminer s’il constitue une mauvaise utilisation raisonnablement prévisible (qui aurait dû être traitée dans le système de gestion des risques) ou un scénario imprévisible qui exige une actualisation de la documentation des risques.

Retours et plaintes

Établissez des canaux formels pour :

• Les retours des déployeurs : mécanismes structurés pour signaler les anomalies, les comportements inattendus, les presque-incidents et les plaintes des personnes concernées.
• Les plaintes des personnes concernées : là où les personnes touchées par une décision assistée par IA peuvent faire valoir une préoccupation (particulièrement pertinent pour les systèmes soumis au droit à une explication de l’article 86).
• Le signalement interne : procédures pour que le personnel et les contractants fassent remonter une préoccupation.

Chaque plainte doit être consignée, triée, investiguée, et, lorsqu’elle est fondée, réinjectée dans le système de gestion des risques. Le volume et la catégorie des plaintes doivent figurer dans les comptes rendus réguliers de surveillance.

Conservation des journaux (article 12, enregistrement automatique, six mois au moins pour les déployeurs)

L’article 12 exige que les systèmes d’IA à haut risque permettent l’enregistrement automatique des événements. Les journaux doivent consigner les événements pertinents pour repérer les risques, faciliter la surveillance après mise sur le marché, et permettre la traçabilité.

Le schéma itemisé de l’article 12, paragraphe 3 (période de chaque utilisation, base de données de référence, données d’entrée ayant abouti à une correspondance, identification des personnes physiques participant à la vérification) ne s’applique qu’aux systèmes visés à l’annexe III, point 1, a) (identification biométrique à distance). Pour les autres systèmes à haut risque, le contenu des journaux doit être adapté à la destination.

Les déployeurs conservent les journaux générés automatiquement pendant une période adaptée à la destination, et en tout état de cause au moins six mois, sauf disposition contraire du droit de l’Union ou du droit national (article 26). Les fournisseurs ont une obligation parallèle de conservation au titre de l’article 19, dans la mesure où les journaux se trouvent sous leur contrôle.

Les fournisseurs devraient concevoir l’infrastructure de journalisation de façon à faciliter la conformité des déployeurs : export automatisé, stockage inviolable, gestion des durées de conservation.

Signalement des incidents graves (article 73)

Qu’est-ce qu’un « incident grave »

L’article 73 impose aux fournisseurs de signaler tout incident grave aux autorités de surveillance du marché de l’État membre ou des États membres où l’incident s’est produit. Le terme est défini à l’article 3, point 49 :

Un incident grave s’entend d’un incident ou d’un dysfonctionnement d’un système d’IA qui entraîne directement ou indirectement l’un des éléments suivants :

1. Décès ou atteinte grave à la santé. La sortie ou la défaillance du système contribue au décès d’une personne, ou cause une atteinte grave à sa santé. Cela inclut le préjudice physique et le préjudice psychologique.

2. Perturbation grave et irréversible d’infrastructures critiques. Le système cause ou contribue à une perturbation de la gestion et du fonctionnement d’infrastructures critiques (énergie, transport, eau, banque, infrastructures numériques, santé, etc.) d’une manière grave et irréversible.

3. Violation des droits fondamentaux. La sortie ou la défaillance du système entraîne une violation d’obligations du droit de l’Union destinées à protéger les droits fondamentaux, y compris la non-discrimination, la vie privée, la protection des données, la liberté d’expression et le droit à un recours effectif.

4. Dommage grave à des biens ou à l’environnement. Le système cause un dommage étendu à des biens ou à l’environnement, grave par son ampleur et son impact.

La formule clé est « directement ou indirectement ». Un système qui fournit une recommandation ensuite suivie par un humain, aboutissant à un préjudice, peut encore déclencher l’obligation de signalement si la chaîne causale est suffisamment directe.

Qui doit signaler

Le fournisseur est le débiteur premier du signalement. L’obligation dépend toutefois de la connaissance :

• Les fournisseurs signalent à l’autorité de surveillance du marché compétente après avoir eu connaissance qu’un incident grave s’est produit.
• Les déployeurs informent le fournisseur (et, le cas échéant, le distributeur) immédiatement après avoir eu connaissance d’un incident grave (article 26). Si le déployeur ne peut joindre le fournisseur, ou dans les cas où le déployeur a lui-même des obligations de fournisseur (par exemple au titre de l’article 25), le déployeur signale directement à l’autorité de surveillance du marché.

Le projet d’orientations de la Commission

En septembre 2025, la Commission européenne a publié un projet d’orientations sur le signalement des incidents graves, qui clarifie plusieurs points ambigus de l’article 73.

Modèle de signalement

Les orientations incluent un modèle normalisé en trois parties :

1. Notification initiale : identification de base du système, de l’incident et du préjudice immédiat.
2. Rapport intermédiaire : informations actualisées à mesure que l’investigation avance, y compris l’analyse des causes.
3. Rapport final : constats complets, actions correctives prises, et mesures pour prévenir la récidive.

Intégrez ce modèle à votre processus de gestion des incidents maintenant, plutôt que d’essayer de l’adopter sous la pression d’un incident réel.

Clarification du « lien causal indirect »

Les orientations précisent que « entraîne indirectement » couvre les situations où : la sortie du système d’IA a été un facteur matériel dans une chaîne d’événements aboutissant au préjudice, même si un humain est intervenu ; le système n’a pas rempli sa fonction prévue et cette défaillance a contribué au préjudice ; ou les effets cumulés du système dans le temps ont abouti au préjudice (par exemple un biais systématique causant des résultats discriminatoires dans une population). Les orientations indiquent expressément que le contrôle humain ne rompt pas automatiquement la chaîne causale : si la sortie du système était conçue pour éclairer la décision humaine, et que l’humain s’y est raisonnablement fié, le lien indirect peut encore être établi.

Exemples tirés des orientations

Le projet d’orientations de la Commission fournit des exemples illustratifs :

• Une IA de triage médical qui classe à tort un patient comme peu prioritaire, contribuant à un diagnostic tardif qui entraîne une détérioration grave de la santé : incident grave à signaler.
• Un système de police prédictive qui surestime systématiquement le risque dans des quartiers minoritaires, aboutissant à une surveillance disproportionnée et à une violation du droit à la non-discrimination : à signaler au titre des droits fondamentaux.
• Un sous-système de véhicule autonome qui identifie mal un danger routier, contribuant à une collision causant une blessure grave : à signaler au titre de la santé / du décès.
• Un incident logiciel mineur qui cause une erreur d’affichage temporaire dans un tableau de bord alimenté par l’IA, sans impact en aval sur les décisions ou la sécurité : pas un incident grave à signaler.

Délais et processus de signalement

Le règlement et les orientations de la Commission établissent un processus structuré, avec des délais définis. Retarder le signalement est en soi un manquement.

Processus, étape par étape

Détail des délais

• Délai de 2 jours pour les incidents impliquant un décès ou une atteinte grave à la santé : le délai court à compter du moment où le fournisseur a connaissance. « A connaissance » inclut la connaissance constructive : si le fournisseur aurait raisonnablement dû savoir au vu des informations disponibles (retours des déployeurs, signalements publics), le délai court à partir de ce moment.
• Délai de 10 jours pour une perturbation grave et irréversible d’infrastructures critiques.
• Délai de 15 jours pour tous les autres incidents graves (violations des droits fondamentaux, dommages aux biens ou à l’environnement).
• Si le fournisseur ne peut achever le signalement initial dans le délai, il doit déposer un rapport préliminaire avec les informations disponibles et le compléter à mesure que l’investigation avance.
• Les signalements doivent être déposés auprès de l’autorité de surveillance du marché de chaque État membre dans lequel l’incident s’est produit.

Ce que le signalement initial doit contenir

Au minimum : l’identité du fournisseur ; l’identification du système d’IA (nom, version, numéro de certificat CE, numéro d’enregistrement dans la base de données de l’UE) ; une description de l’incident et du préjudice causé ; la date et le lieu ; une appréciation initiale de la catégorie d’incident ; les mesures correctives immédiates prises ; et les coordonnées pour le suivi.

Obligations de surveillance : fournisseur et déployeur

Comprendre qui est responsable de quoi est décisif pour éviter les trous et le double emploi. Le tableau ci-dessous compare les obligations de surveillance et de signalement des fournisseurs et des déployeurs pour les systèmes d’IA à haut risque.

Obligations du déployeur, en détail

Les déployeurs ne sont pas des destinataires passifs. Au titre de l’article 26, ils doivent : utiliser le système conformément à la notice du fournisseur ; confier le contrôle humain à des personnes compétentes ; surveiller le fonctionnement du système dans leur contexte de déploiement ; conserver les journaux au moins six mois ; informer les personnes concernées qu’elles sont soumises à un système d’IA à haut risque ; informer immédiatement le fournisseur de tout incident grave ; et suspendre l’usage s’ils estiment que le système présente un risque.

Un déployeur qui omet d’informer le fournisseur d’un incident grave, ou qui continue d’utiliser un système qu’il sait non conforme, s’expose en son nom propre à des mesures d’exécution et à des amendes.

Construire un système de surveillance, en pratique

La théorie compte ; c’est l’exécution que les autorités auditeront. Voici une architecture pratique.

Pipelines de données

Concevez des pipelines automatisés qui ingèrent en continu :

• Journaux d’inférence en production : chaque prédiction, classification ou recommandation, avec horodatage, métadonnées d’entrée, scores de confiance, et labels de référence lorsqu’ils sont disponibles.
• Retours des déployeurs : canaux structurés (API ou portail) pour les observations de performance, les plaintes et les signalements d’anomalies.
• Données externes : bulletins réglementaires, recherche académique, signalements médiatiques, et plaintes déposées auprès des autorités de protection des données.
• Données de réentraînement : toute nouvelle donnée d’entraînement introduite par une mise à jour du modèle, avec traçabilité de la lignée.

Utilisez une architecture événementielle pour que la surveillance soit quasi temps réel pour les systèmes critiques pour la sécurité, plutôt que de vous reposer sur des comptes rendus hebdomadaires par lots.

Seuils d’alerte

Définissez des seuils quantitatifs qui déclenchent une escalade automatique :

Indicateurs à visualiser

Construisez un tableau de bord de surveillance (interne, ou destiné aux déployeurs) qui visualise :

• Tendances d’exactitude et de performance (moyennes glissantes quotidiennes / hebdomadaires).
• Indicateurs de biais par groupe protégé, avec courbes de tendance et seuils d’alerte.
• Indicateurs de dérive (PSI, divergence de Kullback-Leibler) sur les distributions d’entrée et de sortie.
• Volume et catégorisation des plaintes.
• Complétude des journaux et respect des durées de conservation.
• Nombre d’incidents ouverts et leur statut.
• Délai de résolution des incidents précédents.

Procédures d’escalade

Documentez une chaîne claire : niveau 1 (équipe de surveillance) trie les alertes et investigue les questions courantes. Niveau 2 (responsable technique / science des données) mène l’analyse des causes pour les alertes critiques. Niveau 3 (conformité / juridique) apprécie si l’événement constitue un incident grave au titre de l’article 73 et rédige les signalements. Niveau 4 (direction / conseil) est habilité à décider d’une suspension, d’un rappel ou d’un retrait, et est informé immédiatement pour les événements d’urgence.

Modèles de documentation

Tenez des modèles prêts à l’emploi pour :

• Compte rendu mensuel de surveillance : synthèse des indicateurs, tendances, alertes déclenchées, investigations menées, actions correctives.
• Fiche d’appréciation d’incident : questionnaire structuré pour déterminer si un événement franchit le seuil de l’article 3, point 49.
• Signalement au titre de l’article 73 : aligné sur le modèle normalisé de la Commission (initial, intermédiaire, final).
• Fiche d’action corrective : action prise, motif, effet, et vérification qu’elle a résolu le problème.
• Mise à jour de la gestion des risques : relier les constats de surveillance au système de gestion des risques de l’article 9 et consigner comment l’évaluation des risques a été actualisée.

Scénarios de surveillance, en conditions réelles

Scénario 1 : dégradation d’une IA d’évaluation de la solvabilité

Exemple. Un fournisseur de technologie financière exploite un système d’IA à haut risque d’évaluation de la solvabilité (annexe III, point 5, b)) déployé par 30 prêteurs européens. Six mois après la mise en service, le tableau de bord de surveillance après mise sur le marché montre que le taux de faux rejets pour les demandeurs d’une origine nationale donnée est passé de 8 % à 19 %, tout en restant stable à 7 % pour les autres groupes. Le ratio d’impact disparate est tombé sous 0,6.

Ce qui devrait se passer. Le système d’alerte automatique déclenche une alerte critique. L’investigation révèle qu’un glissement macroéconomique a touché de façon disproportionnée le groupe concerné, rendant les caractéristiques du modèle moins prédictives pour ce groupe. Le fournisseur estime qu’il s’agit d’une violation potentielle des droits fondamentaux (non-discrimination) et dépose un signalement initial d’incident grave dans les 15 jours. L’action corrective comprend le réentraînement du modèle avec des données actualisées, l’ajustement des pondérations, et un examen manuel transitoire pour les demandeurs concernés. Les 30 déployeurs sont informés. Le système de gestion des risques est actualisé pour inclure une analyse de sensibilité macroéconomique comme exigence permanente de surveillance.

Scénario 2 : erreur de diagnostic médical

Exemple. Un fournisseur propose un outil d’assistance radiologique alimenté par l’IA, à haut risque en tant que composant de sécurité d’un dispositif médical (voie de l’annexe I / MDR, article 6, paragraphe 1, et non l’annexe III, point 5, a), qui vise les prestations publiques). Un hôpital déployeur signale que le système n’a pas repéré une tumeur maligne sur une radiographie thoracique. Le radiologue, s’appuyant sur la sortie « rien à signaler » comme second avis, n’a pas vu la tumeur lors de son premier examen. Le diagnostic du patient a été retardé de quatre mois, entraînant une progression de la maladie qui a exigé un traitement plus agressif.

Ce qui devrait se passer. Le déployeur informe immédiatement le fournisseur, comme l’exige l’article 26. Le fournisseur classe l’événement dans la catégorie décès / atteinte grave à la santé et dépose un signalement initial dans les 2 jours. L’analyse des causes révèle que la tumeur se situait dans une région d’image où le modèle avait une sensibilité plus faible, déjà connue, mais insuffisamment communiquée dans la notice d’utilisation. Actions correctives : le fournisseur actualise la notice, réentraîne le modèle avec des données annotées supplémentaires, et adresse une communication de sécurité à tous les hôpitaux déployeurs. La documentation technique est actualisée, et le fournisseur lance une revue plus large sur tous les sites.

Scénario 3 : outil de présélection RH signalé pour biais systématique

Exemple. Une entreprise multinationale déploie un outil de tri de CV alimenté par l’IA (haut risque au titre de l’annexe III, point 4, a), recrutement et sélection des candidats). Un salarié du service RH constate que l’outil classe de façon constante les candidates plus bas pour les postes d’ingénierie. Il dépose une plainte interne.

Ce qui devrait se passer. L’équipe de conformité du déployeur analyse six mois de données de présélection (conservées au titre de l’obligation de conservation des journaux) et confirme l’écart : les candidates ont 2,3 fois moins de chances d’être retenues que des candidats masculins également qualifiés. Le déployeur informe immédiatement le fournisseur et suspend l’usage pour le tri des postes d’ingénierie. L’analyse des causes révèle que les données d’entraînement étaient biaisées vers des équipes historiquement masculines, encodant une variable par procuration de genre via des caractéristiques comme le nom de l’université. Le fournisseur dépose un signalement d’incident grave au titre des droits fondamentaux dans les 15 jours, réentraîne le modèle avec des données débiaisées, ajoute des contraintes d’équité explicites, et communique les mesures correctives à tous les déployeurs.

Questions fréquentes

La surveillance après mise sur le marché s’applique-t-elle aux systèmes d’IA qui ne sont pas à haut risque ?

Les obligations de l’article 72 s’appliquent spécifiquement aux systèmes d’IA à haut risque. Les fournisseurs d’autres systèmes ont toutefois intérêt à surveiller : un système peut être reclassé si son contexte d’usage change. Les fournisseurs de modèles d’IA à usage général présentant un risque systémique ont des obligations supplémentaires. La liste de contrôle du règlement sur l’IA couvre la surveillance selon les paliers de risque.

Combien de temps faut-il conserver les données de surveillance et les journaux ?

Les déployeurs conservent les journaux au moins six mois (article 26). Les fournisseurs exploitent le système de surveillance pendant toute la durée de vie du système d’IA, et conservent les journaux sous leur contrôle au titre de l’article 19. En pratique, conservez les données de surveillance au moins pendant la période de responsabilité potentielle, souvent plusieurs années. Les règles sectorielles (dispositifs médicaux, services financiers) peuvent imposer plus long.

Que se passe-t-il si un déployeur découvre un incident mais que le fournisseur est injoignable ?

Si le déployeur ne peut joindre le fournisseur dans un délai raisonnable, il devrait signaler directement à l’autorité de surveillance du marché de l’État membre où l’incident s’est produit. Il devrait aussi consigner toutes les tentatives de contact. Au titre de l’article 26, le déployeur a une obligation indépendante de suspendre l’usage s’il estime que le système présente un risque, qu’il ait ou non communiqué avec le fournisseur.

Un fournisseur peut-il déléguer la surveillance à un déployeur ou à un tiers ?

Un fournisseur peut organiser par contrat que des déployeurs ou des tiers collectent des données, fassent fonctionner des tableaux de bord, ou exécutent des activités de surveillance. L’obligation juridique demeure toutefois celle du fournisseur. Il ne peut pas s’en décharger. Si le tiers surveille mal, le fournisseur reste responsable. Toute délégation doit être documentée dans le système de gestion de la qualité et reflétée dans les contrats avec les déployeurs.

Tout constat de biais est-il un « incident grave » à signaler ?

Non. Un constat de biais n’est un incident grave que s’il entraîne directement ou indirectement une violation des droits fondamentaux grave par nature. Un écart statistique mineur, détecté, investigué et corrigé avant qu’il ne cause un préjudice, n’est pas un incident grave à signaler, même s’il doit être consigné en interne et réinjecté dans le système de gestion des risques. L’appréciation se fait au cas par cas, selon la gravité, l’ampleur et le caractère réversible du préjudice. Dans le doute, mieux vaut signaler : sous-signaler porte un risque réglementaire plus élevé que trop signaler.

Comment le règlement sur l’IA s’articule-t-il avec la notification de violation du RGPD ?

Le signalement d’incident grave du règlement sur l’IA est distinct et s’ajoute à la notification de violation de données à caractère personnel (article 33 du RGPD). Un même événement peut déclencher les deux : notification à l’autorité de protection des données au titre du RGPD et à l’autorité de surveillance du marché au titre de l’article 73. Les délais diffèrent (72 heures contre 2 à 15 jours), les autorités diffèrent, les modèles diffèrent. Votre plan de réponse aux incidents doit traiter les deux. Pour le recoupement entre le règlement sur l’IA et le RGPD, voir la comparaison détaillée.

Prochaines étapes

La surveillance après mise sur le marché et le signalement des incidents sont des systèmes vivants, qui doivent évoluer avec votre système d’IA et avec les risques nouveaux qui apparaissent en production. Auditez vos capacités actuelles au regard de ce guide, identifiez les écarts, et comblez-les. Les échéances opposables sont le 2 décembre 2027 pour l’annexe III et le 2 août 2028 pour l’annexe I.

Si vous n’êtes pas sûr que votre système d’IA qualifie comme à haut risque, commencez par une évaluation gratuite de classification. S’il l’est, ces obligations font partie du coût d’accès au marché européen de l’IA.