Les régulateurs exigent des rapports publics sur les incidents liés à l’IA

Les régulateurs font sortir le signalement des incidents liés à l’IA du domaine de l’éthique volontaire pour l’intégrer à une gouvernance formelle. L’exemple le plus clair est le règlement européen sur l’IA, qui oblige les fournisseurs de systèmes d’IA à haut risque à signaler les incidents graves aux autorités compétentes. Parallèlement, les modèles de la Commission européenne, les obligations d’enregistrement imposées aux déployeurs du secteur public et les travaux de suivi international de l’OCDE font émerger une attente plus large : les défaillances importantes de l’IA doivent être documentées sous une forme cohérente afin que les régulateurs, les opérateurs, les responsables politiques et le public puissent en tirer des enseignements.

Cela ne signifie pas que chaque dossier d’incident deviendra automatiquement un document entièrement public. Le signalement réglementaire à une autorité, l’enregistrement dans une base de données officielle et la publication d’un résumé public de l’incident sont des mécanismes différents. Toute discussion fiable sur les rapports publics d’incidents liés à l’IA doit préserver ces distinctions. Malgré tout, l’orientation politique est claire. Les autorités souhaitent des notifications plus rapides, des éléments de preuve mieux structurés, des mesures correctives documentées et une meilleure visibilité sur les tendances en matière de préjudices réels et de dangers émergents.

Pourquoi le signalement des incidents liés à l’IA devient une priorité réglementaire

Les systèmes d’IA peuvent influencer des décisions et des services à une échelle qui rend les défaillances isolées difficiles à évaluer. Un dysfonctionnement touchant une seule personne peut révéler une faiblesse de conception susceptible d’en affecter beaucoup d’autres. Une perturbation impliquant une infrastructure critique peut mettre en évidence des dépendances que ni le fournisseur ni le déployeur n’avaient pleinement comprises avant l’événement.

Les rapports d’incidents permettent de transformer ces événements individuels en informations utiles à la gouvernance. Ils peuvent montrer ce qui s’est passé, quel système était concerné, comment le préjudice s’est produit, si des personnes ou des infrastructures restent exposées et quelles mesures correctives ont été prises. Lorsque les rapports utilisent des catégories compatibles, les autorités peuvent également aller au-delà d’un cas isolé et repérer des modes de défaillance récurrents.

L’OCDE affirme que le signalement et le suivi des incidents liés à l’IA devraient être « cohérents et interopérables à l’échelle mondiale » afin que les responsables politiques et les opérateurs puissent tirer des enseignements des risques et des incidents signalés dans le monde entier.

Cette importance accordée à l’apprentissage est essentielle. Le signalement des incidents n’est pas seulement un mécanisme permettant d’attribuer les responsabilités après un préjudice. Il peut également favoriser la prévention en montrant où les contrôles techniques, la surveillance humaine, les procédures de déploiement ou la communication organisationnelle ont échoué.

Plusieurs objectifs réglementaires convergent :

• Responsabilité : les fournisseurs et les déployeurs doivent être capables d’expliquer ce qui s’est passé et comment ils ont réagi.
• Intervention rapide : les autorités doivent être informées sans délai lorsqu’un système d’IA est susceptible d’être lié à un décès, à une atteinte grave à la santé, à une violation des droits fondamentaux, à une perturbation d’infrastructures ou à tout autre préjudice grave.
• Apprentissage réglementaire : des rapports structurés peuvent révéler des tendances qui ne ressortent pas des plaintes individuelles ou des articles de presse.
• Mesures correctives : le signalement peut relier un incident à des actions d’endiguement, de remédiation, de suivi ou à des modifications de la manière dont un système est développé et utilisé.
• Confiance du public : une divulgation appropriée peut démontrer que les défaillances importantes sont reconnues plutôt que dissimulées.

Les rapports publics d’incidents liés à l’IA peuvent contribuer à tous ces objectifs, mais leur publication nécessite une conception rigoureuse. Un registre public utile doit fournir suffisamment de détails pour permettre un examen critique sans exposer inutilement des données à caractère personnel, des informations confidentielles ou des détails techniques sensibles sur le plan de la sécurité. Cet équilibre est l’une des raisons pour lesquelles les cadres normalisés de signalement sont importants : ils peuvent distinguer les informations nécessaires aux régulateurs de celles qui conviennent à une diffusion plus large.

Ce que le règlement européen sur l’IA exige concernant les incidents graves

Le règlement européen sur l’IA instaure une obligation contraignante de signalement des incidents graves pour les fournisseurs de systèmes d’IA à haut risque. Le signalement va ainsi au-delà des déclarations générales sur une IA responsable. Lorsque les conditions applicables sont réunies, les fournisseurs doivent avertir les autorités au lieu de décider uniquement en fonction de leur politique interne volontaire si un événement est suffisamment important pour être divulgué.

La signification d’un incident grave

Au sens du règlement, un incident grave est un incident ou un dysfonctionnement d’un système d’IA qui entraîne directement ou indirectement une ou plusieurs conséquences graves déterminées. La définition met l’accent sur les conséquences, y compris les conséquences indirectes, et non uniquement sur le fait qu’un composant logiciel ait manifestement cessé de fonctionner.

• Le décès d’une personne ou une atteinte grave à sa santé
• Une perturbation grave d’une infrastructure critique
• Une violation des obligations prévues par le droit de l’UE et destinées à protéger les droits fondamentaux
• Des dommages graves aux biens ou à l’environnement

Ce champ d’application est important, car un comportement préjudiciable de l’IA peut se produire même lorsqu’un système continue de fonctionner comme prévu d’un point de vue technique restreint. Un résultat peut être généré avec succès tout en contribuant à une violation grave des droits. De même, un modèle peut rester disponible tout en provoquant une série de problèmes opérationnels dans un environnement qui dépend de ses recommandations.

Les organisations ont donc besoin de bien plus qu’une surveillance classique de la disponibilité des logiciels. Elles doivent disposer de processus capables de détecter les conséquences sur la santé, la sécurité, les droits, les infrastructures, les biens et l’environnement. Les équipes techniques peuvent observer le comportement du modèle, tandis que les équipes juridiques, de conformité, de sûreté, de sécurité, de service client ou d’exploitation peuvent détenir les éléments qui font entrer un événement dans la catégorie des incidents graves.

Les délais de signalement sont délibérément courts

Le règlement sur l’IA ne traite pas le signalement des incidents graves comme une enquête sans limite de durée. En cas de décès, un rapport doit être établi immédiatement après que le fournisseur ou le déployeur a établi ou soupçonné un lien de causalité entre le système d’IA et l’événement. Dans tous les cas, le signalement doit intervenir au plus tard dix jours après la prise de connaissance de l’incident.

Les autres incidents graves doivent généralement être signalés dans un délai de quinze jours. Le cadre prévoit des délais plus courts pour les violations graves d’obligations et les perturbations graves d’infrastructures critiques. Comme le délai applicable dépend de l’incident, les organisations doivent consulter les exigences en vigueur plutôt que de supposer que le délai général de quinze jours s’applique systématiquement.

La référence à un lien de causalité soupçonné est importante sur le plan opérationnel. Un fournisseur peut devoir avertir une autorité avant d’avoir achevé son analyse des causes profondes ou formulé une conclusion juridique définitive. Attendre une certitude absolue peut être incompatible avec un délai déclenché par la prise de connaissance de l’incident et l’existence d’un soupçon.

1. La prise de connaissance doit être consignée. L’organisation doit disposer d’une méthode définie pour déterminer à quel moment les membres du personnel concernés ont pris connaissance d’un incident.
2. Le lien de causalité potentiel doit être évalué rapidement. Les équipes doivent examiner si le système d’IA a pu contribuer directement ou indirectement à la conséquence.
3. La gravité doit faire l’objet d’un triage. Les conséquences doivent être évaluées au regard des catégories d’incidents graves prévues par le règlement.
4. La notification ne doit pas attendre la fin de l’enquête. Un rapport initial peut refléter les informations connues à ce moment-là, à condition que les incertitudes soient présentées avec honnêteté.
5. Les éléments de preuve supplémentaires et les mesures correctives doivent être documentés. Le dossier d’incident doit être enrichi à mesure que l’enquête progresse.

Cette structure favorise une remontée rapide de l’information et un suivi rigoureux. Elle rend également indispensable la tenue de registres. Si une autorité demande ultérieurement pourquoi un événement a été ou n’a pas été signalé, l’organisation doit pouvoir montrer comment elle a évalué sa gravité, le lien de causalité, le calendrier et les informations disponibles à chaque étape.

Les rapports réglementaires, l’enregistrement dans une base de données et la divulgation publique ne sont pas identiques

L’expression « rapports publics d’incidents liés à l’IA » peut confondre plusieurs formes distinctes de transparence. Le règlement européen sur l’IA exige que les incidents graves impliquant des systèmes d’IA à haut risque soient signalés aux autorités. Cette exigence ne signifie pas, à elle seule, que chaque signalement et chaque document justificatif doivent être publiés sans restriction.

Trois niveaux doivent être distingués :

• La notification réglementaire confidentielle fournit aux autorités compétentes les informations nécessaires pour évaluer un incident, coordonner la surveillance et envisager des mesures correctives.
• L’enregistrement dans une base de données officielle crée une visibilité structurée sur les systèmes concernés et leur déploiement, sous réserve de la conception et des règles d’accès de la base de données.
• La divulgation publique de l’incident communique des faits sélectionnés aux communautés concernées, aux chercheurs, aux clients, aux journalistes, aux organisations de la société civile et aux autres parties prenantes.

Ces niveaux peuvent se renforcer mutuellement, mais ils s’adressent à des publics différents. Les régulateurs peuvent avoir besoin de renseignements personnels, commerciaux ou techniquement sensibles qu’il serait inapproprié de verser dans un registre public librement accessible. À l’inverse, un dossier technique conçu pour une autorité peut être trop spécialisé pour aider une personne touchée à comprendre les conséquences d’un incident.

Les autorités publiques ont des responsabilités supplémentaires

Le guichet d’assistance consacré au règlement européen sur l’IA indique que les autorités publiques qui déploient des systèmes d’IA à haut risque doivent veiller à leur enregistrement dans la base de données de l’UE. Si une autorité publique détecte un incident grave, elle doit immédiatement en informer le fournisseur, l’importateur ou le distributeur ainsi que les autorités de surveillance du marché compétentes.

Cela crée une chaîne de communication plutôt que de faire peser l’intégralité de la charge sur un seul acteur. Un fournisseur peut comprendre la conception, l’entraînement, les essais et les mises à jour du modèle, tandis qu’un déployeur du secteur public peut être le premier à observer la manière dont le système affecte les personnes dans un contexte administratif réel. Les importateurs, les distributeurs et les autorités de surveillance du marché peuvent assumer d’autres responsabilités ou détenir d’autres informations nécessaires à une réponse efficace.

L’enregistrement et la notification des incidents répondent également à des objectifs différents. L’enregistrement aide à déterminer où un système à haut risque est utilisé et par qui. La notification d’un incident signale qu’un événement préjudiciable ou un dysfonctionnement peut nécessiter une attention urgente. Ensemble, ils peuvent aider les autorités à relier un incident au système, au fournisseur et au contexte de déploiement concernés.

Pour les organismes publics, la transparence revêt une importance particulière, car l’utilisation de l’IA peut concerner les services publics et l’exercice de l’autorité publique. La communication publique doit néanmoins rester exacte. Une déclaration prématurée présentant un soupçon comme un lien de causalité établi peut induire en erreur, tandis que le silence peut laisser les personnes concernées dans l’ignorance d’un risque significatif. Une divulgation bien conçue doit clairement distinguer les faits confirmés, les évaluations en cours, les questions non résolues et les mises à jour prévues.

Comment les organisations peuvent mettre en place un processus défendable de signalement des incidents

Des délais courts ne peuvent pas être respectés de manière fiable au moyen d’une chaîne improvisée de courriels. Les fournisseurs et les déployeurs ont besoin d’un processus de gestion des incidents reliant la surveillance technique aux obligations juridiques et aux préjudices réels. Ce processus doit être établi avant qu’un événement grave ne se produise.

1. Définir largement les canaux de réception

Les incidents liés à l’IA peuvent d’abord apparaître dans des alertes de surveillance, des plaintes d’utilisateurs, des recours, des rapports de sûreté, des tickets de sécurité, des conclusions d’audit, des articles de presse ou des informations provenant d’un partenaire de déploiement. Un programme défendable doit recenser tous les canaux de réception pertinents et acheminer les signaux concernés vers une fonction commune d’évaluation.

Le personnel de première ligne a besoin de critères pratiques de remontée de l’information. Il n’a pas à prendre la décision réglementaire définitive, mais doit savoir que les signalements concernant un décès, une atteinte grave à la santé, des infrastructures critiques, des droits fondamentaux, des biens ou des dommages environnementaux nécessitent un examen urgent.

2. Préserver les éléments de preuve nécessaires pour reconstituer l’événement

Une enquête peut dépendre des versions du système, des registres de configuration, des entrées et sorties pertinentes, des journaux, des étapes de vérification humaine, des instructions de déploiement et du calendrier des mises à jour. La conservation doit être proportionnée et licite, avec des contrôles appropriés concernant les données à caractère personnel et les informations sensibles.

L’objectif n’est pas de tout recueillir sans discernement. Il s’agit de conserver les éléments nécessaires pour comprendre ce que le système a fait, ce que les personnes ont fait, quels contrôles étaient actifs et comment la conséquence s’est développée. Si les enregistrements sont écrasés avant qu’une décision de remontée de l’information ne soit prise, le signalement comme les mesures correctives deviennent plus difficiles.

3. Évaluer la gravité et le lien de causalité sans exiger de certitude

L’équipe chargée de l’examen doit déterminer si l’événement correspond à une conséquence constitutive d’un incident grave et si le système d’IA a pu y contribuer directement ou indirectement. Cette évaluation doit tenir compte de l’environnement de déploiement, car le préjudice peut résulter de l’interaction entre un modèle, une interface, des procédures opérationnelles, des données et des décisions humaines.

Les équipes doivent consigner les incertitudes plutôt que de s’en servir comme prétexte pour interrompre l’analyse. Une chronologie concise de l’incident peut recenser les événements confirmés, les liens plausibles, les lacunes dans les éléments de preuve et les autres explications possibles. Cela est particulièrement important lorsqu’un délai de signalement risque d’expirer avant la fin de l’analyse des causes profondes.

4. Attribuer à l’avance les pouvoirs décisionnels

Un plan efficace précise qui peut classifier un incident, autoriser un signalement, contacter l’autorité compétente et approuver une déclaration publique. Des suppléants doivent être désignés pour les absences et les événements survenant en dehors des heures normales de travail. Le plan doit également traiter de la communication entre les fournisseurs, les déployeurs, les importateurs, les distributeurs et les autorités lorsque ces acteurs sont concernés.

La responsabilité ne doit pas être limitée à l’équipe technique. Une intervention transversale peut nécessiter des compétences en ingénierie, produit, sûreté, droit, conformité, protection de la vie privée, sécurité, communication et exploitation. La haute direction doit avoir une visibilité sur les cas graves sans devenir un goulet d’étranglement qui ferait perdre le délai disponible pour le signalement.

5. Préparer un rapport initial et un processus contrôlé de mise à jour

Le premier signalement doit décrire avec exactitude ce qui est connu et ce qui reste en cours d’examen. Il doit identifier le système et l’incident, résumer les conséquences, expliquer le lien soupçonné, décrire les mesures immédiates d’endiguement et, le cas échéant, indiquer les mesures correctives envisagées.

Après la notification, l’organisation doit tenir un registre contrôlé des nouveaux éléments de preuve, des décisions et des mesures de remédiation. Les mises à jour ne doivent pas remplacer silencieusement les versions antérieures. Un historique clair aide à montrer comment la compréhension de l’incident a évolué et pourquoi les conclusions ultérieures peuvent différer de l’évaluation initiale.

6. Distinguer les détails réglementaires de la communication publique

Un régulateur peut avoir besoin d’informations qui ne peuvent pas être intégralement publiées de manière sûre ou licite. Les organisations doivent donc préparer un volet de divulgation publique parallèlement au volet réglementaire. La version publique peut expliquer la nature de l’événement, les effets connus, les protections en vigueur et les moyens d’obtenir de l’aide sans exposer d’informations personnelles ni de détails susceptibles de créer des risques pour la sécurité.

Cette séparation ne doit pas servir de prétexte à l’emploi de formulations vagues. Des déclarations telles que « un problème est survenu » offrent peu de transparence. Un rapport public utile doit décrire la fonction du système d’IA, le contexte de déploiement pertinent, la catégorie de préjudice, l’état d’avancement de l’enquête et les mesures correctives significatives, sous réserve des restrictions légitimes.

Les modèles normalisés transforment la politique en infrastructure

Le signalement des incidents devient plus utile lorsque les rapports peuvent être comparés. Les récits en texte libre peuvent contenir des faits importants, mais le manque de cohérence terminologique rend difficile l’agrégation des événements, la détection des tendances ou l’échange d’informations entre les autorités et par-delà les frontières.

La Commission européenne s’est orientée vers une divulgation normalisée. En 2025, elle a publié un modèle de signalement des incidents graves impliquant des modèles d’IA à usage général présentant un risque systémique. Les travaux de la Commission sur la mise en œuvre de l’IA en 2026 comprennent également expressément un « modèle de signalement des incidents graves par les fournisseurs de systèmes d’IA à haut risque ».

Ces modèles marquent le passage à une phase opérationnelle de la mise en œuvre. Ils peuvent orienter les fournisseurs vers des catégories communes, réduire les incertitudes quant aux informations attendues et faciliter le traitement des rapports par les autorités. La normalisation peut également favoriser de futurs résumés publics en créant des champs cohérents susceptibles d’être divulgués lorsque cela est approprié.

Modèles d’IA à usage général présentant un risque systémique

Le guichet d’assistance consacré au règlement sur l’IA indique que les fournisseurs de modèles d’IA à usage général présentant un risque systémique doivent assurer le suivi des incidents graves et les documenter. Ils doivent signaler ces incidents et les éventuelles mesures correctives sans retard injustifié au Bureau de l’IA et, le cas échéant, aux autorités nationales compétentes.

La référence aux mesures correctives élargit l’utilité du rapport. Les autorités doivent savoir non seulement qu’un préjudice s’est produit, mais également ce que fait le fournisseur pour éviter qu’il ne se reproduise. Les mesures possibles peuvent encore être en cours d’évaluation ; les fournisseurs doivent donc éviter de présenter une réponse non testée comme une solution achevée.

Les modèles à usage général peuvent également présenter des difficultés particulières en matière de signalement, car le fournisseur ne contrôle pas nécessairement toutes les utilisations en aval. Les organisations chargées du déploiement peuvent avoir la vision la plus claire des conséquences locales, tandis que le fournisseur du modèle peut être mieux placé pour déterminer si un comportement similaire pourrait apparaître dans plusieurs applications. Une gestion efficace des incidents dépend donc de canaux contractuels et opérationnels permettant le partage d’informations.

La base de données de l’UE fait partie de l’environnement émergent de signalement

Des documents du Conseil datant de 2026 indiquaient que la base de données de l’UE sur les systèmes d’IA à haut risque devait être mise en place au deuxième trimestre 2026, parallèlement à d’autres lignes directrices relatives à la mise en œuvre du règlement sur l’IA. Ce calendrier montre que l’infrastructure nécessaire à l’enregistrement et à la surveillance est en cours d’opérationnalisation et ne reste pas un simple projet politique théorique.

Une base de données ne résout pas automatiquement le problème de la qualité. Son utilité dépend de l’exactitude des entrées, de la cohérence des classifications, de la rapidité des mises à jour et de la clarté des règles d’accès. Elle peut toutefois fournir une structure commune permettant de relier plus facilement les systèmes réglementés, les acteurs responsables, les contextes de déploiement et les informations relatives aux incidents.

Les travaux de l’OCDE montrent pourquoi l’interopérabilité mondiale est importante

Les systèmes et les chaînes d’approvisionnement en IA franchissent les frontières, mais les règles de signalement des incidents sont généralement mises en œuvre dans des juridictions particulières. Sans concepts compatibles, le même événement pourrait être classé différemment selon les pays, ce qui compliquerait l’apprentissage international.

OECD.AI affirme que le signalement et le suivi des incidents doivent être cohérents et interopérables à l’échelle mondiale. L’interopérabilité n’exige pas nécessairement que chaque pays adopte des lois identiques. Elle requiert toutefois un alignement suffisant des définitions et des structures de données pour que les autorités et les opérateurs puissent comprendre et comparer les rapports.

Les incidents et les dangers ne doivent pas être confondus

Le cadre de l’OCDE distingue un incident lié à l’IA d’un danger lié à l’IA. Un incident est un événement dans lequel le développement ou l’utilisation d’un système d’IA entraîne un préjudice réel. Un danger est un événement potentiellement préjudiciable.

Cette distinction favorise une analyse plus claire :

• Le signalement des incidents consigne les conséquences préjudiciables réelles et les circonstances qui les ont produites.
• Le signalement des dangers peut révéler des signes avant-coureurs, des quasi-accidents ou des conditions susceptibles de produire un préjudice, même lorsqu’aucun préjudice réel ne s’est encore produit.
• L’analyse combinée peut relier les signaux préventifs aux conséquences ultérieures et aider les organisations à hiérarchiser les contrôles.

Les obligations réglementaires prévues par le règlement européen sur l’IA portent sur les incidents graves répondant aux critères juridiques. Un programme interne de sûreté peut adopter un champ d’application plus large en assurant également le suivi des dangers et des événements de moindre gravité. Cette vision interne élargie peut aider à repérer les faiblesses récurrentes avant qu’elles ne produisent une conséquence soumise à l’obligation de signalement.

Le suivi en temps quasi réel accroît la visibilité, sans assurer une vérification complète

L’outil de suivi des incidents et des dangers liés à l’IA de l’OCDE a été lancé en 2023. Selon l’OCDE, il suit en temps réel les incidents réels liés à l’IA tels qu’ils sont relatés dans la presse et utilise un cadre de signalement pour structurer les données.

Cette approche offre une visibilité rapide sur les événements qui apparaissent dans différents lieux et secteurs. Elle peut aider les chercheurs et les responsables politiques à repérer les sujets qui méritent une enquête plus approfondie. Elle ne doit toutefois pas être considérée comme un registre complet de tous les incidents liés à l’IA ni comme une preuve définitive de chaque lien de causalité signalé.

Un document de la Commission européenne datant de 2026 explicite cette limite dans son analyse des bases de données d’incidents. Il indique que les bases de données examinées ne contiennent pas d’informations complètes et vérifiées sur l’ensemble des incidents liés à l’IA. Il précise également que certaines bases de données sont alimentées par l’IA et recueillent des incidents à partir de sources publiques, principalement des articles de presse.

Ces éléments justifient une interprétation prudente. Les bases de données issues des médias constituent des outils de découverte utiles, mais elles peuvent refléter une couverture inégale, des détails techniques incomplets et des allégations non résolues. Les systèmes officiels de signalement peuvent améliorer l’accès à des éléments structurés, tandis que les outils publics de suivi peuvent faire apparaître des cas qui resteraient autrement en dehors des canaux officiels. Les deux approches sont complémentaires plutôt qu’interchangeables.

Ce qu’un rapport public fiable sur un incident lié à l’IA doit communiquer

Un rapport public doit aider les lecteurs à comprendre l’événement sans exagérer l’étendue des connaissances de l’organisation. Il doit être rédigé à l’intention des personnes touchées et des observateurs informés, et non uniquement des spécialistes qui comprennent déjà l’architecture du système.

Une divulgation publique solide peut répondre à plusieurs questions essentielles :

1. Quel système était concerné ? Identifier sa fonction et le contexte de déploiement pertinent dans un langage clair.
2. Que s’est-il passé ? Décrire l’événement et la nature du préjudice réel ou soupçonné sans le minimiser.
3. Quand l’organisation a-t-elle été informée ? Fournir une chronologie pertinente lorsque sa divulgation est appropriée.
4. Qui peut être touché ? Expliquer quel groupe ou service est concerné sans exposer de données à caractère personnel.
5. Que sait-on du lien de causalité ? Distinguer les conclusions confirmées des liens soupçonnés ou non résolus.
6. Quelles mesures immédiates ont été prises ? Indiquer, le cas échéant, si l’utilisation a été restreinte, si la surveillance a été renforcée ou si une autre mesure d’endiguement a été mise en place.
7. Quelles mesures correctives sont envisagées ou mises en œuvre ? Distinguer les mesures proposées des modifications achevées et testées.
8. Le rapport sera-t-il mis à jour ? Expliquer comment les nouvelles conclusions importantes seront communiquées.

La fiabilité dépend de la précision. Un rapport ne doit pas laisser entendre qu’une notification réglementaire prouve que le système d’IA a causé le préjudice ; la notification peut intervenir alors que le lien de causalité n’est encore que soupçonné. Il doit également éviter de suggérer qu’un incident était sans conséquence au seul motif que l’enquête est toujours en cours.

La transparence a besoin de limites

La publication doit tenir compte de la protection de la vie privée, de la sécurité, des procédures judiciaires et des exigences légitimes de confidentialité. Les dossiers personnels, les détails de sécurité susceptibles d’être exploités et les informations pouvant compromettre une enquête peuvent devoir être occultés ou résumés.

Ces limites doivent être appliquées de manière restrictive et expliquées lorsque cela est possible. Une confidentialité excessive peut empêcher l’apprentissage externe et affaiblir la confiance, tandis qu’une divulgation sans discernement peut créer de nouveaux préjudices. Un modèle à plusieurs niveaux peut prévoir un signalement détaillé aux autorités, un dossier à accès contrôlé pour les partenaires concernés et un résumé public destiné à assurer la transparence.

Les corrections font partie d’un signalement crédible

Les premiers rapports d’incidents contiendront parfois des informations provisoires. Les organisations doivent effectuer les corrections de manière visible plutôt que de modifier discrètement le dossier. Chaque mise à jour doit indiquer ce qui a changé, si l’évaluation du préjudice ou du lien de causalité a évolué et quels nouveaux éléments ont motivé cette modification.

Cette approche reflète la manière dont les enquêtes sérieuses se déroulent réellement. L’exactitude n’exige pas de prétendre tout savoir immédiatement. Elle exige de reconnaître honnêtement les incertitudes, de préserver l’historique de l’évaluation et de corriger les erreurs lorsque de meilleurs éléments deviennent disponibles.

Ce que les fournisseurs, les déployeurs et les responsables politiques doivent faire dès maintenant

Les fournisseurs de systèmes à haut risque doivent faire correspondre leurs obligations de signalement à des déclencheurs opérationnels réels. Ils doivent savoir quelles équipes reçoivent les signaux d’incident, qui évalue l’existence d’un lien de causalité soupçonné, qui surveille le délai applicable et qui communique avec les autorités compétentes. Les fournisseurs de modèles d’IA à usage général présentant un risque systémique doivent également être prêts à documenter les incidents et les éventuelles mesures correctives en vue de leur signalement au Bureau de l’IA et, le cas échéant, aux autorités nationales compétentes.

Les déployeurs ne doivent pas supposer que la réponse aux incidents relève uniquement du fournisseur. L’environnement de déploiement peut déterminer la manière dont le résultat d’un système d’IA affecte une personne, un service ou une infrastructure. Les autorités publiques qui utilisent des systèmes à haut risque ont des responsabilités explicites en matière d’enregistrement et de notification, notamment celle d’informer immédiatement les acteurs concernés de la chaîne d’approvisionnement et les autorités de surveillance du marché lorsqu’elles détectent un incident grave.

Les responsables politiques et les exploitants de bases de données doivent donner la priorité à des définitions compatibles, à des champs structurés, à la traçabilité de l’origine des informations, à des mécanismes de correction et à des règles d’accès claires. Les données publiques doivent préciser si une entrée provient d’un dossier officiel, d’une divulgation par un fournisseur, d’un déployeur, d’un article de presse ou d’une autre source. Ce contexte permet aux utilisateurs d’évaluer le niveau de vérification plutôt que de considérer chaque entrée comme étant établie au même degré.

Les organisations peuvent se préparer en testant leur processus de signalement au moyen d’exercices fondés sur différents scénarios de préjudice. L’exercice doit vérifier si un signal parvient à la bonne équipe, si les éléments pertinents peuvent être conservés, si les décideurs comprennent la définition juridique et si une notification initiale peut être préparée dans un délai très court. Il doit également tester le passage du signalement confidentiel à une communication publique responsable.

Le mouvement en faveur des rapports publics d’incidents liés à l’IA concerne en définitive l’apprentissage institutionnel. Le règlement européen sur l’IA impose des obligations contraignantes pour les incidents graves, les modèles de la Commission normalisent les informations reçues par les autorités, et l’OCDE développe des concepts et des outils de suivi favorisant une compréhension internationale. Chaque élément traite une partie différente du problème : l’obligation, la structure, la visibilité et l’apprentissage transfrontalier.

Le succès ne doit pas être mesuré à la seule publication. Un système crédible doit produire des rapports dans les délais, préserver les incertitudes, protéger les informations sensibles, permettre les corrections et relier la divulgation aux mesures correctives. Lorsque ces garanties sont présentes, le signalement des incidents peut faire davantage que documenter une défaillance après coup : il peut aider les régulateurs, les fournisseurs, les déployeurs et le public à réduire le risque que le même préjudice se reproduise.