Un General Counsel n'est pas jugé sur ce qui se passe mal avec l'IA. Il est jugé au moment où il apparaît que l'organisation ne pouvait pas démontrer qu'elle le savait, ou pire, qu'elle aurait pu le savoir et n'a rien fait. C'est la différence entre un incident et un manquement. Le premier arrive à une organisation. Le second lui est imputé.
La question juridique — ce qui est autorisé, ce qui est obligatoire, quel délai s'applique — est importante, mais elle vient après une autre question. Cette question est : qu'utilisons-nous réellement. Pas ce qui a été acheté, pas ce qui figure sur la liste des fournisseurs de l'IT, mais ce que les gens, dans la pratique, laissent contribuer à une décision, à une rédaction ou à une évaluation. Sans réponse à cette question, tout avis juridique est un avis sur une situation que vous ne connaissez pas.
Cela rend la position du General Counsel inconfortable. On attend de vous que vous évaluiez les risques sur la base d'un inventaire qui, le plus souvent, n'existe pas, ou qui se compose de ce qui a été approuvé — ce qui, par définition, n'est pas ce que quelqu'un a commencé à utiliser sans autorisation.
« Nous n'avons pas besoin de politique en matière d'IA, car nous n'utilisons pas d'IA » n'est pas une réponse qui tient la route. C'est une supposition, et les suppositions sont précisément ce qu'une autorité de contrôle, un juge ou un journaliste n'acceptent pas après coup. Vous n'acceptez pas non plus une liste d'outils approuvés comme image complète : cette liste indique ce qui a été acheté, rien sur ce qui est effectivement utilisé.
Ce dont vous avez besoin, c'est d'une distinction entre les types d'usage. Un modèle de langage qui résume des notes internes présente un risque différent d'un système qui intervient dans une décision de recrutement ou une évaluation de crédit. Sans classification selon le rôle et le niveau de risque, toute discussion sur le risque IA est une discussion générale, et les discussions générales ne débouchent pas sur des positions défendables.
L'IA fantôme — l'usage qui se développe en dehors de toute approbation — n'est pas quelque chose qu'un service informatique détecte avec une analyse réseau. Les gens utilisent l'IA sur leur propre ordinateur portable, dans leur navigateur, avec leur propre compte. Cet usage laisse peu de traces dans un système qui ne cherche pas dans cette direction.
Ce qui fonctionne, c'est de poser la question. Mais seulement si la réponse n'a pas de conséquences pour celui qui la donne. Quelqu'un qui utilise l'IA pour préparer un projet de contrat, ou pour faire résumer une analyse de risque, ne le signale pas si ce signalement peut mener à une réprimande. L'inventaire dont vous avez besoin ne se constitue que si poser des questions n'équivaut pas à sanctionner.
C'est un équilibre précaire pour une fonction juridique. Vous êtes habitué à évaluer le risque sur la base de ce qui peut mal se passer. Ici, vous devez d'abord veiller à ce que les gens osent dire ce qu'ils font déjà, avant de pouvoir évaluer si cela constitue un risque.
Le cœur de votre position n'est pas d'éviter tout risque — ce n'est pas réaliste et on ne l'attend pas non plus de vous. Le cœur, c'est la démontrabilité : pouvez-vous montrer que l'organisation savait ce qu'elle utilisait, avait évalué le risque que cela comportait, et disposait d'une structure pour agir en conséquence. C'est une mission différente de la maîtrise des résultats. C'est la maîtrise du processus par lequel les résultats sont surveillés.
Cette démontrabilité ne doit pas nécessairement s'appuyer sur un nouveau cadre. La plupart des organisations disposent déjà d'une structure de gestion des risques — pour le risque financier, le risque opérationnel, la conformité. Le risque IA doit s'y intégrer, et non exister à côté comme un parcours distinct que personne ne connaît et que personne n'entretient. Un ensemble de gouvernance qui s'articule avec ce qui existe déjà est utilisé. Une structure séparée est oubliée après le premier trimestre.
Cette position décrit le mécanisme : inventorier, classifier, s'articuler avec la structure existante, rendre démontrable. Elle ne décrit pas quelle loi ou réglementation s'applique à votre organisation, quels délais s'appliquent, ni quelle obligation entre en vigueur à quel moment. Ce contenu évolue, est complété, est expliqué par ceux qui s'y spécialisent. Ce qui compte ici, c'est la structure dans laquelle ce contenu pourra s'inscrire dès que vous en aurez besoin.
Les questions que vous posez recoupent ce qu'un risk manager doit savoir sur le risque IA et la position d'un compliance officer qui doit pouvoir démontrer l'usage de l'IA. Le dirigeant qui doit rendre des comptes au conseil de surveillance tire lui aussi profit du même inventaire sur lequel vous fondez votre propre évaluation — c'est la même base factuelle, considérée sous une autre responsabilité.
Le Responsible AI Scan qui exécute ce mécanisme — inventorier, classifier, s'articuler avec la structure de risque existante — est en cours de développement. Quiconque en ressent le besoin dès maintenant peut s'inscrire sur la liste d'attente. Il n'y a pas encore de service à fournir ; il y a une direction dans laquelle cela se construit, et cette direction est celle-ci.
Dès qu'il est clair quelle IA fonctionne et quel risque y est associé, une autre question se pose, qui sort de votre propre responsabilité mais s'y rattache : quelle part du travail sous-jacent cette IA est-elle en train de reprendre. C'est une question qui ne porte pas sur le risque, mais sur l'organisation du travail, et à laquelle répond le scan de travail de FTE TO AI, qui calcule, tâche par tâche, quelle part se prête à une reprise.
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.