Un fournisseur ajoute une fonctionnalité qui tourne sous le capot sur un modèle de langage ou une API tierce. Pour le fournisseur, c'est une mise à jour du produit, pas un événement qui mérite d'être signalé. Les notes de version mentionnent un nouveau bouton, pas la technologie derrière. Votre organisation utilise déjà le logiciel, le contrat a été signé sur la base de l'ancienne fonctionnalité, et la modification n'arrive pas via les achats ou la sécurité — ceux-ci ne voient que ce qui se passe lors d'un nouvel achat, pas ce qu'un produit existant reçoit discrètement en plus.
Le schéma est le même que pour une extension de navigateur ayant accès à votre messagerie : l'accès et la fonction existent déjà avant que quelqu'un ne les évalue. Chez un fournisseur, la distance est simplement plus grande — vous ne pouvez pas consulter le code source et devez vous fier à ce que le fournisseur dit, ou ne dit pas.
Il n'y a aucun moment où cela se signale. Un collaborateur utilise la nouvelle fonction parce qu'elle est pratique, pas parce qu'il reconnaît un composant d'IA. Le fournisseur n'a aucune incitation à le signaler activement tant que personne ne pose la question : cela ne génère pas de revenus et peut soulever des questions. Et la probabilité que vous le découvriez vous-même est faible, sauf en cas d'incident ou si un contrôle périodique le remarque.
Cela ressemble ainsi à un pilote interne qui s'est éternisé : comme pour une installation pilote qui n'a jamais été arrêtée, ce n'est pas la malveillance qui manque, mais un moment où quelqu'un pose la question. Chez un fournisseur, s'ajoute le fait que vous dépendez de sa volonté de répondre.
Le point de départ n'est pas de faire respecter le contrat juridiquement au premier doute, mais de d'abord savoir ce qui se passe. Cela commence par poser des questions au fournisseur : quels composants du produit utilisent l'IA, quelles données y sont envoyées, et cela a-t-il changé depuis la signature du contrat. Les fournisseurs qui peuvent répondre sans conséquences le font plus volontiers de manière véridique que les fournisseurs qui soupçonnent qu'une réponse honnête mettrait le contrat en péril.
La même logique s'applique au sein de l'organisation : les collaborateurs qui utilisent un outil dont personne ne sait qu'il contient de l'IA ne le signalent que lorsque le signalement n'entraîne pas de sanction. La manière d'organiser cela est décrite dans les collaborateurs qui utilisent un outil que personne n'a approuvé. Pour un fournisseur, le principe fonctionne de la même manière : une question sans accusation reçoit une réponse différente d'une question perçue comme un prélude à des sanctions.
Dès qu'il est clair ce que le fournisseur a ajouté, la question suivante n'est pas juridique mais fonctionnelle : quel rôle joue ce composant d'IA dans le processus, quel est le niveau de risque, et qu'est-ce qui doit être consigné à ce sujet. Vous posez les mêmes questions à chaque application d'IA que vous utilisez vous-même, qu'elle arrive via un fournisseur ou via un collaborateur utilisant un outil gratuit — voir aussi les données d'entreprise qui atterrissent dans une fenêtre de chat gratuite. Ce que vous devez consigner par application dépend de ce que fait cette application et avec quelles données, pas de son origine. Un aperçu des éléments pertinents à cet égard se trouve sur ce que vous devez consigner par application.
Un fournisseur qui ajoute de l'IA sans le signaler ne doit donc pas être traité séparément comme un incident, mais intégré dans l'inventaire que vous constituez déjà pour le reste de l'organisation. La manière dont cet inventaire est constitué en pratique — y compris comment vous y intégrez les fournisseurs — est décrite sur comment constituer un inventaire de l'IA.
Ceci n'est pas une raison de lancer une offensive juridique contre chaque fournisseur qui n'a pas signalé quelque chose. Établir une rupture de contrat est une question différente d'établir un risque, et les deux ne vont pas automatiquement de pair : un fournisseur peut avoir omis de signaler quelque chose sans que l'application présente un risque élevé, et inversement. La première étape est d'évaluer le risque, pas la question de la faute. Celui qui commence par les sanctions recevra désormais moins d'informations des fournisseurs, pas plus.
Dès qu'il est clair quels composants d'IA sont actifs au sein de l'organisation via des fournisseurs, des collaborateurs ou des initiatives propres, une autre question se pose : qu'est-ce que cela signifie pour le travail lui-même. Toute application d'IA qui arrive ne fait pas nécessairement quelque chose d'utile dans le processus dans lequel elle se trouve — et tout processus qui se déroule actuellement manuellement n'est pas forcément mieux sans IA. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut raisonnablement être reprise par l'IA, indépendamment de la manière dont cette IA est arrivée. Cela fait de l'inventaire que vous constituez maintenant non seulement un instrument de gouvernance, mais aussi un point de départ pour déterminer où l'IA fait réellement la différence.
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.