El mejor modelo de IA para Pentesting, lo que los ingenieros de seguridad deberían usar realmente en 2026

La pregunta parece bastante sencilla. Quieres el mejor modelo de IA para pentesting, de modo que puedas elegir un modelo, conectarlo a tu flujo de trabajo y avanzar más rápido. Pero en la práctica, esa pregunta esconde tres decisiones diferentes. En primer lugar, ¿está eligiendo un modelo de cimentación o un Producto de seguridad con IA ¿Construido sobre uno? En segundo lugar, ¿está tratando de mejorar el flujo de trabajo diario de un probador humano, o está tratando de automatizar una tubería ofensiva de extremo a extremo? En tercer lugar, ¿le interesa más el razonamiento del código, la interacción con el navegador, el análisis de repositorios de contexto largo o la recopilación de pruebas repetibles?

Estas distinciones son importantes porque la conversación pública es ruidosa. Algunos de los contenidos de profesionales más destacados que se están clasificando sobre este tema señalan que muchas "herramientas de seguridad de IA" son en realidad envoltorios de un pequeño conjunto de modelos básicos. Al mismo tiempo, los artículos comparativos que probablemente encuentren los lectores suelen clasificar productos como XBOW, NodeZero y Burp AI, que no son modelos básicos en absoluto, sino sistemas operativos con capas de orquestación, herramientas, validación e informes. Tratar estas dos categorías como la misma cosa es la forma en que los equipos toman malas decisiones de compra y malas decisiones de arquitectura. (Medio)

Así que aquí está la respuesta honesta por adelantado. Si usted es un ingeniero de seguridad que quiere un modelo de propósito general para la mayoría de los trabajos relacionados con pentesting hoy en día, Claude Sonnet 4.6 es la elección por defecto más fuerte. Si su flujo de trabajo se basa en gran medida en la automatización del navegador, el uso de ordenadores y los bucles de operador basados en herramientas, GPT-5.4 es el mejor especialista. Si su trabajo implica conjuntos de pruebas multimodales gigantes, documentos muy voluminosos y análisis de grandes contextos conscientes de los costes, Gemini 3.1 Pro es la tercera opción más sólida. Si está construyendo un producto pentest serio o un sistema autónomo interno, la mejor respuesta no es un modelo en absoluto, sino una pila enrutada con herramientas deterministas y validación explícita. Esta conclusión se deduce de los documentos oficiales de los modelos, de los patrones actuales de los productos y de las mejores investigaciones públicas sobre el pentesting asistido por IA, y no de un punto de referencia de un único proveedor que pretenda zanjar toda la cuestión. (OpenAI)

Por qué se responde mal a esta pregunta

Muchos de los escritos sobre IA y pentesting siguen cometiendo uno de estos dos errores. El primero es tratar el pentesting como un problema de redacción de instrucciones. En esa versión de la historia, el modelo es "bueno" si puede explicar una clase de vulnerabilidad, sugerir los siguientes pasos o generar un guión que parezca plausible. Eso es útil, pero no es lo mismo que ayudar a alguien a completar una evaluación de seguridad autorizada. El pentesting real significa navegar por la ambigüedad, adaptarse a las suposiciones rotas, manejar la telemetría incompleta, mantener el contexto a través de las etapas y generar pruebas que puedan sobrevivir al escrutinio de ingenieros, gerentes y, a veces, auditores.

El segundo error es confundir demostraciones impresionantes con operaciones fiables. Los materiales públicos de los sistemas de seguridad de IA modernos cuentan una historia muy coherente en este sentido. Aardvark, de OpenAI, que ahora se incluye en Codex Security como avance de investigación, se describe explícitamente como un sistema de varias fases que analiza repositorios, elabora un modelo de amenazas, valida la explotabilidad de forma aislada y propone correcciones específicas. Burp AI no se comercializa como sustituto de los pentesters, sino como una forma de acelerar el trabajo manteniendo el control por parte del operador. XBOW hace hincapié en los hallazgos validados de forma independiente mediante explotación real. NodeZero hace hincapié en el encadenamiento de rutas de ataque y la prueba continua de explotabilidad. En otras palabras, los productos más cercanos a la realidad de la producción no están diciendo "elige un modelo y déjate llevar". Están diciendo lo contrario: los modelos importan, pero la arquitectura importa más. (OpenAI)

Esta es también la razón por la que la investigación pública más sólida sigue recompensando la descomposición. El documento USENIX Security 2024 PentestGPT descubrió que un diseño estructurado de tres módulos mejoraba sustancialmente los resultados con respecto al uso de modelos ingenuos, incluido un aumento del 228,6% en la finalización de tareas con respecto a GPT-3.5 en los objetivos de referencia, al tiempo que destacaba que la pérdida de contexto y la planificación a largo plazo son los principales puntos débiles de la interacción genérica de tipo chat. AutoPenBench demostró posteriormente que los agentes totalmente autónomos sólo alcanzaban un 21% de éxito, mientras que los agentes asistidos por humanos alcanzaban un 64%. PentestEval insistió aún más en este punto y descubrió que, en general, el rendimiento por etapas de los LLM modernos era bajo: las etapas más difíciles rondaban el 25% de éxito y el rendimiento de los sistemas autónomos de principio a fin era muy bajo. Estos trabajos no dicen que la IA sea inútil para el pentesting. Dice que la unidad ganadora no es la respuesta única. Es el flujo de trabajo. (USENIX)

En qué debe ser bueno un modelo de pentesting

Al margen de las exageraciones, un modelo de pentesting sólido debe hacer bien seis cosas.

En primer lugar, necesita leer el código y la configuración con un alto nivel de fidelidad. Esto incluye el trabajo normal de revisión de código, pero también el tipo de razonamiento de seguridad que requiere seguir el flujo de datos, los límites de confianza, los supuestos de autenticación y las condiciones de despliegue. En la práctica, aquí es donde el rendimiento del contexto a largo plazo y la calidad de la búsqueda en la base de código importan más que la astucia puntual.

En segundo lugar, tiene que manejar herramientas sin perderse. El pentesting no es puro razonamiento. Es un bucle desordenado de recogida de resultados, eliminación de ruido, elección de un siguiente paso y actualización de una hipótesis de trabajo. El posicionamiento oficial del modelo refleja ese cambio. GPT-5.4 se presenta explícitamente como fuerte en cargas de trabajo de uso del ordenador y en la escritura de código para operar ordenadores a través de bibliotecas como Playwright, mientras que Claude Sonnet 4.6 se enmarca como más fuerte que los modelos Sonnet anteriores en codificación, uso del ordenador, razonamiento de contexto largo y planificación de agentes. Gemini 3.1 Pro se posiciona en torno a la mejora del uso de herramientas, las tareas de varios pasos y la codificación de agentes con una ventana de contexto de 1M de tokens. Estas capacidades no demuestran por sí solas un rendimiento real en pentest, pero se ajustan a la mecánica de los flujos de trabajo ofensivos modernos. (OpenAI)

En tercer lugar, el modelo debe ser coherente en sesiones largas. Una sorprendente cantidad de trabajo de seguridad muere aquí. Llevas media hora en un objetivo, has recopilado suposiciones sobre el flujo de autenticación, los límites de los roles, los patrones de error, el comportamiento de JavaScript y las peculiaridades del backend, y el modelo de repente empieza a optimizar la rama equivocada porque ha olvidado la estructura de la investigación. PentestGPT señaló esto directamente como un problema de pérdida de contexto, y ese diagnóstico sigue siendo válido. Un modelo con una ventana de contexto más grande no resuelve esto automáticamente, pero da al diseñador del sistema más espacio para preservar artefactos, hipótesis y pruebas sin pérdida de compresión. (USENIX)

En cuarto lugar, debe gestionar los falsos positivos y las hipótesis débiles. Aquí es donde el trabajo de seguridad difiere marcadamente de la ayuda general a la codificación. En ingeniería de software, un modelo que parece convincente pero que es erróneo resulta caro. En pentesting, es peor. Hace perder tiempo a los humanos, quema los límites de velocidad, crea tickets basura y enseña a los equipos a desconfiar del sistema. La documentación del producto de Burp AI es reveladora a este respecto: una de las funciones destacadas de la IA es la reducción de falsos positivos en el control de accesos rotos, y la plataforma presenta repetidamente a la IA como un colaborador que aumenta la capacidad de comprobación en lugar de sustituir el juicio. Esta elección de diseño no es una marca conservadora. Es un reconocimiento de que la gestión de errores es fundamental para la utilidad. (PortSwigger)

En quinto lugar, tiene que ser lo suficientemente barato como para mantenerse en el bucle. Un modelo que funcione de maravilla pero sea demasiado caro de ejecutar en repositorios, cambios en la superficie de ataque y comprobaciones de regresión no se convertirá en el modelo por defecto. En marzo de 2026, OpenAI ofrecía GPT-5.4 a $2,50 por millón de tokens de entrada y $15 por millón de tokens de salida, mientras que Anthropic ofrecía Claude Sonnet 4.6 a $3 y $15 por millón de tokens, y Google ofrecía Gemini 3.1 Pro a $2 y $12 por debajo de 200.000 tokens de entrada, con tarifas más altas por encima de ese umbral. El precio no lo es todo, pero afecta significativamente a si los equipos pueden permitirse un uso continuado. (OpenAI)

En sexto lugar, tiene que producir artefactos sobre los que la gente pueda actuar. El resultado real del pentesting no son "pensamientos interesantes". Se trata de conclusiones validadas, pruebas de apoyo, orientaciones de corrección y, a menudo, confirmación de nuevas pruebas. Esta es la razón por la que los sistemas maduros están convergiendo en tuberías de múltiples etapas en lugar de pura charla. El mejor modelo de pentesting es el que se encuentra dentro de un bucle que puede observar, decidir, verificar y explicar. Sin ese bucle, incluso un modelo sólido no es más que un asistente inteligente.

Lo que dicen los estudios, una vez ignorado el bombo publicitario

La literatura académica se ha vuelto mucho más útil en los últimos dos años porque ha dejado de preguntarse si los LLM pueden ayudar en algo y ha empezado a preguntarse dónde ayudan, dónde fallan y qué diseño de sistema compensa esos fallos.

PentestGPT fue un punto de inflexión porque enmarcó el pentesting automatizado como un problema de colaboración estructurada, no como un problema de una sola sesión. El documento construyó un punto de referencia basado en objetivos del mundo real extraídos de plataformas como Hack The Box y VulnHub, cubriendo 13 objetivos, 182 subtareas, 26 categorías y 18 elementos CWE. Los autores descubrieron que los LLM eran capaces de realizar algunas subtareas, pero tenían dificultades con la planificación a largo plazo, la retención del contexto y la toma de decisiones coordinada. Su diseño de tres módulos, que separa el razonamiento, la generación y el análisis sintáctico, mejoró significativamente los resultados y demostró que las opciones de diseño pueden ser tan importantes como la calidad del modelo. (USENIX)

AutoPenBench amplió la conversación en una dirección diferente. En lugar de preguntarse si un agente hecho a medida podría resolver un puñado de atractivas demostraciones, creó una referencia abierta con 33 tareas que iban desde ejercicios educativos a sistemas vulnerables reales con CVE, utilizando la integración MCP y la evaluación basada en hitos. El resultado principal fue aleccionador y útil al mismo tiempo: los agentes totalmente autónomos alcanzaron un 21% de éxito, mientras que los agentes asistidos por humanos llegaron al 64%. Este resultado debería cambiar la forma en que los equipos interpretan cada demostración de pentesting autónomo que ven. La lección correcta no es que la IA fracasó. La lección correcta es que el despliegue modular guiado por humanos es el camino práctico ahora mismo. (Antología ACL)

PentestEval, publicado posteriormente, es aún más contundente. En él se evalúan nueve LLM y varias herramientas especializadas de pentesting en seis etapas descompuestas del flujo de trabajo. Los investigadores informaron de un rendimiento a nivel de etapa generalmente bajo, con la toma de decisiones de ataque y la generación de exploits rondando el 25 por ciento de éxito, y métodos autónomos de extremo a extremo con un rendimiento pobre. En su configuración, PentestGPT logró un 39% de éxito con la ejecución manual y un 31% con la automatización, mientras que los agentes totalmente autónomos como PentestAgent y VulnBot fueron mucho peores. No es necesario aceptar todas las opciones de diseño de este artículo para reconocer la principal verdad operativa que expone: la autonomía sigue siendo frágil precisamente cuando el trabajo ofensivo se vuelve ambiguo, ramificado y de altas consecuencias. (arXiv)

Dicho de otro modo, las mejores pruebas actuales apuntan a una conclusión firme. El "mejor modelo de IA para pentesting" no es el que escribe el comando más llamativo o la explicación más larga. Es el modelo que menos se degrada cuando el flujo de trabajo se alarga, las pruebas se desordenan y el siguiente paso no es obvio. Por eso, el razonamiento en contextos largos, la fiabilidad de las herramientas y la corrección de errores importan más que las anécdotas de las redes sociales sobre qué modelo parece más inteligente.

GPT-5.4, el modelo de operador más potente del grupo

El propio posicionamiento de OpenAI de GPT-5.4 es inusualmente relevante para el trabajo de seguridad. La empresa destaca explícitamente el rendimiento en cargas de trabajo de uso informático y pide que se escriba código para manejar ordenadores con bibliotecas como Playwright, así como que se responda a capturas de pantalla con acciones del ratón y el teclado. Los documentos de la API también indican una ventana contextual de aproximadamente 1.050.000 tokens y 128.000 tokens de salida máxima. No son características genéricas del estilo de vida. Corresponden directamente a los tipos de automatización del navegador, exploración de la interfaz, navegación con estado y bucles impulsados por herramientas que se encuentran cada vez más dentro de los flujos de trabajo de pruebas de seguridad de productos y web autorizados. (OpenAI)

Eso hace que GPT-5.4 sea especialmente atractiva cuando la tarea adyacente al pentesting no es sólo "razonar sobre este objetivo", sino "manejar un entorno". Piense en la exploración de aplicaciones autenticadas, flujos de trabajo de cuentas de varios pasos, reproducción de límites de permisos, inspección de estados del lado del cliente o instrumentación de comprobaciones de regresión contra superficies recién introducidas. En estos casos, la capacidad de escribir y ajustar código de automatización de forma fiable es tan importante como la intuición de vulnerabilidad. GPT-5.4 parece más fuerte aquí porque OpenAI ahora está optimizando explícitamente hacia ese bucle de estilo operador en lugar de sólo la finalización de código estático. (OpenAI)

La contrapartida es que GPT-5.4 no es obviamente el mejor predeterminado para el uso diario de todos los ingenieros de seguridad. Gran parte del trabajo de pentesting se basa en repositorios, notas o informes más que en navegadores. Si su actividad más común es la revisión de una extensa base de código, la comparación de hallazgos previos, la lectura de documentos de arquitectura, y el razonamiento a través de grandes conjuntos de pruebas, GPT-5.4 puede no darle una ventaja decisiva sobre Claude Sonnet 4.6. Tampoco es la opción más barata si piensa mantenerla constantemente en el bucle para tareas de amplia cobertura. El precio indicado por OpenAI es competitivo para un modelo de frontera, pero los equipos de seguridad que ejecutan análisis continuos a través de muchos artefactos seguirán notando el coste. (OpenAI)

Así que la forma más limpia de pensar en GPT-5.4 es la siguiente: es la mejor opción cuando se desea que un modelo se comporte como un operador técnico adaptable. Es menos convincente como elección universal de "un modelo para cada tarea de seguridad" que como modelo al que recurrir cuando el flujo de trabajo implica interacción, automatización y ejecución activa bajo barandillas.

Claude Sonnet 4.6, la mejor opción por defecto para la mayoría de los ingenieros de seguridad

Claude Sonnet 4.6 es el modelo que yo recomendaría como el mejor por defecto de uso general para la mayoría de los trabajos centrados en el pentesting en estos momentos. Esto no se debe a que Anthropic afirme que gana todas las pruebas comparativas. Todos los proveedores fronterizos afirman lo mismo. Es porque el perfil de características públicas del modelo aterriza inusualmente bien en la textura real de la ingeniería de seguridad: codificación, uso de ordenadores, razonamiento de contexto largo, planificación de agentes, y una ventana de contexto de 1M de tokens, todo a un precio que es factible para el uso frecuente. Anthropic recomienda explícitamente Sonnet 4.6 para la mayoría de las aplicaciones de IA que necesiten un equilibrio entre capacidades avanzadas y rentabilidad. (Antrópico)

¿Por qué importa eso en el pentesting? Porque la mayor parte del trabajo de seguridad real no es una tarea puramente de operador ni una tarea puramente de escritura. Es una tarea intermedia. Estás leyendo código, comparando estados de aplicaciones, razonando sobre registros y documentación, detectando fallos en los límites de confianza, decidiendo qué rama de una investigación merece otra hora, y convirtiendo el resultado en algo que otro humano pueda verificar. Sonnet 4.6 parece el más fuerte por defecto porque no obliga a un difícil equilibrio entre la comprensión del código, el contexto de una sesión larga y la calidad general del flujo de trabajo profesional. Las recomendaciones públicas destacadas en la propia página de Anthropic repiten el mismo tema: grandes bases de código, difícil búsqueda de errores, tareas a largo plazo, menos errores de herramienta y una buena relación rendimiento-coste. Los testimonios de los vendedores no son ciencia neutral, pero la coherencia de los casos de uso es informativa. (Antrópico)

Hay otra razón por la que Sonnet 4.6 encaja bien en el trabajo de seguridad: las mejores investigaciones actuales sugieren que la autonomía parcial más la supervisión humana es donde se concentra el valor, y el reciente posicionamiento de Claude es muy sólido exactamente en ese carril. El resultado de AutoPenBench del 64% para los agentes asistidos por humanos, frente al 21% para los totalmente autónomos, es efectivamente un argumento a favor de la colaboración de alta calidad en lugar de la delegación ciega. La combinación de Sonnet 4.6 de contexto largo, esfuerzo de razonamiento controlado y fluidez de flujo de trabajo amplio lo convierte en un modelo de colaborador muy fuerte. Es el modelo que me gustaría tener abierto mientras audito una gran aplicación interna, leo un paquete de clientes generado, reviso la lógica de autenticación o convierto pruebas sin procesar en una narrativa de hallazgos creíble. (Antología ACL)

Su punto débil no es tanto la capacidad como la especialización. Si su flujo de trabajo está dominado por la automatización de escritorios o navegadores altamente interactivos, GPT-5.4 puede ofrecerle más ventajas. Si su organización ya vive en las profundidades del ecosistema de Google y maneja corpora multimodales gigantes a escala, Gemini 3.1 Pro puede ser un mejor ajuste económico. Pero si me obligas a responder a la pregunta original en una sola línea, Claude Sonnet 4.6 es el mejor solo Modelo de IA para el trabajo pentesting-adyacente en 2026, porque es el más difícil de lamentar estandarizar.

Gemini 3.1 Pro, la mejor opción para paquetes de pruebas gigantes

Gemini 3.1 Pro merece más respeto en los círculos de seguridad del que suele recibir. Google DeepMind lo posiciona en torno al razonamiento avanzado, la comprensión multimodal, el uso mejorado de herramientas, las tareas simultáneas de varios pasos y un fuerte comportamiento de codificación agencial. Los documentos para desarrolladores de Google también exponen algo muy relevante para los equipos de seguridad: un límite de entrada de 1.048.576 tokens, 65.536 tokens de salida, compatibilidad con la ejecución de código, llamadas a funciones, salidas estructuradas, fundamentos de búsqueda, contexto de URL y entrada de PDF. Esta combinación de capacidades hace que Gemini resulte muy convincente en los casos en los que el "objetivo" no es sólo una aplicación o repositorio, sino un montón de documentos, diagramas, PDF, capturas de pantalla, registros y fragmentos de código que deben mantenerse unidos en un marco de trabajo. (Google DeepMind)

Esto importa más de lo que mucha gente cree. Gran parte del trabajo de seguridad en entornos maduros es síntesis de pruebas. Lees notas de arquitectura, exportaciones de Jira, resultados de pentest anteriores, manifiestos de despliegue, configuración de CI, especificaciones de API y capturas de paquetes, e intentas responder a una pregunta más concreta sobre explotabilidad, límites de privilegios o impacto en el negocio. En este tipo de carga de trabajo, un contexto amplio, un manejo multimodal y un uso decente de las herramientas pueden vencer a un modelo que sea ligeramente mejor en la generación de código en bruto. El perfil de precios de Gemini también es atractivo para el análisis a gran escala, especialmente en el nivel de entrada más bajo. (Google AI para desarrolladores)

La razón por la que Gemini 3.1 Pro no es mi elección número uno por defecto no es que sea débil. Es que el ecosistema de seguridad públicamente visible aún no ha convergido en torno a él de forma tan clara para los flujos de trabajo de pentesting cotidianos como lo ha hecho en torno a Claude para el trabajo de codificación de colaboración pesada o los modelos de estilo GPT para la automatización de tipo operador. Esto puede cambiar. Los materiales oficiales ya hacen hincapié en la mejora del uso de herramientas y en la codificación agéntica, y la página de metodología de Google muestra que la empresa está pensando seriamente en las evaluaciones de llamadas a funciones. Pero a partir de marzo de 2026, sigue pareciendo la mejor opción cuando la carga de trabajo es inusualmente grande, heterogénea y pesada en documentos, y todavía no es el modelo único por defecto más natural para el ingeniero de seguridad medio. (Google DeepMind)

Si su equipo dedica más tiempo a la clasificación de enormes paquetes de pruebas que a la gestión activa de interfaces, Gemini puede ser la mejor opción. Por ejemplo, en la validación de incidentes en la nube, las revisiones de seguridad de arquitectura pesada o las evaluaciones de superficie de agentes de IA con enormes artefactos de solicitud, herramientas y tiempo de ejecución, los puntos fuertes multimodales y de documentos del modelo resultan muy prácticos.

Un modelo no es un pentester, y el mercado lo está demostrando

Una de las señales más claras en este espacio es que los productos más interesantes son cada vez más explícitos sobre dónde acaba el modelo y dónde empieza el sistema.

Burp AI es un buen ejemplo porque PortSwigger ha adoptado una postura muy pragmática. Los documentos oficiales dicen que Burp AI ayuda a los probadores a descubrir vulnerabilidades de manera más eficiente, entender las tecnologías web complejas, y agilizar la configuración de autenticación, pero la mensajería del producto subraya repetidamente que el operador sigue teniendo el control. Las características que importan no son místicas. Son prácticas: IA en Repeater, exploración autónoma de problemas, explicaciones sobre tecnologías desconocidas, reducción de falsos positivos en el control de acceso y registros de inicio de sesión generados por IA. Eso no es "la IA sustituye al pentesting". Es "la IA elimina la fricción en las partes del pentesting que queman tiempo". (PortSwigger)

Aardvark de OpenAI, ahora Codex Security, cuenta una historia relacionada desde el punto de vista de la seguridad del código. Su flujo de trabajo incluye el análisis de repositorios, el modelado de amenazas, el escaneado de confirmaciones, la validación aislada y la generación de parches. La palabra clave es validación. El sistema no se conforma con detectar un patrón. Intenta confirmar la explotabilidad en un entorno aislado y proporcionar pruebas para su revisión. Esta elección arquitectónica se ajusta casi perfectamente a lo que los ingenieros de seguridad ofensiva llevan años queriendo de la IA: menos especulación y más pruebas. (OpenAI)

XBOW y NodeZero muestran el mismo patrón desde el punto de vista de la plataforma ofensiva. XBOW se presenta como una plataforma de seguridad ofensiva autónoma que explora las rutas de ataque y valida de forma independiente los posibles hallazgos mediante la explotación real. NodeZero hace hincapié en el encadenamiento de rutas de ataque, las pruebas continuas y la corrección basada en pruebas. Tanto si adopta estas plataformas como si no, demuestran dónde cree el mercado que reside el valor duradero. No reside únicamente en la calidad de las conversaciones. Está en la exploración guiada, el encadenamiento, las pruebas y la repetibilidad. (Xbow)

Una vez que se ve ese patrón, la pregunta original resulta más fácil de responder. Elegir el mejor modelo de IA para el pentesting es importante. Pero elegir el modelo diseño del sistema importa más.

La mejor respuesta actual, por flujo de trabajo

La forma más sencilla de elegir es asignar la elección del modelo al tipo de trabajo de seguridad que realice con más frecuencia.

Flujo de trabajo	Mejor ajuste	Por qué gana
Revisión de grandes bases de código, análisis de la lógica de autenticación, razonamiento de seguridad en todo el repositorio	Claude Soneto 4.6	Mejor equilibrio general entre contexto prolongado, calidad de codificación y razonamiento colaborativo.
Pruebas de productos basadas en navegadores, automatización de interfaces, bucles de operador de varios pasos	GPT-5.4	Perfil más explícito de uso de ordenadores y automatización
Enormes paquetes de pruebas, PDFs, materiales multimodales, revisión de arquitectura pesada	Géminis 3.1 Pro	Excelente combinación de capacidades multimodales y de contexto amplio
Plataforma de seguridad autónoma o semiautónoma de producción	Pila multimodelo enrutada	Tanto la investigación como las pruebas de mercado favorecen los sistemas modulares frente a la autonomía de un solo modelo

La tabla anterior es una opinión basada en documentos oficiales actuales, referencias públicas y la arquitectura de los principales productos de seguridad, no una ley universal. Esta distinción es importante porque la "mejor" respuesta cambia con el trabajo. Un probador web solo haciendo flujos autenticados dentro de Burp puede racionalmente preferir GPT-5.4 para tareas altamente interactivas, y luego cambiar a Claude para la construcción de informes y revisión de código. Un equipo de seguridad en la nube enterrado en documentos y políticas puede preferir Gemini para la síntesis de grandes pruebas mientras utiliza un modelo diferente para la lógica de explotación. Lo peligroso no es elegir de forma diferente. Lo peligroso es asumir que la reputación general de un modelo se transfiere automáticamente a cada tarea de pentesting. (OpenAI)

CVEs que revelan lo que realmente debe hacer un buen modelo de pentesting

Una forma útil de evaluar la IA para el trabajo de seguridad es dejar de preguntarse si "conoce las vulnerabilidades" y preguntarse si ayuda a tomar las decisiones correctas en torno a las reales.

Toma Log4Shell, CVE-2021-44228. La vulnerabilidad en Log4j 2 permitía la ejecución remota de código cuando los datos de registro controlados por el atacante activaban búsquedas JNDI bajo configuraciones vulnerables. Todos los modelos actuales pueden recitar el titular. La pregunta más difícil es si el modelo puede ayudar a rastrear la exposición transitiva, identificar dónde la ruta de registro está realmente influenciada por el atacante, distinguir entre versiones y configuraciones afectadas y no afectadas, y producir una guía de remediación que coincida con el despliegue real. Se trata de un problema de razonamiento contextual y de dependencia, no de trivialidades. (NVD)

Considere CVE-2024-3400 en PAN-OS. NVD lo describe como una vulnerabilidad de inyección de comandos resultante de la creación de archivos arbitrarios en GlobalProtect que puede permitir a un atacante no autenticado ejecutar código arbitrario con privilegios de root, pero sólo para versiones específicas de PAN-OS y configuraciones de características distintas. Esa condicionalidad es exactamente el tipo de detalle que un modelo útil debe razonar correctamente. El trabajo no es decir "RCE crítico". El trabajo es ayudar al ingeniero a verificar las precondiciones de exposición, identificar dónde está habilitada la característica y separar el estado afectado del no afectado sin crear pánico. (NVD)

Ahora mira CVE-2025-0282 en Ivanti Connect Secure. NVD lo describe como un desbordamiento de búfer basado en pila que permite la ejecución remota de código no autenticado contra productos y versiones específicas de Ivanti. Este es el tipo de problema en el que un equipo de seguridad necesita un modelo que pueda conectar rápidamente el inventario de activos, la exposición a Internet, las pruebas de la versión y el radio de explosión probable, y luego ayudar con la validación y la confirmación posterior al parche. El problema es en parte técnico y en parte organizativo. Un buen modelo acorta el tiempo desde el aviso hasta la priorización verificada. (NVD)

Lo mismo ocurre con CVE-2025-53770donde NVD señala que Microsoft era consciente de la explotación en la naturaleza de un problema de deserialización de SharePoint Server que permitía la ejecución no autorizada de código de red, y para CVE-2026-20127donde CISA y NVD describen un bypass de autenticación en Cisco Catalyst SD-WAN Controller and Manager que permitía a un atacante remoto no autenticado obtener privilegios administrativos y que fue activamente explotado. Estos son los momentos en los que un modelo sólido se gana su sustento. Debería ayudar a los ingenieros de seguridad a pasar de la gravedad de los titulares a la verificación concreta: ¿Estamos expuestos, dónde estamos expuestos, qué se puede acceder a través de Internet, qué ha cambiado tras la mitigación y qué pruebas conservamos para la dirección y las operaciones? (NVD)

Ese es el punto de referencia que yo utilizaría al evaluar cualquier modelo para pentesting. No si puede explicar el CVE de memoria, sino si puede ayudar a un equipo real a reducir la incertidumbre más rápido de lo que podrían hacerlo sin él.

Cómo debe ser una evaluación interna

Si su equipo se toma en serio la elección de un modelo, no copie las batallas rápidas de las redes sociales. Construya un punto de referencia interno pequeño y seguro en torno a sus propios flujos de trabajo autorizados. Incluya tareas como triaje de repositorios, razonamiento de flujos autenticados, filtrado de falsos positivos, redacción de soluciones y explicación de rutas de ataque. A continuación, puntúe la precisión, la fiabilidad de la herramienta, la calidad de las pruebas y el tiempo ahorrado.

Una buena evaluación comparativa debe evitar la explotación en vivo y centrarse en tareas que se puedan reproducir de forma legal y segura a partir de compromisos anteriores, laboratorios internos o aplicaciones intencionadamente vulnerables. La investigación pública apoya firmemente la evaluación basada en hitos frente a la puntuación de todo o nada, porque gran parte del valor del trabajo de seguridad reside en el progreso intermedio: encontrar el límite correcto, descartar una pista débil, identificar el modelo de privilegios correcto o producir un rastro de prueba limpio. (Antología ACL)

He aquí un sencillo patrón de arnés de evaluación que es seguro y realmente útil:

from dataclasses import dataclass
from tipificación import List, Dict

@dataclass
clase Tarea:
    nombre: str
    conjunto_artefactos: cadena
    resultados_esperados: Lista[str]
    pruebas_esperadas: Lista[str]
    puntos_fijados_esperados: Lista[str]

@clase_de_datos
clase ModelRun:
    nombre_modelo: str
    nombre_tarea: cadena
    puntuación_encuentro: float
    puntuación_evidencia: float
    puntuación_remedio: float
    penalización_alucinación: float
    puntuación_fiabilidad_herramienta: float
    notas: str

def puntuación_ponderada(ejecución: EjecuciónModelo) -> float:
    return (
        0.30 * puntuación_de_la_ejecución +
        0.25 * puntuación_evidencia_ejecución +
        0,20 * puntuación_corrección_ejecución +
        0,20 * puntuación_fiabilidad_herramienta -
        0,15 * puntuación_alucinación
    )

def clasificar_modelos(ejecuciones: Lista[EjecuciónModelo]) -> Dict[cadena, flotante]:
    totales = {}
    recuentos = {}
    para ejecución en ejecuciones:
        totales[nombre_modelo_carrera] = totales.get(nombre_modelo_carrera, 0.0) + weighted_score(carrera)
        recuentos[nombre_modelo_carrera] = recuentos.get(nombre_modelo_carrera, 0) + 1
    return {m: round(totales[m] / recuentos[m], 3) for m in totales}

# Ejemplo de tareas
tareas = [
    Tarea(
        name="Revisión de la regresión del flujo de autenticación",
        artifact_bundle="sanitized_proxy_log + route_map + code_diff",
        expected_findings=["control de acceso roto", "desajuste de roles"],
        expected_evidence=["par de solicitudes", "brecha de autorización", "pasos repro"],
        expected_fix_points=["comprobación de autenticación en el servidor", "cobertura de pruebas"].
    ),
    Tarea(
        name="triaje de exposición CVE",
        artifact_bundle="asset_inventory + version_data + advisory_text",
        expected_findings=["sistemas afectados", "exposición en Internet", "orden de prioridad"],
        expected_evidence=["coincidencia de versión", "condiciones previas de la función", "estado de la mitigación"],
        expected_fix_points=["objetivo del parche", "contención", "paso de validación"].
    )
]

# Después de que cada modelo complete el mismo conjunto de puntos de referencia, puntúalos con una revisión humana.

Lo importante no es la Python. Lo importante es la rúbrica. Premiar la evidencia y la corrección. Penaliza las tonterías plausibles. Puntúa si el modelo se mantuvo dentro de los hechos disponibles. Puntúa si ayudó al revisor a avanzar más rápido sin hacer que el resultado fuera menos fiable. Así es como se elige un modelo que seguirá siendo útil seis meses después, una vez pasada la novedad.

Este es el punto en el que una discusión sobre modelos se convierte naturalmente en una discusión sobre plataformas. Una vez que se va más allá de la asistencia ad hoc, lo difícil ya no es simplemente "¿Qué modelo da la respuesta más inteligente?". Lo difícil pasa a ser la orquestación. ¿Cómo se conserva el contexto en todas las etapas, se coordinan las herramientas, se validan los resultados, se organizan las pruebas, se vuelven a probar las correcciones y se convierte todo en algo en lo que otro ingeniero pueda confiar?

Ahí es donde un sistema como Penligent encaja de forma natural. El propio material reciente de Penligent vuelve una y otra vez a la misma idea: la brecha entre el razonamiento LLM y el valor de seguridad de la producción se cierra mediante la validación impulsada por herramientas, los flujos de trabajo centrados en pruebas y la generación de informes estructurados, más que únicamente mediante indicaciones inteligentes. También por eso sus escritos recientes distinguen repetidamente entre la asistencia de seguridad estilo chat y los flujos de trabajo de validación agéntica vinculados a las pruebas, el mapeo ATT&CK y la verificación real. (Penligente)

En términos prácticos, eso significa que la mejor pregunta para un equipo puede ser: "¿Qué modelo debe alimentar qué etapa de nuestro flujo de trabajo de seguridad, y qué plataforma garantiza que el resultado sea auditable?". Si su respuesta a esta segunda pregunta es débil, incluso el mejor modelo le decepcionará. Si tu respuesta es fuerte, un modelo imperfecto puede seguir creando mucho valor.

La incómoda verdad, ningún modelo basta por sí solo

La conclusión más firme de las pruebas actuales no es que un proveedor haya resuelto el pentesting autónomo. Es que el sector está mejorando mucho a la hora de identificar dónde ayudan los modelos y dónde siguen fallando.

Ayudan mucho en la comprensión del repositorio, la generación de hipótesis, el resumen de artefactos, la redacción de soluciones, la automatización de bajo nivel y la organización de pruebas. Ayudan menos cuando se ven obligados a gestionar flujos de trabajo ofensivos largos y ramificados sin estructura, disciplina de memoria ni validación. Ayudan aún menos cuando los equipos tratan la confianza como precisión. El historial de investigación sobre este punto es coherente. PentestGPT demostró la importancia de la modularidad y la gestión del contexto. AutoPenBench demostró el valor de la asistencia humana. PentestEval demostró que las debilidades a nivel de etapa todavía se agravan cuando se les empuja a la autonomía total. (USENIX)

Por eso, los mejores equipos de 2026 están construyendo cada vez más flujos de trabajo de seguridad de IA en torno a unas pocas ideas estables: descomposición explícita de tareas, uso determinista de herramientas, captura de pruebas, validación aislada y revisión humana en los puntos en los que el coste de equivocarse es alto. El modelo sigue siendo enormemente importante. Pero el mejor modelo de IA para el pentesting se entiende ahora mejor como la mejor componente en un flujo de trabajo ofensivo disciplinado, no el sustituto mágico de uno.

Veredicto final

Entonces, ¿cuál es el mejor modelo de IA para pentesting en estos momentos?

Para la mayoría de los ingenieros de seguridad, la mejor respuesta es Claude Soneto 4.6. Ofrece el mejor equilibrio general de comprensión del código, razonamiento en contextos largos, calidad del flujo de trabajo colaborativo y coste sostenible. Es el modelo más fácil de recomendar por defecto si se necesita una respuesta y se desea la mayor utilidad cotidiana. (Antrópico)

Si su trabajo es más interactivo y similar al de un operador, especialmente en torno a la automatización del navegador, la navegación por aplicaciones en varios pasos y los bucles de ejecución basados en herramientas, GPT-5.4 es el especialista más fuerte. Es el modelo que elegiría cuando quiero que la IA conduzca y se adapte, no sólo que lea y razone. (OpenAI)

Si su trabajo gira en torno a conjuntos de pruebas muy grandes, PDF, documentos de arquitectura, registros y revisión multimodal, Géminis 3.1 Pro es más capaz de lo que muchos equipos de seguridad suponen y puede ser la opción económica más inteligente para esas cargas de trabajo. (Google DeepMind)

Y si está construyendo un sistema de pentest interno o comercial, la mejor respuesta no es un modelo único en absoluto. Se trata de una arquitectura enrutada con herramientas deterministas, puertas de validación y revisión humana donde haga falta. Lo dice la investigación. Lo dicen los mejores productos actuales. Lo dice la experiencia. (OpenAI)

Lecturas complementarias

OpenAI, Presentación de GPT-5.4 y Presentación de Aardvark, el agente investigador de seguridad de OpenAI. (OpenAI)

Antrópico, Claude Soneto 4.6 y la documentación oficial sobre precios. (Antrópico)

Google DeepMind y Google AI para desarrolladores, Géminis 3.1 Pro documentos modelo y precios. (Google DeepMind)

Seguridad USENIX 2024, PentestGPT, Evaluación y aprovechamiento de grandes modelos lingüísticos para pruebas de penetración automatizadas. (USENIX)

Industria de la REMPL 2025, AutoPenBench, una prueba de vulnerabilidad para agentes generativos. (Antología ACL)

PentestEval, Benchmarking LLM-based Penetration Testing with Modular and Stage-Level Design (Pruebas de penetración basadas en LLM con diseño modular y por etapas). (arXiv)

PortSwigger, Eructo AI documentación y la página del producto. (PortSwigger)

Penligente, Pentest Herramientas de IA en 2026 - Lo que realmente funciona, lo que se rompe. (Penligente)

Penligente, PentestGPT vs. IA Penligente en Compromisos Reales De LLM Escribe Comandos a Hallazgos Verificados. (Penligente)

Penligente, El marco ATT&CK de MITRE, la forma práctica de utilizarlo en la ingeniería de seguridad de 2026. (Penligente)