La plupart des organisations disposent désormais d'une politique d'IA. Souvent, elle est bien rédigée, juridiquement solide et complète. Et souvent, elle n'est pas lue, ou lue le jour où elle est adoptée et plus jamais après. Ce n'est pas une question de mauvaise volonté. C'est une question de place dans le processus.
Les collaborateurs qui travaillent avec l'IA ont déjà un processus : le travail lui-même. Une politique d'IA qui se trouve à côté de ce travail, comme un document séparé qu'on consulte, entre en concurrence avec le temps que la personne n'a déjà pas. Celui qui doit rédiger un texte, analyser un ensemble de données ou répondre à une question client ne va pas d'abord consulter la politique. Il utilise l'outil qui fonctionne, et n'y pense que lorsque quelqu'un le lui demande.
La conséquence est prévisible. Une pratique se développe qui s'écarte du document, sans que personne n'ait de mauvaises intentions. Personne n'a ignoré la politique par mauvaise volonté ; elle ne correspondait simplement pas au moment où le choix a été fait. Une politique qui veut être lue ne doit donc pas se trouver à côté du travail, mais dedans. Cela signifie qu'elle répond aux questions qui se posent déjà — quel outil est autorisé ici, qui est responsable si cela se passe mal, que se passe-t-il avec le résultat — au moment où cette question se pose, pas trois chapitres plus loin dans un pdf.
Une politique d'IA qui fonctionne dans la pratique contient en son cœur quelques éléments reconnaissables. Premièrement, une classification par risque : chaque application de l'IA ne demande pas la même attention, et un document qui met tout dans le même sac n'est pris au sérieux par personne. Deuxièmement, une réponse claire à la question de savoir qui décide lorsqu'un cas ne correspond pas à la classification — cela relève d'une liste de décisions de supervision qui établit qui est responsable de quoi, plutôt que d'une note de bas de page que personne ne retrouve.
Troisièmement, une voie pour ce qui se passe lorsque quelque chose se passe mal ou est douteux : des chemins d'escalade qui fonctionnent décrivent qui l'on appelle, pas qui l'on devrait en théorie informer. Une politique sans escalade fonctionnelle est une politique qui n'est lue qu'après l'incident, et il est alors trop tard pour encore orienter quoi que ce soit.
Quatrièmement, une forme de suivi qui ne s'arrête pas à l'adoption. Une politique rédigée une seule fois et jamais réévaluée par la suite vieillit plus vite que la pratique qu'elle doit couvrir. Un suivi qui produit des résultats n'est pas une charge de reporting supplémentaire, mais le mécanisme par lequel la politique reste en phase avec ce qui se passe réellement.
Une idée fausse répandue est que la politique d'IA a besoin d'un nouveau cadre de gouvernance. Ce n'est généralement pas le cas. La plupart des organisations disposent déjà d'une structure de risque — pour la protection des données, pour les risques financiers, pour la continuité opérationnelle. Le risque lié à l'IA s'y intègre dans la plupart des cas, comme catégorie supplémentaire ou question supplémentaire au sein des lignes de décision existantes, et non comme circuit séparé avec ses propres réunions et ses propres lignes de reporting. S'aligner sur la structure de risque existante est précisément pour cette raison souvent plus efficace que de mettre en place un nouveau cadre : les gens connaissent déjà le processus, et n'ont pas besoin d'apprendre où se trouve le nouveau document.
Cet alignement est aussi là où, en pratique, cela échoue ou réussit. Une politique qui, sur papier, s'aligne bien mais qui reste dans la pratique un document isolé, est tout autant ignorée. La question n'est pas seulement ce que contient le document, mais comment il s'intègre dans ce que les gens font déjà — structures de réunion, flux d'approbation, moments de reporting qui existaient déjà avant que l'IA ne devienne un sujet. La forme concrète que cela prend dépend de la manière dont l'organisation fonctionne déjà aujourd'hui, et ceci est développé plus en détail dans ce qui est décrit sur la manière dont une telle politique s'intègre dans ce qui existe déjà.
Une politique qui fonctionne se résume aussi en quelques phrases pour ceux qui n'y travaillent pas quotidiennement. Un conseil d'administration n'a pas besoin du document complet, mais d'une réponse à la question de savoir si la situation est sous contrôle et où elle ne l'est pas. Un rapport d'une page pour le conseil d'administration est le test qui indique si la politique fonctionne : si elle ne peut pas être résumée en une page, elle n'est probablement pas non plus applicable dans la pratique.
Une politique qui s'aligne sur la pratique suppose que vous savez ce qu'est cette pratique : quelles tâches sont effectuées, et quelle part de celles-ci est déjà exécutée par l'IA ou pourrait l'être. C'est une question différente de la gouvernance, et c'est à cette question que répond le scan de travail de FTE TO AI : il calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA, afin que la politique ne repose pas sur des suppositions mais sur une image concrète du travail lui-même.
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.