La surveillance humaine est souvent consignée comme un rôle : quelqu'un qui est responsable, un nom dans un registre, une case cochée. C'est le point de départ, pas le mécanisme en lui-même. La surveillance ne naît que lorsqu'il existe un moment où un humain peut voir le résultat d'une application d'IA, le comprendre et le corriger avant que ce résultat n'aboutisse quelque part. Sans ce moment, le nom sous la classification n'est qu'une formalité.
Le fonctionnement effectif de la surveillance dépend de plusieurs éléments qui ne se rassemblent pas spontanément. Il faut quelqu'un qui ait l'autorité de bloquer un résultat, pas seulement la tâche de l'examiner. Il faut du temps pour l'examiner, ce qui signifie que le processus ne doit pas être conçu de telle manière que le résultat de l'IA soit déjà traité avant que le contrôle n'ait lieu. Et il faut une compréhension suffisante de ce que fait l'application pour pouvoir reconnaître un écart. Un contrôleur qui ne peut pas évaluer le résultat n'exerce aucune surveillance, même si le rôle lui a été formellement attribué.
Cela rejoint ce que signifie la maîtrise de l'IA pour vos collaborateurs : une surveillance sans compréhension de l'application sous-jacente n'est qu'une surveillance sur papier.
Une structure de gouvernance peut consigner qui est responsable de quoi, quel niveau de risque présente une application et quelles étapes en découlent. Ce que la structure ne fait pas, c'est garantir que cette personne évalue effectivement le résultat au moment où cela compte. C'est une donnée organisationnelle, pas une donnée technique. Une classification peut être correcte et la surveillance peut malgré tout être vide, parce que la personne responsable sur papier n'a pas le temps, l'accès ou les connaissances nécessaires pour vérifier le résultat.
L'inventaire et la classification révèlent où ce risque est le plus élevé : pour les applications présentant un niveau de risque plus élevé, ou pour les applications entrées en dehors du circuit informatique habituel. Ce dernier groupe est souvent le plus difficile à gérer, car quiconque veut organiser une surveillance sur quelque chose qui ne figure pas dans les registres doit d'abord le trouver. Cela touche à la question de ce que vous faites avec les collaborateurs qui utilisent un outil que personne n'a approuvé : la surveillance de l'IA fantôme commence par reconnaître que cette application existe, pas par une sanction de son utilisation.
Une application sous surveillance aujourd'hui peut avoir changé demain. Un modèle est mis à jour, les données d'entrée évoluent, ou l'usage au sein de l'organisation passe d'une tâche simple à quelque chose de plus lourd. Une surveillance conçue pour la situation d'il y a un an ne correspond plus à ce qui se passe aujourd'hui. C'est l'une des raisons pour lesquelles la classification n'est pas un exercice ponctuel ; la fréquence à laquelle cela doit être refait dépend du niveau de risque et du degré d'évolution de l'application, comme développé dans à quelle fréquence vous devez reclassifier.
Cela signifie aussi qu'un registre n'a de valeur que s'il est entretenu. Un inventaire établi lors du premier scan et jamais mis à jour par la suite donne une image de moins en moins précise des endroits où une surveillance est nécessaire. La question de savoir comment une organisation maintient ce registre à jour est distincte de celle de savoir comment le registre a été constitué, et mérite une attention propre : voir comment tenir un registre d'IA à jour.
Un conseil d'administration auquel on demande de démontrer qu'il existe une surveillance sur l'usage de l'IA ne peut se contenter d'une liste de rôles. La démontrabilité exige une trace : qui a examiné quel résultat, à quel moment, avec quelle autorité pour intervenir. Cette trace est également pertinente au moment où quelque chose se passe mal. La question de savoir qui est responsable lorsqu'une application d'IA commet une erreur ne trouve pas sa réponse dans la seule classification, mais dans la surveillance démontrable qui l'a suivie. Ces deux éléments sont facilement confondus, alors que la distinction est pertinente ; voir qui est responsable lorsqu'une application d'IA commet une erreur.
La surveillance touche aussi à ce qui est introduit dans une application. Un collaborateur qui colle des données de l'entreprise dans une fenêtre de chat gratuite place ces données hors de toute surveillance mise en place par l'organisation, quelle que soit la qualité de l'organisation de la surveillance sur les applications approuvées. C'est un domaine d'attention distinct au sein de cette problématique plus large, développé dans ce que vous faites avec des données d'entreprise dans une fenêtre de chat gratuite.
Cette page décrit le fonctionnement de la surveillance comme mécanisme : qui regarde, quand, avec quelle autorité, et comment cela se démontre. Les normes de fond qui déterminent quand la surveillance est obligatoire, à quel point elle doit être stricte selon la catégorie de risque, et dans quels délais elle doit être mise en place, ne figurent pas ici. Ce contenu réglementaire évolue et est tenu à jour ailleurs.
Organiser une surveillance sur une tâche n'a de sens que si l'on sait précisément en quoi consiste cette tâche et quelle part en est prise en charge par une application d'IA. C'est une question différente de celle du rôle ou du niveau de risque d'une application ; il s'agit de la tâche elle-même, décomposée en étapes qu'une application d'IA peut reprendre et en étapes qui ne s'y prêtent pas. Le scan de travail de FTE TO AI calcule cela par tâche, afin de rendre visible quelle part du travail peut être reprise et quelle part doit rester dans le champ de la surveillance humaine.
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.