Un fournisseur livre un logiciel de comptabilité, un système RH ou un outil de service client. Il existe un contrat, un accord de traitement des données, peut-être un audit de sécurité. Puis, dans une mise à jour, le fournisseur ajoute une fonction d'IA : classification automatique, suggestions de texte, un chatbot lâché sur vos données. Les notes de version parlent d'une amélioration. Personne dans votre organisation n'a eu son mot à dire, car personne ne savait que cela arrivait.
Ce n'est pas une exception dans la façon dont les logiciels sont livrés. C'est devenu la norme. Les fournisseurs se font concurrence sur la fonctionnalité IA et l'intègrent aussi rapidement que possible, souvent dans le cadre d'un abonnement que vous payez déjà. La question de savoir si cela relève de vos accords existants est rarement posée avant que la fonction ne soit mise en service.
Un service des achats évalue un fournisseur au moment de l'acquisition. Ensuite, l'attention se déplace vers la facture, la disponibilité et le support. Les mises à jour fonctionnelles échappent à ce processus, car elles relèvent de la maintenance, non d'une nouvelle acquisition. Qui devrait le signaler ? Le fournisseur y voit une amélioration du produit. L'acheteur ne voit pas la mise à jour, ou la voit et pense que cela concerne quelqu'un d'autre. L'utilisateur dans l'organisation remarque surtout qu'un bouton fait quelque chose de plus intelligent et ne se demande pas si un modèle de langage traite des données en externe derrière cela.
Ce schéma ressemble à ce qui se passe avec une extension de navigateur ayant accès à votre messagerie : l'accès est accordé à un moment où personne ne pensait à l'IA, et reste ensuite actif sans être remarqué. Chez les fournisseurs, le problème d'échelle est plus important, car ce n'est pas un seul collaborateur qui est concerné, mais toute une organisation exposée via un seul contrat.
Une disposition contractuelle imposant une obligation de signalement en cas de fonctionnalité IA aide pour les nouveaux contrats. Pour les contrats existants, la disposition n'existe pas, et il n'est pas évident qu'un fournisseur l'accepte avec effet rétroactif. De plus, une clause ne résout pas le problème de détection : si personne ne vérifie périodiquement ce qu'un fournisseur a réellement ajouté, le signalement reste dépendant de la volonté du fournisseur de le communiquer lui-même.
Ce qui fonctionne, en revanche, c'est un instantané fixe : un inventaire périodique de ce que chaque fournisseur clé propose actuellement en matière de fonctionnalité IA, détaché de ce qui a été évalué lors de l'acquisition. Ce n'est pas un instrument juridique mais un aperçu factuel, qui peut ensuite être confronté à la catégorie de risque du processus dans lequel le fournisseur opère.
La même dynamique qui maintient l'IA fantôme chez les collaborateurs est également à l'œuvre ici, mais au niveau des fournisseurs. Celui qui pose la question « utilisez-vous l'IA pour cela » veut une réponse honnête, pas une réaction défensive du gestionnaire de compte. Cela signifie que la question ne doit pas être posée comme prélude à une résiliation de contrat, mais comme élément d'un processus fixe où la réponse n'a d'autre conséquence que la classification. Voyez comment cela fonctionne avec les collaborateurs qui utilisent un outil que personne n'a approuvé : l'information utile ne se libère que lorsque poser des questions est dissocié du fait de sanctionner.
Une liste de fournisseurs est un point de départ, pas un point final. Pour chaque fournisseur ayant accès aux données de production, aux données clients ou aux données du personnel, il est pertinent de savoir si une fonctionnalité IA y a désormais été intégrée, ce que cette fonctionnalité fait avec les données, et si cet usage relève de la même catégorie de risque que celle pour laquelle le fournisseur a été initialement approuvé. Un fournisseur évalué il y a cinq ans comme présentant un risque faible parce qu'il se contentait de facturer, peut désormais faire fonctionner un module qui classe automatiquement les factures sur la base d'un modèle de langage entraîné en externe. C'est une catégorie de risque différente, même si le même nom figure sur la facture.
Cet inventaire ne devrait pas être dissocié du reste de la gouvernance de l'IA au sein d'une organisation. La même classification appliquée aux outils construits en interne ou à une installation pilote qui n'a jamais été désactivée devrait également s'appliquer à ce que les fournisseurs introduisent. Un seul aperçu, une seule échelle de risque, que l'IA ait été construite en interne, apportée par un collaborateur, ou ajoutée par un fournisseur sans annonce.
Dès qu'il est clair quelle IA arrive via les fournisseurs, une question de suivi se pose, qui va au-delà du risque seul : que fait cette IA concrètement avec le travail actuellement effectué par des personnes, et où cela recoupe-t-il des tâches qui se prêtent déjà à l'automatisation. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, indépendamment du fournisseur ou du système qui l'exécute finalement. Cela rend l'inventaire qui commence par le risque également utile pour la question qui suit : non seulement ce qui fonctionne, mais ce que le travail vaut réellement.
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.