De nombreuses organisations partent du principe que leur rôle est fixe : elles sont utilisatrices d'un système construit par un fournisseur, et les obligations qui en découlent sont claires et durables. Cette hypothèse est souvent correcte, mais pas toujours. Le rôle qu'une organisation occupe à l'égard d'un système d'IA n'est pas une étiquette figée. C'est le résultat de ce qui se passe effectivement avec le système, et ce résultat peut évoluer sans qu'un nouveau contrat soit signé ou qu'un nouvel achat soit effectué.
La classification d'un rôle dépend d'un certain nombre d'éléments factuels, et non de la façon dont un fournisseur nomme le système ou dont un service interne le positionne en interne. Sont notamment pertinents : qui a mis le système sur le marché, qui utilise effectivement le système dans le cadre de son propre processus, et qui a modifié le système après sa livraison. Compte également sous quel nom le système est présenté au public, et si une organisation redistribue le système à d'autres sans l'utiliser elle-même. Ces éléments déterminent ensemble si une organisation agit en tant que fournisseur, en tant qu'utilisateur, ou en tant que partie se situant entre les deux.
La raison pour laquelle cela est pertinent pour la gouvernance, est que le rôle déterminé fixe quelles obligations incombent à quelle partie. Une organisation qui n'est qu'utilisatrice a des responsabilités différentes de celles d'une organisation qui agit effectivement en tant que fournisseur. Ce qui est précisément attendu de chaque rôle est décrit ailleurs ; il s'agit ici du mécanisme qui déterminé quel rôle s'applique, et de la détection du moment où ce mécanisme donne un résultat différent d'auparavant.
Un rôle n'est pas lié à un système pour toute sa durée de vie. Il est lié à ce qui se passe effectivement à un moment donné. Cela signifie que la même organisation peut, pour le même système, relever d'un rôle différent à deux moments distincts. Quelques situations où cela se produit : une équipe qui affine (fine-tune) un modèle acheté avec ses propres données, un service qui reconditionne un système et le propose sous son propre nom à d'autres services, ou une organisation qui redistribue à un client ou un partenaire un système initialement destiné à un usage interne. Dans chacun de ces cas, le rôle effectif se déplace, même si peu de choses changent en apparence.
Ce qui change en pratique n'est pas abstrait. Cela déterminé qui est responsable de la documentation, qui doit démontrer qu'un système fait ce qu'il prétend faire, et qui doit réagir en cas de problème. Vous trouverez davantage d'informations sur ce qui change précisément lorsqu'un modèle est modifié sur la page consacrée aux modifications d'un modèle. Ce glissement est l'un des exemples les plus clairs de la façon dont un rôle bascule sans qu'une décision consciente ne le précède.
La raison pour laquelle ce sujet est pertinent non seulement sur le plan juridique, mais aussi sur le plan organisationnel, est qu'un changement de rôle passe souvent inaperçu. Une équipe qui modifie un modèle pense à une amélioration technique, pas à un changement de responsabilité. Un service qui transmet un outil à un autre service pense à la commodité, pas à un nouveau rôle de fournisseur. Une gouvernance qui ne regarde que ce qui a été acheté manque systématiquement ces glissements.
Cela est lié à la question de savoir quelles applications relèvent précisément d'une réglementation et lesquelles n'en relèvent pas ; cette limite est traitée sur la page consacrée au champ d'application des applications. Un système qui se situait hors du champ d'application lors de son achat peut y entrer dès que le rôle de l'organisation évolue. Cela signifie qu'une évaluation unique lors de l'achat ne suffit pas ; l'évaluation doit évoluer avec ce qui se passe effectivement avec un système.
Le niveau de risque d'une application peut également évoluer avec un changement de rôle. Ce que signifie précisément un niveau de risque élevé pour les obligations d'une organisation, et de quoi cela dépend, est expliqué sur la page consacrée aux conséquences d'un niveau de risque élevé. Une organisation qui, en raison d'un changement de rôle, est soudain considérée comme fournisseur d'un système à niveau de risque élevé, porte des responsabilités différentes de celles qu'elle avait lorsqu'elle n'était qu'utilisatrice de ce même système.
Pour détecter les changements de rôle avant qu'ils ne deviennent un problème, une organisation doit savoir quels systèmes existent, qui les modifie, et qui les transmet à qui. Cela nécessite un inventaire allant au-delà de la liste approuvée par l'IT, ainsi qu'un emplacement fixe où sont consignées les décisions relatives aux modifications, transmissions et reconditionnements. Un tel emplacement fixe, ainsi que les questions qui s'y rattachent, sont décrits sur la page consacrée à une liste de décisions de supervision.
Le Responsible AI Scan est conçu pour rendre visibles ces glissements : quels systèmes fonctionnent effectivement, qui les utilise, qui les a modifiés, et quel rôle en découle à ce moment précis. L'outil qui soutient cette démarche est en cours de développement ; toute personne souhaitant l'utiliser peut s'inscrire sur la liste d'attente.
Un changement de rôle ne concerne pas uniquement la gouvernance. Lorsqu'un système passe d'un simple outil ponctuel à quelque chose qui reprend structurellement une partie d'une tâche, la question de savoir quelle part du travail ce système effectue réellement et quelle part reste encore aux mains des personnes évolue également. Le werkscan de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, rendant ainsi visible où un changement de rôle en matière de gouvernance coïncide avec un glissement effectif dans la répartition du travail.
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.