Problème 1621

Début 2018, une société de télécommunications australienne a mordu la balle et a déployé un programme d'IA pour son processus de gestion des incidents. L'opérateur de télécommunications s'attendait à économiser plus de 25 % des coûts opérationnels grâce à cette mise en œuvre. Malheureusement, le plan a échoué.

Le bot a été conçu pour intercepter tous les incidents réseau, 100 % d'entre eux. Une fois intercepté, il suivrait une série de vérifications basées sur le problème signalé par les utilisateurs. Il a été programmé pour prendre l'une des trois actions prédéfinies en fonction des tests qu'il effectuerait.

Premièrement, cela résoudrait l'incident à distance en résolvant le problème par programmation. Si cela ne fonctionnait pas, cela supposerait qu'une visite d'un technicien est nécessaire dans les locaux du client. En conséquence, il émettrait un ordre de travail pour envoyer quelqu'un directement. Si rien de tout cela n'était apparent, il présenterait le cas à l'opérateur humain pour une enquête plus approfondie et une décision.

Au départ, cette approche semblait solide et paraissait tout à fait logique. En quelques semaines, une fois que la société de déploiement s'en est rendu compte, le bot envoyait énormément de techniciens sur le terrain. Bien sûr, envoyer des techniciens pour la visite sur le terrain était une affaire coûteuse, et c'était toujours le dernier choix pour résoudre un problème. Le bot, cependant, a maximisé ce choix.

Plus tard, l'équipe a découvert qu'il y avait quelques scénarios d'incident que seul un opérateur humain pouvait comprendre (et invariablement joindre les points). Apparemment, pour le bot, ils n'étaient pas assez clairs. Dans tous ces cas, un opérateur humain aurait pris une décision différente de celle du bot.

Maintenant, voici le kicker. Malgré la découverte de la faille de logique, l'équipe d'automatisation n'a pas pu désactiver le bot (un peu comme ce que Microsoft a fait avec Tay en 2016). Ils avaient implémenté le bot en mode tout ou rien, et il se trouvait en plein milieu de l'interface utilisateur et opérateur. Ce qui signifiait qu'il n'y avait que deux possibilités. Soit tous les incidents passeraient par le bot et seraient plus souvent mal gérés. Ou aucun d'entre eux ne passerait par le bot et serait ainsi géré manuellement.

Mais l'entreprise de télécommunications n'était pas prête à gérer une telle charge de travail - elle avait déjà libéré le personnel pour réduire les coûts (oups !).

Finalement, l'opérateur de télécommunications a mis en place un autre projet pour réparer le bot alors qu'il était en fonctionnement et a gaspillé plusieurs millions de dollars dans le processus.

Ils ont dépensé l'argent pour deux choses, pour continuer le service avec un bot artificiellement stupide et pour exécuter un projet de réparation massif qui a duré plus d'un an.

Finalement, l'effet de dotation a commencé et l'entreprise n'avait pas l'intention de revenir en arrière et de résoudre le problème à la racine. Au lieu de cela, il a continué à pousser et à gaspiller une énorme somme d'argent, prétendument environ 11 millions de dollars en coûts opérationnels.

La question cruciale demeure : qui a finalement payé pour cela ?

Tout maillon qui relie deux systèmes hétérogènes est un maillon faible !

J'ai vu ce fiasco de près et personnellement. À mon avis, cette implémentation a mal tourné à plusieurs niveaux, depuis la conception du système jusqu'à sa mise en œuvre et la résolution des problèmes.

Mais la première et principale question est : pourquoi il n'y avait pas de plan B, un kill switch quelconque pour arrêter ce bot. Le développement et le déploiement du bot n'ont pas été testés de manière approfondie pour tous les scénarios potentiels et manquaient donc de rigueur de test qui aurait pu identifier les problèmes dès le début. Alors que le temps nécessaire pour régler la situation était trop long, la détection de la défaillance du bot prenait beaucoup plus de temps.

Cette histoire (ou étude de cas, comme certains l'appelleraient) met en évidence de nombreux points faibles de l'IA et de son développement. Il nous guide pour nous concentrer sur des risques spécifiques. Ce n'est peut-être qu'une goutte d'eau dans l'océan, mais une représentation fidèle de quelques aspects communs.

Qu'est ce qui ne s'est pas bien passé?

Certaines choses dans l'histoire ci-dessus ont échoué, et ce n'est pas la technologie !

Les créateurs de l'IA et l'entreprise qui l'a déployée n'ont pas été assez prudents. Ils n'ont pas suivi le principe fondamental de gérer quelque chose d'aussi puissant que l'IA, de manière responsable.

Nous disons souvent : "Avec un grand pouvoir vient une grande responsabilité." Et pourtant, dans ce cas, la conception ou le déploiement responsable n'a pas eu lieu dans son esprit.

Un comportement responsable est nécessaire pour le déploiement et l'utilisation de l'IA ainsi que pour toutes les autres étapes, de la conception à la conception, des tests à la mise en œuvre, en passant par la gestion et la gouvernance continues.

Il existe également un niveau de faiblesse dans l'étape de conception des solutions, qui s'est directement infiltrée dans leur développement.

L'accent mis sur la qualité de la solution n'était pas suffisant. Il pourrait y avoir eu quelques routines de test. Juste assez pour répondre aux exigences des frameworks de développement informatique, mais pas assez pour répondre au framework de développement IA — qui n'existe pas !

Les créateurs ont manqué de réflexion dans la conception de la solution.

Trois choses que vous devriez en tirer

Si vous envisagez de mettre en œuvre une solution d'IA, ou si vous êtes en train de le faire, vous devez tirer les leçons de ce fiasco. Cela vous fera non seulement économiser de l'argent et des ressources, mais vous procurera également une tranquillité d'esprit à long terme.

1. Des tests rigoureux sont de la plus haute importance : premièrement, vous devez comprendre que l'IA étroite concerne la relation entre les entrées et les sorties. Vous fournissez l'entrée X et obtenez la sortie Y, ou il y a une entrée X pour faire la sortie Y. Dans les deux cas, la nature de l'entrée affecte la sortie. Une contribution aveugle peut entraîner des résultats négatifs. Et ce n'est qu'une des bonnes raisons pour lesquelles des tests rigoureux sont si importants. Il faut noter que dans le cas des systèmes d'IA, les mécanismes généraux de test des systèmes informatiques ne suffisent généralement pas.

2. Gardez toujours les humains au courant : lorsque la discrétion et les exceptions sont requises, utilisez les systèmes automatisés uniquement comme un outil pour aider les humains - ou ne les utilisez pas du tout. Il existe encore plusieurs applications et cas d'utilisation que nous ne pouvons pas définir aussi clairement qu'un jeu d'échecs. La majorité des systèmes d'IA sont encore des enfants, et ils ont besoin d'un adulte responsable pour en être responsable. Plus important encore, s'assurer que suffisamment de ressources humaines sont disponibles pour gérer la charge de travail probable est toujours une bonne idée.

3. La bonne gouvernance et la gestion des risques sont essentielles : à mesure que les systèmes d'IA deviennent plus puissants, la gestion des risques va devenir encore plus critique. La mise en place d'une gouvernance solide n'est pas seulement une exigence générale pour l'industrie, mais c'est aussi une bonne idée pour chaque entreprise d'avoir en interne.

Vous n'avez pas toujours besoin de perdre des millions ou de relever des défis pour apprendre. Quand vous voyez un échec, ne manquez pas d'en tirer la leçon !