Inteligencia de riesgos de modelos de IA: descubre en qué modelos puedes confiar antes de implementarlos

Cuando empezamos a pensar en cómo mostrar el riesgo de los modelos de IA en Evo, la respuesta obvia fue seguir el enfoque que usamos para evaluar todo lo demás: encontrar el problema, asignarle una gravedad y mostrarlo. Listo.

La base del nuevo enfoque es una puntuación de riesgo real, creada según la forma en que los equipos de seguridad ya evalúan el riesgo: Probabilidad × Impacto. La probabilidad se basa en la tasa de éxito de los ataques (ASR), es decir, la proporción de ataques adversariales reales que logran vulnerar un modelo. El impacto mide el daño que causa el objetivo del atacante cuando tiene éxito. Combinamos ambos factores en una sola puntuación de 0 a 1000 (cuanto menor, mejor).

Como se multiplican entre sí, ninguno de los dos factores prevalece por sí solo: un ataque poco frecuente, pero catastrófico, se ve atenuado por su baja probabilidad, y uno frecuente, pero inofensivo, por su bajo impacto. Lo que queda en primer plano es lo que más importa: los ataques que tienen éxito con frecuencia y causan daños reales cuando lo hacen.

Nueva metodología de puntuación de riesgos

Lo que la diferencia de una lista de verificación o una ficha de seguridad del proveedor es que la ASR se calcula a partir de pruebas adversariales reales, como prompts de extracción, escalamiento en varios turnos, jailbreaks basados en roles y estrategias de árbol de ataque. Además, evaluadores basados en modelos confirman si cada ataque tuvo éxito.

No son situaciones teóricas ni cifras de modelos «sin protección». Cada ataque de la prueba de referencia se ejecuta contra una defensa de referencia que refuerza las instrucciones del sistema. Así, la puntuación de riesgo refleja lo que logra superar una barrera de seguridad estándar ya implementada: los ataques que funcionan en producción, no solo en un laboratorio.

La puntuación es útil para tomar medidas porque se centra en el impacto: se basa en lo que realmente sale mal cuando un ataque tiene éxito, no solo en si tuvo éxito. Y no se queda en una cifra. Evo desglosa cada puntuación según el objetivo específico del atacante: extracción de información de identificación personal (PII), extracción de instrucciones del sistema mediante inyección y generación de código inseguro. Así puedes ver exactamente en qué puntos es vulnerable un modelo y crear la barrera de seguridad adecuada. Ese nivel de detalle es la señal que necesitas antes de decidir implementarlo.

Esto les resulta útil de inmediato a los equipos de seguridad. Ven el desglose del riesgo de un modelo según los objetivos específicos de los atacantes frente a los que falla, en lugar de un veredicto abstracto de «seguro o inseguro». Ya no tienen que preguntarse si el modelo es seguro en general; pueden empezar a preguntarse si es seguro para lo que están por crear.

Ese primer impulso de encontrar el problema, asignarle una gravedad y seguir adelante tenía un problema grave, y nuestros clientes nos lo hicieron saber directamente.

Cuando los equipos de seguridad veían un hallazgo que indicaba que un modelo tenía un problema de «divulgación de información», siempre hacían la misma pregunta: ¿Qué significa eso en realidad y qué hago al respecto? La etiqueta les indicaba que algo estaba mal, pero no les decía qué tan grave era, en qué contexto, frente a qué tipo de ataque ni qué debían crear para solucionarlo.

Así que lo rediseñamos. Esto es lo que cambió y por qué.

La brecha se hizo evidente una y otra vez en las llamadas con clientes. Cuando empezamos a mostrar cifras concretas —GPT-3.5 con una puntuación de 397/1000 en contenido inseguro y GPT-4 con 317/1000 en sesgo y equidad—, los equipos dejaron de preguntar si un modelo era seguro y empezaron a compararlos.

El problema no es la puntuación, sino el contexto.

La mayoría de las evaluaciones de riesgos de IA tratan un modelo como un artefacto estático: ejecutan algunas pruebas, asignan una categoría y publican una ficha de seguridad. Los equipos la consultan e intentan decidir si implementan el modelo.

Pero el riesgo de la IA no funciona así. Un mismo modelo conlleva riesgos fundamentalmente distintos según cómo se implemente. Un agente de programación se enfrenta al robo de credenciales, las puertas traseras, los comandos controlados por atacantes y el envenenamiento de dependencias. Un chatbot de atención al cliente se enfrenta a jailbreaks, generación de contenido dañino y extracción de prompts. Un asistente personal con acceso al correo electrónico, el calendario y los documentos se enfrenta a una superficie de ataque completamente distinta.

Una puntuación de riesgo que no refleja el contexto de implementación no es una puntuación de riesgo. Es una suposición. Evo incorpora ese contexto en la ponderación del impacto, para que la puntuación refleje cómo se usará realmente un modelo, no cómo se comporta en el vacío.

Hay un segundo problema: los ataques indirectos. La mayoría de las evaluaciones de modelos se centran en prompts directos: un usuario escribe algo malicioso y vemos si el modelo se resiste. Eso importa, pero deja de lado la clase más peligrosa de ataques dirigidos a sistemas con agentes: la inyección indirecta de prompts inserta instrucciones maliciosas en los datos que lee el agente, como un documento recuperado, el resultado de una herramienta o un comentario en el código. El usuario nunca las ve. El agente las procesa como contexto. Si el modelo sigue esas instrucciones, puede filtrar datos confidenciales, usar herramientas de forma indebida o realizar acciones no autorizadas. Las pruebas que solo evalúan el modelo nunca detectan esto.

No se trata de una preocupación teórica. Una empresa acudió a nosotros por un incidente urgente provocado específicamente por el riesgo de un modelo LLM y, en un banco global, un problema similar llegó hasta el director ejecutivo. Una entidad crediticia nacional quería tener visibilidad del uso de MCP e incorporar barreras de seguridad. Estos equipos no preguntaban por la seguridad de los modelos en abstracto, sino por su comportamiento en un contexto específico con agentes.

Queríamos que Risk Intelligence respondiera a otra pregunta: ¿cómo se comporta este modelo bajo ataque en la forma en que realmente planeas implementarlo?

Lo que creamos: riesgo basado en el impacto, hasta el objetivo del atacante

1. ¿Qué modelos y habilidades de IA se usan en toda la base de código? Los equipos de seguridad necesitan saber dónde se usa la IA, qué modelos se invocan y qué habilidades o herramientas forman parte del sistema.

2. ¿Cómo se comporta cada modelo bajo ataque? Los equipos necesitan perfiles de riesgo basados en pruebas adversariales, no en afirmaciones estáticas ni documentación genérica de seguridad.

3. ¿Cómo podemos actuar según los hallazgos? Una puntuación solo es útil si ayuda a los equipos a comparar modelos, priorizar barreras de seguridad y aplicar políticas en todas las aplicaciones y repositorios.

El resultado principal es una sola puntuación de riesgo de 0 a 1000, ponderada según el impacto real de lo que puede lograr un atacante. La tasa de éxito de los ataques es la señal medida que la sustenta.

La puntuación te indica qué tan expuesto está un modelo. La taxonomía muestra qué ataques contribuyeron a ella y por qué son relevantes para tu implementación.

Evo organiza los hallazgos en una taxonomía de tres niveles basada en el impacto, es decir, en lo que realmente sale mal. Una categoría de impacto de nivel superior (por ejemplo, divulgación de información) se divide en una subcategoría y luego en el objetivo específico del atacante, con el mayor nivel de detalle (por ejemplo, extracción de PII). Los ataques directos e indirectos se registran como superficies distintas en toda la taxonomía porque requieren defensas diferentes. Un agente de programación con una ASR alta ante inyección indirecta mediante comentarios en el código necesita una barrera de seguridad distinta a la de un chatbot con una ASR alta ante jailbreaks. La taxonomía deja clara esa diferencia.

Además, cada objetivo del atacante se vincula con los marcos que tu equipo ya usa para sus informes: OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS y NIST. Así, los hallazgos no quedan etiquetados con términos exclusivos de Snyk que debas traducir; se integran directamente en los estándares por los que ya te riges. Verás esa correspondencia en la pestaña del perfil de riesgo, junto con la puntuación.

Ese nivel de especificidad permite que los equipos pasen de una puntuación a un plan de corrección. También permite que Evo conecte directamente los hallazgos de riesgos con la aplicación de políticas, como parte del mismo flujo de trabajo y no de uno aparte.

Cobertura de habilidades, no solo de modelos

Las etiquetas generales de riesgo no bastan. Decirle a un equipo que un modelo tiene un problema de «divulgación de información» o «contenido inseguro» puede generar conciencia, pero no indica qué debe corregir. La inteligencia de riesgos útil desglosa cada hallazgo hasta llegar al objetivo específico del atacante. Por ejemplo: extracción de instrucciones del sistema mediante inyección, ejecución de herramientas sin autorización, generación de contenido dañino, generación de código inseguro o exfiltración de datos confidenciales.

Ese nivel de detalle ayuda a los equipos a decidir qué barreras de seguridad crear, qué políticas aplicar y si un modelo es adecuado para un caso de uso determinado. También ayuda a los líderes a entender los riesgos desde distintos niveles. Una categoría general puede mostrar en qué áreas está expuesta la organización. Una superficie de ataque más detallada puede mostrar si los ataques son directos o indirectos. Un objetivo específico del atacante puede indicarle a los equipos de ingeniería exactamente qué falló.

El riesgo no reside solo en los modelos. Reside en la combinación de un modelo, las herramientas que puede invocar y las habilidades que usa. Un modelo que obtiene buenos resultados de forma aislada puede comportarse de manera muy distinta al combinarse con una herramienta de sistema de archivos, un entorno de ejecución de código o un almacén de datos confidenciales.

Evo muestra la cobertura de habilidades junto al riesgo de los modelos y ofrece a los equipos una visión clara de qué habilidades están en uso, a qué modelos están asociadas y cómo es la superficie de ataque combinada. Es la vista de inventario que los equipos de seguridad necesitan antes de tomar decisiones de implementación con confianza.

Esto es especialmente relevante para los agentes de programación, donde el mismo modelo puede revisar pull request en un momento y ejecutar comandos de implementación al siguiente. El perfil de riesgo cambia significativamente según lo que hace el modelo y las herramientas a las que tiene acceso mientras lo hace.

De la evidencia a la aplicación de políticas

Evo está diseñado para ayudar a los equipos a entender cómo se comportan los modelos bajo ataque antes de confiarles tareas en producción. Al analizar una base de código, Evo identifica los modelos y las habilidades de IA en uso y los complementa con perfiles de riesgo basados en pruebas adversariales. Estos perfiles se basan en la tasa de éxito de los ataques, medida frente a ataques adversariales reales y ponderada según su impacto, para que la puntuación refleje las consecuencias y no solo la cantidad de ataques.

Risk Intelligence también organiza los hallazgos mediante una taxonomía detallada, desde categorías generales hasta objetivos específicos de los atacantes. Cada uno se vincula con OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS y NIST. Así, los equipos pueden pasar de una puntuación general al patrón de ataque exacto que tuvo éxito y relacionarlo con el marco que ya usan para sus informes. Como Risk Intelligence se conecta con el motor de políticas de Evo, los equipos pueden convertir la información en acciones de cumplimiento. Pueden comparar modelos antes de decidirse por uno, identificar cuáles conllevan más riesgo en contextos específicos de implementación, comenzar con políticas listas para usar y personalizar los umbrales según su tolerancia al riesgo.

La brecha entre una puntuación de riesgo y una política de cumplimiento es donde se estancan la mayoría de los programas de seguridad de IA. Los equipos reciben un hallazgo, pero no saben qué hacer con él.

Evo cierra esa brecha al conectar Risk Intelligence directamente con su motor de políticas. Cuando un modelo tiene una puntuación de riesgo alta para un objetivo específico del atacante o un patrón de ataque, los equipos pueden establecer umbrales, aplicar políticas y bloquear el uso de modelos de alto riesgo en contextos sensibles, todo dentro del mismo flujo de trabajo.

Para los clientes de Snyk, esto amplía un enfoque conocido: descubrir riesgos donde trabajan los desarrolladores, priorizar lo que importa y aplicar políticas de forma consistente. La diferencia es que la política ahora también abarca la selección de modelos de IA y la configuración de agentes, no solo el código.

Por qué esto importa ahora

La seguridad de la IA no puede basarse en conjeturas. A medida que los modelos y los agentes se incorporan a aplicaciones reales, los equipos necesitan entender cómo se comportan esos sistemas bajo ataque.

La inteligencia de riesgos de modelos de IA permite que las organizaciones midan el comportamiento de los modelos, comparen los riesgos según el caso de uso, prioricen la corrección de problemas y rijan la adopción de la IA a gran escala. La pregunta ya no es simplemente: «¿Es seguro este modelo?» La mejor pregunta es: «¿Cómo se comporta este modelo bajo ataque en la forma en que planeamos implementarlo?»

La mayoría de los equipos con los que hablamos usan modelos de IA que no eligieron explícitamente. Los heredaron de un proveedor, los adoptaron mediante una herramienta para desarrolladores o los descubrieron durante una auditoría. El nuevo informe de Snyk, Estado de la adopción de agentes, volumen II, analizó datos de telemetría anónimos de la lista de materiales de IA (AI-BOM) de 3,044 organizaciones. El patrón es constante: por cada modelo que un equipo conoce, hay aproximadamente 2.8 componentes de IA, bibliotecas, servidores MCP y SDK adicionales que se ejecutan sin gestión, y la mayoría de las organizaciones no puede elaborar un inventario completo de lo que tiene. Un equipo calculó que completar el inventario de IA habría tomado de 4 a 5 semanas y requerido la participación de 10 a 12 personas. El problema del inventario de modelos es real incluso antes de empezar a hablar sobre la evaluación de riesgos.

La demanda de este tipo de capacidad está creciendo rápidamente. Las capacidades mejoradas de AI-SPM ya están disponibles para los clientes actuales. Los puntajes de riesgo basados en el impacto y en la tasa de éxito de los ataques (Attack Success Rate) obtenida mediante pruebas adversariales reales estarán disponibles a finales de agosto de 2026. Agenda una demostración hoy para obtener más información.