La IA podría convertirse en la peor deuda tecnológica de los directores de informática hasta la fecha

Algunos defensores de la IA la promueven como una herramienta ideal para erradicar la costosa deuda tecnológica. Sin embargo, los responsables de TI están descubriendo que un exceso de proyectos piloto o una dependencia excesiva del código generado por la IA podrían dar lugar a sus propios problemas.

A modo de ejemplo, las herramientas de IA se pueden utilizar para limpiar el código antiguo o para reducir el software sobredimensionado. Con esto se consigue también una disminución de lo que es una de las principales formas de deuda tecnológica. Ya el pasado mes de septiembre, Microsoft anunció una nueva suite de agentes autónomos de IA diseñados para modernizar automáticamente las aplicaciones heredadas de Java y .NET.

A la vez, los responsables de TI sostienen que la IA tiene potencial para aumentar su deuda tecnológica, dado que existen demasiados proyectos de IA que dependen de modelos o agentes caros de implementar y mantener, y los asistentes de codificación de IA generan más líneas de software de las que pueden ser necesarias.

La ausencia de hojas de ruta de IA hace que las organizaciones corran el riesgo de realizar implementaciones a ciegas cuyo resultado podrían problemas de calidad y mantenimiento a largo plazo, según sostiene Simon Wallace, director técnico y cofundador de la plataforma de acción cívica en línea Suffrago.

En su opinión, “sin una estrategia clara de implementación de la IA o una idea básica de por qué se utiliza la IA, acabaremos teniendo un montón de herramientas acumulando polvo digital”. Y añade: “Lo vimos con los microservicios y la computación en la nube: las herramientas se utilizaron para presentaciones y nunca volvieron a ver la luz”.

Wallace recuerda haber creado herramientas para proyectos piloto de aprendizaje automático y luego ver cómo se implementaban en la nube para no usarlas nunca. “Ahora tienes una herramienta obsoleta que puede estar tres o cuatro versiones por detrás y que utiliza conectores heredados”, dice.

A esto hay que unir que, bien sea la fase de experimentación bien la de producción, muchas organizaciones priorizan la rapidez en sus proyectos de IA, una receta clásica que constituya una manera de acumular problemas de mantenimiento y limpieza que tendrá que resolverse algún día, incluso en el caso de implementaciones exitosas.

Parálisis piloto

Ryan Achterberg, director técnico de la consultora informática Resultant, considera que los interminables proyectos piloto de IA también crean su propia forma de deuda tecnológica. Según sostiene, esta ”parálisis piloto”, en la que las organizaciones lanzan docenas de pruebas de concepto que nunca se escalan, puede llegar a agotar los recursos informáticos.

“Cada experimento conlleva un coste continuo”, afirma Achterberg, para añadir: “Incluso si un modelo nunca se escala, deja tras de sí artefactos que requieren mantenimiento y supervisión de seguridad”.

Parte del problema radica en la inestabilidad de las bases de datos de IA, incluso en un escenario de gran ambición de la IA, explica este especialista. “Eso significa que la mayoría de los proyectos piloto ya parten de una base frágil, lo que los hace más propensos a estancarse o fracasar”, dice. Y apostilla: “Sin embargo, una vez que existen, los directores de informática se ven obligados a gestionar el riesgo”.

Achterberg aconseja a las organizaciones que experimentan con la IA realizar revisiones rigurosas del código, utilizar un canal de implementación continua y documentar todo de manera minuciosa.

Lo que le lleva a decir que “docenas de proyectos piloto de IA pequeños y descoordinados pueden inflar la deuda tecnológica tanto como los sistemas heredados de hace décadas”. Entonces, “sin una gobernanza y una priorización implacable, las organizaciones acaban pagando el precio de mantener costosos experimentos que no aportan valor empresarial”.

Kurt Muehmel, responsable de estrategia de IA en la plataforma de desarrollo de IA Dataiku, añade que el desarrollo de IA genera deuda tecnológica en muchas organizaciones cuando surgen muchos proyectos en diferentes unidades de negocio, añade. En algunas de ellas, explica, los trabajadores con capacidad para poner en marcha proyectos de IA no dependen directamente del director de informática ni tampoco de ningún otro responsable sénior de TI.

“Podemos imaginar un escenario en el que algunos de sus científicos de datos empiecen a configurar servidores MCP”, dice. “Y luego empiezan a utilizar esas herramientas para crear rápidamente agentes, pero no necesariamente se dispone de supervisión integrada de forma nativa en ese tipo de sistemas”, añade.

Demasiado código

A la deuda tecnológica derivada del exceso de proyectos piloto de IA hay que unir los propios problemas que pueden crear los asistentes de codificación sin una supervisión adecuada, añade Jaideep Vijay Dhok, director de operaciones tecnológicas del proveedor de ingeniería digital Persistent Systems.

En algunos casos, advierte, los asistentes de codificación de IA generarán más líneas de software de las que solicitó un desarrollador.

A su juicio, “se generará código superfluo a menos que yo, como desarrollador, sea diligente con lo que acepto”. Y es que, cree, “los modelos tienen una tendencia inherente a lanzarte cosas adicionales”.

Además, los resultados pueden desalinearse en caso de que todos los miembros de un equipo de desarrollo de software, incluidos los evaluadores de control de calidad, los gestores de productos y los ingenieros de lanzamiento, no utilicen las mismas herramientas de codificación de IA, afirma Dhok.

Por eso, este especialista explica que “cuando estos agentes digitales trabajan entre sí de una manera mucho más colaborativa, en términos de casos de prueba y requisitos básicos, todos se elevan juntos. El riesgo de deuda tecnológica de las aplicaciones disminuye cuando se eleva el uso de la IA generativa del individuo al equipo, de forma colectiva”.

Supervisión de proyectos de IA

Muehmel recomienda a las organizaciones utilizar herramientas de gobernanza que hagan un seguimiento de la seguridad de los datos y las cuestiones de cumplimiento, y que también supervisen el gasto y las métricas de los proyectos de IA. De ahí que sugiera que el director de informática u otro responsable sénior de TI deberían tener el control de esa función de supervisión.

Y afirma que las herramientas de gobernanza son fundamentales para garantizar que los proyectos de IA cumplan con métricas realistas.

“Esto surge en todas las conversaciones que mantengo con un director de informática o con alguien que piensa a nivel estratégico sobre los agentes: la gobernanza. ¿Cómo me aseguro de tener control sobre todo lo que se está creando?”, dice Muehmel. Y añade: “Existe un temor real a los agentes ocultos que han sido creados por algunas personas inteligentes de la organización que están haciendo cosas que no comprendemos del todo”.

Los responsables de TI y empresariales que supervisan proyectos de IA también deben asegurarse de que, en especial los agentes, estén estrechamente vinculados a los procesos empresariales, añade Muehmel. En su opinión, los agentes rebeldes que no se ajustan a los procesos empresariales pueden generar desconfianza entre los usuarios.

“Lo que hace únicos a los agentes es que, en cierto modo, se supone que son casi nuevos compañeros o colaboradores de los empresarios del departamento de marketing, del departamento financiero y de operaciones”, afirma Muehmel. “Si esas personas no pueden confiar en el rendimiento del agente, se produce un déficit de confianza real que puede llevar a crear un montón de cosas que la gente se muestra reacia a utilizar”.

De ahí que defienda que los responsables de TI deben evaluar constantemente los proyectos de IA de sus organizaciones y no tener miedo a fracasar rápidamente, ya sea en las primeras fases de desarrollo o en la fase de implementación.

A juicio de Muehmel, “en ese enfoque de fracaso rápido, es necesario que todas las personas involucradas en la creación y el despliegue de agentes comprendan profundamente que el proceso no puede terminar con la creación del agente”. En consecuencia, “las situaciones externas van a cambiar, porque los objetivos empresariales pueden variar ligeramente, por lo que también hay que prever este proceso de adaptación continua del funcionamiento del agente”, dice para concluir.