Por qué los agentes de IA rompen las pruebas de software

👁 113 lecturas

Los sistemas empresariales tradicionales se basan en tres premisas: las tareas terminan rápido, reiniciar o reintentar no cuesta nada y las mismas entradas devuelven los mismos resultados. Las cargas de trabajo con agentes de IA rompen estas tres reglas a la vez, lo que explica por qué los proyectos piloto funcionan bien bajo supervisión humana pero se desmoronan al llegar a producción.

El análisis de estos problemas lo ha publicado en SiliconAngle M. Touheed, señalando tres brechas claras en las prácticas de ingeniería actuales.

Tres propiedades que los agentes no tienen

En primer lugar, el tiempo de ejecución. Una tarea gestionada por un agente puede tardar minutos, no milisegundos, un margen suficiente para superar límites de tiempo (timeouts) que ningún componente de tu infraestructura había alcanzado antes. Sistemas que parecían estables empiezan a fallar de forma misteriosa hasta que alguien revisa la duración real de cada proceso.

En segundo lugar, el coste de los reintentos. En el software tradicional, un reintento es prácticamente gratuito, por lo que los equipos suelen configurarlo con generosidad. Con agentes, cada intento frente a un modelo con facturación por uso consume recursos de computación, sea útil o no la respuesta. Como la facturación de las API en la nube y los modelos es asíncrona y llega en ciclos mensuales, los costes acumulados de los reintentos crecen en silencio y solo se detectan cuando llega la factura, semanas después.

En tercer lugar, la imposibilidad de reproducir los fallos. Según Touheed, este es el cambio más radical. La práctica habitual tras detectar un mal resultado consiste en repetir la ejecución y observar el error. Con los agentes esto no sirve: sin una traza paso a paso de las decisiones tomadas, las llamadas a herramientas y las peticiones a la API, no hay nada que investigar y el análisis queda en mera especulación.

Por qué las pruebas piloto no detectan estos fallos

Los entornos de evaluación ocultan todos estos problemas porque, en modo interactivo, el propio humano actúa como controlador de errores. Lees cada respuesta, detectas los fallos y corriges a mano. Los costes se mantienen controlados porque los intentos se cuentan y se ajustan al momento. En ese escenario no parece necesario un registro de auditoría ni un mecanismo estricto de reproducción.

Un flujo de trabajo con agentes automatizado opera de otra forma: se ejecuta en modo desatendido (headless), sin nadie frente a la consola. Tal y como refleja el análisis, un proceso que funcionaba de maravilla cuando una persona interactuaba con la IA y revisaba cada respuesta se comporta de forma muy distinta cuando un programador de tareas lo lanza 400 veces de noche sin supervisión. El error siempre estuvo ahí; simplemente permanecía invisible porque el operador humano lo absorbía y corregía respuesta a respuesta.

De ahí se extrae una lección práctica: antes de dar el salto a la producción automatizada con agentes, los responsables de ingeniería deben inventariar cada tarea que realizaba el operador humano y definir qué mecanismo automático asumirá esa responsabilidad. Touheed también aconseja cambiar la conversación sobre presupuestos: en lugar de preguntar por el coste por llamada a la API, conviene calcular el coste por unidad completada, ya que esta métrica descuenta los reintentos fallidos y ofrece una visión real del gasto.

Es un análisis clave para cualquiera que esté a punto de dar por concluido un piloto con éxito y planee desplegarlo en producción el próximo trimestre.

// sigue leyendoAgentes de IA bloqueados: Amazon, bancos y PSD2Panorama de la IAPKO BP: 38,3 millones de charlas con bots no prueban el éxito de la IAPanorama de la IA¿Tu agente IA repite el resultado? El problema de consistenciaPanorama de la IA

Kinetyra