Projet d’alliance pour l’intelligence artificielle élabore des règles de signalement d’incidents confidentiels avec des délais publics

La Linux Foundation a publié le 4 août 2026 une demande de commentaires pour le Shared AI Findings Exchange (SAFE), un projet de cadre qui obligerait les membres de l’Open Secure AI Alliance à signaler les incidents de sécurité de l’IA dans des délais fixés — confidentiellement au début, puis publiquement dans les 30 jours. Des contributeurs de Cisco, CrowdStrike (CRWD ), Hugging Face, NVIDIA (NVDA ), Red Hat et d’autres membres de l’alliance ont élaboré la proposition initiale, qui coïncide avec l’ouverture de la conférence Black Hat à Las Vegas.

La proposition de projet SAFE décrit un système d’apprentissage d’incidents confidentiel : les membres signalent les incidents de sécurité de l’IA et les quasi-accidents, les organisations touchées sont informées, les défaillances de contrôle récurrentes sont identifiées et les résultats deviennent des recommandations d’exploitation fondées sur des preuves. L’alliance, lancée le 27 juillet 2026, compte désormais plus de 120 organisations membres, selon NVIDIA, avec Amazon (AMZN ) et Visa parmi les derniers à rejoindre.

Ce à quoi le projet engage réellement les membres

Le projet SAFE va plus loin à deux endroits spécifiques : un ensemble défini d’événements signalés et un calendrier de notification avec des dates attachées.

En vertu de l’accord de signalement du projet, un membre devrait signaler un incident lorsque son système d’IA accède ou perturbe un système tiers sans autorisation, s’échappe ou contourne une limite de sandbox, de réseau, d’identité, de politique ou d’outil de manière à affecter un tiers, accède à des informations confidentielles de tiers ou continue à sonder une cible de production après que l’opérateur suspecte que l’activité est hors de portée. Le projet ajoute que l’intention ne détermine pas si un événement est signalable — un opérateur qui croyait que l’environnement était simulé a toujours l’obligation de signaler.

L’échelon de notification est où vivent les délais : informer l’organisation directement touchée le plus tôt possible, les clients avec une exposition crédible dans les 72 heures, un rapport SAFE confidentiel initial dans les quatre jours ouvrables, un avis plus large aux clients dans les 14 jours si cela est justifié, un rapport préliminaire publié dans les 30 jours, le statut de remédiation publié dans les 90 jours et des mises à jour lisibles par machine hebdomadaires pendant que les risques importants restent non résolus. Les membres devraient également fournir une analyse préliminaire des défaillances de contrôle dans les 30 jours — et devraient signaler les quasi-accidents, et non seulement les dommages confirmés.

Chaque incident serait examiné à travers huit couches de la pile d’exploitation, du modèle et de ses instructions jusqu’aux sauvegardes, outils, environnement, surveillance, opérations humaines et chaîne d’approvisionnement. Une disposition à noter : l’organisation touchée peut corriger les erreurs factuelles, mais le projet indique qu’elle ne devrait pas avoir un pouvoir de veto sur les apprentissages ou les recommandations qui résultent d’un examen.

Adhésion volontaire, conditions contraignantes, pas de bras d’exécution

SAFE est structuré comme un accord volontaire — les devoirs de signalement lieraient les membres en tant que condition d’adhésion, et non comme loi. Le projet indique que l’apprentissage est distinct de l’exécution, que les régulateurs et les parties touchées conservent leurs droits légaux et que les délais ne remplacent pas les obligations de notification existantes en vertu de la divulgation coordonnée des vulnérabilités, des contrats ou des devoirs légaux envers les régulateurs et les forces de l’ordre. La conduite intentionnelle ou criminelle se situerait en dehors de la protection du canal confidentiel.

Le projet propose également que SAFE opère de manière indépendante, de sorte qu’aucun fournisseur ou segment d’industrie unique ne contrôle ses constatations, avec la participation de gouvernements et d’organisations de normalisation en tant qu’observateurs non contrôlants. Le cadre de la proposition est franc sur ce point : « La confiance n’est pas un contrôle de sécurité. Les preuves partagées et les améliorations vérifiables sont la manière dont la confiance est gagnée. » Que cette indépendance soit maintenue une fois que les incidents réels nomment des membres réels est la question à laquelle la période de commentaires existe pour répondre — mais le projet met au moins l’obligation par écrit avant que le premier test n’arrive.

L’incident qui a motivé l’affaire

L’alliance a été formée il y a huit jours, le 27 juillet 2026, en tant que coalition d’une trentaine d’entreprises et de fondations open source, en citant explicitement la divulgation de sécurité de Hugging Face du 16 juillet 2026 comme déclencheur. Hugging Face a signalé qu’un cadre d’agent autonome avait exécuté une intrusion dans son infrastructure de production de bout en bout et que, lorsque la société a tenté d’analyser plus de 17 000 actions enregistrées de l’attaquant, des modèles d’API commerciaux ont bloqué le travail de forensic — leurs garde-fous ne pouvaient pas distinguer un répondant d’incident d’un attaquant. L’équipe a terminé l’analyse sur le modèle GLM-5.2 open-weight exécuté sur son propre infrastructure. Unite.AI a couvert le lancement de l’alliance et le compte rendu de forensic de Hugging Face lorsqu’ils sont arrivés.

Le projet SAFE se lit comme la réponse de l’alliance à cet épisode : si un quasi-accident d’un membre avait été partagé sous ces règles, le calendrier de notification et l’analyse des défaillances de contrôle seraient déjà en cours.

Que se passe-t-il ensuite

La demande de commentaires est ouverte pour l’examen, la discussion et la contribution de la communauté via le référentiel RFC de l’alliance, publié sous licence Creative Commons Attribution 4.0, la Linux Foundation invitant les développeurs, les entreprises, les chercheurs et les organisations de normalisation à façonner le cadre avant qu’il ne se solidifie. Le projet est explicitement un document de démarrage — la Linux Foundation le décrit comme une discussion ouverte plutôt que comme une spécification terminée, de sorte que les devoirs de signalement et les délais ci-dessus restent des conditions proposées jusqu’à ce que le groupe de travail les adopte.