Un responsable de la conformité ne perd pas à la première question sur l'IA. Il perd à la deuxième : lorsqu'il s'avère que la réponse à la première question était incomplète. « Quels systèmes d'IA votre organisation utilise-t-elle » peut se répondre par une liste tirée du portefeuille informatique. La question qui suit — « est-ce bien la liste complète » — est celle sur laquelle échouent la plupart des dossiers de conformité.
Pas : quels outils d'IA l'organisation a-t-elle acquis. Mais : quels systèmes d'IA sont réellement utilisés, par qui, pour quelles décisions, et sur la base de quelle évaluation des risques. Ce sont quatre questions, pas une seule. La première est une liste d'achats. Les trois autres exigent que les personnes racontent ce qu'elles font, y compris ce qu'elles n'ont pas fait valider. Un responsable de la conformité qui ne dispose que de la liste d'achats a un faux sentiment de couverture — et c'est plus risqué qu'une absence de couverture, car cela est rapporté comme étant complet.
Les collaborateurs qui utilisent un outil de langage ou d'analyse sans passer par un achat via l'informatique n'en laissent aucune trace dans un registre d'actifs. Ils en laissent en revanche une trace dans ce qu'ils produisent : rapports, communications avec les clients, avis. L'écart entre ce qui est enregistré et ce qui est utilisé n'est généralement pas une infraction délibérée. C'est le résultat d'une organisation qui trouve un outil plus vite qu'elle ne parcourt une procédure d'approbation. La conformité ne peut pas combler cet écart par une interdiction plus stricte — cela ne fait que déplacer l'usage plus loin des regards. On comble cet écart en posant la question sans qu'une sanction pèse sur la réponse. Celui qui craint une note dans son dossier ne dit pas ce qu'il utilise ; il dit ce qu'il pense que vous voulez entendre.
Un gestionnaire des risques veut savoir quelle est l'ampleur de l'exposition. Un responsable de la conformité veut cela, plus quelque chose de supplémentaire : puis-je démontrer que nous avons suivi le processus, même si le résultat s'avère par la suite discutable. C'est un autre type de charge de la preuve. Il ne s'agit pas seulement de la classification d'un système, mais de la trace : qui a évalué cela, à quel moment, avec quelles informations, et cette évaluation a-t-elle été répétée lorsque le système a changé. Les systèmes d'IA sont mis à jour sans préavis ; une classification datant d'il y a six mois ne dit que peu de chose sur le système d'aujourd'hui. La conformité doit donc pouvoir montrer non seulement un résultat, mais un processus qui continue de fonctionner.
« Nous avons une politique IA » n'est pas une réponse à la question de savoir si cette politique couvre quelque chose. Un document de politique qui n'a jamais été confronté à ce qui est réellement utilisé est une déclaration d'intention, pas une déclaration de situation. Ce dont un responsable de la conformité a besoin, c'est d'un inventaire qui s'articule avec les catégories de risque existantes — la même classification déjà utilisée pour d'autres risques opérationnels — afin que l'IA ne se présente pas comme un sujet séparé, exotique, à côté du reste du cadre de gestion des risques, mais bien à l'intérieur de celui-ci.
Le responsable de la conformité travaille rarement seul sur ce sujet. La question de savoir quels systèmes sont considérés comme à haut risque et quelle charge de la preuve y est associée touche à ce que un General Counsel doit savoir sur le risque IA sous l'angle de la responsabilité et des obligations contractuelles. La question de savoir si l'organisation peut techniquement retracer quels systèmes sont en service relève de ce qu'un CIO doit savoir sur le risque IA. Et la question de savoir si ce sujet parvient jusqu'à la table du conseil d'administration avant qu'il n'escalade relève de ce qu'un administrateur doit savoir sur le risque IA. La conformité est souvent la partie qui doit réunir ces trois lignes sans être elle-même propriétaire de la technologie ou du contrat.
Le contenu réglementaire — quelles obligations s'appliquent précisément, par catégorie de risque, avec quels délais — se trouve ailleurs et évolue. Cette page décrit le mécanisme : comment savoir ce qui est en service, comment le classifier, et comment démontrer que le processus a été suivi. Un responsable de la conformité à la recherche du texte de loi actuel ne le trouvera pas ici.
La quantité d'IA de l'ombre que possède une organisation dépend du secteur, de la culture et de la rigueur avec laquelle les interdictions précédentes ont été appliquées. Une interdiction plus stricte est souvent corrélée à davantage d'usage caché, pas à moins. Ce schéma n'est pas identique partout : dans le secteur de la construction, le centre de gravité se situe au niveau du calcul de projet et de la planification, tandis que dans le secteur de l'installation technique, il s'agit plus souvent de diagnostic de maintenance et d'analyse de pannes. L'inventaire doit donc se faire par organisation ; une moyenne nationale ne dit que peu de chose sur votre propre exposition.
Le Responsible AI Scan cartographie ce qui est réellement utilisé, le classifie par rôle et par niveau de risque, et fournit un ensemble de gouvernance qui s'articule avec la structure de risque existante — sans pour autant anticiper sur ce qui est déjà fixé ailleurs. Ce scan est en cours de développement. Toute personne intéressée peut s'inscrire sur la liste d'attente ; rien n'est proposé qui ne soit pas encore achevé.
Une fois que l'on sait quels systèmes d'IA sont en service, la question suivante se pose souvent : qu'est-ce que cela signifie pour les effectifs et la répartition des tâches. C'est un autre calcul que la classification des risques, et c'est celui que fait FTE TO AI avec le werkscan, qui calcule par tâche quelle part du travail peut être reprise par l'IA.
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.