La IA empresarial está entrando en una fase diferente. La brecha de rendimiento entre los modelos líderes se está reduciendo, pero la brecha de seguridad no. Los datos más recientes del Índice integral de seguridad de la IA (CASI) de F5 Labs muestran que la capacidad y la resiliencia frente a ataques divergen cada vez más, mientras que los resultados de la puntuación de resistencia agéntica de F5 (ARS) muestran que la resiliencia puede volver a variar cuando los modelos se someten a pruebas en escenarios agénticos de varios pasos a lo largo del tiempo.
Para los CISO, esto cambia la naturaleza de la selección de modelos. La cuestión no es simplemente qué modelo ofrece el mejor rendimiento, sino si sus características de seguridad son adecuadas para la función que desempeñará, el nivel de autoridad que tendrá y las consecuencias en caso de que sea manipulado con éxito.
No existe un único indicador de referencia de seguridad que permita determinar si un modelo es adecuado para una implementación concreta. Los resultados de septiembre de F5 CASI y F5 ARS lo dejan claro: solo tres modelos se sitúan entre los diez primeros de ambas clasificaciones. Para los CISO, esto implica que las pruebas de seguridad utilizadas para aprobar un modelo deben reflejar cómo funcionará realmente, incluidos su nivel de autonomía, su acceso a datos y herramientas, y el posible impacto empresarial en caso de que se vea comprometido.
“Los últimos hallazgos de F5 dejan claro que, antes de implementar modelos de IA, las organizaciones deben saber qué propiedades de seguridad se han evaluado realmente, cuáles no y si los controles del entorno son suficientes para afrontar el riesgo residual.”
Esto se basa en una serie de hallazgos que hemos seguido a lo largo del año. En una publicación anterior del blog de F5, analizamos por qué las pruebas de seguridad cuantificables deben tenerse en cuenta en la selección y adquisición de modelos antes de aprobarlos. En otra publicación del blog, examinamos una investigación de F5 Labs que muestra por qué las consecuencias de un fallo del modelo dependen en gran medida de aquello a lo que el sistema circundante le permite acceder y de las acciones que le permite realizar.
Nuestras investigaciones más recientes sobre amenazas y las clasificaciones de agosto y septiembre aúnan estas ideas: los CISO necesitan datos objetivos tanto sobre el propio modelo como sobre el entorno en el que este funcionará.
Un patrón observado en los datos de septiembre resulta especialmente revelador. Anthropic ocupa los cinco primeros puestos de F5 CASI, mientras que los diez primeros puestos de F5 ARS se reparten entre cinco modelos de OpenAI, cuatro de Anthropic y uno de MiniMax. En conjunto, las clasificaciones demuestran por qué la reputación del proveedor, la familia del modelo y el rendimiento no son indicadores fiables del tipo específico de resiliencia que requiere una implementación. Para los CISO, esto significa que las pruebas de seguridad a nivel de modelo deben fundamentar la decisión de implementación desde el principio.
El rendimiento no es una medida de seguridad
Los resultados recientes de F5 Labs muestran una brecha persistente entre lo que un modelo es capaz de hacer y su resistencia frente a los ataques. En agosto, GLM-5.2 ocupó el cuarto puesto de 31 modelos en cuanto a capacidad, pero el 24.º en F5 CASI; DeepSeek V4 Flash ocupó el sexto puesto en capacidad y el 28.º en F5 CASI. Grok 4.5 mostró la misma divergencia entre los modelos cerrados. El patrón dependía del modelo concreto, no del proveedor ni de la licencia.
Los resultados de seguridad pueden presentar divergencias igual de marcadas. Tres modelos Qwen3.5 obtuvieron puntuaciones F5 ARS de 91,04, 89,81 y 88,23, mientras que sus correspondientes puntuaciones F5 CASI fueron de 58, 31 y 53 (la puntuación perfecta en ambas clasificaciones es 100). La conclusión no es que una métrica tenga más autoridad que la otra, sino que revelan distintas vulnerabilidades ante diferentes formas de ataque.
Esto cambia la forma en que deben utilizarse las evaluaciones comparativas de modelos en un proceso de aprobación. El rendimiento puede ayudar a reducir la lista de candidatos, pero no basta para justificar la seguridad de su despliegue. Un buen resultado en una única métrica de seguridad también debe interpretarse en su contexto. Las pruebas deben reflejar la función que desempeñará el modelo, el grado de autonomía que tendrá y los sistemas a los que podrá acceder.
En un informe de julio de 2026, Gartner analizó la creciente importancia de la seguridad comparativa. Los datos recientes aclaran los motivos: la selección de modelos debe tener en cuenta no solo lo que un modelo puede hacer, sino también en qué punto empieza a fallar su resiliencia.
Mida en qué puede confiar el modelo
Uno de los hallazgos más relevantes del estudio de agosto se refiere a una capacidad que las empresas buscan activamente: la posibilidad de trabajar conforme a las políticas y normas proporcionadas.
«Dilema moral», un ataque analizado por F5 Labs, aprovecha ese comportamiento. En lugar de ocultar una instrucción maliciosa, el atacante proporciona una regla engañosa y pide al modelo que razone a partir de ella. La tasa media de éxito del ataque osciló entre el 44,8 % contra Llama 3.1 8B y el 91,1 % contra Gemini 2.5 Pro. F5 Labs también señaló el bajo rendimiento de los modelos de protección a nivel de prompt frente a esta técnica.
La cuestión de seguridad radica en si un modelo puede seguir instrucciones y, al mismo tiempo, distinguir cuáles está autorizado a considerar vinculantes. Se puede confiar en un documento recuperado como fuente de información sin considerarlo una directriz fiable. La respuesta de una herramienta puede proporcionar datos sin tener autoridad para redefinir lo que un agente puede hacer con ellos.
Para los CISO que evalúan modelos antes de su implementación, los equipos deben saber de dónde procede el contexto externo y qué fuentes pueden influir en el comportamiento del modelo.
Un prompt no es un límite de seguridad
La misma investigación pone de relieve dónde termina la gobernanza de los modelos y comienza la arquitectura de seguridad. F5 Labs examinó tres casos en los que los agentes traspasaron los límites de sus entornos de evaluación previstos. En uno de ellos, un agente que supuestamente no debía tener acceso a Internet más allá de un proxy de registro de paquetes encontró una vulnerabilidad de día cero en dicho proxy, llegó a un nodo conectado a Internet y obtuvo acceso para ejecutar comandos como usuario raíz en un entorno aislado externo. En otros casos, la conectividad seguía activa pese a que se había indicado a los modelos que estaban operando sin acceso a Internet, y se produjo una fuga de un entorno aislado debido a una configuración incorrecta de la red.
El problema común no era simplemente que un agente ignorase una instrucción. El propio límite se había dado por supuesto, se había descrito o se había implementado de forma incorrecta. La implicación práctica es clara: decidir qué se debe permitir hacer a un agente solo tiene sentido si el entorno impone ese mismo límite.
Los datos de identidad refuerzan esta idea. GitGuardian encontró 4576 tokens únicos de la API de n8n en commits públicos de GitHub; de las 896 instancias accesibles, 321 aceptaron al menos un token expuesto. No fue necesario explotar ninguna vulnerabilidad de software. Dado que esos flujos de trabajo pueden conectarse con sistemas de control de código fuente, servicios en la nube, bases de datos y aplicaciones SaaS, la exposición puede extenderse mucho más allá del propio flujo de trabajo.
Por tanto, la cuestión no es solo si un agente puede ser manipulado, sino también qué podría ocurrir si lo fuera. El acceso a la red, las herramientas, las credenciales y los sistemas posteriores determinan el alcance del impacto. Estos controles deben existir con independencia de lo que se le haya indicado al modelo que puede o no puede hacer.
Los modelos de pesos abiertos cambian dónde recae la responsabilidad
El informe de F5 Labs, «Modelos chinos de IA de pesos abiertos: riesgos y ventajas para la ciberseguridad», añade otra consideración a la hora de seleccionar un modelo: «pesos abiertos» no constituye por sí solo una calificación de seguridad.
En julio, Qwen3.5-397B-A17B obtuvo una puntuación de 81,13 en F5 CASI, Xiaomi MiMo-V2.5 obtuvo 73,80 y GLM-5.2, 46,58. Esta disparidad resulta más útil que cualquier conclusión general sobre la categoría. Demuestra por qué la familia del modelo, el proveedor y el modelo de licencia no sustituyen adecuadamente las pruebas del modelo concreto que se está considerando.
Lo que sí cambia con el despliegue de modelos de pesos abiertos es en quién recae la responsabilidad. Un mayor control sobre la ubicación de los datos, la infraestructura y la personalización también implica una mayor responsabilidad en cuanto a la procedencia, la aplicación de parches, el registro de eventos y la integridad de los artefactos del modelo. F5 Labs recomienda tratar los artefactos del modelo como componentes de entrada de la cadena de suministro de software, lo que incluye verificar su procedencia, fijar versiones de confianza y analizar los artefactos antes del despliegue.
Por tanto, la decisión no depende tanto de si un modelo abierto o cerrado es intrínsecamente más seguro, sino de qué riesgos está preparada la organización para asumir.
Qué deben medir los CISO antes de la implementación
Los hallazgos recientes desaconsejan tratar la seguridad de los modelos como un único punto de aprobación. Una revisión útil previa al despliegue debe responder a una serie de preguntas:
- Capacidad y resiliencia frente a ataques adversarios: ¿Puede el modelo realizar la tarea y cómo se comporta ante los ataques pertinentes para dicha tarea?
- Resiliencia a nivel de prompt y de los agentes: ¿Reflejan las pruebas cómo funcionará realmente el modelo, especialmente cuando intervienen herramientas, credenciales o acciones autónomas?
- Autoridad de las instrucciones: ¿Qué sistemas pueden proporcionar contexto y cuáles de ellos tienen permitido influir en las políticas o el comportamiento?
- Límites impuestos: ¿Qué queda técnicamente fuera del alcance del modelo, independientemente de lo que le indique un prompt?
- Identidad y procedencia: ¿En qué credenciales, versiones de modelos y artefactos se confía, y cómo se gestionan?
- Reevaluación: ¿Qué cambios invalidarían la aprobación original, incluidas las actualizaciones del modelo, las nuevas herramientas, los cambios en los permisos o las nuevas técnicas de ataque?
Al responder a estas preguntas, los CISO evitarán reducir varias decisiones de riesgo diferentes a una única cuestión sobre si un modelo es «seguro» o no.
Cómo F5 Labs mide la resiliencia de la IA
F5 CASI y F5 ARS deben entenderse como evidencias, no como certificaciones. F5 CASI mide la vulnerabilidad frente a ataques habituales de inyección de instrucciones y jailbreak, mientras que F5 ARS analiza la resiliencia en escenarios de agentes autónomos y de varios pasos. Las clasificaciones de septiembre de 2026 ofrecen la comparativa más reciente de ambas métricas.
Una puntuación resulta más útil cuando se vincula al despliegue que se está considerando. No puede indicar a una organización si un agente tiene privilegios excesivos, si un entorno aislado está configurado correctamente o si una fuente externa puede introducir instrucciones en las que el modelo no debería confiar. Sí puede proporcionar a los equipos de seguridad información específica sobre cómo se comportó ese modelo en condiciones adversas definidas.
Ese es el hilo conductor de esta serie de investigaciones. Y los últimos hallazgos de F5 dejan claro que, antes de implementar modelos de IA, las organizaciones deben saber qué propiedades de seguridad se han evaluado realmente, cuáles no y si los controles del entorno son suficientes para afrontar el riesgo residual.
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 los cambios a lo largo del tiempo.
- Descubra la F5 AI Security Platform para proteger los modelos, las aplicaciones y los agentes de IA de toda 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.