Une application d'IA commet une erreur. Une décision est incorrecte, un conseil est trompeur, un client est refusé à tort. La question qui suit alors n'est pas seulement technique. Qui aurait dû le voir venir, qui gérait le système, et qui peut expliquer pourquoi il a été déployé comme il l'a été.
Cette réponse n'existe pas indépendamment d'un registre. La responsabilité présuppose que quelqu'un sache qu'une application existe, à quoi elle sert, et qui en a la charge. Sans cette base, la question de la responsabilité est rhétorique : personne ne le sait, donc personne ne peut l'expliquer.
Un Responsible AI Scan cartographie ce qui fonctionne, qui l'utilise et à quel niveau de risque cela correspond. C'est un point de départ, pas un jugement de faute. Le scan classe une application selon son rôle et son risque ; il ne juge pas si une décision individuelle était correcte. Cette évaluation relève de l'incident lui-même, pas de l'inventaire qui l'a précédé.
Ce que le scan fait bien, c'est fournir la structure dans laquelle cette évaluation pourra ultérieurement être effectuée. Si l'on sait qui a acquis une application, qui la gère et pour quel usage elle a été approuvée, il existe une ligne sur laquelle s'appuyer. Sans cette structure, la question de la responsabilité se réduit à des suppositions après coup.
La plupart des organisations disposent d'un aperçu des logiciels approuvés. Cet aperçu n'est presque jamais complet. Les collaborateurs utilisent des outils que personne n'a déclarés, souvent parce que le travail avance plus vite ainsi et que personne n'a posé la question. Ce n'est pas par définition un comportement irresponsable ; c'est ce qui se produit lorsqu'une organisation n'offre pas d'autre voie.
Qui veut savoir ce qui est réellement utilisé doit le demander. Et cela ne fonctionne que si le fait de poser la question n'entraîne aucune conséquence. Dès qu'un collaborateur suppose qu'une réponse honnête débouchera sur un entretien correctif, la réponse s'arrête. Que faites-vous des collaborateurs qui utilisent un outil que personne n'a approuvé traite précisément de ce mécanisme : l'inventaire vaut ce que vaut la confiance avec laquelle il est recueilli.
S'y ajoute la question de ce qui advient des informations de l'entreprise dès qu'elles sont saisies dans une fenêtre externe. Que faites-vous des données de l'entreprise dans une fenêtre de chat gratuite décrit un risque indépendant de toute mauvaise intention : quelqu'un veut simplement faire vérifier un texte, et tape au passage ce qui n'aurait pas dû l'être.
Un ensemble de gouvernance qui suit un inventaire règle qui approuve une application, qui exerce le contrôle et comment cela est consigné. Cela s'inscrit dans la structure de risque qu'une organisation possède déjà pour d'autres domaines : les mêmes comités, les mêmes lignes de reporting, les mêmes voies d'escalade. Il ne s'agit pas d'un nouvel appareil venant s'ajouter à l'existant ; c'est une catégorie qui vient s'ajouter à ce qui existe déjà.
Cela permet la démontrabilité : un conseil d'administration peut montrer qu'on a examiné, classé et mis en place un contrôle. Cela ne garantit pas qu'une application ne commettra plus jamais d'erreur. Ces deux éléments sont distincts et le scan ne se prononce pas sur le second. Ce qu'il apporte, c'est une base permettant à un conseil d'administration d'expliquer ce qui a été fait, pas une assurance contre ce qui peut encore arriver.
Une erreur fréquente consiste à mettre en place un processus IA distinct, séparé de la structure existante de risque et de conformité. Ce processus reçoit de l'attention au début puis passe à l'arrière-plan, parce que personne ne continue à entretenir un second système parallèlement au premier. Pourquoi un second processus parallèle à l'existant est ignoré explique pourquoi l'intégration aux structures existantes n'est pas une question d'efficacité, mais une condition pour faire perdurer quelque chose.
Cela implique également qu'un inventaire est un instant, pas un aboutissement. De nouvelles applications s'ajoutent, des applications existantes changent de fonction, et une classification correcte à la livraison ne reste pas automatiquement valable un an plus tard. À quelle fréquence devez-vous reclassifier et comment tenir à jour un registre d'IA décrivent ce que cet entretien exige en pratique, et pourquoi un registre établi une seule fois ne correspond plus à la réalité au bout d'un temps relativement court.
Les personnes qui travaillent avec ces applications font par ailleurs partie de la solution, pas seulement un risque à maîtriser. Ce que les collaborateurs comprennent ou non des systèmes qu'ils utilisent déterminera si un ensemble de gouvernance a une réelle portée en pratique. Que signifie la littératie en IA pour vos collaborateurs aborde cet aspect.
Une fois que l'on sait quelles applications d'IA fonctionnent et qui en a la charge, une question suivante se pose naturellement : quelle part du travail actuellement effectué manuellement se prête réellement à être confiée à une application d'IA. C'est une question différente de celle de la responsabilité, mais qui repose sur le même inventaire. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, comme étape suivante une fois qu'il est clair ce qui fonctionne déjà et qui en décide.
Le scan décrit sur cette page est en cours de développement. Les personnes intéressées peuvent s'inscrire sur la liste d'attente ; rien n'est encore livré qui ne soit achevé.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.