Dans le transport et la logistique, l'IA ne se trouve souvent pas dans un système distinct avec un nom et un propriétaire, mais entrelacée dans l'exploitation elle-même : planification des itinéraires, optimisation du chargement, systèmes de maintenance prédictive, prévision de la demande, et les algorithmes qui déterminent quel chauffeur reçoit quel trajet. Une partie de cela arrive via des logiciels de transporteurs, d'expéditeurs ou de plateformes, et fonctionne donc avec des règles de décision que l'organisation elle-même n'a pas définies et qu'elle ne peut parfois pas voir entièrement. Le rapport entre ce que le service de planification a lui-même acquis et ce qui arrive via des partenaires de la chaîne ou des fonctionnalités intégrées évolue constamment. Cela ne rend pas l'inventaire plus simple dans ce secteur qu'ailleurs, mais différent : la question n'est pas seulement de savoir qui a installé un outil d'IA, mais aussi quelles décisions automatisées existaient déjà dans les systèmes en place avant que quelqu'un ne les qualifie d'IA.
Un aperçu des logiciels approuvés ne raconte rarement toute l'histoire. Des planificateurs qui utilisent un outil d'IA pour optimiser les itinéraires, un service client qui déploie un chatbot pour le suivi des envois, ou un employé d'entrepôt qui utilise une application pour établir des prévisions de stock : ce type d'applications naît souvent localement, sous la pression du temps ou pour une tâche concrète, sans que personne n'ait déposé de demande. Qui souhaite en dresser un inventaire doit se renseigner auprès des personnes qui effectuent le travail, et cela ne fonctionne que si poser des questions n'entraîne pas immédiatement une correction. Une organisation qui veut trouver de l'IA fantôme doit d'abord faire clairement comprendre que signaler ne constitue pas un risque.
Un inventaire qui va au-delà de la liste informatique met en évidence quelles applications d'IA sont réellement utilisées, où elles se situent dans le processus, et qui y associe des décisions. Dans le transport et la logistique, cela implique souvent une distinction entre les systèmes qui se contentent de conseiller, les systèmes qui planifient automatiquement sans intervention, et les systèmes qui ont un effet sur des personnes extérieures à l'organisation, comme des chauffeurs ou des clients à qui l'on présente un délai de livraison basé sur une prévision. Cette distinction est pertinente car elle modifie le niveau de risque : un outil qui donne simplement une suggestion à un planificateur nécessite une forme de supervision différente d'un système qui fixe de manière autonome des plannings ou des itinéraires.
Après l'inventaire vient la question de savoir ce que fait précisément chaque application et pour qui. Un système qui prédit quand une maintenance est nécessaire a un impact différent d'un système qui déterminer quel chauffeur se voit attribuer un trajet sur la base de données de performance. La classification ne consiste pas ici à appliquer un modèle fixe, mais à ordonner ce qui a été trouvé : quelle application touche des décisions concernant des personnes, laquelle ne touche qu'à l'optimisation logistique, et laquelle fonctionne purement en soutien. La réglementation en vigueur qui détermine quelles obligations sont liées à quel niveau de risque est traitée ailleurs ; il s'agit ici de la structure nécessaire pour pouvoir appliquer ces règles ultérieurement, quel que soit précisément le contenu du texte.
Les entreprises de transport travaillent généralement déjà avec une gestion des risques liée à la sécurité, à la planification et à la conformité. L'AI-governance ne doit pas être un dispositif nouveau à côté de ce système existant ; elle fonctionne mieux si la classification des applications d'IA s'aligne sur des catégories déjà présentes, afin qu'un dirigeant ou un gestionnaire des risques n'ait pas à tenir deux aperçus distincts. Cela nécessite un ensemble de gouvernance qui indique qui gère une application, qui en est responsable, et quel contrôle existe à cet égard, sous une forme adaptée à ce qui existe déjà en matière de structure de reporting et de responsabilisation.
Un dirigeant ou un General Counsel à qui l'on demande de déclarer quels systèmes d'IA sont actifs dans l'organisation doit pouvoir l'étayer avec plus qu'une liste issue du système d'achats. La démontrabilité signifie qu'il existe un aperçu actuel des applications, de leur classification et du statut de la supervision correspondante, et que cet aperçu résiste également lorsque quelqu'un pose des questions plus poussées. D'autres secteurs connaissent des enjeux comparables, comme on peut le voir avec l'AI-governance dans le commerce de détail, l'AI-governance dans le secteur agricole et l'AI-governance dans le secteur informatique, chaque fois avec un rapport propre entre ce qui a été acquis de manière centralisée et ce qui est né localement.
Le Responsible AI Scan qui réunit cet inventaire, cette classification et cette structure de gouvernance est en cours de développement. Qui souhaite s'y engager peut s'inscrire sur la liste d'attente ; il n'existe actuellement aucun produit prêt à l'emploi à commander, et ce n'est pas ce qui est suggéré ici.
Dès qu'il est clair quelles applications d'IA fonctionnent dans la chaîne de transport et quel niveau de risque leur correspond, une question de suivi se pose, à laquelle l'inventaire ne répond pas : quelle part du travail que les planificateurs, les chauffeurs ou les employés du service client effectuent actuellement peut réellement être reprise par ces applications. Cette question est proche de la gouvernance, sans lui être identique, et trouve sa réponse dans le scan de travail de FTE TO AI, qui calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA.
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.