Tarjeta de título de «¿Qué es un modelo ciber?» que muestra tres columnas etiquetadas GENERALISTA DE FRONTERA, DEFENSOR AJUSTADO A CIBER y OFENSIVO AJUSTADO A CIBER, con una descripción de una línea de cada una.
Guides & Insights

¿Qué es un modelo ciber? La categoría y lo que realmente cambia

Autor

Rowan Sterling

Fecha de publicación

Últimos modelos · 20Ver todos los modelos →
Benchmarks: Artificial Analysis · actualizado a diario
Volver a todas las publicaciones

Cada semana se llama «cyber model» a tres productos que no tienen casi nada en común. Uno es un modelo generalista con corpus de seguridad en su mezcla de entrenamiento. Otro es un modelo corriente envuelto en un bucle que le proporciona un sandbox, un fuzzer y reintentos. El tercero es el mismo modelo que el de todos los demás, detrás de un formulario de verificación. Solo el primero de ellos es un modelo distinto. Los otros dos son decisiones de producto —buenas, en algunos casos— y se comercializan con la misma frase, y por eso la categoría se resiste a la comparación. Una tabla de benchmark que no dice cuál de los tres midió no se puede comparar con una que sí lo dice, y la mayoría de las tablas no lo dicen. Esta es una guía sobre la distinción, sobre el pequeño número de modelos que de verdad se sitúan en la primera categoría y sobre qué debería hacer un equipo de seguridad con la respuesta. Es también la visión por categorías que hay detrás de los 400 incidentes de agentes catalogados en el archivo de incidentes de IA, donde la pregunta «¿el problema fue el modelo o el despliegue?» surge constantemente.

Las tres cosas que abarca la frase

Empieza por la diferencia que importa operativamente: qué cambió cuando el proveedor construyó la cosa.

Card 'Three things people mean by cyber model' contrasting trained for security (the weights changed), wrapped in a harness (the loop changed) and gated by access (the door changed), with what each one changes and who owns the resulting score.

Entrenado para seguridad significa que los pesos cambiaron. Los corpus de seguridad se incorporaron a la mezcla de entrenamiento, la base suele ser un modelo generalista que ya era sólido, y el modelo resultante es mediblemente distinto en tareas donde el conocimiento de seguridad es el cuello de botella: leer un fallo, razonar sobre la disposición de la memoria, reconocer un patrón vulnerable en un diff grande. Los modelos de este grupo suelen reportarse frente a benchmarks específicos de seguridad como CyberGym o CyberSecEval, y pueden ser de pesos abiertos o solo API.

Envuelto en un arnés significa que el bucle cambió y el modelo no. El proveedor añadió un sandbox, herramientas, lógica de reintentos, un planificador, quizá un fuzzer, y construyó un sistema que rinde bien en tareas de seguridad porque el sistema está bien diseñado. Es un producto legítimo y a menudo subestimado. También es la categoría en la que una puntuación se vuelve ambigua, porque el número pertenece tanto al arnés como al modelo —y el arnés no es algo que puedas intercambiar de forma independiente.

Restringido por acceso significa que la puerta cambió. El modelo puede ser idéntico a uno público; lo que cambia es que debes ser una empresa verificada, que realiza trabajo autorizado, bajo condiciones que restringen el uso. Este es un producto de política, y uno defendible, pero de ello no se deriva ninguna afirmación de capacidad. Un modelo que es peligroso en las manos equivocadas y seguro en las correctas no se ha vuelto más capaz; se ha vuelto más controlado.

La consecuencia práctica: cuando lees que algún modelo es «un modelo de ciberseguridad», la siguiente pregunta es cuál de los tres, porque la respuesta determina si estás comprando capacidad, ingeniería o permiso — y esos tienen precios distintos y modos de fallo distintos.

Por qué existe la categoría en absoluto

El trabajo de seguridad es inusualmente sensible a dos propiedades que los modelos generales exhiben de forma inconsistente: el razonamiento de contexto largo sobre código que no se escribió para ser leído, y la disposición a describir un ataque con suficiente detalle como para que resulte útil. La primera es una cuestión de capacidad y es la razón por la que los modelos de este grupo suelen anunciar ventanas de contexto de cientos de miles o millones de tokens. La segunda es una cuestión de seguridad, y es la razón por la que la categoría está entrelazada con el control de acceso.

Un modelo que razona bien sobre una base de código pero se niega a escribir una prueba de concepto funcional es inútil para el triaje, porque la prueba de concepto es la evidencia. Un modelo que escribe pruebas de concepto libremente es útil para un defensor e igualmente útil para alguien que no lo es. Los modelos ajustados para ciberseguridad son, en efecto, un intento de resolver esa tensión al restringir quién puede preguntar en lugar de restringir qué puede responderse —lo cual es un diseño coherente y difícil de aplicar en la capa del modelo, ya que la aplicación es un proceso de verificación y no un cambio de pesos.

Donde realmente se argumenta la capacidad

Las ventajas que se atribuyen a los modelos ajustados para ciberseguridad son concretas y verificables, lo cual resulta refrescante en un campo que suele discutir con adjetivos. Las que se repiten son la ingesta de contexto largo de todo un repositorio o registro de auditoría en una sola pasada, la salida estructurada para su uso en pipelines y la llamada a herramientas o funciones lo bastante estable como para formar parte de un flujo de trabajo automatizado. Son afirmaciones de ingeniería tanto como afirmaciones sobre el modelo, y se pueden probar con tu propio corpus en una tarde.

El lado de la evaluación ha desarrollado instituciones propias. Wiz Research dirige un Cyber Model Arena que evalúa agentes de IA compuestos por un modelo fundacional más un arnés estándar en tareas reales de ciberseguridad, y reporta la calidad del modelo frente a la eficiencia: la tasa de éxito representada frente al coste, el tiempo o los pasos por resolución a lo largo de k intentos independientes. Vale la pena adoptar ese enfoque en su totalidad, porque captura lo que una tasa de éxito bruta oculta: dos agentes pueden alcanzar la misma tasa de éxito con costes por resolución muy distintos, y el caro suele ser el que gastó su presupuesto en reintentos.

Screenshot of Wiz Research's Cyber Model Arena headed 'We evaluate AI agents with foundation models and standard harnesses on multiple real-world cybersecurity tasks', showing a 'Model Quality vs. Efficiency' section described as success rate against cost, time or steps per solve over k independent attempts.

Fíjate en lo que implica esa construcción. Es un benchmark de agentes, no de modelos —modelo fundacional más harness—, que es exactamente la ambigüedad que tiene la categoría. La arena es honesta al respecto al nombrar el harness en la definición. La mayoría de las publicaciones de lanzamiento no lo son.

La puerta de acceso, y por qué es el verdadero límite de la categoría

Si se observa cómo se entregan realmente los modelos ajustados para ciberseguridad, la puerta de verificación resulta más determinante que cualquier cifra de benchmark, porque define quién puede siquiera ejecutar la evaluación. El patrón es constante: un paso de verificación empresarial, términos que restringen el uso a labores de seguridad autorizadas y una política de uso aceptable contra la que se registra el acceso.

Screenshot of the OrcaRouter cyber page headed 'Cyber models for your red team. Gateway controls for your blue team.', stating that OrcaCyber Zero and the rest of the cyber tier are open to business-verified security teams doing authorized work, with the agent firewall, guardrails, code review gate and compliance packs running in the same gateway.

Hay dos detalles de diseño en ese patrón que merece la pena copiar aunque nunca compres un modelo de ciberseguridad. El primero es la verificación empresarial en lugar de la autodeclaración, porque una casilla de verificación no es un mecanismo de rendición de cuentas. El segundo es colocar la puerta de control junto con los controles de tiempo de ejecución — la misma pasarela que aloja el modelo también aloja el cortafuegos, las salvaguardas y el registro, de modo que el permiso y la aplicación de las normas estén en un mismo lugar. Una puerta de verificación que reside en un sistema distinto del tráfico es una puerta que no se puede auditar.

Nuestro propio nivel de ciberseguridad sigue esa estructura: modelos para el trabajo ofensivo, controles de pasarela para el trabajo defensivo y verificación delante de ambos. También es la respuesta honesta a «¿puedo simplemente llamar a este modelo?»: para el nivel ofensivo, la respuesta es que el acceso es una decisión que alguien toma sobre ti, no un campo en una solicitud de API.

¿Qué modelos cyber existen y cómo distinguirlos?

La población es lo suficientemente pequeña como para retenerla en la cabeza, y se divide por las tres categorías anteriores en lugar de por proveedor.

• Modelos genuinamente ajustados para ciberseguridad. Entrenados con datos con un fuerte componente de seguridad, normalmente reportados en CyberGym o CyberSecEval, con una diferencia medible en tareas de lectura de fallos y escritura de parches. Algunos son de pesos abiertos, lo que permite la evaluación local; otros son solo API y están en verificación.

• Generalistas con un sólido comportamiento en seguridad.Modelos de frontera que resultan buenos en el trabajo sin haber sido ajustados para ello. A menudo son la elección correcta para los defensores, porque el mismo modelo también hace el resto del trabajo.

• Productos de agentes. Un modelo más un bucle específico de seguridad —sandbox, fuzzer, planificador— que se vende como un sistema. Juzga estos productos por el coste por resolución y por lo que hace el bucle cuando falla, no por un benchmark del modelo.

• Versiones con acceso restringido de lo anterior. Los mismos modelos, acceso restringido. La restricción cambia quién puede usarlos, no lo que pueden hacer.

La comparación que realmente importa para un equipo de seguridad rara vez es modelo contra modelo. Es si el trabajo que necesitas hacer está ligado al conocimiento o ligado a bucles. Leer un informe de auditoría y razonar sobre una cadena de explotación está ligado al conocimiento y favorece a un modelo ajustado. Ejecutar un fuzzer durante seis horas y clasificar los fallos está ligado a bucles y favorece una buena ingeniería. La mayoría de los programas reales necesitan ambas cosas, por lo que la pregunta útil en la adquisición es «¿para cuál de estos dos trabajos estoy comprando?» y no «¿qué modelo obtiene una puntuación más alta?».

Qué preguntar antes de adoptar uno

Cinco preguntas separan una decisión de categoría de una de marketing.

• ¿Qué cambió: los pesos, el bucle o el acceso? El proveedor debería poder responder en una frase. Si la respuesta es «el bucle», evalúa el producto como producto.

• ¿Qué benchmark, ejecutado por quién, en qué harness? Una cifra de CyberGym sin el harness es una cifra sobre una configuración que no puedes reproducir.

• ¿Cuál es el costo por resolución, y no la tasa de aprobación? El planteamiento de Wiz es el correcto; dos agentes con la misma tasa de éxito no representan la misma compra.

• ¿Qué hace la puerta cuando no la supero? Cualquier despliegue que dependa del acceso verificado debería indicarte qué ocurre ante un falso negativo, porque tus propios ingenieros serán los falsos negativos.

• ¿Qué no puede hacer? Las variantes exclusivamente defensivas documentan sus propios límites, y esa documentación es una característica: un modelo que no puede orientarse hacia la ofensiva es un objeto de riesgo distinto de uno que sí puede.

La categoría es real, las diferencias de capacidades son reales, y la mayor parte de la confusión viene de que tres productos distintos comparten un mismo nombre. Una vez que separas los pesos del bucle y de la puerta, las tablas comparativas dejan de ser contradictorias y empiezan a tratar sobre cosas diferentes — que es la única condición bajo la cual un equipo de seguridad puede tomar una decisión con ellas.