Google bloquea cientos de fallos al mes: el agente también puede crear otros
Google comunicó el 18 de septiembre de 2026 que ya utiliza agentes de IA para examinar cada cambio en el código que despliega sobre su infraestructura. La cobertura independiente de AI Stack Current confirma el anuncio y precisa que la empresa atribuye al sistema cientos de vulnerabilidades bloqueadas al mes, aunque se trata de resultados operativos internos, no de un benchmark reproducido por terceros.
El anuncio del 18 de septiembre describe un proceso que no permite al agente aprobar su propio trabajo: separa el escaneo, la validación estructural y la generación del parche, que finalmente vuelve al flujo de revisión humana. Esa cautela encaja con un experimento independiente de reparación automatizada: redujo los hallazgos de análisis estático hasta un 69%, pero introdujo vulnerabilidades nuevas en el 15%–22% de los casos. El estudio no evaluó el sistema de Google y, por tanto, demuestra un riesgo del método, no una tasa de fallos de su despliegue.
El control comienza antes de incorporar el cambio
La diferencia principal está en el momento del análisis. En vez de depender únicamente de auditorías amplias y periódicas, el agente revisa cada modificación durante la fase previa a su incorporación, cuando puede trabajar con un fragmento más pequeño y su contexto inmediato.
La descripción técnica de Google Cloud afirma que este proceso abarca cada cambio sobre cientos de millones de líneas de código y evita que cientos de vulnerabilidades mensuales lleguen a la base de código o a producción. Para precisar el contexto, emplea modelos de amenazas localizados, metadatos vivos y un grafo de llamadas entre paquetes y bibliotecas; con esa combinación, la tasa de falsos positivos baja al 3% en algunos casos.
Ese último porcentaje tiene un alcance limitado: “en algunos casos” no equivale a una tasa general para todas las categorías de fallos. El anuncio tampoco publica el conjunto completo de evaluación ni los denominadores que permitirían comparar el resultado con otros sistemas. Además, una inspección posterior durante las pruebas nocturnas busca debilidades surgidas por la interacción de varios cambios, fuera del alcance de una revisión aislada.
El triage exige una ruta vulnerable alcanzable
Una alerta inicial pasa a un agente especializado de triage. Este comprueba la estructura real del programa mediante análisis del árbol de sintaxis, recorrido del grafo de llamadas y reglas de seguridad previamente indexadas, con el objetivo de determinar si un atacante podría alcanzar la ruta señalada.
La empresa sitúa la precisión de esta etapa por encima del 92% y su duración por debajo de un minuto. El diseño evita que un único modelo detecte una sospecha y la declare válida atendiendo solo a su propia confianza: una hipótesis probabilística debe superar comprobaciones estructurales antes de convertirse en un hallazgo.
La separación también delimita qué puede trasladarse a otros repositorios. Mantis, el arnés multiagente relacionado con la iniciativa, está disponible como proyecto abierto, pero su repositorio público no reproduce por sí solo los metadatos, modelos de amenazas, reglas internas, grafos de llamadas ni sistemas de revisión que sostienen las métricas de Google. Es una referencia modular, no una copia empaquetada de la plataforma de producción.
El parche automático sigue siendo una propuesta
Cuando un hallazgo supera el triage, otro agente recibe el resultado del escaneo y una prueba generada que muestra cómo se activa la vulnerabilidad. Con ese material construye una corrección acorde con las normas internas de programación y la incorpora a la solicitud de cambio original. El agente propone el parche, pero no lo aprueba ni lo escribe directamente en producción.
La revisión humana protege frente a fallos de segundo orden. Una corrección puede eliminar la alerta sin cerrar la ruta explotable, alterar un comportamiento legítimo o abrir una debilidad diferente. Mantener separados los agentes de desarrollo, detección, triage y reparación reduce el riesgo de una validación circular, pero no garantiza que el código resultante sea seguro.
La arquitectura combina así dos clases de control. Los modelos amplían la búsqueda, formulan hipótesis y generan candidatos de reparación; el análisis de sintaxis, los grafos de llamadas, las reglas indexadas y la aprobación humana imponen comprobaciones observables. Lo transferible es esa división de funciones, no la expectativa de reproducir automáticamente las cifras internas.
El reescaneo mide lo que la reparación puede romper
El trabajo experimental enviado a arXiv el 17 de agosto de 2026 estudió una configuración distinta: generó código Python a partir de 26 instrucciones de LLMSecEval, cubrió nueve categorías CWE y completó 80 ejecuciones con cuatro modelos Claude. La tubería combinó un validador basado en un LLM con CodeQL y Bandit, generó reparaciones y volvió a analizar el resultado.
Cuando el contexto de reparación incluyó los hallazgos iniciales de los analizadores, el número de alertas cayó entre un 29% y un 69%, según el modelo. Sin embargo, aparecieron vulnerabilidades que no existían antes en el 15%–22% de los casos reparados; cerca del 70% de esos episodios añadió un único hallazgo. El modelo con el mejor código inicial tampoco produjo el mejor resultado final dentro de la tubería.
La comparación no permite trasladar esos porcentajes a Google: cambian el código, los modelos, las herramientas y el entorno de evaluación. Sí respalda una conclusión más estrecha: contar las alertas eliminadas no basta. La verificación debe comparar el código anterior y posterior, comprobar el fallo original y buscar regresiones nuevas.
Las cifras de Google todavía no tienen reproducción externa
Por ahora están documentados el escaneo previo de cada cambio, el triage estructural, la inspección nocturna y los parches sometidos a revisión humana. También está documentada la publicación de Mantis como punto de partida abierto. No hay una reproducción independiente de las tasas internas de precisión, falsos positivos o vulnerabilidades bloqueadas.
Quedan por conocer métricas como la proporción de parches aceptados, modificados o rechazados y cuántos generan regresiones tras el reescaneo. Hasta que exista una evaluación más completa, los cientos de fallos bloqueados al mes deben leerse como una medida interna de escala; la evidencia experimental explica por qué incluso una reparación convincente necesita una comprobación nueva antes de ser aceptada.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.