Azul lanza un asistente de IA que audita el riesgo del parque Java en producción
La compañía monta una capa conversacional sobre su inventario de JVM y de código en ejecución para localizar vulnerabilidades y licencias de Oracle que los informes estáticos ya no reflejan.
Azul ha metido un asistente de IA dentro de su Intelligence Cloud. La idea se enuncia rápido: que un ingeniero pregunte en lenguaje natural dónde está el riesgo en su parque Java de producción y reciba la respuesta con datos del runtime, no de un documento de hace tres semanas. El anuncio es del miércoles.
El problema que dice atacar lo conoce cualquiera que haya hecho inventario de JVM. Los informes de ITAM/SAM y los escáneres de código fotografían un instante. A partir de ahí empeoran: se levantan máquinas virtuales nuevas, se parchean otras, hay hosts que derivan de su configuración y nodos que se jubilan sin que nadie toque el documento. Azul sostiene que siguen siendo la herramienta habitual de la mayoría de equipos. «Durante años las empresas han construido paneles e informes para entender qué corre de verdad en su parque Java, pero cuando el informe se resume y se revisa, el riesgo que describe ya ha cambiado», dice Scott Sellers, cofundador y consejero delegado. «Eso era un problema de productividad. Ahora que la IA puede encontrar y explotar una vulnerabilidad en horas en vez de semanas, es un riesgo de negocio: de seguridad, de cumplimiento y de exposición de licencias en una auditoría».
Cómo funciona
El asistente se apoya en dos inventarios que Azul actualiza de forma continua. JVM Inventory cataloga cada instancia en ejecución, esté en local, en nube o en contenedor. Code Inventory registra qué código se ejecuta de verdad frente al que solo está desplegado. Encima va una capa conversacional con modelos de lenguaje, que además permite consultar el histórico. Los ejemplos que da la compañía son del tipo: qué JVM corren versiones de Java que no son las últimas actualizaciones, dónde queda Oracle Java corriendo en producción ahora mismo, o qué código no se ha ejecutado en los últimos cuatro trimestres y se puede borrar.
La urgencia la pone un dato. Azul cita un documento del Cloud Security Alliance de abril de 2026, marcado como investigación asistida por IA y no oficial, según el cual la mediana de tiempo hasta la explotación de una vulnerabilidad ha pasado de unos 32 días a unos 5 días en 2025.
Un mercado concurrido
No está solo. Contrast Security vende agente de JVM e instrumentación de bytecode en la aplicación; Runtime Vulnerability Analytics es la extensión de observabilidad de Dynatrace, con OneAgent sobre funciones vulnerables de Java; Fortify, hoy en OpenText tras pasar por HP y Micro Focus, mantiene su agente RASP para vigilar cargas Java en ejecución; Imperva cubre seguridad en runtime para Java y .NET, aunque su RASP independiente va camino del fin de venta; y Datadog entra por APM con trazas distribuidas hasta el código.
Andrew Krug, responsable de advocacy de seguridad en Datadog, señala a este medio que el problema de los escaneos puntuales es que «no siempre son representativos» del entorno en ejecución, y añade que incluso en ciclos de desarrollo maduros las herramientas que generan SBOM estáticos se pueden sortear para desplegar una funcionalidad. Fuera del CI/CD, subir una versión a mano rompe las barandillas y añade riesgo.
Lo interesante no es la interfaz conversacional, sino el drift. Un rollback, un nodo olvidado, un despliegue en sombra o un script que nadie actualizó devuelven una JVM de Oracle a producción, y con ella la exposición de licencia. El asistente promete señalarlo en el momento. Falta ver cómo se comporta el inventario en parques grandes y con equipos que ya tienen su propio stack de observabilidad.
