Incidents graves d’IA : préserver les preuves, contenir le préjudice et décider si une défaillance doit être notifiée au titre de l’article 73 de l’AI Act

Une défaillance n’est pas automatiquement un incident grave

La réponse à un résultat dangereux produit par un système d’IA commence par distinguer des notions souvent confondues. Une erreur de modèle peut être une sortie inexacte, incohérente ou non souhaitée. Un incident opérationnel peut inclure une indisponibilité de service, une configuration incorrecte, une intégration défaillante ou l’utilisation d’outils en dehors du comportement prévu. Un préjudice est une conséquence négative concrète pour une personne, une organisation, des biens, l’environnement ou un processus. Un incident grave, au sens réglementaire pertinent pour ce guide, est une catégorie plus étroite, liée à des effets spécifiques définis par l’AI Act.

Toute hallucination, baisse de qualité, réclamation d’utilisateur ou réponse offensive ne déclenche pas, à elle seule, le régime de l’article 73. Il ne serait pas non plus prudent d’écarter un cas au motif qu’une sortie isolée semble mineure : une réponse apparemment ordinaire peut avoir influencé une décision clinique, de recrutement, d’accès à un service, de sécurité physique ou d’exploitation d’infrastructures. L’analyse doit partir de faits observables, et non d’étiquettes internes telles que « bug mineur » ou « plainte non critique ».

Le texte consolidé de l’AI Act définit l’incident grave par des catégories de conséquences, notamment le décès ou une atteinte grave à la santé, une perturbation grave et durable de la gestion ou de l’exploitation d’infrastructures critiques, une violation d’obligations destinées à protéger les droits fondamentaux, ou un dommage grave aux biens ou à l’environnement. La qualification impose d’examiner le fait, le système concerné et le lien possible entre les deux. Elle ne doit pas être remplacée par un score de gravité interne sans correspondance documentée avec ces catégories.

Il est utile de conserver deux voies dès le premier signalement. La voie technique vise à arrêter un comportement dangereux et à rétablir un service maîtrisé. La voie des preuves et de la conformité vise à conserver les faits, évaluer le lien de causalité potentiel, coordonner le fournisseur et le déployeur, et déterminer s’il convient de préparer une communication à l’autorité compétente. Elles peuvent avancer en parallèle, mais une correction précipitée peut compromettre la seconde voie si elle modifie ou supprime les informations nécessaires pour expliquer ce qui s’est produit.

Périmètre : identifier le système, l’opérateur et la voie de haut risque

L’article 73 s’adresse aux fournisseurs de systèmes d’IA à haut risque mis sur le marché de l’Union. Le premier point à vérifier n’est donc pas la gravité ressentie par l’équipe, mais le système exact qui est intervenu, l’entité qui en est le fournisseur au sens du règlement, et son éventuelle soumission à la classification pertinente de haut risque. L’article 6 de l’AI Act prévoit deux voies principales : certains systèmes liés à des produits réglementés ou à leurs composants de sécurité, et les cas d’utilisation énumérés à l’annexe III, sous réserve des conditions et exceptions prévues par le règlement lui-même.

Il ne suffit pas d’affirmer qu’un modèle fondamental, une interface conversationnelle ou une automatisation est « à haut risque » en raison de son thème. L’unité d’analyse doit être le système mis à disposition ou utilisé dans son contexte concret : version, finalité prévue, intégration, fonctions activées, utilisateurs, données d’entrée et résultat produit. Un même composant peut appartenir à des configurations soumises à des obligations différentes. Le projet de lignes directrices de la Commission sur la classification peut aider à structurer l’examen, mais demeure un projet et ne remplace ni le texte contraignant ni l’appréciation juridique du cas.

La planification temporelle doit séparer préparation et applicabilité effective. Les organisations peuvent dès à présent construire leurs processus d’enregistrement, de préservation, de contact et d’escalade. En revanche, les dates d’application concrètes pour les différentes catégories de systèmes à haut risque doivent être vérifiées au regard de la version juridiquement applicable du règlement et de toute modification en vigueur au moment de décider un cas. Il n’est pas recommandé de transformer une date de planification interne en conclusion selon laquelle une obligation est déjà exigible.

Pour organiser les travaux associés, l’équipe peut séparer ce protocole des revues générales de Sécurité, de l’évaluation des alternatives dans Comparer et de l’identification des capacités dans Découvrir. Ces activités peuvent apporter du contexte, mais l’enquête sur un incident exige un dossier centré sur le fait survenu et sur la configuration effectivement déployée.

Les premières heures : préserver avant de corriger

Lorsqu’un cas potentiellement pertinent est détecté, désignez un responsable d’incident habilité à coordonner les opérations, le produit, la sécurité, la qualité et la conformité. Sa première responsabilité opérationnelle consiste à établir une chronologie : quand le fait est survenu, quand il a été détecté, qui a reçu chaque alerte, quels systèmes sont restés actifs et quelles décisions ont été prises. L’heure de prise de connaissance par le fournisseur et, le cas échéant, par le déployeur doit être consignée séparément, avec la source qui l’établit.

Préserver les preuves ne signifie pas copier indistinctement toutes les données disponibles. Il s’agit de conserver, de manière proportionnée, intègre et sous accès contrôlé, les éléments qui permettent de reconstruire le comportement examiné. Au minimum, le dossier devrait relier les identifiants de demande et de session, les entrées et sorties, la version et les paramètres du modèle, le prompt système et les modèles de prompt, les politiques, la configuration de récupération, les documents récupérés ou leurs identifiants, les appels aux outils et leurs réponses, les autorisations humaines, l’identité ou le rôle de l’opérateur, ainsi que les changements de configuration proches de l’événement.

La préservation doit inclure des métadonnées d’intégrité : origine, date d’extraction, responsable, méthode d’exportation, empreinte de fichier lorsque cela est possible, contrôles d’accès et toute transformation ultérieure. En présence de données personnelles, de secrets d’affaires ou d’informations de sécurité, l’accès doit être limité conformément aux règles applicables. Restreindre l’accès ne justifie pas l’effacement des éléments nécessaires à l’enquête. Lorsqu’une donnée ne peut pas être conservée, le dossier doit indiquer ce qui a été supprimé, pourquoi, quand, et quelle preuve de remplacement demeure disponible.

L’AI Act exige que le fournisseur enquête immédiatement sur l’incident grave et sur le système concerné, y compris par une évaluation des risques et des mesures correctives. Il prévoit également que le système ne doit pas être modifié avant la notification lorsque cette modification est susceptible d’affecter l’évaluation ultérieure des causes de l’incident. En pratique, cela impose de concevoir le confinement de manière à limiter le préjudice sans effacer l’état qui doit être examiné.

Contenir le préjudice sans compromettre l’enquête

Le confinement n’a pas une forme unique correcte. Suspendre l’ensemble du système peut être nécessaire si un risque grave persiste, mais peut aussi affecter des processus essentiels ou pousser les utilisateurs vers des solutions non maîtrisées. D’autres mesures peuvent être plus proportionnées : retirer temporairement un outil d’exécution, réduire les droits, empêcher les actions automatisées à fort impact, bloquer un ensemble identifié d’entrées, désactiver une source de récupération compromise ou exiger un contrôle humain pour une décision déterminée.

Chaque mesure doit répondre à une hypothèse explicite de préjudice et comporter des conditions de réexamen. « Mettre le système en mode sûr » n’est pas une description vérifiable si l’on ne précise pas quelle capacité a été bloquée, ce qui demeure disponible, quelle population est affectée, quelles alternatives ont été proposées et comment l’effet a été vérifié. La communication aux clients, utilisateurs et opérateurs peut faire partie du confinement, mais elle doit reposer sur des faits confirmés et ne pas attribuer une causalité avant que l’enquête ne l’étaye.

Le retour à une version antérieure exige de la prudence. Il peut résoudre le symptôme immédiat, mais ne prouve pas que la cause résidait dans la version retirée et peut introduire des différences empêchant de reproduire le cas. Avant le changement, préservez l’artefact déployé, la configuration et les journaux permettant de comparer l’état antérieur et l’état ultérieur. Si le changement est indispensable pour prévenir un préjudice, documentez sa nécessité et l’étendue de l’écart.

L’autorité de surveillance du marché peut disposer de ses propres pouvoirs face à des produits présentant un risque grave, notamment des mesures d’évaluation et de restriction. Ces interventions ne remplacent pas l’enquête interne et ne transforment pas l’organisation en autorité. L’équipe doit pouvoir fournir des faits vérifiables, des évaluations et les mesures appliquées si elle reçoit une demande.

Reconstruire le cas comme une chaîne de décisions

Une enquête utile doit pouvoir répondre à une question simple : quel système exact a produit ou contribué au résultat, et par quelle séquence ? Une transcription de conversation ne suffit pas. Un dossier reproductible relie l’identifiant du cas au modèle et à sa version, aux paramètres d’inférence, aux instructions système, au prompt assemblé, aux données jointes, à la configuration de récupération, aux documents sélectionnés, aux outils disponibles, aux appels effectués, aux politiques actives et aux décisions humaines.

Il faut aussi distinguer les faits du mécanisme supposé. Fait : un outil a reçu certains paramètres et une action a été enregistrée. Hypothèse : le modèle a mal interprété une instruction ambiguë. Fait : un opérateur a approuvé une recommandation. Hypothèse : l’interface n’affichait pas un contexte suffisant pour détecter l’erreur. Cette séparation évite que le premier diagnostic devienne le récit définitif et permet d’examiner des hypothèses alternatives, y compris des défaillances de données, d’intégration, d’interface, de formation, de processus humain ou des facteurs externes.

La reproductibilité complète n’est pas toujours possible. Un service externe peut avoir changé, une entrée peut manquer, un résultat peut dépendre d’aléa ou la conservation des données peut être limitée. Dans ce cas, le dossier doit décrire précisément la lacune, son effet sur les conclusions et les essais de substitution employés. L’absence de reproduction ne démontre pas à elle seule que le système n’était pas lié à l’incident.

La reconstruction doit inclure les changements introduits pendant la réponse. Sans ce relevé, une amélioration ultérieure peut être confondue avec la configuration d’origine, et un résultat sûr obtenu après le confinement peut être présenté à tort comme la preuve que l’incident était impossible. Préserver la comparabilité entre l’état initial, l’état confiné et l’état corrigé est une condition pratique pour tirer des enseignements du cas.

Qualifier la gravité et le lien de causalité sans rendre un verdict prématuré

La qualification doit partir de questions concrètes. Y a-t-il eu décès ou atteinte grave à la santé ? La gestion ou l’exploitation d’une infrastructure critique a-t-elle connu une perturbation grave et durable ? Une obligation visant à protéger les droits fondamentaux a-t-elle été violée ? Des dommages graves ont-ils été causés à des biens ou à l’environnement ? Pour chaque question, le dossier doit identifier le fait allégué, les sources qui l’étayent, l’étendue connue, les personnes ou actifs affectés et les éléments encore incertains.

Il faut ensuite analyser le lien avec le système. L’article 73 n’impose pas d’attendre une preuve causale définitive lorsqu’il existe une probabilité raisonnable de relation, mais une simple coïncidence temporelle ne peut pas remplacer l’analyse. Les voies causales plausibles, les éléments qui les soutiennent, les facteurs alternatifs et les vérifications en attente doivent être documentés. Par exemple, une sortie erronée peut être pertinente, mais la décision finale peut avoir dépendu d’une revue humaine indépendante ou de données externes inexactes ; ces deux éléments doivent être examinés.

Une matrice interne de gravité peut faciliter l’escalade, mais ne doit pas remplacer la définition légale. Il est recommandé que le formulaire interne distingue « impact observé », « risque d’impact supplémentaire », « catégorie réglementaire potentielle », « lien établi », « lien raisonnablement probable » et « lien non établi ». Cette structure rend visible ce qui relève du fait et ce qui constitue une analyse provisoire.

La décision selon laquelle un cas n’atteint pas le seuil doit être motivée et révisable. De nouvelles informations peuvent provenir d’un déployeur, d’un utilisateur, d’un outil connecté ou d’une autorité. Clore la question de la notification ne signifie pas clore le dossier technique ni supprimer les preuves.

Fournisseur et déployeur : coordonner l’information, non transférer le problème

Le fournisseur et le déployeur peuvent détenir des parties différentes des éléments de preuve. Le fournisseur contrôle souvent la documentation du système, les versions, les essais, les journaux d’exploitation et les mesures correctives du produit. Le déployeur peut connaître le contexte d’utilisation, la population affectée, les décisions humaines, les données locales, les conséquences matérielles et les communications reçues. Un contrat peut répartir des tâches opérationnelles, mais ne devrait pas empêcher la transmission rapide des informations nécessaires au respect des obligations applicables.

Il est préférable de préparer une matrice de contacts et une clause opérationnelle sur les incidents avant qu’un cas ne survienne. Elles doivent inclure des interlocuteurs joignables hors horaires ouvrés, les catégories minimales d’information, des canaux sécurisés, des délais internes plus courts que les maximums réglementaires, des règles de préservation, une procédure d’approbation des communications et le traitement des données protégées. L’objectif n’est pas de transférer automatiquement la responsabilité, mais de réduire le délai entre la connaissance d’un fait et l’obtention des éléments nécessaires à son évaluation.

Le déployeur doit conserver et fournir les données sous son contrôle qui sont nécessaires, dans les limites légales applicables. Le fournisseur ne devrait pas exiger une reproduction parfaite pour commencer l’évaluation. Réciproquement, le déployeur ne devrait pas appliquer de changements locaux, effacer des journaux ou communiquer une cause technique comme établie sans coordonner le dossier. Lorsque plusieurs entités interviennent, un registre partagé des demandes de preuves aide à distinguer ce qui a été livré, ce qui reste attendu et ce qui ne peut pas être obtenu.

Les obligations de transparence, de journalisation et de coopération associées aux systèmes à haut risque peuvent être importantes pour le bon fonctionnement de cette coordination, mais elles ne font pas automatiquement du déployeur le responsable de la notification prévue pour le fournisseur à l’article 73. La répartition finale dépend du rôle effectif de chaque entité et des circonstances du système examiné.

Notification : gérer les délais sans les réduire à une formule automatique

L’article 73 impose de communiquer les incidents graves aux autorités de surveillance du marché des États membres dans lesquels l’incident s’est produit, dans les conditions prévues par le règlement. La communication est liée à la fois à la connaissance de l’incident et à la détermination d’un lien de causalité, ou de sa probabilité raisonnable. L’équipe doit donc enregistrer séparément le moment de la prise de connaissance, le moment où une conclusion provisoire sur le lien a été adoptée, et les éléments soutenant ces deux jalons.

Le règlement prévoit des délais maximaux de deux, dix et quinze jours pour des situations différentes, ainsi que la possibilité d’un rapport initial incomplet suivi d’informations complémentaires. L’attribution exacte de chaque délai dépend de la catégorie concrète de l’incident et de la rédaction applicable à la situation. Elle ne doit pas être déduite d’un tableau interne simplifié ni de la seule gravité technique. Le protocole doit déclencher une revue juridique immédiate, calculer le délai à partir d’un jalon documenté et consigner le motif du choix de ce délai.

Un rapport initial ne doit pas simuler une certitude qui n’existe pas. Si la cause est inconnue, il doit indiquer qu’elle fait l’objet d’une enquête, décrire les faits confirmés, le périmètre connu, les mesures de confinement, les éléments disponibles et le plan de complétude. La possibilité de fournir un rapport incomplet ne justifie ni le report d’une communication requise, ni l’absence d’enquête diligente.

Le modèle de rapport et les orientations publiés par la Commission sur les incidents graves sont des ressources utiles pour organiser les rubriques et les séquences, mais ils sont présentés comme des projets soumis à consultation. Ils ne doivent pas être traités comme des orientations finales contraignantes. Pour un cas réel, l’équipe doit confronter le contenu de sa communication au règlement applicable et aux instructions de l’autorité compétente.

Enquête, correction et reprise contrôlée

L’enquête ne s’achève pas avec l’envoi d’une communication. Elle doit expliquer la cause ou les causes contributives avec un niveau de confiance proportionné : comportement du modèle, données d’entrée, récupération, outil, interface, autorisations, configuration, supervision humaine, formation, processus opérationnel ou combinaison de ces éléments. Une cause racine unique peut être une simplification trompeuse lorsqu’un incident dépend de plusieurs contrôles défaillants ou inexistants.

L’action corrective doit être liée à la voie de préjudice identifiée. Ajuster un prompt peut être insuffisant si le problème était un droit excessif accordé à un outil ; ajouter une revue humaine peut être insuffisant si le réviseur ne reçoit pas les données nécessaires ; retirer un document peut être insuffisant si le connecteur continue d’intégrer des sources non autorisées. Pour chaque mesure, définissez le risque qu’elle réduit, le risque résiduel qu’elle laisse, les effets secondaires possibles et le mode de validation.

La validation doit intégrer le cas d’incident et une régression plus large. Ne tester que la conversation d’origine peut favoriser une correction trop ajustée. Il est préférable de combiner des essais représentatifs, des cas limites, des tests de droits et des flux complets jusqu’à l’action externe, ainsi que d’examiner les effets sur les utilisateurs et les groupes affectés lorsque cela est pertinent. Conservez les résultats, l’environnement de test, les versions et les critères d’acceptation.

La reprise ne doit pas être une décision implicite prise lors de la clôture d’un ticket. Elle doit avoir un responsable, des critères d’autorisation, un périmètre initial, des métriques de surveillance renforcée, un mécanisme de retour arrière et des conditions imposant une nouvelle suspension. Si une incertitude importante subsiste, l’organisation peut choisir de maintenir la capacité affectée limitée pendant qu’elle complète l’enquête. Cette décision et ses motifs doivent figurer dans le dossier.

Préparation trimestrielle : vérifier que le protocole fonctionne avant l’incident

La capacité à répondre n’est pas démontrée parce que des journaux techniques ou une politique écrite existent. Il faut prouver que l’équipe peut récupérer un cas réaliste sans dépendre d’une seule personne ni d’outils qui ne conservent pas les données nécessaires. Un exercice trimestriel peut sélectionner un flux à risque, simuler une alerte et mesurer le temps nécessaire pour identifier la version déployée, isoler la capacité concernée, obtenir les journaux du déployeur et produire une chronologie fondée sur des sources vérifiables.

La revue doit inclure les changements de fournisseurs, de modèles, d’outils, de corpus, de droits, de responsables et de marchés de déploiement. Un protocole préparé pour un modèle statique peut échouer en cas de routage entre modèles, de déploiements progressifs, de récupération dynamique ou d’outils tiers. Il est également utile de vérifier si les accords avec les clients et fournisseurs permettent le partage rapide des preuves nécessaires, avec des contrôles adaptés de confidentialité et de protection des données.

Le résultat de chaque exercice doit conduire à des améliorations observables : champs manquants dans les journaux, décisions sans responsable, impossibilité de récupérer des configurations, absence de canal d’urgence ou critères de suspension ambigus. Il ne s’agit pas de déclarer une conformité générale à l’AI Act, mais de réduire l’incertitude lors d’une réponse précise à un incident. La préparation la plus utile est celle qui permet de dire ce qui est connu, ce qui ne l’est pas et ce qui a été fait pour empêcher la poursuite du préjudice.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.