La compañía combina revisión antes de incorporar código, modelos de amenazas locales, validación estructural y parches con supervisión humana. Las métricas provienen de Google y todavía no tienen una auditoría independiente publicada.

La seguridad entra antes de que el código llegue a producción

Google informó el 18 de septiembre de 2026 que incorporó agentes de inteligencia artificial a la revisión continua del software que usa en su infraestructura. En vez de esperar un gran análisis periódico, el sistema examina cada cambio antes de que se incorpore al código, vuelve a buscar problemas durante las pruebas nocturnas y puede proponer una corrección para que una persona la revise.

La compañía afirma que este proceso recorre cientos de millones de líneas y evita que cientos de vulnerabilidades por mes entren en su base de código o lleguen a producción. También publica cifras de precisión y velocidad: una tasa de falsos positivos de hasta 3% en algunos casos, y más de 92% de precisión para el agente de clasificación con respuestas en menos de un minuto.

Son resultados importantes, pero tienen una limitación decisiva: proceden de Google. El anuncio no enlaza una evaluación externa, un conjunto de prueba reproducible ni un desglose que permita trasladar esos porcentajes a otra empresa. La noticia es, por tanto, la arquitectura que Google dice haber puesto en uso y las métricas que reporta, no una garantía universal de rendimiento.

Un flujo de agentes con tareas separadas

El diseño comienza con un escaneo pre-submit, antes de aceptar un cambio. Analizar una modificación pequeña requiere menos contexto que revisar de una vez un repositorio enorme y permite responder dentro del flujo habitual de trabajo. El objetivo es que la seguridad se parezca a una prueba automática o una revisión de estilo: aparece cuando el desarrollador todavía puede corregir el problema sin esperar una auditoría posterior.

El agente no recibe solamente el fragmento modificado. Google dice que lo combina con modelos de amenazas localizados, metadatos actualizados del repositorio y un grafo de llamadas que muestra relaciones entre paquetes y bibliotecas. Esa información ayuda a responder preguntas que una regla aislada no puede resolver: si una función vulnerable es accesible desde una entrada externa, qué dependencia la utiliza o qué activo quedaría expuesto.

Después interviene un agente de triage separado. Este componente usa análisis del árbol sintáctico, recorrido del grafo de llamadas y reglas de seguridad ya indexadas para comprobar si la ruta señalada sería realmente alcanzable por un atacante. La separación importa: el agente que encuentra una hipótesis no es el único que decide si merece atención.

El proceso agrega una segunda capa después de incorporar el cambio. Durante la integración nocturna, un análisis más amplio busca vulnerabilidades que solo aparecen al combinar varias modificaciones. Si la evidencia se sostiene, otro agente prepara un parche de acuerdo con las normas internas de Google y adjunta una prueba que muestra cómo se activa la falla. La corrección se presenta para revisión humana; el anuncio no dice que los parches pasen directamente a producción sin aprobación.

Mantis abre parte del enfoque, pero no es un producto listo para instalar

Google publicó Mantis en GitHub, un conjunto modular de habilidades y una implementación de referencia para organizar agentes que buscan, reproducen y corrigen vulnerabilidades. El repositorio utiliza la licencia Apache 2.0, por lo que equipos externos pueden estudiar, adaptar y ejecutar el código bajo sus condiciones.

Eso no convierte el sistema interno de Google en una solución empaquetada. El propio repositorio describe Mantis como un punto de partida, sin soporte oficial y no preparado para producción. También advierte que los modelos son no deterministas: pueden inventar hallazgos, omitir fallas o proponer parches incorrectos. Todos los resultados deben ser verificados por especialistas.

La advertencia más seria se refiere al entorno de ejecución. Mantis puede generar y ejecutar código para reproducir vulnerabilidades. Google recomienda usarlo solo en espacios aislados y restringidos, nunca en una máquina conectada a producción, datos sensibles o redes internas. Si querés probarlo, la primera tarea no es elegir el modelo más potente, sino diseñar el sandbox, los permisos y los límites de red.

Qué pueden adoptar los equipos sin copiar toda la infraestructura de Google

Una organización mediana difícilmente tenga la escala, los metadatos o las herramientas internas de Google. Sin embargo, el anuncio ofrece cuatro principios aprovechables.

Primero, conviene acercar el análisis al cambio. Una revisión pequeña y frecuente puede entregar una respuesta más accionable que un informe masivo al final de un ciclo. Segundo, el contexto debe estar controlado: un modelo de amenazas vigente y un inventario de dependencias resultan más útiles que enviar todo el repositorio sin prioridades.

Tercero, separá generación y verificación. Si un agente propone un hallazgo, hacé que otra etapa compruebe la ruta con herramientas deterministas, pruebas y reglas conocidas. Cuarto, mantené una persona responsable de aceptar el diagnóstico y el parche. La automatización puede reducir trabajo repetitivo, pero no transfiere la responsabilidad por un cambio de seguridad.

Antes de medir éxito, definí una línea de base. Registrá cuántos hallazgos terminan confirmados, cuánto tarda el equipo en revisarlos, cuántos parches se rechazan y qué defectos llegan a producción. Sin esas cifras, una herramienta puede producir mucha actividad sin mejorar el riesgo real.

Por qué interesa en Paraguay y América Latina

Para equipos regionales que venden software a banca, comercio, salud o gobierno, incorporar controles durante el desarrollo puede ser más accesible que ampliar indefinidamente un grupo especializado de seguridad. Mantis permite estudiar la arquitectura sin pagar una licencia, aunque operarlo de forma segura exige infraestructura, experiencia y tiempo de revisión.

La principal lección para una empresa paraguaya no es “automatizá todo”. Es empezar con un alcance limitado: un repositorio no crítico, una categoría de vulnerabilidad, acceso de solo lectura y un entorno sin secretos. Compará los hallazgos contra las herramientas que ya usás y pedí aprobación humana para cualquier cambio.

También conviene revisar la residencia del código y los datos. Si el modelo o la infraestructura de análisis se ejecutan fuera del país, evaluá qué fragmentos se envían, cuánto tiempo se conservan y qué obligaciones contractuales existen. El anuncio de Google describe su operación interna; no confirma disponibilidad regional, precios ni un servicio comercial equivalente para organizaciones externas.

Lo que falta demostrar

Las próximas señales útiles serán evaluaciones reproducibles, resultados de equipos independientes y detalles sobre la gravedad de las vulnerabilidades evitadas. “Cientos por mes” puede incluir defectos muy distintos, y una tasa baja de falsos positivos no informa por sí sola cuántos problemas reales quedaron sin detectar.

Google muestra una evolución clara de DevSecOps: agentes especializados dentro del ciclo de cambios, respaldados por contexto estructural y controles humanos. El diseño merece atención porque no trata al modelo como juez único. Pero si tu equipo quiere replicarlo, tomá las métricas como evidencia del proveedor y el código abierto como una base experimental. La seguridad seguirá dependiendo de aislamiento, pruebas y profesionales capaces de decir que un hallazgo —o su parche— está equivocado.

Este cambio también se conecta con la expansión de agentes en mantenimiento empresarial: Devin y AWS ya exploran la modernización de software con IA, aunque seguridad y migración exigen controles distintos.

Fuentes