Une classification d'une application d'IA décrit une situation à un moment donné : quel modèle, quelle application, quels utilisateurs, quel risque. Cette situation évolue. Un fournisseur modifie un modèle, une équipe utilise un outil pour autre chose que ce pour quoi il a été acquis, un prestataire ajoute une fonction sans que personne n'en demande l'autorisation. La classification que vous avez établie l'année dernière ne décrit donc pas automatiquement encore la situation d'aujourd'hui.
La question "à quelle fréquence" n'a pas de réponse fixe valable pour chaque organisation. Cela dépend du nombre d'applications d'IA existantes, de la vitesse à laquelle elles évoluent, de la diversité des équipes qui les utilisent, et de la rigueur du contrôle exercé sur le secteur dans lequel vous opérez. Un moment fixe annuel constitue un point de départ, pas une garantie que rien ne vous échappe entre-temps.
Un recalibrage annuel ou semestriel fonctionne bien pour les applications que vous connaissez déjà et qui sont entrées par une voie formelle. Pour les applications que personne n'a signalées, un intervalle fixe ne fonctionne pas, tout simplement parce qu'il n'y a rien à réévaluer à une date fixe. Que faites-vous des collaborateurs qui utilisent un outil que personne n'a approuvé décrit pourquoi cette question ne se résout pas avec un rendez-vous récurrent dans l'agenda, mais avec une autre façon d'interroger l'organisation.
Par ailleurs, le risque évolue non seulement en fonction de ce que fait une application, mais aussi de ce dont on l'alimente. Une fenêtre de chat utilisée aujourd'hui pour résumer un texte public peut demain être utilisée pour résumer un contrat. Que faites-vous des données de l'entreprise dans une fenêtre de chat gratuite montre que le niveau de risque d'un même outil peut évoluer sans que l'outil lui-même ne change.
Outre un moment fixe, certains événements appellent un recalibrage intermédiaire. Un changement dans la fonction d'une application, un élargissement du groupe d'utilisateurs, un incident ou un near-miss, une modification des conditions du fournisseur, ou un signal d'un collaborateur indiquant qu'un usage diffère de l'usage prévu. Ces signaux n'ont pas tous le même poids, et toutes les organisations ne les remarqueront pas aussi rapidement.
La question de savoir qui réagit à ces signaux, et qui assume la responsabilité du recalibrage lui-même, est une question distincte. Qui est responsable en cas d'erreur d'une application d'IA décrit que la responsabilité n'est souvent établie qu'au moment où quelque chose se passe mal, alors que cette question aurait déjà dû trouver réponse dès la première classification.
Un rythme de recalibrage placé à côté des processus de risque existants, sans y être intégré, perd généralement en priorité en moins d'un an. C'est une étape supplémentaire que personne ne demande jusqu'à ce que quelque chose aille mal, et c'est précisément pour cette raison qu'elle reste en suspens. Pourquoi un second processus à côté de l'existant est ignoré explique pourquoi le recalibrage fonctionne plus efficacement lorsqu'il est intégré à la gestion des risques existante, plutôt que comme un parcours distinct qui doit rivaliser pour l'attention avec le reste de l'organisation.
Une méthode de classification peut offrir une structure permettant d'évaluer de façon cohérente les applications d'IA selon leur rôle et leur niveau de risque, et cette structure peut être appliquée de manière répétable. Ce que la méthode ne peut pas faire, c'est garantir que vous voyez tout. Une classification n'est aussi bonne que l'information qui la sous-tend, et cette information provient en partie de personnes qui peuvent avoir une raison de ne pas signaler quelque chose. Un collaborateur qui utilise un outil non approuvé ne le signale pas spontanément s'il s'attend à une sanction.
La méthode ne peut pas non plus prédire quand un fournisseur modifiera un modèle, ou quand une application à faible risque aujourd'hui sera utilisée différemment demain. Le recalibrage reste donc une question de répétition et d'organisation de la transparence, et non d'un système mis en place une fois pour toutes qui reste ensuite actuel de manière autonome. La manière de tenir ce registre à jour sans qu'il ne redevienne obsolète après quelques mois est décrite dans comment tenir un registre d'IA à jour, qui met au centre la distinction entre un inventaire ponctuel et un processus continu.
S'y ajoute la question de ce que signifie concrètement le contrôle de l'IA entre les moments de recalibrage : qui surveille, à quelle fréquence, et sur la base de quels signaux. Qu'est-ce que le contrôle humain en pratique établit cette distinction entre le contrôle conçu comme une case formelle à cocher et le contrôle conçu comme un accompagnement continu de l'usage.
Une classification vous indique quelles applications existent, quel rôle elles jouent et quel niveau de risque leur correspond. Cette classification ne vous indique pas quelle part du travail est effectivement réalisée par l'IA, ni quelle marge subsiste encore par tâche. Qui souhaite répondre à cette question ne peut se contenter d'un inventaire des risques ; cela nécessite un regard sur le travail lui-même, tâche par tâche. Le scan de travail de FTE TO AI calcule, par tâche, quelle part de celle-ci peut être reprise par l'IA, en complément de l'image que fournit une 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.