L’IA de décision de crédit d’une société de crédit à la consommation avait refusé une demande de crédit d’une manière que le demandeur jugeait discriminatoire, en affirmant plus précisément que la décision semblait enfreindre l’Equal Credit Opportunity Act en raison de variables de substitution indirectes. L’équipe conformité de l’entreprise devait enquêter : la décision de l’IA était-elle appropriée compte tenu de son entraînement et de ses paramètres de conception ? Quelles données d’entrée précises avaient été utilisées pour la décision ? Le modèle avait-il fonctionné correctement ou y avait-il eu une défaillance opérationnelle ? La décision pouvait-elle être reconstituée et examinée au regard de la conformité aux règles de prêt équitable ? L’équipe de réponse aux incidents de l’entreprise était expérimentée et bien préparée aux types d’incidents couverts par son playbook : violations de données nécessitant une investigation forensique, rançongiciels nécessitant l’isolement et la restauration des systèmes, et interruptions de service nécessitant un rétablissement technique. Aucun de ces scénarios ne correspondait à ce qu’exigeait un incident de décision d’un modèle d’IA. L’équipe de IR n’avait aucun processus pour reconstituer une décision d’IA à partir des journaux d’audit des décisions, aucune expertise pour évaluer si un modèle d’IA avait dysfonctionné ou fonctionné correctement sur des hypothèses inappropriées, aucune procédure établie pour conserver les preuves du comportement du modèle d’IA, et aucune voie d’escalade définie pour déterminer si l’incident d’IA nécessitait une expertise externe de validation de modèles. La capacité de IR de l’entreprise était réelle et bien éprouvée. Son périmètre n’avait pas été étendu aux incidents de modèles d’IA.
Que sont les lacunes de la réponse aux incidents d’IA, au fond ?
Les lacunes de la réponse aux incidents d’IA sont les carences du programme de réponse aux incidents d’une organisation qui laissent les incidents de décision des modèles d’IA (décisions d’IA préjudiciables, défaillances de modèles d’IA, manipulation de systèmes d’IA et violations de la gouvernance de l’IA) sans procédures d’enquête, exigences de conservation des preuves, voies d’escalade ni processus de remédiation définis. Les playbooks de IR traditionnels sont conçus pour les incidents de cybersécurité : violations de données, logiciels malveillants, compromissions de systèmes et interruptions de service. Les incidents de modèles d’IA exigent d’autres compétences d’enquête, d’autres preuves et d’autres approches de remédiation que les playbooks de IR traditionnels ne traitent pas.
Le problème de l’enquête sur les incidents de décision d’IA est la première lacune de IR. Enquêter sur un incident de décision d’un modèle d’IA exige de reconstituer la décision précise à partir des journaux d’audit des décisions, d’évaluer si le modèle a fonctionné correctement dans ses paramètres de conception ou s’il a dysfonctionné, de déterminer si la décision reflète un biais des données d’entraînement ou un problème d’architecture, et d’établir si la décision a enfreint les exigences réglementaires applicables. Aucune de ces étapes n’est comparable à l’investigation forensique, à l’analyse de logiciels malveillants ou à la restauration des systèmes que décrivent les playbooks de IR traditionnels. Une équipe de IR sans expertise en IA aura du mal à reconstituer un incident de décision d’IA sans expertise externe en modèles.
Le problème de la conservation des preuves est la deuxième lacune. Les incidents de décision des modèles d’IA exigent de conserver des preuves différentes de celles des incidents de cybersécurité : la version précise du modèle qui a pris la décision, les données d’entrée au moment de la décision, les résultats intermédiaires du modèle, le journal d’audit de la décision et, éventuellement, l’intégralité des données d’entraînement et de la documentation d’architecture du modèle nécessaires à une validation indépendante. Les équipes de IR qui appliquent aux incidents d’IA les procédures standard de conservation des preuves de cybersécurité risquent de ne pas conserver les preuves propres à l’IA nécessaires à l’enquête et à l’examen juridique ultérieurs.
Pourquoi c’est important
Les lacunes de la réponse aux incidents d’IA sont importantes pour la TPRM car les produits d’IA des fournisseurs qui prennent des décisions à fort enjeu (crédit, assurance, emploi, soins cliniques) finiront par produire des décisions contestées, faisant l’objet d’enquêtes ou de litiges. L’entreprise incapable d’enquêter sur un incident de décision de l’IA d’un fournisseur ne peut pas démontrer sa diligence dans la supervision de ses fournisseurs d’IA et peut s’exposer à des risques réglementaires et juridiques découlant d’un incident d’IA auquel elle n’était pas préparée.
- Aucun playbook d’incident d’IA : incidents de décision d’IA non couverts
- Capacité de reconstitution des décisions d’IA absente de l’équipe de IR
- Conservation des preuves propres à l’IA absente des procédures de IR
- Évaluation réglementaire des incidents d’IA (prêt équitable) non couverte
- Voie d’escalade vers une expertise externe en IA non définie
À quoi ressemblent les bonnes pratiques
Les programmes matures de réponse aux incidents d’IA étendent les cadres de IR existants aux incidents de décision des modèles d’IA, en définissant des procédures d’enquête sur les décisions d’IA, des exigences de conservation des preuves propres à l’IA, des voies d’escalade vers une expertise en modèles d’IA et des processus de remédiation des défaillances de modèles d’IA.
- Playbook d’incident d’IA : playbook distinct ou étendu couvrant les incidents de décision d’IA
- Processus de reconstitution des décisions d’IA : utilisation des journaux d’audit des décisions pour reconstituer des décisions précises
- Conservation des preuves propres à l’IA : version du modèle, variables d’entrée, résultats intermédiaires
- Expertise externe en IA dans le contrat de disponibilité IR ou voie d’escalade définie
- Évaluation réglementaire des incidents d’IA : implications du prêt équitable, du règlement européen sur l’IA et du GDPR pour les incidents d’IA
Outils
Enquête sur incident d’IA : journaux d’audit des décisions MLflow, outils d’explicabilité des modèles pour l’examen post-incident
Les outils de gestion des modèles et d’explicabilité fournissent la base technique de la reconstitution des décisions d’IA lors d’une enquête sur incident. Pour les praticiens de la TPRM, demander si le fournisseur a défini un playbook d’incident d’IA couvrant spécifiquement les incidents liés aux décisions des modèles d’IA, et s’il a accès à une expertise externe en modèles d’IA pour les incidents complexes, constitue une question précise sur les lacunes de IR propres à l’IA.
Enjeux de gouvernance
Le défi de gouvernance posé par les lacunes de IR liées à l’IA est le problème de la disponibilité de l’expertise. L’enquête sur un incident de modèle d’IA requiert des compétences (analyse du comportement du modèle, évaluation des données d’entraînement, évaluation de l’équité) que les équipes de IR traditionnelles ne possèdent généralement pas. Développer cette expertise en interne coûte cher. La solution de gouvernance consiste à établir des relations avec des fournisseurs d’expertise en modèles d’IA (partenaires universitaires, cabinets de conseil spécialisés ou programmes de conseil de fournisseurs d’IA) pouvant être mobilisés rapidement lorsque des incidents d’IA nécessitent une enquête spécialisée.
- Élaborer un playbook d’incident d’IA comme extension du cadre de IR existant
- Établir une voie d’escalade vers une expertise en IA : contrat de disponibilité ou processus de mobilisation défini
- Définir les exigences de conservation des preuves propres à l’IA
- Former l’équipe de IR aux bases des incidents d’IA : reconstitution des décisions et évaluation du comportement des modèles
- Inclure l’évaluation de la capacité de IR liée à l’IA dans les examens des risques fournisseurs
Si vous êtes une petite équipe
Posez une question de préparation à la IR liée à l’IA : si l’une des décisions d’IA de votre fournisseur était formellement contestée aujourd’hui, par exemple un refus de crédit que le demandeur juge discriminatoire, quel serait votre processus d’enquête ? Qui mènerait l’enquête, de quelles preuves aurait-on besoin et à quelle expertise ferait-on appel pour déterminer si la décision de l’IA reflétait une défaillance du modèle ou un biais des données d’entraînement ? La difficulté à répondre à cette question révèle la lacune de IR liée à l’IA. La réponse à cette question est le playbook d’incident d’IA qu’il faut construire.
- Poser la question de l’enquête sur une décision d’IA contestée : qui, quelles preuves, quelle expertise
- Élaborer un playbook d’incident d’IA couvrant la reconstitution des décisions et les implications réglementaires
- Établir une voie d’escalade vers une expertise en IA
- Définir les exigences de conservation des preuves propres à l’IA
Ce qu’il faut exiger
Demandez directement :
« Si l’une des décisions de votre modèle d’IA était formellement contestée, plus précisément un refus de crédit présumé discriminatoire, quel serait votre processus d’enquête ? Qui mène l’enquête, quelles preuves propres à l’IA sont conservées et à quelle expertise faites-vous appel pour évaluer l’IA au regard des règles de prêt équitable ? »
Preuves attendues
- Playbook d’incident d’IA ou équivalent
- Processus d’enquête sur les décisions d’IA
- Conservation des preuves propres à l’IA
- Voie d’escalade vers une expertise externe en IA
Un fournisseur qui confirme une capacité de IR complète doit être invité à présenter son playbook d’incident d’IA. La IR traditionnelle couvre les incidents de cybersécurité. La réponse aux incidents d’IA couvre les incidents de décision des modèles. Les deux sont nécessaires pour les déploiements d’IA en entreprise.
Comment le prouver
- Playbook d’incident d’IA
- Capacité de reconstitution des décisions d’IA
- Dossiers de conservation des preuves propres à l’IA
- Voie d’escalade vers une expertise en IA
À retenir
Incident de décision d’IA. Enquête de conformité requise. Équipe de IR : expérimentée, bien préparée, playbook éprouvé. Reconstitution des décisions d’IA : absente du playbook. Conservation des preuves propres à l’IA : absente des procédures. Expertise en évaluation de l’IA au regard des règles de prêt équitable : absente de la voie d’escalade. La capacité de IR était réelle et complète pour son périmètre. Les incidents de décision des modèles d’IA se situaient hors de ce périmètre. Étendre les cadres de IR aux incidents d’IA exige un playbook propre à l’IA, une conservation des preuves propre à l’IA et un accès à une expertise en modèles d’IA. La question de la décision contestée est le test de préparation : si vous ne pouvez pas dire qui enquête, de quelles preuves cette personne a besoin et à quelle expertise elle fait appel, la lacune de IR liée à l’IA est la réponse.