Les manuels de sécurité à l’ancienne ne peuvent pas gérer les problèmes d’IA. Les entreprises ont donc besoin d’une nouvelle approche pour détecter les erreurs de modèle et les risques juridiques avant qu’ils ne se retournent contre eux.
Soixante et onze pour cent des organisations déclarent que l’IA a accès aux principaux systèmes de l’entreprise. Seuls 16 % régissent efficacement cet accès, selon le rapport 2026 sur les risques liés à l’IA des RSSI. Posez trois questions à votre équipe IR : Où se trouve l’inventaire de votre système d’IA ? Que se passe-t-il si un modèle de production commence à générer des résultats nuisibles ? Qui a le pouvoir de le mettre hors ligne ?
J’ai passé 14 ans dans la sécurité – énergie, banque, télécommunications, industrie manufacturière. Le travail de l’équipe rouge, les programmes de détection et les dernières années se sont concentrés sur les risques liés à l’IA et à ShadowAI. Ce que je vois régulièrement : les organisations ont l’IA en production, elles ont un manuel de RI et elles pensent que ces deux choses sont liées. Ce n’est pas le cas.
Le RSSI qui pense que son manuel de RI couvre les incidents liés à l’IA ne l’a probablement pas testé. Ceux qui l’ont testé savent que ce n’est pas le cas.
Deux types d’incidents liés à l’IA – et pourquoi cette répartition est plus importante que la liste
Les incidents liés à l’IA ont augmenté de 56,4 % entre 2023 et 2024, atteignant 233 cas documentés. La plupart des cadres IR, notamment NIST SP 800-61, MITRE ATLAS et GLACIS AI Incident Response Playbook, vous fournissent une taxonomie de six types d’incidents et s’arrêtent là. Bien qu’utile, il passe à côté de la division la plus importante : les échecs provoqués par le modèle par lui-même et les échecs provoqués par un humain. Votre approche de détection, votre logique de confinement et votre exposition juridique sont très différentes entre ces deux groupes.
Les défaillances provoquées par le modèle (dégradation, biais, hallucinations) se produisent lorsque le système fait exactement ce pour quoi il a été conçu, mais mal. Le modèle Epic Sepsis, déployé dans des centaines d’hôpitaux américains, avait une sensibilité de seulement 33 % lors de la validation externe. Il a manqué les deux tiers des cas réels de sepsis et a inondé les médecins de fausses alertes, comme l’a révélé une étude de médecine interne du JAMA de 2021. Personne ne l’a attaqué. Il a simplement cessé de fonctionner tandis que chaque tableau de bord restait vert.
Des défaillances d’origine externe (attaques contradictoires, empoisonnement des données, violations de la vie privée) se produisent lorsque quelqu’un corrompt les entrées ou l’environnement de formation. Les cas de freinage fantôme du pilote automatique de Tesla, étudiés par la NHTSA sur des centaines de milliers de véhicules, montrent à quoi ressemblent les défaillances d’entrée contradictoires dans un système critique pour la sécurité. Ces deux groupes ont besoin de défenses primaires différentes et de leurs propres playbooks.
Il y a ensuite le cas hybride, qui est actuellement le plus exposé juridiquement. Les hallucinations proviennent de modèles, mais elles atterrissent devant les tribunaux comme des erreurs humaines. Lorsque le chatbot d’Air Canada a inventé une politique tarifaire en cas de deuil, la compagnie aérienne a été tenue responsable. Lorsqu’un tribunal fédéral américain a autorisé l’affaire Mobley contre Workday, il a accepté qu’une plateforme de recrutement d’IA puisse être directement responsable en tant qu’« agent » des employeurs qui l’utilisent. Aucun des deux échecs ne ressemblait à un incident de sécurité. Les deux ont fini par être légaux. Si votre équipe juridique ne figure pas dans votre arbre d’appels IR, votre playbook est déjà incomplet.
La triade de la CIA ne couvre pas une hallucination
La triade de la CIA – confidentialité, intégrité, disponibilité – ne s’applique pas à la plupart des incidents d’IA. Lorsque le chatbot d’Air Canada a élaboré une politique, rien n’était indisponible, rien n’a été modifié sans autorisation, rien n’a été divulgué. Le cadre n’y parvient tout simplement pas. Lorsque le modèle Epic Sepsis a manqué les deux tiers des cas, il n’y a eu aucune violation, aucune intrusion, aucun indicateur de compromission. Selon toutes les mesures IR traditionnelles, le système semblait correct.
Il ne s’agit pas d’un cas limite. Les cadres RI classiques supposent des échecs déterministes avec des indicateurs statiques de compromission – une hypothèse qui ne s’applique pas aux systèmes probabilistes. Le blog de sécurité de Microsoft l’a bien dit en avril 2026 : un modèle peut produire une sortie nuisible aujourd’hui et quelque chose de complètement différent de la même invite demain. La cause première n’est pas une ligne de code. Il s’agit d’une distribution de probabilité et, comme le dit le blog de sécurité de Microsoft, vous ne pouvez pas corriger une distribution de probabilité.
Les chiffres confirment l’écart. Le temps moyen de détection des incidents d’IA est de 4,5 jours. Soixante-sept pour cent des incidents d’IA proviennent d’erreurs de modèle et non d’attaques contradictoires. Pourtant, les budgets de sécurité continuent de financer les outils de périmètre conçus pour ces dernières. Nous recherchons les mauvais signaux, avec les mauvais outils, les mauvais modes de défaillance.
À quoi ressemble une capacité IA IR mature
On me pose cette question à chaque conférence à laquelle je prends la parole. Voici la réponse courte : trois éléments que les équipes matures ont mis en place avant qu’un incident ne se produise.
Premièrement, une nomenclature IA (AIBOM) pour chaque système de production. Considérez-le comme un SBOM logiciel, mais pour l’IA : il documente le modèle de base, les ensembles de données de formation, les dépendances tierces et la pile complète de composants. Sans cette base de référence, vous ne savez pas de quoi est faite votre IA et vous ne pouvez pas enquêter sur un incident d’empoisonnement de données ou sur une compromission de la chaîne d’approvisionnement. Le projet de sécurité OWASP GenAI a publié un générateur AIBOM open source en décembre 2025 qui produit une sortie au format CycloneDX aligné sur les normes SPDX. C’est pratique à mettre en œuvre maintenant.
Deuxièmement, une carte modèle pour chaque système d’IA de production – pas un document dans un lecteur partagé que personne n’ouvre, mais quelque chose que votre équipe IR peut extraire dans les dix premières minutes d’une réponse. Provenance des données de formation. Version modèle. Limites de performances connues, y compris les sous-populations qui ont montré une précision plus faible lors des tests. Contrôles d’accès. Rayon d’explosion en cas d’échec. La plupart des organisations avec lesquelles je travaille disposent d’une documentation modèle écrite pour les data scientists que personne en sécurité ne peut utiliser à 2 heures du matin. Ce n’est pas de la documentation. C’est la responsabilité.
Troisièmement, un data scientist nommé sur l’arbre d’appels IR. Pas quelqu’un à informer après l’incident – quelqu’un ayant le pouvoir d’interroger le comportement du modèle en temps réel. L’IR traditionnel dispose d’un ingénieur réseau de garde. AI IR a besoin de la même logique appliquée aux personnes qui comprennent le fonctionnement du système défaillant.
Une quatrième chose dont très peu d’équipes disposent : un seuil de restauration documenté pour chaque modèle déployé. Une définition convenue à l’avance du taux d’anomalies, de la mesure de dérive ou de l’écart d’équité qui déclenche le confinement ou un commutateur de repli. Les équipes sans cela passent les premières heures d’un incident d’IA à se demander si ce qu’elles voient constitue réellement un problème. Les équipes avec un seuil passent ces heures à répondre.
Quatre choses à faire avant le prochain incident
Réécrivez vos déclencheurs de détection. La notation des anomalies de sortie, la surveillance de la distribution des données pour la dérive et le suivi comportemental de l’utilisation de l’API du modèle doivent figurer dans votre couche de détection. Ils ne proviendront pas de votre SIEM. Il s’agit d’un travail d’instrumentation au niveau du système d’IA.
Redéfinir le confinement. Pour la plupart des incidents liés à l’IA, « isoler le système » n’est pas la bonne première décision. Passer à une solution de secours basée sur des règles tout en maintenant le service en fonctionnement peut causer moins de dommages que de mettre le système hors ligne et de déclencher une escalade commerciale. Chaque modèle déployé nécessite des critères de restauration prédéfinis et une solution de secours nommée. Notez-les maintenant.
Soyez légal dans la pièce avant l’incident. Mobley contre Workday signifie que le fournisseur d’IA et l’organisation qui le déploie peuvent être tenus responsables des incidents de partialité. Air Canada signifie que vous ne pouvez pas nier ce que votre IA dit à un client. Si votre équipe juridique prend connaissance d’un incident lié à l’IA grâce à une enquête de presse, quelque chose s’est déjà mal passé.
Construisez votre inventaire d’IA et traitez-le comme votre registre d’actifs. Commencez par l’AIBOM pour vos systèmes les plus à risque, ceux qui ont accès aux données clients, aux décisions financières ou aux flux de travail cliniques. Le cadre GenAI-IRF vous offre une taxonomie structurée pour ce travail et le GLACIS AI Incident Response Playbook le mappe aux procédures NIST SP 800-61 et MITRE ATLAS que votre équipe peut adapter sans repartir de zéro.
Quarante-deux pour cent des organisations ont déjà eu un incident d’IA suspect ou confirmé, et plus de la moitié déclarent que leur posture de sécurité est en retard, incohérente ou réactive. La mise à jour de votre playbook n’est pas facultative. Réparez-le avant d’en avoir besoin.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
