La question de savoir si une application d'IA au sein de votre organisation est considérée comme à haut risque n'est pas une question à laquelle vous répondez une fois pour toutes et que vous cochez ensuite. C'est le résultat d'un ensemble de facteurs qui déterminent ensemble le poids d'une application. Si l'un de ces facteurs change, la classification peut également changer. Cela fait de la classification des risques moins une question de remplissage de formulaire et davantage une question de suivi continu.
Cette page décrit le mécanisme derrière cette classification : de quoi elle dépend, et ce qui se passe lorsque la situation évolue. Les définitions légales et les seuils en vigueur se trouvent ailleurs ; ici, il s'agit de ce que vous devez pouvoir observer et démontrer au sein de votre propre organisation.
Un certain nombre de facteurs jouent structurellement un rôle dans la question de savoir si une application est lourde de conséquences.
Le premier est le domaine dans lequel l'application est déployée. Certains domaines — pensez aux décisions concernant des personnes, leurs opportunités ou leurs droits — pèsent plus lourd que les applications purement internes et de soutien. Ce que fait précisément l'application au sein de ce domaine fait également une différence : un système qui conseille pèse différemment d'un système qui décide automatiquement.
Le deuxième facteur est le rôle que joue votre organisation par rapport au système. Le construisez-vous vous-même, l'achetez-vous, ou utilisez-vous un service dans lequel de l'IA est intégrée sans que vous l'ayez acheté en tant que telle ? Le rôle que vous occupez — fournisseur ou utilisateur — déterminera en partie quelles obligations vous incombent et quelle part de la responsabilité reste chez un fournisseur.
Le troisième facteur est ce qui se passe avec le modèle après le premier déploiement. Un système utilisé sans modification, tel qu'il a été livré, est une situation différente d'un système que vous affinez, reconfigurez ou faites apprendre sur vos propres données. Ce qui change lorsque vous adaptez vous-même un modèle est donc une question à laquelle il faut répondre séparément — une adaptation peut faire basculer un système d'une catégorie à l'autre.
Le quatrième facteur est la portée : combien de personnes sont concernées, à quelle fréquence, et dans quelle mesure une erreur est-elle réversible. Une application utilisée occasionnellement par une petite équipe pèse différemment d'une application qui influence quotidiennement des décisions pour des milliers de clients.
Ces facteurs ne sont pas statiques. Une application considérée aujourd'hui comme à risque limité peut ne plus l'être demain — non pas parce que les règles ont changé, mais parce que l'application elle-même a changé. Un projet pilote qui s'étend à l'ensemble de l'organisation, un outil interne qui commence à toucher un processus client, un modèle réentraîné sur de nouvelles données : chacune de ces étapes peut faire basculer la classification.
Cela signifie que la classification n'est pas un exercice ponctuel. C'est une question qui doit être reposée chaque fois que quelque chose change dans ce que fait un système, qui il touche, ou qui le gère. Une structure de gouvernance qui ne suit pas cela est en retard sur la pratique.
Toutes les applications d'IA ne doivent pas nécessairement passer par ce parcours complet. Une partie de ce qui fonctionne au sein d'une organisation se situe hors du champ de la classification des risques — par exemple parce que cela ne touche pas de décisions concernant des personnes ou parce que cela n'a qu'une fonction de soutien, non déterminante. L'endroit exact où se situe cette limite et quelles applications sont hors champ dépend des mêmes facteurs décrits ci-dessus : domaine, rôle, adaptation et portée. Ce n'est donc pas une liste distincte, mais l'autre face de la même évaluation.
Une classification en elle-même ne change rien. Elle détermine seulement quelles étapes suivantes sont à l'ordre du jour, et avec quelle urgence. Certaines actions sont immédiatement nécessaires, d'autres peuvent être planifiées — et ce qui doit se passer maintenant et ce qui peut être planifié dépend à son tour du poids de l'application et du nombre de personnes qu'elle touche.
Pour rendre ces étapes visibles et traçables, les décisions relatives à la classification et aux actions à suivre doivent être consignées quelque part — non pas sous forme de notes isolées, mais dans le cadre d'un registre des décisions de supervision qui montre qui a décidé quoi et sur la base de quelles informations. Sans cette consignation, une classification n'est qu'un instantané que plus personne ne peut reconstituer.
Cette question de classification ne peut être correctement résolue que si l'on sait ce qui fonctionne réellement. Une liste informatique d'outils approuvés ne suffit pas à cet effet : une grande partie de l'usage naît en dehors de cette liste, dans des équipes qui ont commencé à utiliser un outil sans le signaler nulle part. Quiconque souhaite cartographier cet usage doit poser la question — et le faire uniquement sans qu'il y ait de sanction à la clé, sinon la réponse ne viendra pas.
Dès qu'il est clair quelles applications existent et quel est leur poids, une question suivante se pose, qui ne porte plus sur le risque mais sur le travail : quelle part d'une tâche un système d'IA peut-il reprendre, et quelle part reste du travail humain. C'est à cette question que répond le scan de travail de FTE TO AI, qui calcule par tâche quelle part du travail peut être reprise — un angle différent de la classification des risques, mais qui s'appuie sur le même inventaire.
Cette page décrit le mécanisme derrière la classification. Le Responsible AI Scan lui-même est en cours de développement ; ceux qui souhaitent utiliser ses résultats dès qu'ils seront disponibles peuvent s'inscrire sur la liste d'attente.
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.