Réponse aux incidents d'IA : bâtir un plan d'action avant que tout dérape

Un incident d'IA est tout événement où un système d'IA se comporte d'une façon qui cause ou risque de causer un préjudice — résultats biaisés, fuite de données, attaque par injection d'invite, dérive de l'exactitude — et pas seulement une atteinte classique aux données. Un plan d'action rédigé au calme précise ce qui compte, qui fait quoi, comment contenir, quand aviser les organismes de réglementation et comment réviser ensuite. Bâtissez-le avant d'en avoir besoin, car vous en aurez besoin.

Pourquoi l'IA a-t-elle besoin de son propre plan d'action ?

La plupart des organisations ont déjà une forme de plan de réponse aux incidents, et il est d'ordinaire construit autour d'une atteinte à la protection des données : quelqu'un lit des dossiers auxquels il ne devrait pas, un portable disparaît, une base de données se retrouve exposée. Ces plans sont nécessaires, mais incomplets, car les systèmes d'IA défaillent de manières qu'un plan d'atteinte classique n'a jamais vues venir. Un incident d'IA ne concerne pas toujours des données qui filent par la porte. Parfois, c'est le système qui prend discrètement des décisions biaisées pendant des semaines. Parfois, il affirme avec assurance une fausseté aux clients. Parfois, c'est une attaque par injection d'invite qui transforme votre assistant serviable en source de fuite.

Le pire moment possible pour déterminer qui commande et quoi faire, c'est pendant que l'incident se déroule. Un plan d'action rédigé au calme transforme la panique de 2 h du matin en liste de vérification. Et avec l'IA désormais cousue dans l'embauche, le service et les opérations, la question n'est plus de savoir si vous aurez un incident d'IA. C'est de savoir si vous serez prêt le moment venu.

Ce qui constitue un incident d'IA

Étirez votre définition au-delà de « des données personnelles ont été exposées ». Un incident d'IA est tout événement où un système d'IA se comporte d'une façon qui cause, ou risque de causer, un préjudice. En pratique, ils se regroupent en une poignée de types :

• Résultats nuisibles ou biaisés. Le système produit des résultats discriminatoires, diffamatoires ou dangereusement erronés — un outil de présélection qui déclasse systématiquement un groupe protégé, un agent conversationnel qui donne des conseils dangereux.
• Fuite de données. Le système expose des renseignements personnels ou confidentiels — en restituant des données d'entraînement, ou un outil mal configuré qui renvoie les données d'un utilisateur à un autre.
• Manipulation et attaques de sécurité. Injection d'invite, contournements, ou entrées empoisonnées qui détournent le comportement du système.
• Perte de contrôle ou dérive de l'exactitude. La performance du modèle se dégrade avec le temps, ou il se met à fonctionner hors de sa portée prévue sans que personne ne le remarque.
• Défaillances de tiers. Un fournisseur d'IA dont vous dépendez subit une panne, une atteinte, ou déploie une modification de modèle qui casse votre processus.

Consigner ces catégories à l'avance importe, car la première difficulté de tout incident réel, c'est simplement de reconnaître qu'il en survient un. Une équipe qui n'a jamais nommé « résultat biaisé » comme type d'incident le classera comme un bogue de produit et l'éloignera discrètement des personnes qui devraient jauger l'exposition juridique.

Rôles : décidez qui fait quoi dès maintenant

Un incident est le mauvais moment pour se mettre à débattre de qui en est responsable. Attribuez ces rôles à l'avance, et assurez-vous que chaque personne sait vraiment qu'elle en est titulaire :

• Responsable de l'incident — coordonne la réponse et a le pouvoir de décider, y compris de mettre le système hors ligne.
• Responsable technique — la personne ou l'équipe capable d'enquêter réellement et de contenir le système d'IA.
• Vie privée ou service juridique — évalue les obligations de notification et le risque juridique.
• Communications — gère ce qui est dit aux clients, au personnel et, au besoin, au public.
• Parrain de direction — le cadre supérieur responsable, tenu informé, qui tranche les grandes décisions.

Dans une petite entreprise, une même personne peut porter plusieurs de ces chapeaux, et c'est bien — ce qui compte, c'est que les chapeaux soient attribués, pas que cinq personnes distinctes soient dans la pièce. Tenez une liste de contacts courte et à jour, et assurez-vous que quelqu'un est vraiment joignable en dehors des heures d'ouverture, car les incidents ont rarement la courtoisie de survenir un mardi à 10 h.

Confinement : arrêter l'hémorragie d'abord

L'envie de courir tout de suite après la cause profonde est compréhensible, mais la première tâche est de limiter le préjudice. Le confinement en matière d'IA vous donne souvent des options qu'un plan d'atteinte classique n'a pas :

• Suspendez le système. Prévoyez un moyen convenu d'avance de mettre l'IA hors ligne ou de basculer vers une solution de repli sûre (un processus humain, un système plus simple fondé sur des règles). Savoir que le coupe-circuit existe — et l'avoir testé — représente la moitié de la bataille.
• Préservez les preuves. Capturez les journaux, les entrées et sorties fautives, ainsi que la configuration et la version du système avant toute modification. Vous en aurez besoin pour l'évaluation et le correctif.
• Limitez le rayon d'impact. Révoquez une clé divulguée, restreignez l'accès, ou revenez à une version antérieure d'un modèle défectueux pour empêcher l'incident de se propager pendant l'enquête.

Les organisations qui se relèvent le plus vite sont celles qui ont décidé, à l'avance, ce que « suspendre ce système » signifie concrètement pour chaque outil d'IA qu'elles exploitent — et qui ont vérifié que ça fonctionne.

Notification : connaissez vos déclencheurs

C'est ici que les incidents d'IA butent contre des délais juridiques stricts, et où un plan d'action fait ses preuves. Les déclencheurs que vous êtes le plus susceptible de croiser au Canada :

En vertu de la LPRPDE, une atteinte aux mesures de sécurité mettant en cause des renseignements personnels doit être déclarée au Commissariat à la protection de la vie privée du Canada, et les personnes concernées avisées, lorsqu'elle crée un *risque réel de préjudice grave* — et vous devez tenir un registre de toutes ces atteintes, même celles sous le seuil de déclaration. Déclarez dès que possible une fois que vous avez établi que l'atteinte est survenue.

En vertu de la Loi 25 du Québec, un incident de confidentialité présentant un *risque de préjudice sérieux* exige d'aviser la Commission d'accès à l'information et les personnes concernées, et un registre de tous les incidents doit être tenu dans tous les cas. Ce registre est précisément ce qu'un journal des incidents est conçu pour contenir.

Une bonne part des incidents d'IA seront aussi des incidents de confidentialité, et ces obligations retombent en plein. Au-delà de la vie privée, gardez l'œil sur l'orientation propre à l'IA qui prend forme : le EU AI Act — le Règlement (UE) 2024/1689 — instaure des obligations de signalement des incidents graves pour certains systèmes à haut risque, et le projet de Loi sur l'intelligence artificielle et les données du projet de loi C-27 pointe vers des devoirs semblables pour les systèmes à incidence élevée. Les règles sectorielles en finance et en santé peuvent en rajouter avec leurs propres attentes de signalement. Votre plan d'action devrait énumérer chaque déclencheur susceptible de vous viser, avec qui l'évalue et le compte à rebours qui s'enclenche — pour que la décision soit une consultation, et non un débat au pire moment possible.

La revue post-incident : là où réside la valeur

La réponse n'est pas terminée lorsque le système revient en ligne. La partie la plus précieuse vient après : une revue sans blâme qui demande ce qui s'est passé, pourquoi, si la réponse a vraiment fonctionné et ce qui empêcherait que ça se reproduise. « Sans blâme » est le mot clé — si les gens s'attendent à une punition, ils enterreront les quasi-incidents qui sont votre meilleure alerte précoce. Réinjectez les constats dans la fiche de modèle, la surveillance, le ROPA et le plan d'action lui-même. Un incident dont vous n'apprenez rien est un pur coût; un incident que vous disséquez est le conseil en sécurité le moins cher que vous obtiendrez jamais.

Le présent article constitue de l'information générale et non un avis juridique; vos obligations précises de notification dépendent de l'incident, des données et des lois qui s'appliquent à vous, et méritent d'être confirmées auprès d'un professionnel.

Canuckt a conçu Valdra pour réunir au même endroit les éléments qu'exige un incident d'IA — votre inventaire des systèmes d'IA, les déclencheurs de notification, le registre des incidents et la trace des revues — afin que lorsqu'un problème dérape, la réponse soit un plan que vous avez répété plutôt qu'une page que vous rédigez sous pression.