Problema 1621

A principios de 2018, una empresa de telecomunicaciones australiana mordió la bala e implementó un programa de IA para su proceso de gestión de incidentes. La empresa de telecomunicaciones esperaba ahorrar más del 25% de los costos operativos de esta implementación. Desafortunadamente, el plan fracasó.

El bot fue diseñado para interceptar todas las incidencias de la red, el 100% de ellas. Una vez interceptado, seguiría una serie de controles basados en el problema informado por los usuarios. Estaba programado para tomar una de las tres acciones predefinidas en función de las pruebas que realizaría.

En primer lugar, resolvería el incidente de forma remota solucionando el problema mediante programación. Si eso no funcionara, se supondría que se requiere la visita de un técnico a las instalaciones del cliente. En consecuencia, emitiría una orden de trabajo para enviar a alguien directamente. Si nada de eso fuera evidente, presentaría el caso al operador humano para una mayor investigación y decisión.

Al principio, este enfoque parecía sólido y parecía bastante lógico. En unas pocas semanas, después de que la empresa de implementación se dio cuenta, el bot estaba enviando una gran cantidad de técnicos al campo. Por supuesto, enviar técnicos para la visita de campo era un asunto costoso y siempre era la última opción para solucionar un problema. El bot, sin embargo, maximizó esa elección.

Más tarde, el equipo descubrió que había algunos escenarios de incidentes que solo un operador humano podía entender (e invariablemente unir los puntos). Aparentemente, para el bot, no fueron lo suficientemente claros. En todos estos casos, un operador humano habría tomado una decisión diferente a la del bot.

Ahora, aquí estaba el truco. A pesar de descubrir la falla en la lógica, el equipo de automatización no pudo apagar el bot (muy parecido a lo que hizo Microsoft con Tay en 2016). Habían implementado el bot en forma de todo o nada, y estaba ubicado justo en el medio de la interfaz de usuario y operador. Lo que significaba que sólo había dos posibilidades. O todos los incidentes pasarían por el bot y se manejarían incorrectamente con más frecuencia. O ninguno de ellos pasaría por el bot y, por lo tanto, se manejaría manualmente.

Pero la empresa de telecomunicaciones no estaba lista para manejar tal carga de trabajo: ya habían liberado al personal para ahorrar costos (¡ups!).

Eventualmente, la empresa de telecomunicaciones estableció otro proyecto para reparar el bot mientras estaba en funcionamiento y desperdició varios millones de dólares en el proceso.

Gastaron el dinero en dos cosas, continuar con el servicio con un bot artificialmente estúpido y ejecutar un proyecto de reparación masivo que duró más de un año.

Eventualmente, el efecto de dotación entró en acción y la compañía no tenía planes de regresar y solucionar el problema desde la raíz. En cambio, siguió avanzando y desperdiciando una enorme cantidad de dinero, supuestamente alrededor de $ 11 millones en costos operativos.

La pregunta crucial sigue siendo: ¿quién pagó finalmente por esto?

¡Todo eslabón que une dos sistemas heterogéneos es un eslabón débil!

Vi este fiasco de cerca y personalmente. En mi opinión, esta implementación salió mal en varios niveles, desde el diseño del sistema hasta su implementación y solución de problemas.

Pero la primera y más importante pregunta es: ¿por qué no había un plan B, un interruptor de emergencia de algún tipo para detener este bot? El desarrollo y la implementación del bot no se probaron exhaustivamente para todos los escenarios potenciales y, por lo tanto, carecían del rigor de las pruebas que podrían haber identificado problemas desde el principio. Si bien el tiempo requerido para solucionar la situación fue demasiado largo, la detección de la falla del bot tomó mucho más tiempo.

Esta historia (o estudio de caso, como algunos lo llamarían) destaca muchos puntos débiles en la IA y su desarrollo. Nos guía para centrarnos en riesgos específicos. Puede ser simplemente una gota en el océano, pero una representación precisa de algunos aspectos comunes.

¿Qué salió mal?

Algunas cosas en la historia anterior fallaron, ¡y no es la tecnología!

Los creadores de IA y el negocio que la implementó no han sido lo suficientemente cuidadosos. No siguieron el principio fundamental de manejar algo tan poderoso como la IA de manera responsable.

A menudo decimos: "Un gran poder conlleva una gran responsabilidad". Y, sin embargo, en este caso, el diseño o implementación responsable no se produjo en su totalidad.

El comportamiento responsable es necesario para la implementación y el uso de la IA, así como para todas las demás etapas, desde la concepción hasta el diseño, desde las pruebas hasta la implementación y la gestión y el gobierno continuos.

También hay un nivel de debilidad en la etapa de concepción de la solución, que se filtró directamente en su desarrollo.

El énfasis en la calidad de la solución no fue suficiente. Podría haber habido algunas rutinas de prueba. Solo lo suficiente para cumplir con los requisitos de los marcos de desarrollo de TI, pero no lo suficiente para cumplir con el marco de desarrollo de IA, ¡que no existe!

Los creadores carecieron de consideración en el diseño de la solución.

Tres cosas que debes aprender de esto

Si planea implementar una solución de IA, o está en medio de ella, debe aprender de este fiasco. No solo ahorrará dinero y recursos, sino que también le dará tranquilidad a largo plazo.

1. Las pruebas rigurosas son de suma importancia: en primer lugar, debe comprender que la IA estrecha tiene que ver con la relación entre la entrada y la salida. Proporciona la entrada X y obtiene la salida Y, o hay una entrada X para hacer la salida Y. De cualquier manera, la naturaleza de la entrada afecta la salida. La entrada indiscriminada puede conducir a resultados adversos. Y esta es solo una buena razón por la cual las pruebas rigurosas son tan importantes. Debemos tener en cuenta que, en el caso de los sistemas de IA, los mecanismos generales de prueba del sistema de TI no suelen ser suficientes.

2. Siempre mantenga a los humanos informados: cuando se requiera discreción y excepciones, use los sistemas automatizados solo como una herramienta para ayudar a los humanos, o no los use en absoluto. Todavía hay varias aplicaciones y casos de uso que no podemos definir tan claramente como un juego de ajedrez. La mayoría de los sistemas de IA todavía son niños y necesitan un adulto responsable para estar a cargo. Lo que es más importante, siempre es una buena idea asegurarse de que haya suficientes recursos humanos disponibles para manejar la carga de trabajo probable.

3. La buena gobernanza y la gestión de riesgos son fundamentales: a medida que los sistemas de IA se vuelvan más potentes, la gestión de riesgos será aún más crítica. Tener una gobernanza sólida en su lugar no solo es un requisito general para la industria, sino que también es una buena idea para que cada empresa tenga internamente.

No siempre es necesario perder millones o enfrentar desafíos para aprender. Cuando veas un fracaso, ¡no dejes de aprender la lección!