El riesgo de un modelo de IA depende de a qué puede acceder

Una nueva investigación de Snyk, realizada en miles de entornos empresariales analizados, muestra por qué una puntuación alta de riesgo del modelo marca el inicio de la priorización y cómo deben responder los equipos de seguridad.

Imagina dos aplicaciones que hacen referencia al mismo modelo de IA. Una resume notas de reuniones y la otra usa un agente para consultar registros de clientes y activar flujos de trabajo empresariales. El modelo podría obtener las mismas puntuaciones en pruebas adversariales en ambas aplicaciones. Pero las consecuencias de una falla podrían ser muy distintas, al igual que la falla que más importa. Una aplicación que resume reuniones debe saber si se puede manipular el modelo para que genere información engañosa. Un agente que accede a registros de clientes debe saber si se puede lograr que filtre datos o realice acciones no autorizadas. Por eso, una puntuación del modelo para cada tipo de ataque es más útil que un promedio único de todos ellos.

Esta distinción es fundamental en el Informe sobre el estado de la adopción de la IA agéntica en 2026, volumen III de Snyk. Los dos primeros volúmenes establecieron que la IA empresarial es un ecosistema de software conectado, no solo un conjunto de modelos. Este nuevo análisis agrega puntuaciones de riesgo para modelos identificables y plantea la pregunta que los líderes de seguridad realmente necesitan responder: ¿Qué hallazgos requieren acción y qué medidas reducirán el riesgo?

Casi la mitad de los inventarios de modelos de IA incluyen una referencia con puntuación de riesgo crítica

Cómo funcionan las puntuaciones: Snyk prueba cada modelo frente a 29 objetivos de ataque, como extraer datos personales o ejecutar comandos, y asigna a cada uno una puntuación de 0 a 1.000. La puntuación combina la frecuencia con que tuvo éxito un ataque y el daño que podría causar ese objetivo. Una puntuación de 500 o más es alta; de 750 o más, crítica. Los modelos se prueban con protecciones básicas, por lo que las puntuaciones describen un modelo protegido, no uno sin protección.

De los 1.693 entornos con al menos un identificador de modelo detectado, el 74,5 % hace referencia a un modelo con una puntuación alta (500+) en al menos un objetivo de ataque, y el 49,2 % hace referencia a uno con puntuación crítica (750+). La extracción de información de identificación personal (PII) y la ejecución de comandos representan los hallazgos de nivel crítico observados en esta muestra.

Estas cifras deben impulsar una investigación, no el pánico. La investigación compara los identificadores de modelos encontrados en el código con los resultados de pruebas adversariales. No establece que todos los modelos estén activos en producción, que se pueda acceder a una herramienta o conjunto de datos específicos, ni que un ataque haya tenido éxito en la aplicación de una organización.

La cobertura es otra razón para ser precisos: solo el 37,5 % de las apariciones de modelos detectadas tiene una puntuación de riesgo asociada. Cerca del 17 % de los entornos que contienen modelos no tiene ninguno con puntuación. Trata las referencias sin puntuación o sin versión como datos desconocidos que aún requieren revisión.

El tamaño del inventario cambia la cantidad de hallazgos, pero no la proporción. La probabilidad de encontrar al menos un modelo con puntuación alta aumenta del 34,6 % en los ecosistemas de modelos más pequeños al 100 % en los más grandes. Sin embargo, la proporción de apariciones de modelos vinculadas a modelos con puntuaciones altas se mantiene entre el 21 % y el 25 % en todos los tamaños, y entre el 18,9 % y el 25,5 % en ocho industrias. Usa la cantidad para dimensionar el trabajo de revisión pendiente y la proporción para comparar la selección de modelos con la de tus pares. Ninguna de las dos cifras muestra lo que una aplicación activa permite hacer a un modelo.

Ante cada modelo con una puntuación alta, las primeras preguntas son: ¿Está activo? ¿A qué puede acceder? ¿Qué pasa si falla?

Los agentes y los servidores MCP hacen imposible ignorar el contexto de implementación

Un modelo puede generar una respuesta insegura por sí solo. Al conectarlo con herramientas, datos y flujos de trabajo, también puede llegar a actuar en función de esa respuesta. Esa es la diferencia entre la exposición comprobada de un modelo y el alcance del sistema que lo rodea.

De las 1.051 cuentas de Estados Unidos con una referencia a MCP, 744 (70,8 %) muestran indicios de crear un servidor MCP con un SDK. Las demás solo muestran conexiones de cliente o referencias de configuración. Crear un servidor, configurarlo y operarlo son tres señales distintas; solo la verificación en tiempo de ejecución confirma la última.

Entre los entornos sin señales detectadas de agentes ni MCP, el 49,1 % hace referencia a un modelo con puntuación alta; la cifra aumenta al 96,6 % entre los que tienen tanto un indicador de agente como código para crear servidores MCP.

Este último grupo también tiene un inventario mediano de modelos mucho mayor: 104 modelos frente a 4. Al comparar entornos con entre 5 y 19 modelos, la diferencia se reduce de 47 a 26 puntos (62,1 % frente a 87,8 %). Este patrón es una asociación. Lo que cambian los agentes y los servidores MCP es hasta dónde puede llegar el impacto de la puntuación de un modelo; por eso, conviene empezar por ahí.

El siguiente paso para los equipos de seguridad es verificar: confirmar qué agentes y servidores MCP están activos, qué herramientas exponen, qué datos pueden recuperar y qué aprobaciones se requieren antes de que una salida del modelo provoque una acción con consecuencias. La puntuación de un modelo no puede responder esas preguntas.

No apliques la misma solución a todas las debilidades de la IA

Una vez que sabes a qué puede acceder un modelo, la siguiente pregunta es qué solución se ajusta a la falla. Un programa útil de gestión del riesgo de modelos no se limita a clasificar la gravedad. Analiza qué objetivo de ataque importa para la aplicación y si otro modelo tiene un desempeño considerablemente mejor en ese objetivo. La respuesta se divide en dos:

• Cuándo puede ayudar cambiar de modelo. En ejecución de comandos, el 77 % de los modelos probados obtuvo una puntuación de cero, mientras que el peor llegó a 834. En puertas traseras en el código, el 57 % obtuvo cero y el peor llegó a 695.

• Cuándo los controles de la aplicación marcan la diferencia. En desinformación, el modelo mediano alcanzó la puntuación máxima posible. En sesgo racial, ninguno de los modelos probados obtuvo cero.

Una puntuación de cero significa que ningún ataque tuvo éxito en esa prueba. Además, un modelo que funciona bien ante un objetivo puede tener un desempeño deficiente ante otro, así que valida cualquier reemplazo frente a todos los objetivos de los que depende la carga de trabajo. Cuando los resultados son similares, la defensa está en la aplicación: limita el acceso, valida las salidas, exige aprobaciones, monitorea el uso y analiza el código generado y las dependencias antes de incorporarlos a una compilación.

Los umbrales de alerta también cuentan solo una parte de la historia: 18 de los 29 objetivos de ataque nunca pueden alcanzar el umbral de alerta predeterminado de 500, porque el daño que cada uno puede causar limita su puntuación máxima a un valor inferior. Esas fallas siguen siendo importantes aunque la cola de alertas esté vacía.

Cuando los modelos difieren, prueba un reemplazo. Cuando no, reduce el acceso y la autoridad de la aplicación.

¿Qué objetivos se pueden resolver realmente al cambiar de modelo y cuáles nunca generarán una alerta? Consulta los gráficos de los 29 objetivos. Descarga el informe completo.

Quizás debas revisar tu lista de modelos aprobados

La familiaridad, la licencia y el precio no sustituyen un análisis del modelo específico.

Conviene revisar primero los modelos con menos capacidades

En el grupo evaluado, los modelos con menos capacidades tuvieron un peor desempeño en filtración de datos personales, anulación de decisiones y generación de código inseguro. En anulación de decisiones, el promedio bajó de 501 para los modelos por debajo de 130 en el Índice de Capacidades de Epoch (ECI) a 45 para los modelos con un ECI de 150 o más. Estos modelos con menos capacidades representan aproximadamente un tercio de las apariciones de modelos en la comparación con puntuaciones, por lo que el hallazgo va mucho más allá de un caso aislado.

La capacidad es una medida distinta de la seguridad, y aun así es necesario probar un modelo más potente para la tarea que realizará. Revisa las versiones aprobadas con menos capacidades y prueba alternativas del proveedor que ya usas, ya que el patrón también aparece en las líneas de productos de proveedores individuales.

El proveedor es una señal inicial útil, aunque dice menos cuando se trata de los modelos más avanzados. Entre los modelos de gama media, los promedios por proveedor van de 113 a 356; entre los más capaces, tres proveedores líderes quedan dentro de un rango de 22 puntos entre sí. Si tu lista de modelos aprobados depende de un solo proveedor, el informe completo muestra en qué aspectos sus modelos destacan y en cuáles se quedan atrás. Seis proveedores se comparan lado a lado en siete tipos de ataque, desde la exfiltración de datos hasta la manipulación de salidas. En esta muestra, los niveles de precios premium no mostraron una ventaja de seguridad constante, en gran medida porque el nivel de precio alto incluye principalmente modelos más antiguos y con menos capacidades.

Modelos de pesos abiertos y linaje de los datos de entrenamiento

El informe también encuentra puntuaciones más altas de filtración de datos personales entre los 16 modelos de pesos abiertos evaluados que entre los modelos propietarios: 562 frente a 274, en promedio. La muestra es pequeña, así que considera esta diferencia una señal que vale la pena investigar para las cargas de trabajo que manejan datos personales.

La visibilidad del linaje muestra una diferencia similar. En 904 de los 1.693 entornos con modelos, los análisis no encontraron datos sobre el linaje de entrenamiento, en gran medida porque los proveedores de modelos propietarios no publican sus conjuntos de datos de entrenamiento. Por lo tanto, la evidencia depende del tipo de modelo: pide garantías documentadas a los proveedores propietarios y revisa los datos de linaje que publican los modelos de pesos abiertos.

Cuatro acciones para los líderes de seguridad

1. Haz un inventario y clasifica los datos desconocidos: Lleva un registro de los identificadores y versiones de modelos, sus responsables, usos activos, agentes, herramientas, servidores MCP y datos de linaje disponibles. Mantén visibles los modelos sin coincidencias; no los consideres de bajo riesgo sin más.

2. Verifica el alcance: Confirma la ruta en tiempo de ejecución desde cada modelo activo hasta los datos confidenciales, las credenciales, las herramientas y las acciones posteriores. Distingue el código para crear servidores de su configuración y de las conexiones reales.

3. Adapta la corrección al objetivo: Prioriza las fallas según sus consecuencias para el negocio. Prueba modelos de reemplazo específicos cuando los resultados adversariales varíen; cuando no varíen, aplica el mínimo privilegio, verifica las salidas, exige aprobaciones y analiza el código.

4. Integra la decisión en la gobernanza: Registra el modelo y su versión, las pruebas realizadas, el responsable, los controles aprobados, la justificación y la fecha de revisión. Vuelve a evaluar cuando cambien los modelos, los permisos, los datos de ajuste fino o las aplicaciones.

La conclusión del volumen III: la puntuación de un modelo muestra su exposición, y el sistema que lo rodea determina su alcance. Actúa sobre ambos aspectos, cambia de modelo cuando haya diferencias y refuerza los controles cuando no las haya.

Metodología: Datos anonimizados y agregados de análisis de listas de materiales de IA (AI-BOM) de organizaciones que usan Snyk, a partir de septiembre de 2026: 3.023 entornos, incluidos 1.693 con al menos un identificador de modelo. Los hallazgos a nivel de modelo abarcan cuentas de Estados Unidos.

Los líderes de seguridad necesitan saber qué fallas podrían afectar a su negocio y qué cambio de control modifica el resultado. ¿Qué patrón de agentes y MCP describe tu entorno y cómo se compara tu proveedor en siete tipos de ataque? El informe completo desglosa ambos aspectos, además de los resultados por industria y nivel de precio, y las seis preguntas que todo líder de gobernanza debería poder responder. Descarga el Informe sobre el estado de la adopción de la IA agéntica en 2026, volumen III.

¿Listo para evaluar tu propio ecosistema de IA? Explora Evo AI-SPM.