Dans de nombreuses organisations existe une liste fixe d'applications qui seraient « hors champ d'application ». Une suggestion de texte dans un traitement de texte, un filtre anti-spam, un chatbot qui répond uniquement sur la base d'une FAQ fixe. L'hypothèse est que ces applications sont trop petites, trop anciennes ou trop anodines pour relever de la gouvernance. Cette hypothèse est parfois correcte. Elle ne l'est pas toujours, et elle l'est rarement de façon durable.
Qu'une chose soit hors champ d'application n'est pas une caractéristique de la technologie. C'est une classification qui découle de ce que le système fait, pour qui, et avec quel effet en cas d'erreur. La même suggestion de texte qui est aujourd'hui hors champ d'application parce qu'elle ne propose qu'un mot à un employé, peut demain entrer dans le champ d'application dès qu'elle finalise et envoie automatiquement des e-mails sans intervention.
Trois facteurs déterminent ensemble si une application relève ou non du champ d'application.
Le premier est la fonction : le système prend-il une décision, ou fournit-il seulement une information qu'un humain évalue ? Un outil qui classe des candidats se situe plus près du champ d'application qu'un outil qui rend seulement des CV consultables. La place exacte d'une application sur ce spectre, et pourquoi, est expliquée dans l'analyse de ce que signifie un niveau de risque élevé pour votre organisation.
Le deuxième est le rôle de l'organisation elle-même. Celui qui achète un système et l'utilise sans modification est dans une situation différente de celui qui le construit, l'entraîne ou l'adapte lui-même. Cette même application peut être hors champ d'application pour une organisation et pas pour une autre, uniquement en fonction de qui porte quelle responsabilité. Cette répartition est développée dans la question de savoir si vous êtes fournisseur ou utilisateur, et change dès qu'une personne au sein de l'organisation adapte ou réentraîne un modèle, comme décrit dans ce qui change lorsque vous adaptez vous-même un modèle.
Le troisième facteur est le temps. Un système qui est actuellement hors champ d'application peut ne plus l'être un an plus tard, non pas parce que les règles ont changé, mais parce que l'usage a évolué. Un chatbot qui a commencé comme source d'information peut évoluer vers un système qui traite des réclamations. Le rôle d'une équipe ou d'un service par rapport à un tel système évolue alors en conséquence, et le moment où cela se produit est décrit dans quand votre rôle change et de quoi cela dépend.
La conséquence de ces trois facteurs est que « hors champ d'application » n'est jamais un statut permanent. C'est un instantané qui doit être réexaminé dès que la fonction d'un système change, dès que l'organisation obtient un rôle différent par rapport à ce système, ou dès que l'usage s'étend à quelque chose qui n'était pas prévu lors de l'acquisition.
C'est précisément là que l'IA fantôme perturbe la classification. Une application notée « hors champ d'application » sur la liste informatique peut, en pratique, être utilisée d'une manière qui ne correspond plus à cette classification. Une équipe qui déploie un modèle de langage pour rédiger des brouillons de communication client peut aussi l'utiliser pour envoyer des réponses définitives sans le signaler. La classification sur papier et l'usage en pratique divergent alors, et personne qui ne regarde que les licences achetées ne voit cette différence.
Le seul moyen d'y voir clair est de poser des questions. Pas à un système, mais aux personnes qui l'utilisent. Cela ne fonctionne que si poser des questions n'équivaut pas à sanctionner : qui craint des conséquences adapte sa réponse ou n'en donne pas. Une classification qui repose exclusivement sur les licences achetées manque donc systématiquement les applications nées d'un usage pratique, et ce sont souvent précisément les applications dont plus personne ne sait si elles sont encore hors champ d'application ou si elles y sont désormais bien ancrées.
La question « ceci est-il hors champ d'application » ne peut donc pas être répondue indépendamment de la question de ce qui se passe exactement, qui en décide, et depuis combien de temps cette situation existe. Un inventaire qui consigne ces trois facteurs par application donne une classification qui correspond à la situation réelle plutôt qu'à l'hypothèse avec laquelle un système a été acquis autrefois. Ce qui nécessite déjà de l'attention maintenant et ce qui peut être planifié tranquillement dépend des mêmes facteurs et est traité dans la distinction entre ce qui doit être fait maintenant et ce qui peut être planifié.
Dès qu'il est clair quelles applications relèvent du champ d'application et quel rôle joue votre organisation à cet égard, une question suivante se pose, qui ne porte pas sur la gouvernance mais sur le travail : quelle partie d'une tâche est en réalité reprise par une telle application, et quelle partie reste un travail humain ? Le scan de gouvernance ne répond pas à cette question. C'est à cela que sert le scan de travail de FTE TO AI, qui calcule pour chaque tâche quelle partie du travail peut être reprise par l'IA, offrant ainsi une image de l'engagement qui se cache derrière la classification.
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.