La cifra por la que hay que empezar
En una medición revisada por pares con 458 escenarios reales, un modelo potente resolvió a la primera el 19,36 % de las tareas de infraestructura como código. El mismo modelo sacó un 86,6 % en un conjunto de tareas de Python bien asentado.
No es que el modelo se haya vuelto tonto de golpe. La infraestructura es otro trabajo: aquí la pregunta no es si se ejecuta, sino qué permite.
Otras dos mediciones de 2026 apuntan al mismo sitio:
- Sobre 153 tareas reales, seis modelos de vanguardia dieron una configuración desplegable a la primera entre el 20,8 % y el 30,2 % de las veces, y según las reglas de cumplimiento habituales solo el 8,4 % cumplía la norma.
- Según un estudio con 17 modelos, a los modelos la sintaxis HCL les cuesta más que YAML o JSON.
Tres o cuatro veces más densidad de fallos que en el código humano
Hay un estudio que hace exactamente lo que habría que hacer: compara 1.196 definiciones de infraestructura generadas por máquina con 634 plantillas escritas por personas, con tres motores independientes de comprobación de reglas.
Ajustado por tamaño, en todas las configuraciones estudiadas la densidad de vulnerabilidades del código generado es entre 3,21 y 3,87 veces la del humano.
Y dentro hay un detalle contraintuitivo: la diferencia es de 4,9x con un solo recurso y de solo 1,4x con veinte recursos o más. Es decir, el fragmento corto pedido con prisa es el peligroso, no la configuración larga y pensada. Justo el que se pega más rápido.
(Los ajustes de «razonamiento extendido» son un 12 % mejores más o menos que la generación estándar: ayudan, pero no resuelven.)
Que se ejecute no quiere decir que no esté abierto
Esta es la distinción práctica más importante de todo el post.
Una medición de 2026 estudió siete modelos en diecisiete escenarios, con dos comprobadores de reglas enganchados al proceso. Dos extremos de los resultados:
- Un modelo open-weight alcanzó una tasa de validez del 77,8 %: la configuración era correcta sintácticamente y el comando se ejecutó. Tasa de cumplimiento: cero.
- Con un modelo cerrado potente, un comprobador daba un 23,1 % de aprobados y el otro un 92,5 %: es decir, la elección del propio comprobador también decide.
La conclusión del estudio, literal: «el prompting por sí solo no basta: el escaneo automatizado y con varias herramientas sigue siendo un complemento necesario.»
En cristiano: que la validación pase no es una prueba de seguridad. Un contenedor completamente abierto es una configuración tan válida como uno cerrado.
Los cuatro patrones de fallo que se repiten
En las definiciones de infraestructura generadas vuelven las mismas cuatro cosas una y otra vez:
- Valores por defecto permisivos: permisos con comodines, acceso público.
- Bloques de seguridad ausentes: cifrado y registro simplemente no están.
- Credenciales incrustadas en el código.
- Patrones obsoletos: sintaxis retirada, imágenes sin versión.
Ninguno es un «fallo» en el sentido de que algo se rompa por su culpa. Los cuatro funcionan en silencio, justo hasta que alguien los encuentra.
La medición que lo llevó del 14 % al 93 %
Este es el núcleo práctico del post, y el resultado es tan fuerte que merece la pena repasarlo entero.
Un estudio de 2026 metió una comprobación en tres fases en 186 tareas: validez → cambio previsto → evaluación de la norma. Y luego fue añadiendo un elemento cada vez:
| Qué añadieron | Acierto a la primera |
|---|---|
| Punto de partida, con un modelo abierto pequeño | 14,0 % |
| + traer la documentación relevante | 45,7 % |
| + estructura de prompt optimizada | 53,2 % |
| + refinamiento iterativo con el feedback | 62,9 % |
| lo mismo con un modelo potente | 84,4 % |
| + el texto de la norma dentro del prompt | 93,0 % |
Y la frase clave: «el 79 % de los fallos de cumplimiento posteriores al refinamiento nace de la falta de información y se resuelve cuando el texto de la norma está a la vista.»
O sea, cuatro quintas partes de los fallos de cumplimiento no son falta de capacidad: el modelo sencillamente no conocía la norma.
La receta práctica sale sola: no pulas el prompt, mete el texto de la norma y engancha el escáner al bucle. En el salto del 14 al 93 por ciento, 21,5 puntos sí vinieron de cambiar de modelo, pero los otros 57,5 los pusieron la documentación traída, la estructura del prompt, el bucle iterativo y el texto de la norma, y este último sumó otros 8,6 puntos incluso con el mejor modelo.
AIOps: muy legible, medianamente preciso
La gestión de incidentes es la otra área donde la promesa es grande. La mejor medición sobre esto viene de un gran proveedor de nube, y es poco habitual por lo honesta.
Los datos: unos 180.000 incidentes históricos de severidad alta, y las pruebas sobre 2.900 incidentes reales. Según la evaluación automática, el modelo con el prompt optimizado es un 21 % mejor que la línea base manual.
Pero lo importante está en la evaluación humana, en la opinión de 47 ingenieros de guardia:
| Qué valoraron | Puntuación (1–5) |
|---|---|
| Precisión | 2,91 |
| Legibilidad | 4,21 |
Esta es la combinación más peligrosa que existe. A las tres de la madrugada, el ingeniero de guardia recibe un resumen bien redactado, bien estructurado y a medias correcto. Lo que ve no es duda: lo que ve es seguridad.
Sobre la reducción del ruido de alertas y el acortamiento del tiempo de reparación no encontramos ninguna medición independiente publicada con metodología. Lo que hay son promesas de fabricante.
Lo que sí se mide: la propia IA es fuente de incidentes
Un análisis de fiabilidad procesó 177.960 entradas de páginas de estado entre 2018 y junio de 2026:
| Indicador | 2023 | 2026 |
|---|---|---|
| Incidentes atribuibles a un proveedor de IA | 1,7 % | 10,7 % |
| Modo de fallo de tipo IA en los incidentes clasificados | 0,5 % | 5,1 % |
| «Degradación de la calidad de la salida de IA» como causa | 1,3 % | 6,3 % |
De la misma fuente: los incidentes de terceros, de proveedores, son más de una cuarta parte del total, y su tiempo mediano de resolución es de 247 minutos, frente a los 96 minutos de los fallos propios. Lo que no operas tú, no lo arreglas tú.
Casos concretos y documentados: un agent ejecutó un comando de destrucción de infraestructura y se perdieron 1,94 millones de filas; una estrategia de borrar y recrear provocó una caída de 13 horas; en otro caso «la base de datos de producción y todas las copias de seguridad, borradas en una llamada de API de 9 segundos».
Y la otra cara: esa misma herramienta resolvió una caída
Por equilibrio, merece la pena mirar también un post-mortem público de marzo de 2026.
La cadena causal es clásica: una condición de carrera en la integración continua se saltó un paso de build, por eso el despliegue se ejecutó con una asignación de artefactos equivocada, y el servicio dejó de aceptar datos durante ocho horas.
Y aquí la IA no fue la causa, sino la herramienta para descubrirlo. Los propios agents de monitorización de la empresa avisaron del fallo y después, según su propio relato, dirigiendo un coding agent al informe del fallo, con acceso a la nube y al control de versiones, localizaron el despliegue roto, reconstruyeron la imagen y volvieron a ejecutar los scripts de despliegue.
Y su conclusión fue que le van a dar al agent más permisos, no menos.
La misma tecnología provoca una caída en un sitio y resuelve una caída aquí. La diferencia está en dónde terminan los permisos y en si la acción se puede deshacer.
El procedimiento
1. EL TEXTO DE LA NORMA, DENTRO DEL PROMPT.
El 79 % de los fallos de cumplimiento es falta de dato.
No es que el modelo no sepa - no conoce tu norma.
2. EL ESCÁNER DENTRO DEL BUCLE, NO DESPUÉS.
Genera -> escanea -> recibe el fallo -> corrige.
Sin el bucle el escáner avisa, pero no corrige.
3. VARIOS ESCÁNERES, NO UNO.
Sobre la misma configuración uno midió un 23 % y el
otro un 92 %. Con una herramienta no basta.
4. LA VALIDEZ NO ES SEGURIDAD.
Hubo un modelo que dio configuración válida el 77,8 %
de las veces con CERO cumplimiento.
5. EL FRAGMENTO CORTO ES EL MÁS PELIGROSO.
Con un recurso, la densidad de vulnerabilidades es 4,9x
la humana; con veinte, 1,4x. El pegado rápido es el malo.
6. NINGUNA OPERACIÓN IRREVERSIBLE SE APRUEBA
SOLA. Borrado, destrucción, base de datos en producción:
una persona, siempre.
7. EL RESUMEN AUTOMÁTICO DE INCIDENTE ES HIPÓTESIS,
NO DIAGNÓSTICO. Legibilidad 4,21/5, precisión 2,91/5.
Malentendidos habituales
- «La validación pasó, así que está bien.» Hubo un modelo con un 77,8 % de validez y una tasa de cumplimiento de cero.
- «Con un escáner basta.» Dos herramientas midieron un 23 % y un 92 % sobre el mismo código.
- «Lo arriesgado es la configuración larga y complicada.» Al revés: la diferencia es mayor con un solo recurso.
- «Con un modelo mejor se arregla.» El modelo más potente aporta mucho —21,5 puntos en la medición—, pero no lo resuelve del todo: cuatro quintas partes de los fallos de cumplimiento son falta de información, y hasta con el mejor modelo el texto de la norma puso los últimos 8,6 puntos.
- «El resumen de incidente de la IA me dice qué pasa.» Muy legible, medianamente preciso, y justo por eso resulta convincente a las tres de la madrugada.
Lo que conviene llevarse
En infraestructura la pregunta no es si la configuración se ejecuta, sino qué permite, y ahí el código generado es medible y claramente peor que el humano. Pero la mejora no sale de un solo paso: en la medición que fue del 14 % al 93 %, el cambio de modelo aporta 21,5 de los 79 puntos y el resto lo ponen la documentación traída y la norma y el escáner enganchados al bucle. Y para las operaciones irreversibles, que siga habiendo una persona en el bucle: esa es exactamente la única cosa que tienen en común todas las caídas documentadas.
La configuración de los permisos del agent la detalla el post los tres modos de programar con IA , modo a modo; y el panorama de seguridad más amplio lo recorre el post la factura de seguridad del código generado por IA , con las cifras.