Un responsable des opérations examine une démonstration d'IA triant les demandes de service entrantes. Le système lit un message, lui attribue une catégorie et l'envoie à la bonne équipe. Cela semble être une petite occasion d'automatisation.

Puis, un message d'essai arrive : le client formule une question de facturation ordinaire, mais explique aussi que ses tentatives d'aide précédentes ont échoué. Le modèle choisit la facturation. Un réviseur estime que la demande nécessite un autre cheminement.

Ce désaccord expose la décision derrière la démonstration : que doit reconnaître l'organisation avant de choisir la destination d'une demande?

Consigner les changements entraînés par la décision

La classification n'a de valeur que par ses suites. Une catégorie peut modifier la priorité de la file d'attente, l'accès à un spécialiste ou les renseignements demandés au client. Un même résultat du modèle peut entraîner des conséquences très différentes selon le flux de travail.

Définissez la décision autorisée et les preuves requises. Séparez les renseignements contenus dans le message de ceux déduits par le modèle. Rendez visible le contexte manquant et précisez quels cas doivent être soumis directement à un réviseur qualifié.

Le NIST AI Risk Management Framework propose une approche volontaire pour intégrer la fiabilité dans la conception, le développement, l'utilisation et l'évaluation de l'IA. Pour cet exemple, l'implication pratique consiste à évaluer le système dans le travail qu'il influencera, tout en attribuant la responsabilité de son utilisation.

Déterminer les erreurs les plus importantes

Un score d'exactitude global peut masquer les erreurs qui méritent le plus d'attention. Envoyer une question de routine à la mauvaise file générale diffère du fait de ne pas reconnaître une demande exigeant l'examen d'un spécialiste.

Créez un ensemble d'évaluation comprenant ces cas difficiles, des formulations ambiguës, des messages incomplets et des situations hors du champ d'application prévu. Examinez les désaccords avec des personnes qui connaissent le service et notez pourquoi l'action correcte diffère de la suggestion du modèle.

Il y a un compromis à faire. Soumettre plus de cas incertains à la révision peut ralentir le processus et limiter les gains d'automatisation apparents. En soumettre moins peut laisser des erreurs importantes non détectées. L'équilibre acceptable doit dépendre des conséquences de la décision, et non d'un objectif choisi pour assurer le succès du projet pilote.

Maintenir une solution de rechange efficace

Avant de modifier l'acheminement en direct, exécutez le modèle en parallèle avec le processus actuel et comparez les recommandations. Cela permet de révéler les catégories faibles et les preuves manquantes, sans laisser le système déterminer le parcours du client.

Un déploiement ultérieur nécessite toujours une capacité d'examen, un moyen de corriger une décision et un responsable désigné pouvant suspendre l'automatisation. Une file d'attente d'exception n'est pas une solution de rechange si personne n'a le temps ou l'autorité de la gérer.

Suivez les corrections par type, y compris les cas découverts après l'acheminement. Évaluez la charge de travail créée par le système pour l'équipe suivante, ainsi que celle qu'il élimine pour la première.

Dans l'exemple initial, le résultat le plus précieux du projet pilote est peut-être une meilleure définition de la décision d'acheminement. C'est un progrès. Un investissement utile en IA commence par une décision que l'entreprise comprend et se termine par la preuve que cette décision est mieux gérée.