Avoir une feuille de calcul des risques liés à l’IA est une bonne chose, mais cela ne dira pas à votre équipe quoi faire ni qui peut appuyer sur le kill switch lorsqu’un modèle tombe en panne.
Imaginez le moment après qu’un problème d’IA soit signalé.
Un analyste de sécurité examine un ticket signalant qu’un outil d’IA interne a produit une mauvaise recommandation dans un flux de travail professionnel en direct. Le risque n’est plus théorique. Quelqu’un veut savoir s’il s’agit d’un incident de sécurité, d’un problème de modèle, d’un problème de confidentialité, d’un problème de fournisseur ou simplement de « quelque chose que l’IA a fait ». Le registre des risques comporte une ligne pour les résultats inexacts, et il peut même avoir un indice de gravité.
Ce qu’il n’apporte pas, c’est une réponse à la question que tout le monde se pose désormais : qui a le pouvoir d’arrêter cette chose ?
C’est l’écart que de nombreux programmes de gouvernance de l’IA doivent encore combler. Les organisations parviennent de mieux en mieux à identifier les risques liés à l’IA, à les documenter et à les attribuer à des catégories de gouvernance. Ce à quoi ils sont souvent moins préparés, c’est le moment opérationnel où un risque IA devient un événement réel qui doit être étudié, contenu et expliqué.
Dans les programmes de sécurité, cette distinction est importante. Un registre des risques peut documenter les préoccupations, mais il ne peut pas préserver les preuves, informer les dirigeants, évaluer l’impact ou décider si un système d’IA doit continuer à fonctionner. Les responsables de la sécurité n’ont pas besoin d’une autre feuille de calcul indiquant que l’IA peut échouer ; ils ont besoin d’un modèle de réponse exécutable pour ce qui se passe lorsque cela se produit.
La liste n’est pas la réponse
Les registres des risques sont utiles car ils créent de la visibilité. Ils aident les organisations à identifier les risques, à en comparer la gravité, à en attribuer la responsabilité et à communiquer leurs préoccupations aux dirigeants. Au début de l’adoption de l’IA, la visibilité est importante, car de nombreuses organisations découvrent encore où l’IA est utilisée, quelles données sont impliquées et quels processus métier peuvent être affectés.
Mais un registre des risques n’est pas un contrôle. Les équipes de sécurité le comprennent déjà dans d’autres domaines. Une liste de vulnérabilités n’est pas un programme de gestion des vulnérabilités, et une liste de risques tiers n’est pas une fonction de gestion des risques des fournisseurs. La liste n’est que le début du travail.
Le risque lié à l’IA crée le même problème. Une entrée de risque indiquant « les résultats du modèle peuvent être inexacts » ne définit pas qui surveille la qualité des résultats, quel niveau d’erreur est acceptable, quelles preuves doivent être préservées ou qui peut suspendre le système. Une entrée de risque indiquant « des données sensibles peuvent être exposées » n’explique pas si les invites sont enregistrées, si les résultats sont examinés, si le fournisseur peut utiliser les données soumises ou si l’événement doit déclencher une escalade de confidentialité, juridique ou de sécurité.
C’est là que la gouvernance de l’IA peut paraître plus solide qu’elle ne l’est en réalité. L’organisation peut avoir une politique, un comité, un formulaire d’admission et un registre des risques, mais ces artefacts ne créent pas automatiquement une préparation opérationnelle. Lorsque quelque chose se produit, le véritable test est de savoir si l’organisation sait quoi faire ensuite.
Les incidents d’IA ne ressemblent pas toujours à des violations
Une partie du défi réside dans le fait que les incidents liés à l’IA ne ressemblent pas toujours aux incidents de cybersécurité traditionnels. Une violation présente des schémas familiers : accès non autorisé, exfiltration de données, malware, compromission d’identifiants ou activité suspecte dans un système. Les échecs de l’IA peuvent être plus compliqués car ils peuvent apparaître d’abord comme une mauvaise recommandation, un résumé trompeur, une automatisation dangereuse, une classification erronée ou un résultat qui modifie discrètement une décision.
Cela ne les rend pas moins importants. Un outil d’IA utilisé dans un workflow de sécurité pourrait mal classer une alerte. Un assistant d’IA générative pourrait exposer des informations sensibles dans une réponse. Un modèle intégré dans un processus métier pourrait dériver au fil du temps et produire des recommandations peu fiables. Une fonctionnalité d’IA gérée par le fournisseur pourrait changer de comportement après une mise à jour que l’organisation n’a pas entièrement examinée.
Les équipes de sécurité ont besoin d’un moyen pratique pour trier ces événements. Toutes les erreurs d’IA ne doivent pas être traitées comme un incident de sécurité complet. Néanmoins, chaque organisation utilisant l’IA dans des flux de travail significatifs doit savoir comment les événements liés à l’IA sont signalés, triés et remontés. Sans cette structure, les équipes risquent de perdre du temps à débattre de la propriété alors que l’impact se poursuit.
La première étape consiste à définir ce qui constitue un incident d’IA. Cette définition doit être suffisamment large pour englober les préoccupations en matière de sécurité, de confidentialité, de sûreté, d’exploitation et de conformité, mais suffisamment précise pour que les employés sachent quand signaler quelque chose. Une réponse confuse d’un chatbot peut ne pas nécessiter la même réponse qu’un événement d’exposition de données, mais les deux doivent avoir un chemin d’examen.
Les preuves doivent exister avant l’enquête
La réponse aux incidents dépend des preuves. Cela est évident en matière de cybersécurité, mais est souvent négligé dans les discussions sur la gouvernance de l’IA. Si une organisation ne peut pas reconstituer ce qui s’est passé, qui a utilisé le système, quelles données ont été impliquées et quels résultats ont été produits, elle aura du mal à enquêter sur l’événement ou à défendre sa réponse.
Les systèmes d’IA peuvent compliquer cette piste de preuves. Les invites peuvent ne pas être enregistrées. Les résultats ne peuvent pas être conservés. Les outils des fournisseurs peuvent offrir une visibilité limitée. Les versions des modèles peuvent changer. Les utilisateurs peuvent copier le contenu généré par l’IA dans d’autres systèmes sans conserver sa source. Les équipes commerciales peuvent traiter les résultats de l’IA comme une recommandation plutôt que comme un événement système.
Les responsables de la sécurité devraient exiger des preuves avant que les systèmes d’IA ne passent en production. Au minimum, les organisations doivent savoir quels journaux sont disponibles, combien de temps ils sont conservés, qui peut y accéder et s’ils sont suffisants pour une enquête. Pour les cas d’utilisation à plus haut risque, les équipes peuvent également avoir besoin d’enregistrements de la version du modèle, de l’historique des invites, de l’historique des sorties, des actions des utilisateurs, des sources de données et des décisions en aval.
Cela ne signifie pas que chaque interaction avec l’IA nécessite une surveillance étroite. La surveillance doit être proportionnelle au risque, et les organisations doivent toujours respecter les considérations en matière de confidentialité, de droit et de personnel. Le point est plus simple : si le système d’IA est suffisamment important pour influencer le travail réel, il est suffisamment important pour laisser une trace de preuve en cas de problème.
La propriété ne peut pas être implicite
La propriété de l’IA est souvent fragmentée. Une unité commerciale peut parrainer le cas d’utilisation, une équipe de science des données peut configurer le modèle, le service informatique peut gérer la plate-forme, la sécurité peut évaluer les risques et un fournisseur peut fournir la fonctionnalité sous-jacente. Tout le monde est impliqué, mais personne ne peut être entièrement responsable après le déploiement.
Cette ambiguïté devient dangereuse lors d’un incident. Si un outil d’IA commence à produire des résultats peu fiables, l’organisation doit savoir à qui appartient le système, à qui appartient le processus métier et à qui appartient la décision de continuer ou d’arrêter l’utilisation. Un comité de gouvernance peut assurer une surveillance, mais il ne peut généralement pas servir de propriétaire opérationnel de chaque capacité d’IA déployée.
Les programmes de sécurité devraient insister sur la propriété nommée des systèmes d’IA, en particulier ceux utilisés dans des flux de travail sensibles ou à fort impact. La propriété doit inclure la responsabilité de la surveillance, des exceptions, des conseils aux utilisateurs, de la coordination des fournisseurs et de la remontée des incidents. Cela devrait également inclure les droits de décision, car la responsabilité sans autorité n’est qu’un nom dans une feuille de calcul.
La question la plus difficile est souvent celle de suspendre l’autorité. Qui peut suspendre, restreindre, restaurer ou mettre hors service un système d’IA lorsque le risque dépasse la tolérance ? Si cette question n’est pas résolue avant le déploiement, l’organisation peut être contrainte d’y répondre sous pression.
Les responsables de la sécurité ont besoin d’un manuel de réponse à l’IA
Un manuel de réponse à l’IA n’a pas besoin d’être compliqué, mais il doit être réel. Il doit expliquer comment les employés signalent les problèmes liés à l’IA, comment l’événement est trié, quelles preuves sont conservées, qui enquête, quand les équipes juridiques ou de protection de la vie privée sont impliquées et qui peut prendre des décisions opérationnelles. Il convient également de définir à quel moment la direction exécutive doit être informée.
Le playbook doit refléter le type de système d’IA impliqué. Un outil de productivité interne à faible risque peut nécessiter un chemin de révision léger. Un système d’IA prenant en charge les opérations de sécurité, les décisions réglementées, la communication avec les clients, les flux de travail de santé ou les processus financiers nécessite une surveillance et une escalade plus strictes. Le modèle de réponse doit correspondre au risque du cas d’utilisation.
C’est là que la sécurité peut ajouter de la discipline sans transformer la gouvernance de l’IA en bureaucratie. Les équipes de sécurité savent déjà comment créer des voies de remontée d’informations, conserver les preuves, effectuer des analyses d’incidents et améliorer les contrôles après des pannes. L’opportunité est d’étendre ce pouvoir opérationnel à la gouvernance de l’IA avant que des incidents ne provoquent le problème.
Les organisations doivent également procéder à des examens post-incident pour les événements d’IA significatifs. L’objectif ne doit pas être le blâme ; ça devrait être un apprentissage. La surveillance a-t-elle fonctionné ? Le propriétaire était-il clair ? Les preuves étaient-elles suffisantes ? Le vendeur a-t-il répondu ? Les utilisateurs étaient-ils confus quant à l’utilisation acceptable ? L’organisation savait-elle qui pouvait prendre la décision ?
La gouvernance doit être exécutable
La gouvernance de l’IA est souvent abordée comme un défi politique, éthique ou de conformité. C’est tout cela, mais une fois que les systèmes d’IA entrent en production, cela devient également un défi d’exécution en matière de sécurité. Les risques doivent être surveillés, les événements doivent faire l’objet d’une enquête et quelqu’un doit pouvoir agir.
C’est pourquoi la prochaine étape de maturité ne consiste pas simplement à une meilleure documentation. Les organisations ont besoin d’une gouvernance qui fonctionne lorsqu’un système est opérationnel, qu’une décision est urgente et que les faits sont incomplets. À ce moment-là, le registre des risques peut aider à expliquer ce à quoi l’organisation s’attend, mais il ne pilotera pas la réponse.
Les responsables de la sécurité ne devraient pas attendre que la gouvernance de l’IA soit pleinement formée ailleurs dans l’entreprise. Ils devraient contribuer à façonner le modèle opérationnel dès maintenant, alors que de nombreuses organisations sont encore suffisamment tôt pour rectifier le tir. L’objectif n’est pas de maîtriser tous les risques liés à l’IA ; il s’agit de garantir que les risques liés à l’IA pourront être gérés une fois que l’IA deviendra opérationnelle.
Un registre des risques peut indiquer aux dirigeants ce qui pourrait mal se passer. Un plan de réponse aux incidents indique aux gens quoi faire lorsque cela se produit. Pour que la gouvernance de l’IA soit importante dans les programmes de sécurité, les organisations ont besoin des deux.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
