La superficie de ataque de la IA se está ampliando a medida que los modelos obtienen acceso a herramientas, credenciales, código y sistemas de producción. De las investigaciones de F5 Labs publicadas entre abril y julio de 2026 se desprende una conclusión clara: el riesgo que la IA supone para las empresas no depende únicamente de si un modelo puede ser manipulado, sino también de aquello a lo que el sistema que lo rodea le permite acceder y de las acciones que le permite realizar cuando se producen manipulaciones o errores.
La investigación de F5 revela que modelos con capacidades similares pueden presentar perfiles de seguridad radicalmente distintos, que dichos perfiles pueden cambiar tras la implementación, que las funciones útiles pueden crear nuevas vías de ataque y que unos permisos excesivos pueden convertir una vulnerabilidad del modelo en un incidente empresarial. Ese riesgo ya no es teórico. En incidentes analizados por F5 Labs, los atacantes manipularon un proceso de recuperación de cuentas asistido por IA para modificar los datos de acceso, mientras que un agente de programación eliminó una base de datos de producción y sus copias de seguridad.
Para los CISO, el valor de la investigación no reside en un resumen de la clasificación, sino en las lecciones prácticas que aporta para la selección y adquisición de modelos, la garantía continua y el control de aquello a lo que los sistemas de IA pueden acceder y de las acciones que pueden realizar.
F5 Labs utiliza dos métricas complementarias para evaluar estos riesgos. El Índice Integral de Seguridad de la IA de F5 (F5 CASI) mide la resistencia a los ataques de inyección de instrucciones y jailbreak, mientras que la Puntuación de Resistencia Agéntica de F5 (F5 ARS) mide la resistencia a ataques sostenidos y de múltiples pasos en escenarios agénticos. Ambas utilizan una escala de 0 a 100, en la que las puntuaciones más altas indican una mayor resistencia.
“La investigación de F5 revela que modelos con capacidades similares pueden presentar perfiles de seguridad radicalmente distintos, que dichos perfiles pueden cambiar tras la implementación, que las funciones útiles pueden crear nuevas vías de ataque y que un exceso de privilegios puede convertir una vulnerabilidad del modelo en un incidente empresarial.”
La autoridad convierte el riesgo del modelo en impacto empresarial
Una vulnerabilidad a nivel de modelo se convierte en un incidente empresarial cuando el sistema que lo rodea permite realizar acciones con consecuencias. Un modelo que genera una respuesta no segura crea un riesgo. Un modelo conectado a código, credenciales, flujos de recuperación de cuentas o datos de producción puede provocar un incidente.
En uno de los casos analizados por F5 Labs, un agente de programación eliminó una base de datos de producción y sus copias de seguridad. En otro, unos atacantes manipularon un proceso de recuperación de cuentas asistido por IA para cambiar los datos de acceso de cuentas destacadas en redes sociales. El fallo crítico no fue solo que la IA llegara a una conclusión errónea. El sistema circundante permitió que esa conclusión desencadenara una acción de gran impacto.
La operación de ransomware JadePuffer reforzó esta idea desde la perspectiva del atacante. Una persona seleccionó a la víctima, proporcionó las credenciales y estableció la infraestructura, pero el agente automatizó partes importantes del reconocimiento, la explotación, el movimiento lateral y el cifrado. No era necesaria una autonomía total; la automatización parcial ya reducía el tiempo, los conocimientos y el esfuerzo necesarios.
Para los CISO, el riesgo inmediato no reside únicamente en la autonomía, sino también en la autoridad. Los agentes de IA deben gestionarse como identidades privilegiadas, con credenciales de alcance estrictamente limitado, acceso restringido a herramientas, supervisión continua y aprobación independiente para las acciones de gran impacto. La siguiente cuestión es cómo aprovechan los atacantes los comportamientos que hacen que estos sistemas resulten útiles en primer lugar.
Las funciones útiles crean vías de ataque
La investigación de F5 Labs reveló que los atacantes explotaban reiteradamente comportamientos que las empresas buscan activamente en los sistemas de IA. Ataque de rol de desarrollador se centró en cómo los modelos interpretan las instrucciones privilegiadas. BiasJailbreak utilizó un enfoque demográfico para poner de manifiesto incoherencias en el comportamiento de rechazo, mientras que Topic Bridge aprovechó la continuidad de la conversación para llevar gradualmente a los modelos desde temas legítimos hacia solicitudes perjudiciales.
Relatos adversarios amplió el mismo patrón al integrar procedimientos dañinos en narraciones ficticias y pedir a los modelos que analizaran la historia en lugar de responder a una solicitud abiertamente maliciosa. En 26 modelos de vanguardia de nueve proveedores, la técnica alcanzó una tasa media de éxito de los ataques del 71,3 %.
Estos ataques se dirigieron contra la capacidad de seguir instrucciones, el razonamiento contextual, la comprensión de roles y el análisis de contenido, capacidades que sustentan casos de uso empresariales legítimos. Demuestran cómo las funciones útiles pueden ampliar la superficie de ataque de la IA. Los filtros estáticos y las bibliotecas de técnicas de jailbreak conocidas tendrán dificultades cuando los atacantes puedan conservar la intención maliciosa y, al mismo tiempo, cambiar la forma en que se presenta.
Por tanto, los comportamientos útiles pueden abrir la puerta a la manipulación, mientras que la autoridad y el acceso determinan el posible impacto empresarial. La probabilidad de manipulación también depende de la resiliencia intrínseca del modelo, y su capacidad no es un buen indicador de dicha resiliencia.
La capacidad no predice la resiliencia
Las pruebas de F5 Labs revelaron que modelos con capacidades similares pueden situarse en extremos opuestos de la clasificación de seguridad, mientras que los modelos de una misma familia pueden comportarse de forma muy diferente.
El ejemplo más claro fue el de Qwen3.5. Su modelo de 2.000 millones de parámetros obtuvo una puntuación de 1,28 en F5 CASI, mientras que la versión de 4.000 millones de parámetros obtuvo 80, una diferencia de casi 79 puntos entre dos modelos de la misma familia.
Las pruebas más recientes confirmaron este patrón. Los modelos insignia con capacidades relativamente similares obtuvieron puntuaciones de entre 93,08 y 16,25 en F5 CASI. Los datos de F5 ARS aportaron otra dimensión: Qwen3.5-4B obtuvo 91,04 en F5 ARS, pero 58 en F5 CASI, con un rendimiento medio del 16 %. Este contraste demuestra por qué F5 CASI, F5 ARS y el rendimiento deben interpretarse como indicadores distintos y complementarios.
Para los CISO, las pruebas comparativas de capacidades indican si un modelo puede completar una tarea, no si puede hacerlo de forma segura. Cada modelo y versión debe evaluarse de manera independiente durante el proceso de adquisición y a lo largo de todo el despliegue. Sin embargo, la selección del modelo es solo la primera decisión; los equipos de seguridad también deben tener en cuenta cómo cambia la resiliencia con el tiempo.
La postura de seguridad de la IA puede cambiar tras su implementación
La resiliencia de los modelos no es inmutable. F5 Labs observó que un modelo descendió más de 29 puntos F5 CASI en un mes, mientras que otro varió más de 55 puntos durante el periodo analizado. Otras versiones se mantuvieron relativamente estables, por lo que la propia consistencia también forma parte del panorama de riesgos.
Los proveedores pueden actualizar los prompts del sistema, los clasificadores y los controles de seguridad sin cambiar el nombre del modelo que se muestra a los clientes. Por tanto, un modelo puede parecer que no ha cambiado aunque su postura de seguridad se haya modificado sustancialmente.
No se trata de un problema tradicional de aplicación de parches. Una aprobación puntual resulta insuficiente cuando la postura de seguridad de un modelo puede cambiar sin que haya un nuevo nombre de modelo ni un evento de despliegue visible. Los equipos de seguridad deben volver a evaluar los modelos tras las actualizaciones del proveedor, los cambios de configuración y los cambios sustanciales en la aplicación, y comprobar continuamente que los controles complementarios sigan siendo eficaces.
Esa volatilidad hace que la garantía continua sea esencial, pero la evaluación por sí sola no basta. Los CISO también deben controlar a qué pueden acceder los sistemas de IA y qué acciones tienen permitido realizar.
Qué deben hacer ahora los CISO
La conclusión más clara de la investigación es que el nivel de autorización determina el impacto. Los CISO deben gestionar los sistemas de IA en función de aquello a lo que tienen permitido acceder y de las acciones que pueden realizar, al tiempo que evalúan continuamente los modelos, los controles y los sistemas que los rodean.
- Trate a los agentes de IA como identidades privilegiadas. Haga un inventario y restrinja el acceso a credenciales, herramientas, datos y sistemas de producción; exija una aprobación independiente para las acciones de gran impacto; y registre cada paso relevante.
- Evalúe continuamente el sistema de IA completo. Evalúe cada modelo y versión de forma independiente durante el proceso de adquisición y a lo largo de todo el despliegue, vuelva a evaluarlos tras cualquier cambio de proveedor o configuración, y pruebe las pasarelas, los paquetes, los complementos, los flujos de trabajo, las identidades y las integraciones, no solo el modelo.
Cómo mide F5 Labs la resiliencia de la IA
F5 CASI y F5 ARS son medidas comparativas, no certificaciones de seguridad permanentes. Los resultados deben interpretarse teniendo en cuenta la versión exacta del modelo, la fecha de evaluación, el uso previsto y los controles complementarios.
En conjunto, la investigación revela una cadena de riesgos interconectados: la capacidad no permite predecir la resiliencia, la resiliencia puede cambiar tras el despliegue, las funcionalidades útiles pueden ampliar la superficie de ataque de la IA y un exceso de autoridad puede convertir una debilidad del modelo en un incidente empresarial.
La cuestión para los CISO ya no es solo si un modelo de IA puede ser manipulado, sino qué permitirá hacer a ese modelo el sistema que lo rodea cuando la manipulación tenga éxito.
Más información
- Consulta las últimas clasificaciones de seguridad de IA de F5 CASI y F5 ARS para comparar la resiliencia de los modelos y hacer un seguimiento de cómo evoluciona la postura de seguridad de la IA con el tiempo.
- Descubre cómo F5 AI Red Team ayuda a las organizaciones a probar modelos, aplicaciones y agentes frente a ataques reales.
- Descubra la F5 AI Security Platform para obtener visibilidad, gobernanza y protección continuas en todas las aplicaciones, modelos y agentes de IA de la empresa.
Sobre los autores
Malcolm Heath es investigador principal de amenazas en F5 Labs. A lo largo de su carrera, ha trabajado en respuesta a incidentes, gestión de programas, pruebas de penetración, auditoría de código, investigación de vulnerabilidades y desarrollo de exploits en empresas tanto muy grandes como muy pequeñas. Antes de incorporarse a F5 Labs, fue ingeniero sénior de seguridad en el SIRT de F5.
Más artículos de Malcolm HeathLouise Scully es directora sénior de Marketing de Producto para Seguridad de la IA e Inteligencia de Amenazas en F5. A lo largo de su carrera, ha trabajado en marketing de producto, gestión de producto, estrategia de comercialización, comunicación, liderazgo de opinión y desarrollo de categorías en los ámbitos de la seguridad de la IA y la tecnología empresarial. Antes de incorporarse a F5, Louise dirigió el área de marketing tanto en CalypsoAI como en Artomatix, contribuyendo a llevar al mercado tecnologías e investigaciones de IA.
Más artículos de Louise ScullyArtículos relacionados del blog
IA agéntica en ciberseguridad: promesas y riesgos
Descubre por qué el uso de la IA agéntica en ciberseguridad es esencial para combatir las amenazas impulsadas por IA y por qué los agentes también generan nuevos riesgos empresariales.
Cómo los clientes de F5 del sector financiero abordan la soberanía digital sin frenar la innovación
¿Cómo se materializa la soberanía digital en el mundo real? Dos proyectos recientes de F5 con clientes muestran cómo distintas empresas están afrontando estos retos.
Soberanía operativa: cómo desarrollar resiliencia en un mundo impredecible
Para muchas organizaciones, la cuestión ya no consiste únicamente en controlar los datos, sino en mantener la capacidad de operar, adaptarse y recuperarse a medida que evolucionan las leyes y las circunstancias.
No se puede proteger una conversación con un cortafuegos: cómo el red teaming de IA se volvió esencial
Dado que las implementaciones de IA avanzan a la velocidad de las máquinas, los métodos tradicionales de prueba de software ya no resultan adecuados.
Protege tu canalización de datos de IA sin ralentizarla
Proteger el flujo de datos de la IA no es opcional. Eso está claro. Lo que resulta mucho menos evidente —y mucho más difícil— es cómo protegerlo adecuadamente.
Las extranets no están muertas; solo necesitan una actualización
Modernice su extranet: descubra cómo F5 y Equinix ofrecen una conectividad para partners repetible, segura y escalable, sin la complejidad de las redes tradicionales.