Le signalement obligatoire des incidents liés à l’IA progresse

Le signalement obligatoire des incidents liés à l’IA devient une exigence opérationnelle, et non plus une simple proposition de politique. En vertu du règlement européen sur l’IA, les règles de signalement des incidents graves impliquant des systèmes d’IA à haut risque sont devenues applicables le 2 août 2026. Il est donc important que les fournisseurs et les déployeurs sachent qui doit agir, ce qui peut constituer un incident et dans quels délais les informations doivent circuler.

Le signalement comporte plusieurs volets. Les fournisseurs de systèmes d’IA à haut risque sont soumis aux obligations de l’article 73, tandis que les fournisseurs de modèles d’IA à usage général présentant un risque systémique sont soumis à des exigences distinctes concernant le suivi, la documentation et le signalement des incidents graves. En pratique, le défi consiste à relier ces obligations juridiques à la détection, à l’enquête, à la remontée des alertes et aux mesures correctives, sans supposer que toutes les défaillances de l’IA suivent la même procédure de signalement.

Ce qu’exige désormais le signalement obligatoire des incidents liés à l’IA

Réponse directe : En vertu du règlement européen sur l’IA, les fournisseurs de systèmes d’IA à haut risque doivent signaler les incidents graves aux autorités compétentes. Les déployeurs qui identifient un incident grave doivent en informer immédiatement le fournisseur, puis l’importateur ou le distributeur ainsi que les autorités compétentes de surveillance du marché. Les fournisseurs de modèles d’IA à usage général présentant un risque systémique ont une obligation distincte de suivre, de documenter et de signaler les incidents graves ainsi que les éventuelles mesures correctives au Bureau de l’IA et, le cas échéant, aux autorités nationales, sans retard injustifié.

Il est important de distinguer ces obligations. Une règle applicable à un système d’IA à haut risque ne doit pas être considérée comme interchangeable avec une règle applicable à un modèle d’IA à usage général présentant un risque systémique, même lorsque ce modèle est utilisé dans un système. La Commission traite ces deux procédures de signalement dans des orientations distinctes, et le texte du règlement sur l’IA demeure la référence juridique fondamentale pour déterminer l’obligation applicable.

Pour les systèmes d’IA à haut risque, la Commission indique que les règles, qui comprennent l’obligation de signaler les incidents graves, sont devenues applicables le 2 août 2026. Le signalement vise, selon elle, à détecter rapidement les risques, à garantir la responsabilisation et à permettre une intervention rapide. Ces objectifs expliquent pourquoi un signalement n’est pas simplement un document administratif établi une fois l’enquête terminée : il permet aux autorités de prendre connaissance de défaillances potentiellement lourdes de conséquences alors qu’une intervention peut encore être nécessaire.

Avant l’entrée en application des règles, la Commission a publié un projet d’orientations et un modèle de signalement des incidents graves afin de recueillir les commentaires des parties prenantes. Ces travaux préparatoires permettent de structurer le signalement, mais les orientations et les modèles doivent être consultés en complément du règlement, et non s’y substituer. Le texte consolidé du règlement sur l’IA disponible sur EUR-Lex, notamment son article 73, est la référence essentielle pour la procédure de signalement et les responsabilités correspondantes des fournisseurs et des déployeurs.

Le signalement s’inscrit également dans un ensemble plus large d’obligations de conformité. La présentation du règlement sur l’IA par la Commission le relie à l’enregistrement, à la transparence, aux mesures correctives et à la coopération avec les autorités de surveillance du marché. Une organisation qui sait transmettre un signalement, mais qui ne peut pas identifier le système concerné, expliquer ce qui s’est passé ou coordonner les mesures de suivi, n’a résolu qu’une partie du problème.

Qui signale un incident lié à l’IA : fournisseurs, déployeurs et développeurs de modèles

La première question opérationnelle n’est pas de savoir quel formulaire remplir, mais quel rôle l’organisation joue par rapport au système ou au modèle d’IA concerné. Différentes équipes peuvent être confrontées au même événement à différents stades : un déployeur peut observer les conséquences dans le monde réel, tandis qu’un fournisseur peut détenir les données techniques nécessaires à l’examen du comportement du système.

Les fournisseurs de systèmes d’IA à haut risque sont responsables du signalement aux autorités

Le service d’assistance consacré au règlement sur l’IA indique que les fournisseurs de systèmes d’IA à haut risque doivent signaler les incidents graves. La remontée d’informations vers le fournisseur constitue donc une étape cruciale lorsqu’un incident se manifeste d’abord en dehors de ses propres activités. Les fournisseurs doivent pouvoir recevoir des alertes crédibles, préserver les informations pertinentes, évaluer l’événement et déterminer comment respecter la procédure de signalement applicable.

Cela ne signifie pas qu’un fournisseur doit attendre d’avoir une explication technique complète avant de prendre au sérieux un incident potentiel. La règle relative aux décès fait expressément référence à un lien de causalité suspecté, et non uniquement à un lien établi de manière concluante. Cette distinction est importante lorsque les éléments de preuve sont encore incomplets et que les personnes chargées d’enquêter doivent respecter un délai légal.

Les déployeurs doivent transmettre les informations relatives aux incidents graves

Les déployeurs ont leur propre obligation lorsqu’ils identifient un incident grave. Ils doivent en informer immédiatement le fournisseur, puis l’importateur ou le distributeur ainsi que les autorités compétentes de surveillance du marché. Un déployeur ne peut donc pas supposer que prévenir son fournisseur suffit à satisfaire à l’ensemble des exigences prévues par les règles.

Cette séquence nécessite une liste pratique de contacts. Un déployeur doit savoir quel fournisseur est associé au système déployé, quel importateur ou distributeur est concerné et comment joindre l’autorité compétente de surveillance du marché. L’organisation doit également être en mesure de transmettre les informations dont elle dispose, sans transformer des observations incertaines en conclusions techniques définitives.

Les fournisseurs de modèles d’IA à usage général présentant un risque systémique suivent une procédure distincte

Pour les fournisseurs de modèles d’IA à usage général présentant un risque systémique, les orientations de la Commission relatives aux modèles d’IA à usage général prévoient de suivre, de documenter et de signaler les incidents graves ainsi que les éventuelles mesures correctives au Bureau de l’IA et, le cas échéant, aux autorités nationales, sans retard injustifié. La Commission a également publié un modèle de signalement destiné à mettre en œuvre concrètement les obligations de signalement prévues à l’article 55 et à aider ces fournisseurs à démontrer leur conformité.

Il ne s’agit pas d’affirmer de manière générale que tous les développeurs de tous les modèles d’IA sont soumis à des obligations de signalement identiques. Il faut d’abord établir la classification du modèle concerné et le rôle de l’organisation. Lorsqu’un modèle présentant un risque systémique est utilisé dans un produit en aval, une communication claire entre le fournisseur du modèle et l’exploitant du système peut aider chaque partie à comprendre les éléments de preuve dont elle dispose et la procédure de signalement qu’elle peut devoir suivre.

• Fournisseur d’un système d’IA à haut risque : Déterminer comment les incidents graves sont transmis à l’équipe chargée du signalement et du suivi au titre de l’article 73.
• Déployeur d’un système d’IA à haut risque : Déterminer comment le personnel reconnaît un incident grave potentiel et le signale immédiatement aux parties désignées par les règles.
• Fournisseur d’un modèle d’IA à usage général présentant un risque systémique : Déterminer comment les incidents graves liés au modèle et les éventuelles mesures correctives sont suivis, documentés et communiqués dans le cadre distinct applicable aux modèles d’IA à usage général.

Ces rôles peuvent nécessiter une coordination, mais coordonner les actions ne revient pas à se décharger de ses responsabilités. Un contrat peut préciser les contacts et les procédures d’échange d’informations ; il ne doit pas être considéré comme un substitut aux obligations qui incombent à une partie au titre de son rôle en vertu du règlement sur l’IA.

Qu’est-ce qui constitue un incident grave lié à l’IA ?

Le terme « incident » peut désigner aussi bien une interruption mineure de service qu’un événement aux conséquences durables. La question à poser au regard des règles européennes de signalement est plus précise et plus lourde de conséquences : l’événement répond-il aux critères applicables aux incidents graves ? Les orientations de la Commission relatives aux considérants décrivent les incidents graves de manière suffisamment large pour que les équipes ne limitent pas leur examen aux seules blessures physiques.

• Décès : Un événement entraînant le décès d’une personne exige une attention particulière, car l’article 73 prévoit une règle de signalement spécifique lorsqu’un lien de causalité avec le système d’IA est établi ou suspecté.
• Perturbation des infrastructures critiques : La perturbation grave et irréversible des infrastructures critiques figure parmi les conséquences relevées dans les orientations de la Commission.
• Droits fondamentaux : Les atteintes aux protections des droits fondamentaux prévues par le droit de l’Union peuvent relever de la définition d’un incident grave ; la question ne se limite pas aux dommages matériels.
• Préjudices matériels ou environnementaux : Les dommages graves causés aux biens ou à l’environnement sont également mentionnés dans la description de la Commission.

Ces catégories rendent le triage plus complexe que la simple recherche d’un type unique de dysfonctionnement du système. Une conséquence préoccupante peut apparaître dans le cadre de la surveillance opérationnelle, de réclamations, d’une enquête de sécurité ou d’informations détenues par une organisation utilisant le système. Une procédure de réception des signalements utile consigne à la fois la conséquence rapportée et les raisons pour lesquelles le système d’IA pourrait y être lié, tout en permettant à cette évaluation d’évoluer à mesure que de nouveaux éléments apparaissent.

La présence d’un préjudice ne justifie pas, à elle seule, d’affirmer sans preuve qu’un système d’IA en est la cause. À l’inverse, l’incertitude quant au lien de causalité ne doit pas servir de prétexte pour ignorer une alerte crédible. Pour le délai applicable en cas de décès, le texte juridique couvre expressément le lien de causalité suspecté ; une organisation doit donc pouvoir distinguer un soupçon raisonnable justifiant une remontée de l’information d’une conclusion qui nécessite encore une enquête.

Classer la conséquence avant de débattre du formulaire

Un dossier de triage pratique peut commencer par la description du résultat observé : qui ou quoi a été touché, si la conséquence perdure et quelle catégorie d’incident grave pourrait être concernée. Il peut ensuite identifier le système ou le modèle d’IA en cause, le contexte dans lequel il a été utilisé et les informations qui étayent ou affaiblissent l’hypothèse d’un lien. La première évaluation porte ainsi sur la question du signalement, sans chercher à remplir tous les champs d’un compte rendu technique définitif.

Certains événements resteront difficiles à classer. Par exemple, un défaut technique peut être évident alors que ses effets réels sont encore inconnus, ou une conséquence grave peut être manifeste alors que le rôle du système d’IA est contesté. Ces situations justifient de préserver les éléments de preuve et de signaler l’incertitude, et non de forcer une réponse définitive prématurée à partir d’informations incomplètes.

Le rapport de la Commission sur les incidents liés à l’IA publié en 2026 indique que seules certaines catégories d’incidents ont fait l’objet d’une analyse plus approfondie. Cela témoigne utilement de l’évolution générale des politiques vers une classification structurée, mais ne permet pas de déterminer à lui seul si un événement particulier doit être signalé. Les dispositions applicables du règlement sur l’IA et les faits propres à l’événement restent les points de départ.

Comment le délai de signalement prévu par le règlement sur l’IA en cas de décès modifie la gestion des incidents

La règle fournie qui prévoit le délai le plus clair concerne les incidents entraînant le décès d’une personne. L’article 73 dispose que le signalement doit être transmis immédiatement après que le fournisseur ou le déployeur a établi ou suspecté un lien de causalité avec le système d’IA, et au plus tard 10 jours après avoir pris connaissance de l’incident. Ces deux éléments doivent être lus conjointement : le délai maximal ne transforme pas l’obligation de signalement immédiat en autorisation d’attendre.

Cette formulation signifie que l’équipe chargée de l’incident doit pouvoir reconstituer deux éléments : la date à laquelle elle a pris connaissance de l’incident et celle à laquelle un fournisseur ou un déployeur a établi ou suspecté le lien de causalité. Si ces moments diffèrent, ils sont tous deux importants. Une procédure qui ne consigne que la date d’achèvement d’une enquête interne peut omettre le moment où l’obligation d’agir était déjà déclenchée.

1. Consigner la première alerte crédible. Notez quand l’organisation a pris connaissance de l’événement, la source de l’alerte et les informations disponibles à ce moment-là. Conservez le compte rendu initial au lieu de le remplacer par un résumé ultérieur.
2. Signaler rapidement tout lien de causalité possible. Transmettez aux personnes chargées de l’évaluation juridique et technique les éléments indiquant un lien possible avec le système d’IA. Distinguez les observations, les déductions et les questions non résolues.
3. Informer les parties requises. Si un déployeur identifie un incident grave, il est important de respecter la séquence de notification immédiate. La tâche de signalement du fournisseur doit être confiée à une personne désignée et prévoir un moyen de contacter l’autorité compétente.
4. Conserver une trace des décisions. Consignez le moment où le soupçon est apparu, la personne qui a procédé à l’évaluation, les informations qui l’étayaient et les mesures prises par la suite. Une précision ultérieure des faits ne doit pas effacer la chronologie initiale.

Cette procédure ne vise pas à remplacer l’article 73 par une liste de contrôle interne. Elle permet de rendre la conformité réalisable lorsque les éléments de preuve sont répartis entre les équipes des opérations, de la sécurité, de la sûreté et de la gestion des fournisseurs. Une organisation peut adapter ces étapes à sa structure, mais elle ne peut pas supposer qu’un cycle d’enquête normal, plus lent, convient à une règle qui impose d’agir immédiatement dès qu’un lien de causalité est suspecté.

Le délai maximal de 10 jours applicable en cas de décès ne doit pas être appliqué à la légère à tous les incidents graves liés à l’IA. Les éléments fournis indiquent ce délai précis ainsi que l’obligation distincte de signaler les incidents liés aux modèles d’IA à usage général présentant un risque systémique « sans retard injustifié » ; ils n’établissent pas un délai universel pour tous les événements. Les équipes doivent vérifier la disposition applicable et les orientations officielles à jour en fonction de l’événement et du rôle concernés, plutôt que de s’en remettre à une formule simplifiée valable à l’échelle de l’entreprise.

Pourquoi le signalement des incidents liés aux modèles d’IA à usage général inclut les événements de cybersécurité

Pour les modèles d’IA à usage général présentant un risque systémique, un incident peut concerner le modèle ou l’infrastructure qui le soutient, et pas seulement un préjudice immédiatement visible découlant d’une application déployée. Les orientations de la Commission relatives aux modèles d’IA à usage général prévoient que les fournisseurs suivent, documentent et signalent les incidents graves ainsi que les éventuelles mesures correctives au Bureau de l’IA et, le cas échéant, aux autorités nationales, sans retard injustifié.

La foire aux questions de la Commission établit explicitement un lien entre cette obligation de signalement et les violations graves de la cybersécurité liées au modèle ou à son infrastructure physique. Elle cite notamment l’exfiltration autonome des paramètres du modèle et les cyberattaques comme exemples susceptibles de relever de cette obligation. Ce lien élargit le cercle des équipes susceptibles de détecter un signal à signaler : les spécialistes de la sûreté des modèles ne seront pas nécessairement les premiers à repérer une alerte d’intrusion ou une anomalie de l’infrastructure.

Relier les alertes de sécurité à l’évaluation des incidents liés aux modèles

Une alerte de cybersécurité ne suffit pas automatiquement à répondre à toutes les questions de signalement. Le personnel de sécurité peut savoir qu’une attaque a eu lieu tout en continuant d’en examiner l’ampleur, tandis que les équipes chargées des modèles peuvent en comprendre les conséquences potentielles sans avoir accès aux journaux de sécurité sous-jacents. La procédure de signalement doit prévoir une transmission entre ces fonctions afin que l’événement soit évalué au regard du modèle, de son infrastructure et de l’obligation applicable aux incidents graves.

Les premiers éléments utiles à consigner comprennent le système ou l’infrastructure touchés, le comportement observé, le moment où l’équipe en a eu connaissance pour la première fois ainsi que les mesures de confinement ou autres mesures correctives envisagées. Ces éléments ne remplacent pas une évaluation juridique. Ils la rendent possible et aident le fournisseur à expliquer l’évolution de sa compréhension des faits.

Le modèle de signalement de la Commission relatif aux modèles d’IA à usage général vise à mettre en œuvre concrètement les obligations de signalement prévues à l’article 55 et à aider les fournisseurs à démontrer leur conformité. Un modèle peut favoriser la cohérence des informations, notamment lorsque plusieurs équipes internes contribuent au signalement. À lui seul, il ne peut toutefois ni détecter une violation, ni déterminer si un événement est grave, ni garantir que le Bureau de l’IA et les autorités nationales compétentes, le cas échéant, soient contactés sans retard injustifié.

Il faut également veiller à bien distinguer deux situations pratiques : une plainte d’une organisation en aval concernant un produit utilisant l’IA et une violation grave de la cybersécurité impliquant le modèle sous-jacent peuvent être adressées à des personnes différentes et soulever des questions distinctes en matière de signalement. Un canal commun de réception des incidents peut aider à recueillir les deux types d’informations, mais le triage doit identifier le système ou le modèle concerné ainsi que la procédure de signalement applicable, au lieu de regrouper des obligations distinctes dans une catégorie générique unique d’« incident lié à l’IA ».

Mettre en place une procédure de signalement qui favorise les mesures correctives

Le signalement obligatoire est plus efficace lorsqu’il est lié à la capacité de l’organisation à comprendre et à traiter l’événement sous-jacent. La Commission présente le signalement en parallèle de l’enregistrement, de la transparence, des mesures correctives et de la coopération avec les autorités de surveillance du marché. Cette approche plaide en faveur d’une procédure avec des responsables clairement désignés et des éléments de preuve exploitables, et non d’un simple formulaire qui n’apparaît qu’à la fin d’une crise.

Définir un canal de réception des alertes avant qu’un incident ne survienne

Les personnes concernées doivent savoir où transmettre un signalement potentiel d’incident grave. Il s’agit notamment du personnel qui exploite un système à haut risque, des équipes chargées de recevoir les réclamations des utilisateurs, du personnel technique qui surveille les défaillances et des équipes de sécurité qui surveillent l’infrastructure d’un modèle présentant un risque systémique. La procédure de réception doit permettre de transmettre une alerte incertaine sans exiger de la première personne qui la découvre qu’elle établisse une classification juridique définitive.

Un dossier de réception pratique distingue les observations du déclarant de l’analyse ultérieure. Il peut consigner le système ou le modèle concerné, la conséquence apparente, la première date connue de l’événement, la première date à laquelle l’organisation en a eu connaissance et les parties déjà informées. Le fait de conserver ces informations séparément réduit le risque qu’un compte rendu ultérieur, mieux formulé, masque ce qui était connu au moment où une décision de notification immédiate devait être prise.

Confier les décisions aux bonnes personnes

Les enquêteurs techniques peuvent analyser le comportement du système, mais ils ne savent pas nécessairement quelle autorité de surveillance du marché est compétente. Les équipes juridiques ou de conformité peuvent connaître les règles de signalement, mais elles ont besoin de faits opérationnels fiables. Un groupe d’escalade défini peut réunir les compétences nécessaires et déterminer qui est habilité à envoyer les notifications requises, à approuver les signalements et à coordonner les mesures correctives.

Pour les déployeurs, cela signifie également qu’ils doivent traiter les coordonnées du fournisseur comme des données opérationnelles, et non comme un détail enfoui dans les dossiers d’approvisionnement. Pour les fournisseurs, cela signifie qu’ils doivent recevoir et examiner les notifications des déployeurs en préservant leur date et leur contenu. Lorsque des importateurs ou des distributeurs sont concernés, les déployeurs doivent comprendre la procédure de notification prévue avant qu’un incident ne la rende urgente.

Utiliser les modèles comme des outils, et non comme des décideurs

Le projet d’orientations et le modèle de signalement de la Commission pour les incidents graves impliquant des systèmes d’IA à haut risque, ainsi que son modèle distinct pour les modèles d’IA à usage général présentant un risque systémique, peuvent aider les équipes à organiser les informations. Ils sont précieux précisément parce que les signalements d’incidents s’appuient souvent sur des faits répartis entre différents services. Un modèle doit inciter à recueillir et à communiquer des informations ; il ne doit pas servir de prétexte pour retarder la remontée d’une alerte jusqu’à ce que toutes les réponses soient établies.

• Détection : Rendre les signaux liés à la sûreté, aux opérations, aux droits, à l’environnement et aux biens, ainsi que les signaux pertinents de cybersécurité, visibles des personnes chargées d’évaluer les incidents.
• Triage : Consigner les conséquences graves potentielles, le lien avec l’IA examiné et le rôle concerné : fournisseur, déployeur ou fournisseur d’un modèle d’IA à usage général.
• Notification et signalement : Tenir à jour les coordonnées nécessaires et conserver une trace du moment où chaque partie ou autorité concernée a été informée.
• Suivi : Relier le dossier d’incident aux conclusions de l’enquête, aux éventuelles mesures correctives et à la coopération avec les autorités lorsque celle-ci est requise.

Cette approche implique un compromis. Une procédure fortement centralisée peut améliorer la cohérence, mais risque de devenir un goulot d’étranglement lorsqu’une intervention immédiate est nécessaire. Une procédure entièrement décentralisée peut sembler plus rapide au départ, mais conduire les équipes à appliquer des définitions différentes ou à oublier un destinataire obligatoire. Le juste milieu consiste à désigner clairement les responsables de l’escalade tout en autorisant le personnel de première ligne à signaler rapidement les incertitudes.

Les signalements d’incidents liés à l’IA peuvent-ils être harmonisés entre les différents règlements de l’UE ?

Les organisations peuvent déjà gérer des procédures de signalement des incidents de cybersécurité et d’autres incidents réglementaires en parallèle de leurs obligations au titre du règlement sur l’IA. Une question d’efficacité se pose donc naturellement : un même dossier interne peut-il servir à plusieurs obligations de signalement ? La volonté politique d’une meilleure harmonisation gagne du terrain, mais il ne faut pas confondre harmonisation et supposition selon laquelle différentes lois reposent sur des critères de déclenchement, des destinataires ou des délais identiques.

Un document du Conseil de 2026 consacré au règlement omnibus numérique sur l’IA souligne le « chevauchement important » entre les exigences du règlement sur l’IA en matière de cybersécurité et d’autres textes européens sur la cybersécurité, et cite expressément le signalement des incidents en exemple. Cette observation plaide en faveur d’une meilleure coordination entre les équipes internes chargées de l’IA et de la cybersécurité. Elle n’établit pas qu’un signalement effectué au titre d’un régime satisfait automatiquement aux obligations d’un autre.

L’OCDE a également défendu la mise en place d’un cadre commun de signalement des incidents liés à l’IA. Son rapport de 2025 décrit les données requises pour chaque signalement et indique que le cadre peut être adapté en lui ajoutant des critères obligatoires pour un contexte de signalement donné. Cela offre un principe de conception utile : recueillir une seule fois, dans la mesure du possible, un ensemble cohérent d’informations essentielles sur l’incident, puis ajouter les champs et les mesures qu’exige la procédure juridique applicable.

Un dossier interne commun pourrait suivre la chronologie de l’événement, le système ou le modèle d’IA concerné, la conséquence observée, les éléments étayant un lien de causalité suspecté, l’état de l’enquête et les notifications déjà effectuées. Des procédures distinctes pourraient ensuite déterminer si l’événement relève de l’article 73, de l’obligation applicable aux modèles d’IA à usage général présentant un risque systémique ou d’une autre procédure pertinente. Cela évite de recueillir plusieurs fois les mêmes faits sans effacer les différences juridiques importantes.

La standardisation a toutefois ses limites. Une atteinte grave aux protections des droits fondamentaux peut nécessiter des compétences différentes de celles requises pour une cyberattaque contre l’infrastructure d’un modèle. L’obligation de notification immédiate qui incombe à un déployeur diffère également du signalement aux autorités qui relève d’un fournisseur. Si un formulaire commun masque ces distinctions, il peut donner une impression de cohérence tout en compliquant la prise de décisions urgentes.

Les travaux de la Commission sur les données relatives aux incidents, notamment son rapport de 2026 dans lequel seules certaines catégories ont fait l’objet d’une analyse approfondie, témoignent d’une évolution vers une classification plus structurée. Une meilleure classification peut aider les organisations à comparer les événements et à en tirer des enseignements au fil du temps. Pour chaque événement, la tâche immédiate reste toutefois concrète : établir ce qui s’est passé, identifier la partie responsable, préserver la chronologie et agir conformément à la règle applicable.

Le signalement obligatoire des incidents liés à l’IA renforce la capacité de l’UE à identifier les risques graves liés à l’IA et à y répondre, mais son efficacité dépend de ce qui se passe avant la transmission d’un signalement. Les fournisseurs et les déployeurs de systèmes à haut risque ont besoin d’un processus fiable de remontée des alertes ; les fournisseurs de modèles d’IA à usage général présentant un risque systémique ont besoin d’un processus reliant la surveillance des modèles au suivi de la cybersécurité et des infrastructures.

La meilleure prochaine étape consiste à tester la procédure de signalement d’une organisation à partir d’un incident plausible : qui le remarquerait, à quel moment le soupçon serait-il consigné, quelles parties seraient informées et qui déciderait des éléments à signaler ? Des réponses fondées sur le texte du règlement sur l’IA, les orientations actuelles de la Commission et les systèmes réellement utilisés par l’organisation sont plus utiles qu’un formulaire générique que personne ne peut utiliser sous pression.