El mejor agente de IA resolvió solo el 60% de las tareas de DevOps en la nube, y el 80% de los fallos se debe a la lógica

Imagine que le pide a un agente de IA que cierre el acceso en AWS a un empleado que ha dejado la empresa. Un ingeniero con experiencia revisará usuarios, roles, claves y cuentas de servicio. El agente puede desactivar una sola cuenta, informar de que está "listo" y dejar abiertas otras vías de acceso.

Ese es el tipo de fallo que ha puesto de manifiesto CloudOpsBench, un nuevo benchmark abierto, es decir, un conjunto de tareas estándar para comparar modelos. El mejor de los modelos probados, Claude Fable 5.1, resolvió solo el 60% de las tareas, y GPT-6 Astra, el 53%.

Cerca del 80% de los fracasos no se debe a que el modelo desconozca la nube, sino a que razona mal: calcula mal el alcance del trabajo, no revisa todos los servicios necesarios o se detiene demasiado pronto. Si está pensando en delegar en un agente operaciones sobre infraestructura en la nube, estas cifras indican dónde conviene poner salvaguardas.

Qué evalúa CloudOpsBench

El benchmark lo creó un equipo dirigido por Ang Chen, de la Universidad de Míchigan. La versión 1.0 incluye 45 tareas sobre AWS, redactadas por ingenieros DevOps con experiencia. El conjunto cubre el trabajo habitual: reparar un servicio, eliminar recursos, restringir permisos de acceso, desplegar una actualización y retirar un proyecto de producción.

Cada tarea se ejecuta de la misma forma en la nube real de AWS y en un emulador. El emulador permite repetir las pruebas sin arriesgar la infraestructura real. El proyecto está publicado en GitHub con licencia Apache 2.0 e incluye un análisis detallado de los errores. Están previstas extensiones para GCP, Azure y OCI (Oracle Cloud Infrastructure).

Dónde fallan los agentes

Incluso el líder suspende una parte notable de las tareas: Claude Fable 5.1 logra un 60% de éxito y GPT-6 Astra, un 53%. Ningún modelo resolvió todas las tareas. Según los autores, en la mayoría de los casos el cuello de botella es precisamente el razonamiento.

Aproximadamente el 80% de los fallos encaja en tres escenarios:

• el agente calcula mal el volumen de la tarea;
• no revisa todos los servicios relacionados;
• se detiene antes de que el trabajo esté terminado.

Es justo lo que ocurre con el acceso del empleado despedido: el agente conoce los comandos, pero no comprueba que el panorama esté cerrado por completo.

El otro 20% aproximado de los errores son acciones incorrectas. Algunas tienen consecuencias irreversibles para la infraestructura. Por ejemplo, un recurso eliminado no se puede recuperar, y ahí el coste del error es mayor que en un trabajo inacabado.

Qué hacer en la práctica

Las conclusiones que siguen son recomendaciones nuestras, no resultados de los autores del benchmark.

Primero, limite los permisos. En una cuenta de producción es razonable dar al agente acceso de lectura y un conjunto reducido de operaciones seguras, y exigir confirmación humana para eliminar recursos, cambiar políticas de acceso y retirar un proyecto de producción.

Segundo, no acepte el "listo" sin más. Si una causa frecuente de fallo es la parada prematura, hace falta una verificación independiente del resultado: un script o una revisión que enumere los servicios afectados y los compare con el estado esperado.

Tercero, pruebe con tareas parecidas a las suyas. Como CloudOpsBench es abierto y funciona en un emulador, se puede usar para comparar modelos o variantes de prompts sin arriesgar la nube real.

Limitaciones

Un conjunto de 45 tareas es pequeño y, por ahora, cubre solo AWS, de modo que las cifras corresponden a una versión concreta del benchmark y a modelos concretos. En su infraestructura, con sus propias convenciones, los resultados pueden ser distintos. Pero la conclusión general es clara: lo que más frena a los agentes en las operaciones en la nube es la planificación y la autoverificación, no el conocimiento de los comandos. Hasta que mejoren esas capacidades, el humano sigue siendo la última línea de defensa ante las acciones irreversibles.