El informe de Azul sobre la brecha de vulnerabilidades de IA de 2026 revela que las empresas están rezagadas en la aplicación de parches frente a las amenazas de IA

El Informe de 2026 sobre la brecha de vulnerabilidades de IA de Azul revela una discrepancia entre la rapidez que los responsables de seguridad atribuyen a los atacantes que utilizan IA y el tiempo que necesitan sus organizaciones para implementar correcciones. En una encuesta a 300 responsables de seguridad de Estados Unidos, el 69 % afirmó que los atacantes podrían crear un exploit funcional en un plazo de tres días, mientras que el 44 % indicó que sus organizaciones necesitan cuatro días o más para aplicar parches a una vulnerabilidad crítica en los entornos de producción.

El hallazgo más llamativo del informe es la experiencia que los encuestados vinculan con esos retrasos: el 85 % declaró haber sufrido un incidente, un presunto incidente o un incidente que estuvo a punto de ocurrir debido a la lentitud en la aplicación de parches. Esta cifra refleja experiencias declaradas, no una tasa de brechas verificada de forma independiente, y tampoco demuestra que la IA haya causado esos sucesos.

La investigación, encargada por Azul y realizada por Censuswide, se centra en organizaciones con despliegues de Java de gran envergadura. Su mensaje general es de carácter operativo: detectar una vulnerabilidad es solo el comienzo. Una corrección debe superar las pruebas, llegar a los sistemas afectados y cerrar la exposición en todo un parque de sistemas que los equipos quizá no alcancen a ver por completo.

Dos relojes que no están sincronizados

La encuesta distingue entre las expectativas de los responsables sobre los atacantes y la capacidad de sus propias organizaciones para implementar parches:

• El 69 % cree que los atacantes que utilizan IA pueden crear un exploit en tres días o menos; el 22 % considera que pueden hacerlo en menos de 24 horas.
• El 56 % afirma que puede implementar un parche crítico en los entornos de producción en un plazo de tres días: el 13 % en menos de 24 horas y el 43 % en uno a tres días.
• El 44 % necesita más tiempo: el 32 % requiere de cuatro a seis días y el 12 %, más tiempo.

Se trata de distribuciones de las respuestas a la encuesta, no de mediciones de atacantes que compiten con organizaciones concretas por explotar las mismas vulnerabilidades. La diferencia justifica la preocupación por el nivel de preparación, pero no debe interpretarse como un plazo preciso de exposición de tres días para todas las empresas.

El mismo desequilibrio se observa al considerar el umbral de un día: el 22 % espera que los atacantes actúen con esa rapidez, frente al 13 % que afirma que su organización puede implementar una corrección dentro de ese plazo. Mientras tanto, el 59 % reconoce que las herramientas de ataque basadas en IA aumentan la exposición, pero no ha modificado su postura de seguridad.

Las pruebas son una parte importante del retraso

En el 58 % de las organizaciones encuestadas, probar las actualizaciones del entorno de ejecución de Java añade cuatro días o más al ciclo de aplicación de parches. Esto incluye al 36 %, que declaró necesitar de cuatro a seis días, y al 22 %, que indicó una semana o más. Otro 33 % señaló que necesitaba de uno a tres días, y el 9 %, menos de 24 horas. Ningún encuestado afirmó que se omitieran las pruebas.

Los cambios en el entorno de ejecución pueden afectar a muchas aplicaciones, por lo que las pruebas tienen una finalidad práctica: una actualización de seguridad que interrumpa un servicio crítico crea otro problema operativo. El informe sostiene que el alcance de las actualizaciones contribuye a esa carga, porque las versiones trimestrales completas de OpenJDK pueden incluir cambios no relacionados con la seguridad junto con las correcciones de vulnerabilidades.

Por separado, Azul evaluó 26 actualizaciones trimestrales de OpenJDK a lo largo de más de seis años y clasificó seis como causantes de una regresión grave. Esa cifra del 23 % corresponde a la evaluación de versiones realizada por el proveedor; no es una estimación basada en encuestas de la frecuencia con que podría fallar la aplicación de un cliente concreto.

Entre los principales obstáculos declarados para agilizar la aplicación de parches, el 44 % menciona las pruebas exhaustivas, el 40 % la complejidad o antigüedad de los sistemas afectados y el 36 % la visibilidad limitada de las vulnerabilidades conocidas. El 25 % mencionó los retrasos de los proveedores en la publicación de parches. Este patrón sitúa buena parte del reto de remediación en el propio proceso de implementación de las empresas.

Los informes de incidentes y las carencias de inventario requieren interpretaciones distintas

El 55 % declara haber sufrido un incidente confirmado debido a la lentitud en la aplicación de parches, y el 53 % informa de un incidente que estuvo a punto de ocurrir. Los encuestados podían seleccionar varias respuestas, por lo que estas cifras se superponen y no deben sumarse. La cifra general del 85 % que destaca el informe también incluye los presuntos incidentes.

La encuesta no demuestra que todos esos sucesos estuvieran relacionados con vulnerabilidades de Java. Los participantes trabajan en organizaciones que utilizan Java de forma intensiva, pero la investigación incluye tanto preguntas generales sobre la aplicación de parches de software como preguntas específicas sobre los entornos de ejecución de Java.

El inventario plantea una segunda dificultad. Solo el 19 % afirma que al menos el 90 % de los entornos de ejecución de Java de producción de su organización cuenta con el nivel más reciente de parches de seguridad. Esto significa que el 81 % está por debajo de ese umbral; no significa que el 81 % no tenga ningún entorno de ejecución actualizado. Aproximadamente una de cada cinco organizaciones afirma que la mitad o menos de sus entornos está actualizada.

Por otra parte, el 51 % reconoce tener una visibilidad parcial o limitada de los entornos de ejecución de Java críticos, incluidos los integrados, heredados y no gestionados. Puede ser más difícil encontrar un entorno de ejecución vulnerable dentro de una aplicación empaquetada o un contenedor que identificar una instalación gestionada de forma centralizada. Un parche no puede cerrar la exposición de un sistema al que nunca llega el proceso de implementación.

Qué aporta la tecnología de Azul a este debate

La oferta de Azul de actualizaciones de seguridad limita algunas versiones a correcciones de seguridad sobre una versión base de OpenJDK previamente estabilizada. La empresa ofrece actualizaciones trimestrales, mensuales específicas y fuera del ciclo habitual, con el objetivo de reducir la cantidad de cambios no relacionados que las empresas deben evaluar al implementar una corrección urgente.

Se trata de una intervención técnica más acotada que eliminar la necesidad de controlar los cambios. Limitar los cambios en el código puede reducir el alcance de la validación, pero siguen siendo importantes las comprobaciones específicas de cada aplicación, la responsabilidad sobre los despliegues y la preparación para revertirlos. Azul patrocina el informe y vende productos que abordan los problemas que este mide.

Sus herramientas de inventario de Java y de gestión de vulnerabilidades abordan la otra parte del proceso: identificar entornos de ejecución, versiones y exposición para determinar qué sistemas se ven afectados por una nueva vulnerabilidad divulgada. El informe no presenta una comparación controlada que demuestre cuánto mejorarían las organizaciones encuestadas al adoptar esos productos.

«Nuestra investigación demuestra que los responsables de seguridad comprenden la amenaza: la brecha ya no está en la concienciación, sino en la ejecución», afirmó Scott Sellers, cofundador y director ejecutivo de Azul.

Convertir la intención de aplicar parches en un proceso medible

De cara al próximo año, el 32 % señala que aplicar parches con mayor rapidez y frecuencia es su principal estrategia para reducir la exposición, mientras que el 26 % opta por mejorar el inventario de software y entornos de ejecución. Otro 17 % da prioridad a la detección y la respuesta en lugar de aplicar parches con mayor rapidez.

La investigación sugiere hacer un seguimiento de todo el proceso, desde la divulgación hasta la corrección: qué sistemas están afectados, quién es responsable de ellos, qué pruebas se requieren y si la corrección llegó efectivamente a producción. Un plazo solo es útil si los equipos pueden verificar que se cumplió en todos los sistemas pertinentes.

Los resultados de Estados Unidos se basan en un trabajo de campo realizado del 3 al 7 de agosto de 2026 entre responsables de seguridad de organizaciones con al menos 1.000 empleados y un uso significativo de Java/JVM en producción. Se trata de respuestas autodeclaradas de una población definida, no de un censo de empresas ni de una medición directa del desarrollo de exploits.

El Informe sobre la brecha en vulnerabilidades de IA de 2026 completo detalla los resultados y la metodología. Su conclusión más clara es que la velocidad de aplicación de parches y la visibilidad de los entornos de ejecución deben mejorar a la vez: una corrección rápida tiene un valor limitado si la organización no puede identificar todos los despliegues afectados o confirmar que la actualización llegó a ellos.