Dans une seule implantation, vous pouvez encore faire le tour et engager la conversation. Avec plusieurs implantations, avec des responsables différents et des cultures différentes autour de ce qui se signale ou non, cela ne fonctionne plus. Il faut alors trouver une façon de poser la même question partout, de la même manière, et c'est précisément là que cela dérape le plus souvent : la question est posée comme un contrôle, et il n'en résulte alors aucune réponse utilisable.
Si vous demandez « utilisez-vous des outils d'IA qui n'ont pas été approuvés », vous demandez à quelqu'un d'admettre qu'il enfreint les règles. La réponse que vous obtenez alors est presque toujours non, même quand ce n'est pas vrai. Pas parce que les gens mentent pour mentir, mais parce que la question est formulée de telle sorte qu'une réponse honnête devient un aveu. Cela vaut pour le collaborateur qui utilise un chatbot pour rédiger des e-mails, et cela vaut plus encore pour le responsable d'implantation qui a acquis un outil en dehors de l'IT, parce que c'était plus rapide que d'introduire une demande.
La question qui fonctionne ne porte pas sur l'autorisation mais sur l'usage : quel travail effectuez-vous, et qu'est-ce qui vous y aide. Pas une question sur une infraction, une question sur la pratique. Cela change non seulement le ton, mais aussi ce que les gens osent signaler.
Un aperçu utilisable ne se compose pas d'impressions mais d'un ensemble limité de données, recueillies de manière cohérente :
Ces cinq points, vous les transformez en une liste de questions fixe, identique partout, afin que l'implantation A et l'implantation B produisent des données comparables. Ce que vous devez exactement consigner par application et pourquoi est détaillé sur la page consacrée à ce qu'il faut consigner par application.
La question posée aux collaborateurs est une source, pas la seule. Les factures et les aperçus de licences montrent souvent quels abonnements IA existent quelque part, même sans que personne ne le signale ; ce que les données d'achat et de licences révèlent au sein d'une organisation comptant plusieurs implantations, c'est que chaque implantation a son propre schéma d'achat, et que les écarts s'y remarquent souvent plus tôt qu'au cours d'un entretien. Par ailleurs, les signaux IT utilisables au sein d'une organisation comptant plusieurs implantations offrent une seconde piste : trafic réseau vers des services d'IA connus, nouvelles extensions de navigateur, demandes d'accès API. Aucune de ces sources n'est complète en elle-même. Ensemble, elles donnent une image plus fiable que ce qu'un seul canal peut produire, et cela permet aussi plus facilement de ne pas faire porter au seul collaborateur la charge du point de contrôle.
Sans un accord clair selon lequel signaler ne mène pas à une sanction, l'IA fantôme reste fantôme. Cela ne signifie pas qu'il n'y a jamais de conséquences — si une application se révèle être un risque, il faut agir en conséquence — mais que le signalement lui-même n'est jamais le point de départ d'un problème. Cette séparation entre signaler et évaluer doit être communiquée au préalable, pas expliquée après coup. La façon de construire cet inventaire étape par étape, y compris l'ordre des questions et des sources, est décrite sur la page consacrée à la construction d'un inventaire de l'IA.
Dès qu'une application est identifiée, la question suivante n'est pas « est-ce autorisé » mais « qu'est-ce que c'est ». L'organisation est-elle ici utilisatrice d'un système externe, ou, dans certains cas, elle-même fournisseur — par exemple parce qu'une équipe a entraîné son propre modèle ou a modifié en profondeur un système existant. Cette distinction déterminine quelles obligations s'appliquent et qui en est responsable ; elle est détaillée sur la page qui distingue les rôles de fournisseur et d'utilisateur. Même au sein du rôle d'utilisateur, la position peut changer — une adaptation, une nouvelle application de données existantes — ce qui est expliqué sur la page consacrée au moment où votre rôle change. Ces deux questions relèvent de la classification, pas du premier entretien avec les collaborateurs. D'abord l'aperçu, ensuite le classement.
Un inventaire de ce qui est utilisé ne vous dit pas encore combien de travail y est lié ni ce qui change si une application disparaît ou est au contraire étendue. Pour cette question — quelle part du travail d'une tâche est reprise par l'IA, et quelle part ne l'est pas — le scan de travail de FTE TO AI est conçu. Il calcule, par tâche, la répartition entre l'humain et l'IA, sur la base des tâches telles qu'elles sont exécutées aujourd'hui, et non sur la base d'une estimation préalable.
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.