Post-Deployment Accountability in AI Governance: A Cross-Regulatory Empirical Analysis of AI Incidents

Imaginez le monde de l'intelligence artificielle (IA) comme une ville immense et bouillonnante où des robots sont embauchés pour tout faire, du diagnostic de maladies à l'approbation de prêts. Pendant longtemps, la grande inquiétude concernait simplement la manière dont ces robots étaient construits — s'assurer qu'ils étaient intelligents, équitables et qu'ils n'avaient pas de mauvais codes dans leur cerveau. Mais récemment, des scientifiques et des juristes ont réalisé que construire un robot n'est que la moitié de l'histoire. Le véritable défi est ce qui se passe après que le robot a commencé à travailler. Ce domaine est appelé la « gouvernance post-déploiement ». Pensez-y comme à la différence entre construire une voiture et la conduire réellement sur la route. Vous pouvez construire une voiture parfaite en usine, mais si vous n'avez pas de mécanicien pour vérifier les freins chaque jour, un compteur qui fonctionne réellement et un plan clair sur ce qu'il faut faire si le moteur prend feu, la voiture est un danger pour tout le monde.

Ce document plonge dans cette phase « après l'usine ». Il examine trois grands ensembles de règles que les gouvernements et les organisations ont créés pour garder l'IA en sécurité : l'IA Act de l'UE (un ensemble strict de lois européennes), le cadre de gestion des risques de l'IA du NIST (un guide volontaire des États-Unis) et le RGPD (un manuel pour la protection des données personnelles). La grande question n'est pas seulement « Ces règles existent-elles ? » mais « Fonctionnent-elles réellement quand les choses tournent mal ? » Les auteurs voulaient voir si, lorsqu'un système d'IA commet une erreur, les responsables surveillent réellement, signalent le problème et le corrigent, ou s'ils espèrent simplement que personne ne remarquera rien.

---

Le grand test de réalité de l'IA

Imaginez que vous êtes un détective enquêtant sur une ville où 480 robots différents ont causé des accidents entre 2020 et 2026. Certains robots ont donné de mauvais conseils médicaux, certains ont rejeté des demandes de prêt injustement, et certains ont causé des embouteillages. Votre travail est de vérifier les rapports de police et de voir si les propriétaires de robots ont suivi les manuels de règles qu'ils étaient censés posséder.

Les auteurs de ce document ont fait exactement cela. Ils ont examiné 480 catastrophes réelles de l'IA et les ont comparées à neuf règles spécifiques issues des trois grands manuels mentionnés ci-dessus. Ils cherchaient des « preuves » — comme un journal de bord montrant que quelqu'un surveillait le robot, un rapport déposé lorsque le robot est tombé en panne, ou un plan pour l'arrêter.

La grande surprise : Les règles « fantômes »
Les résultats ont été un peu effrayants. Il s'avère que pour la plupart de ces accidents, les règles de sécurité étaient essentiellement des fantômes. Elles existaient sur le papier, mais vous ne pouviez trouver aucune trace d'elles dans le monde réel.

• L'IA Act de l'UE : Ce manuel de règles stipule que les robots à haut risque ont besoin d'un « suivi post-commercialisation » — en gros, une caméra de sécurité qui surveille le robot 24h/24 et 7j/7 après son lancement. L'étude a révélé que dans 77,1 % des accidents, il n'y avait absolument aucune preuve que quelqu'un surveillait. C'était comme conduire une voiture sans freins et sans personne pour vérifier le tableau de bord.
• Le RGPD (Protection des données) : Cette règle stipule que si vous utilisez des données personnelles de manière risquée, vous devez effectuer une « analyse d'impact relative à la protection des données » (une vérification de sécurité avant de commencer). L'étude a révélé que 99,6 % des incidents n'avaient aucun enregistrement de cette vérification de sécurité.
• Le cadre du NIST : Ce guide suggère que vous devriez avoir un plan pour réparer les choses lorsqu'elles tournent mal. Bien que certaines entreprises aient fini par arrêter les robots défectueux (environ 57,5 % du temps), elles ne l'ont fait qu' après que les dégâts furent faits et que la nouvelle était déjà à la télévision. Elles ne réparaient pas de manière proactive ; elles nettoyaient simplement le désordre.

Le bug « systémique »
Les auteurs ont également vérifié si ces échecs étaient des erreurs aléatoires ou si tout le système était défaillant. Ils ont découvert que 9,8 % des accidents étaient des échecs sous deux manuels de règles ou plus en même temps. Cela suggère que le problème n'est pas seulement qu'un manuel est mauvais, mais que la façon dont nous gérons l'ensemble de la sécurité de l'IA manque de quelques rouages essentiels. C'est comme une voiture qui n'a ni freins, ni volant, ni ceintures de sécurité, tout cela en même temps.

L'arme secrète : Le « Détective Interne »
Voici la partie la plus intéressante de l'histoire. Les chercheurs ont remarqué une énorme différence entre les accidents découverts par l'équipe de l'entreprise elle-même et les accidents découverts par le monde extérieur (comme les journalistes, les utilisateurs mécontents ou les chercheurs).

• Détection interne : Lorsque l'entreprise trouvait le problème elle-même, elle était beaucoup plus susceptible d'avoir suivi les règles. Pour l'IA Act de l'UE, 87,5 % de ces accidents trouvés par l'entreprise montraient une conformité.
• Détection externe : Lorsque le monde extérieur trouvait le problème, le taux de conformité chutait à un infime 5,3 %.

Cela suggère que les entreprises qui possèdent réellement un « détective » dans leurs bureaux, surveillant le robot chaque jour, sont celles qui détectent les problèmes tôt et suivent les règles. Les entreprises qui attendent que la nouvelle éclate avant de savoir qu'il y a un problème sont celles qui échouent aux tests de sécurité. Les auteurs suggèrent que posséder un système de surveillance interne est un indice majeur qu'une entreprise fait du bon travail, bien qu'ils admettent qu'ils ne peuvent pas prouver que cela provoque le bon comportement (peut-être que les bonnes entreprises ont simplement tendance à avoir les deux).

La solution proposée : Le PAGCF
Puisque le système actuel est principalement réactif (réparer après la casse), les auteurs proposent un nouveau plan appelé le Cadre de Conformité de Gouvernance de l'IA Proactive (PAGCF). Imaginez cela comme un nouveau manuel d'instruction pour les conducteurs de robots. Au lieu de simplement réagir aux accidents, ce plan comporte quatre étapes :

1. Évaluation pré-déploiement : Avant même que le robot ne commence, vérifiez son équipement de sécurité et établissez un plan.
2. Surveillance continue : Gardez une caméra en direct sur le robot 24h/24 et 7j/7 pour détecter les problèmes avant qu'ils ne deviennent des accidents.
3. Préparation aux incidents : Ayez un « exercice incendie » prêt. Sachez exactement qui appeler et quoi dire si le robot bugue.
4. Vérification inter-cadres : Assurez-vous de suivre tous les manuels de règles à la fois, et pas seulement un.

Ce que cela signifie pour nous
L'article conclut que nous ne pouvons pas nous contenter d'écrire plus de règles en espérant qu'elles fonctionnent. Les règles sont déjà là, mais personne ne les utilise. La plus grande leçon est que nous devons cesser d'attendre que les informations nous disent qu'une IA est cassée. Nous devons construire des systèmes qui surveillent l'IA pendant qu'elle travaille. Les auteurs suggèrent que si les entreprises commencent à pratiquer cette « surveillance interne » en premier, elles pourraient passer d'une conformité quasi nulle à plus de 85 % de conformité.

Ce n'est pas une baguette magique, et les auteurs précisent bien qu'ils se basent sur ce qu'ils ont vu dans les données, et non sur une solution garantie. Mais le message est clair : si nous voulons que l'IA soit sûre, nous devons cesser d'être les personnes qui nettoient le désordre et commencer à être les personnes qui préviennent le désordre dès le départ.