Il existe souvent déjà un document intitulé procédure d'escalade. On y trouve un schéma avec des flèches, une liste de noms, et quelques seuils. Le problème n'est pas que le document manque. Le problème est que personne ne l'ouvre au moment où il est nécessaire.
Cela ne se produit pas par mauvaise volonté. Cela se produit parce qu'il existe déjà un chemin par lequel les problèmes remontent : le manager de ligne qui signale l'incident IT, le compliance officer qui parle avec le business, le team lead qui pose son problème auprès de son propre supérieur. Ce chemin existe, est utilisé quotidiennement, et fonctionne — pour les choses pour lesquelles il est prévu. Un nouveau chemin d'escalade spécifique aux incidents IA devient alors une deuxième route à côté d'une route qui fonctionne déjà. En cas de doute, chacun choisit la route qu'il connaît.
Un chemin d'escalade dissocié de la structure existante demande au collaborateur de d'abord reconnaître qu'il s'agit d'un incident IA, puis de se rappeler qu'un autre processus s'applique dans ce cas, et enfin de prendre la peine de suivre ce processus plutôt que d'appeler simplement son supérieur. Chaque étape de cette chaîne est un moment où le chemin est abandonné.
S'ajoute à cela une deuxième raison, moins visible mais tout aussi déterminante : celui qui signale un écart ne veut pas se retrouver immédiatement sur le formulaire d'incident de l'organisation. Si escalader équivaut à être sanctionné, on n'escalade pas. Cela vaut pour un collaborateur qui a utilisé un outil IA non approuvé, et cela vaut pour un manager qui a fait fonctionner un modèle sans que personne ne le sache. Un chemin d'escalade réellement utilisé est un chemin où le premier signalement n'est pas un jugement, mais un signal.
Un chemin d'escalade qui fonctionne décrit trois choses, et pas plus.
Celui qui constate quelque chose — un collaborateur, un client, un tiers externe — doit savoir à qui s'adresser sans devoir d'abord déterminer s'il s'agit d'une question liée à l'IA ou d'une question opérationnelle ordinaire. Le chemin s'articule avec le point de contact qui existe déjà, avec une ramification supplémentaire au moment où il s'avère que l'IA est concernée.
Celui qui prend la décision — de stopper quelque chose, de l'adapter, ou de le signaler à une autorité de contrôle — doit être fixé avant que l'incident ne se produise. Pas comme un titre de fonction abstrait, mais comme un nom, avec un remplaçant. Une escalade qui s'arrête devant un mandat vide n'est pas une escalade.
Ce qui se passe ensuite pour la personne qui signale doit être clair. Si un deuxième processus consiste uniquement en une obligation de signalement sans clarté sur les conséquences pour celui qui signale, il sera évité. C'est précisément là que se cache l'IA fantôme : non pas dans les systèmes que connaît l'IT, mais dans les outils que quelqu'un a commencé à utiliser sans le signaler, parce que signaler avait l'impression d'avouer.
La solution n'est pas un document plus épais. C'est un chemin d'escalade qui utilise la structure déjà existante — le point de contact, la ligne d'escalade, le comité des risques — et y ajoute une ramification spécifique à l'IA aux points où cela fait une différence. La manière précise dont cet alignement fonctionne, y compris pour la politique plus large et la liste des décisions de l'organe de surveillance, est décrite dans comment obtenir une politique IA qui est lue parce qu'elle est intégrée dans l'existant et dans comment obtenir une liste des décisions d'oversight qui s'aligne sur le rythme de décision existant. Ces deux documents touchent le même point : un processus qui se trouve à côté de l'organisation est ignoré ; un processus qui s'y intègre est suivi.
Ce principe ne vaut pas uniquement pour l'escalade. Il vaut pour toute la structure de gouvernance autour de l'IA. Qui souhaite savoir à quoi cela ressemble plus largement — comment la classification des risques s'articule avec les catégories de risque existantes, comment s'aligner sur la structure de risque existante évite qu'une bureaucratie parallèle ne se crée — y trouvera le principe sous-jacent. Il en va de même pour le reporting vers le haut : un reporting au board d'une page ne fonctionne que si les escalades qu'il contient ont effectivement été signalées. Et sans observation continue de ce qui change, tout chemin d'escalade devient obsolète en moins d'un an ; ce que cela signifie en pratique est expliqué sur monitoring qui apporte quelque chose.
Un chemin d'escalade ne peut être rédigé que lorsqu'on sait ce qui peut faire l'objet d'une escalade. Aussi longtemps que personne ne sait quelle IA fonctionne dans l'organisation — y compris ce qui n'a pas été approuvé — le document reste théorique. Le Responsible AI Scan ne commence donc pas par le chemin d'escalade, mais par l'inventaire : ce qui fonctionne, qui l'utilise, et quel niveau de risque correspond à cela. Ce n'est que sur cette base qu'on peut rédiger un chemin d'escalade qui s'aligne sur ce qui existe déjà, plutôt que sur ce qui devrait exister sur papier.
Les chemins d'escalade concernent ce qui va mal avec l'IA déjà utilisée. Une autre question, tout aussi négligée, est de savoir où l'IA pourrait elle-même reprendre le travail. Le werkscan de FTE TO AI calcule, par tâche, quelle part du travail s'y prête, indépendamment de la question de savoir si cela se fait déjà ou doit encore être mis en place.
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.