El red teaming automatizado de OpenAI GPT-Red reduce los fallos por inyección de prompts, pero el benchmark es interno

OpenAI afirma que GPT-Red redujo seis veces una tasa de fallos por inyección directa de prompts en cuatro meses, pese a haber logrado atacar casi todos los modelos anteriores a los que se enfrentó. La empresa publicó los detalles el 15 de julio de 2026 y presentó el entrenamiento adversarial automatizado como una defensa fundamental para unos agentes de IA cada vez más autónomos.

El cambio importante no es otro liderazgo en un benchmark. El red teaming automatizado de OpenAI GPT-Red sitúa a un atacante de IA directamente dentro del ciclo de entrenamiento de producción. El atacante busca instrucciones capaces de comprometer un modelo, mientras que los modelos defensores aprenden a resistir esos ataques sin abandonar las tareas legítimas.

Esto crea una competición más incisiva que un simple enfrentamiento entre modelos. OpenAI apuesta por que la mejora autónoma mediante técnicas adversariales pueda mantener la seguridad de los agentes a la altura de sus capacidades crecientes. La realidad opuesta es que un atacante entrenado en entornos controlados puede pasar por alto amenazas generadas por aplicaciones, usuarios, herramientas y decisiones de implementación desconocidos.

La empresa no ha publicado GPT-Red, y sus resultados más sólidos dependen en gran medida de evaluaciones internas. Estas limitaciones son importantes porque la inyección de prompts es un problema de seguridad de todo el sistema. El entrenamiento del modelo puede reducir los fallos, pero no puede controlar todos los permisos, conectores o aplicaciones que lo rodean.

El red teaming automatizado de OpenAI GPT-Red se integra en el entrenamiento de modelos

OpenAI ha convertido el red teaming automatizado, antes una prueba previa al lanzamiento, en una fuente continua de datos para el entrenamiento de producción.

El red teaming consiste en atacar deliberadamente un sistema para descubrir fallos antes de que los exploten adversarios reales. Por lo general, especialistas humanos diseñan escenarios de ataque, observan el sistema y documentan las vulnerabilidades para que puedan corregirse.

GPT-Red realiza una búsqueda similar de forma automática. Lanza un ataque, observa la respuesta del defensor y modifica su estrategia en función de lo ocurrido. Los ataques que tienen éxito se convierten después en material para evaluar o entrenar modelos posteriores.

Según la investigación sobre GPT-Red, OpenAI entrenó al atacante mediante aprendizaje por refuerzo con autojuego. El autojuego entrena conjuntamente sistemas rivales, recompensando a uno por provocar fallos y al otro por resistirlos.

OpenAI dio a GPT-Red control sobre componentes realistas del entorno de un agente. Entre ellos se encontraban el contenido de correos electrónicos, archivos locales, banners de páginas web y resultados de herramientas. Cada entorno también definía el objetivo del atacante y las condiciones necesarias para considerar válido un ataque exitoso.

Este detalle diferencia el proyecto de las pruebas habituales de jailbreak. Un jailbreak suele comenzar cuando un usuario hostil pide al modelo que infrinja una política. Una inyección indirecta de prompts puede ocultar instrucciones maliciosas dentro de información que el usuario nunca escribió.

Un agente podría encontrar esas instrucciones mientras resume un correo electrónico, examina código o investiga un sitio web. El texto inyectado puede ordenarle que ignore su tarea original, revele información o haga un uso indebido de una herramienta conectada.

OpenAI afirma que GPT-Red vulneró casi todos los modelos internos y de producción sometidos a prueba hasta GPT-5.5. Posteriormente, la empresa utilizó sus ataques para entrenar GPT-5.6, incluido el modelo GPT-5.6 Sol.

La mejora resultante parece considerable dentro del entorno de pruebas de OpenAI. Según la empresa, GPT-5.6 Sol produjo seis veces menos fallos en su benchmark más exigente de inyección directa de prompts que su mejor modelo de producción cuatro meses antes.

OpenAI también informa de que GPT-5.6 Sol falló en el 0,05 por ciento de los ataques directos de GPT-Red en un conjunto más amplio de entornos de resiliencia. Esa cifra describe el rendimiento frente al atacante entrenado por la empresa, no una protección universal contra la inyección de prompts.

Variantes anteriores de GPT-Red descubrieron una técnica denominada Fake Chain-of-Thought. El ataque proporciona un razonamiento inventado con el que intenta convencer al modelo de que una acción prohibida es válida.

OpenAI informa de que estos ataques tuvieron éxito en más del 95 por ciento de los casos contra GPT-5.1. Según la empresa, la tasa descendió por debajo del 10 por ciento con GPT-5.6 Sol.

Estas cifras hacen que el anuncio sea relevante. OpenAI ya no considera el descubrimiento de ataques como una evaluación aislada realizada después del entrenamiento. Está utilizando la búsqueda adversarial para dar forma al modelo antes de su implementación.

Esto convierte las pruebas de seguridad en un insumo de entrenamiento con su propia vía de escalado. Los defensores más sólidos obligan a GPT-Red a encontrar ataques más difíciles, mientras que esos ataques se convierten en lecciones para el siguiente defensor.

El autojuego crea un atacante que evoluciona junto con el defensor

El mecanismo central es una competición dinámica en la que la defensa exitosa de ayer se convierte en la dificultad mínima de hoy.

Los conjuntos de datos tradicionales de seguridad contienen ataques conocidos y las respuestas esperadas. Ayudan a los modelos a reconocer patrones recurrentes, pero pueden perder valor a medida que mejoran las defensas. Una colección estática no puede buscar activamente la siguiente vulnerabilidad.

GPT-Red modifica ese proceso al recibir una recompensa cuando provoca un fallo válido. Los modelos defensores reciben recompensas por mantener la tarea original mientras resisten instrucciones hostiles. Por tanto, ambos lados están sometidos a presión para mejorar.

El artículo técnico completo describe una población de defensores diversos, en lugar de un único oponente fijo. Esta elección evita que el atacante dependa de una vulnerabilidad presente en un solo modelo.

Los entornos también representan diferentes superficies de ataque. Una instrucción oculta en un correo electrónico requiere una vía distinta de la utilizada por contenido malicioso dentro de un repositorio de código. El acceso a herramientas puede convertir cualquiera de esos fallos, de una respuesta textual incorrecta, en una acción externa.

Esta diversidad ayuda a explicar la inversión en capacidad de cómputo. OpenAI afirma que GPT-Red utilizó recursos comparables a los de algunas de sus mayores sesiones de posentrenamiento. La empresa lo describe como un compromiso interno de capacidad de cómputo sin precedentes dedicado exclusivamente a mejorar la seguridad.

La capacidad de cómputo por sí sola no ofrece una cobertura integral. Amplía la cantidad de ataques que el modelo puede intentar y el tiempo durante el que puede continuar la competición. El diseño del entorno sigue determinando qué amenazas puede descubrir el atacante.

El resultado comparativo más sólido de GPT-Red procedió de una réplica de un entorno competitivo de inyección indirecta de prompts. OpenAI informa de que encontró ataques exitosos en el 84 por ciento de los escenarios contra GPT-5.1. Según la empresa, los especialistas humanos de red teaming tuvieron éxito en el 13 por ciento.

La comparación respalda la automatización como multiplicador de la capacidad de búsqueda. Un modelo puede probar numerosas variantes de ataque sin que una persona tenga que escribir cada prompt. También puede conservar los intentos fallidos y perfeccionarlos sistemáticamente.

Sin embargo, la comparación no vuelve obsoleto el trabajo humano en seguridad. Las personas pueden cuestionar el modelo de amenazas, detectar supuestos poco realistas e identificar daños que una recompensa automatizada pasa por alto. También pueden examinar vulnerabilidades sociales y organizativas ajenas al entorno del modelo.

OpenAI presenta explícitamente GPT-Red como un complemento de las pruebas humanas y de terceros. También mantiene salvaguardas por capas y monitorización en tiempo real. Este enfoque reconoce que el entrenamiento no puede representar todas las condiciones de producción.

La diferencia se aprecia con mayor claridad en el experimento de la máquina expendedora de OpenAI. GPT-Red exploró primero ataques en una simulación basada en un agente de producción. Después, transfirió una selección de esos ataques al sistema real.

OpenAI afirma que el ataque modificó los precios de artículos, organizó un pedido desfavorable y canceló el pedido de otro cliente. La empresa comunicó las vulnerabilidades al desarrollador del sistema, que comenzó a probar salvaguardas adicionales.

El ejercicio se asemeja a Project Vend, el experimento de Anthropic con una tienda de oficina operada por IA. Ambos proyectos demuestran por qué la fiabilidad de los agentes difiere de la seguridad habitual de los chatbots.

El fallo de un chatbot puede generar una respuesta no deseada. El fallo de un agente puede modificar registros, ejecutar código, enviar mensajes o aprobar transacciones. El software circundante determina qué consecuencias son posibles.

OpenAI también probó GPT-Red contra un agente de línea de comandos de Codex basado en GPT-5.4 mini. La evaluación contenía diez escenarios reservados de exfiltración de datos, excluidos de los entornos de entrenamiento del atacante.

La empresa afirma que GPT-Red comprometió más escenarios que un sistema de referencia basado en GPT-5.5 mediante prompting, al tiempo que utilizó menos tokens. Este resultado sugiere que el entrenamiento especializado mejoró la búsqueda de ataques más allá de limitarse a asignar un rol hostil a un potente modelo generalista.

Por tanto, el mecanismo es más importante que cualquier tasa de éxito concreta. El red teaming automatizado de OpenAI GPT-Red crea un proceso repetible para generar ataques, convertirlos en datos de entrenamiento y medir a los defensores posteriores.

Los desarrolladores de agentes afrontan ahora unos requisitos mínimos de seguridad más exigentes

GPT-Red presiona a todos los desarrolladores de agentes para que traten las pruebas de inyección de prompts como un proceso continuo de ingeniería, no como una lista de comprobación previa al lanzamiento.

La presión inmediata recae sobre los competidores de OpenAI, incluidos Anthropic y Google. Cualquier empresa que venda agentes capaces de utilizar herramientas debe explicar cómo prueba las instrucciones ocultas en navegadores, archivos, correos electrónicos, código y servicios de terceros.

El anuncio también eleva las expectativas de los clientes. Un proveedor ya no puede presentar unas pocas instrucciones de ataque diseñadas manualmente como prueba suficiente. Los compradores preguntarán cada vez más si las pruebas evolucionan cada vez que cambia un modelo, un conector o un permiso.

Los estándares independientes ya apuntan hacia esta perspectiva más amplia. La taxonomía de ataques de NIST abarca la inyección directa e indirecta de prompts, además de otras amenazas para la IA generativa.

Esta taxonomía considera los ataques y las mitigaciones como partes de un proceso de gestión de riesgos. No plantea que una única intervención de entrenamiento resuelva el problema. Las organizaciones siguen necesitando controles de implementación, pruebas, monitorización y gestión de incidentes.

El mismo principio aparece en las directrices de seguridad de aplicaciones. El riesgo para agentes de OWASP conocido como autonomía excesiva describe sistemas con más funcionalidades, permisos o autonomía de los que requieren sus tareas.

Este riesgo es importante porque una inyección exitosa solo puede utilizar las capacidades disponibles para el agente comprometido. Un asistente sin permiso para enviar correos electrónicos no puede reenviar un mensaje en secreto. Uno con acceso amplio al buzón puede causar daños mayores.

Por tanto, GPT-Red modifica dos requisitos mínimos distintos para los desarrolladores. El primero se refiere a la resistencia del modelo. El segundo, a cuánta confianza deberían depositar las aplicaciones en esa resistencia.

Un modelo subyacente más sólido puede reducir fallos habituales en numerosos productos. No puede determinar si una aplicación concreta concede acceso ilimitado a archivos u omite la confirmación antes de realizar una acción externa.

Los equipos de seguridad deberían exigir que los proveedores comuniquen resultados de flujos de trabajo realistas, no solo de benchmarks basados exclusivamente en texto. Las evaluaciones útiles deben abarcar el modelo, las instrucciones del sistema, las descripciones de herramientas, el contenido recuperado, las reglas de autorización y las confirmaciones del usuario.

La necesidad aumenta a medida que los agentes manejan contextos más sensibles. Los navegadores los exponen a sitios web no controlados. El acceso a archivos locales los expone a documentos procedentes de numerosas fuentes. Las aplicaciones conectadas los exponen a mensajes y espacios de trabajo compartidos.

Una instrucción maliciosa puede introducirse a través de cualquiera de esos canales. También puede permanecer invisible para la persona que inició la tarea. Esto elimina la advertencia evidente que proporcionaría un prompt sospechoso del usuario.

Los trabajadores del conocimiento tienen un motivo relacionado para prestar atención. Los sistemas de IA recopilan cada vez más contexto de documentos dispersos antes de responder preguntas o actuar. Un mejor contexto puede mejorar los resultados, pero cada fuente importada amplía el perímetro de confianza.

Una base de conocimiento de IA controlada puede ayudar a los usuarios a comprender de dónde procede la información y quién puede acceder a ella. Sin embargo, conocer la procedencia no convierte automáticamente en seguras las instrucciones incrustadas.

La respuesta adecuada no consiste en dejar de conectar información útil, sino en separar los datos de la autoridad. Un documento debe aportar hechos sin obtener permiso para redefinir la tarea del agente.

Los diseñadores de aplicaciones pueden reforzar esa distinción mediante accesos con privilegios mínimos, tokens de alcance limitado, vistas previas de las acciones y requisitos de confirmación. Estos controles siguen siendo útiles incluso cuando un atacante descubre una técnica lingüística desconocida.

El resultado de OpenAI proporciona a los desarrolladores un componente defensivo más sólido. También elimina una excusa. Si los ataques automatizados pueden generar datos de entrenamiento diversos a gran escala, los equipos de producto deberían incorporar pruebas adversariales continuas en su proceso de lanzamiento.

La respuesta obligada se desarrollará a largo plazo. Los competidores necesitarán sus propios generadores de ataques, evaluaciones compartidas o programas de pruebas de terceros. Los compradores empresariales necesitarán pruebas vinculadas a sus integraciones reales.

Los benchmarks internos dejan abiertas las preguntas más difíciles

Las mejoras comunicadas son significativas, pero no demuestran que la inyección de prompts se haya resuelto fuera de los entornos elegidos por OpenAI.

La primera incertidumbre se refiere a quién controla la evaluación. OpenAI diseñó GPT-Red, seleccionó sus entornos, entrenó a los defensores y publicó las puntuaciones resultantes. El artículo ofrece abundantes detalles técnicos, pero los investigadores externos no pueden ejecutar el modelo interno.

GPT-Red sigue siendo privado porque OpenAI lo entrenó deliberadamente para crear ataques eficaces. Publicar el modelo podría proporcionar a los adversarios capacidades que la empresa desarrolló con fines defensivos.

Esa decisión tiene una clara justificación de seguridad. También limita la replicación independiente. Los investigadores pueden examinar el método, pero no comprobar plenamente si el mismo atacante obtiene resultados similares frente a sistemas no relacionados.

La segunda incertidumbre se refiere al cambio de distribución, que se produce cuando las entradas reales difieren de los datos de entrenamiento y evaluación. Los atacantes eligen sus propios idiomas, interfaces, tiempos y combinaciones de técnicas.

Un agente en producción también puede utilizar una capa de orquestación distinta de la empleada por OpenAI en sus pruebas. Puede tener instrucciones de sistema, memoria, recuperación de información, herramientas y reglas de aprobación personalizadas. Cada componente modifica la superficie de ataque.

Por tanto, una baja tasa de fallos frente a ataques directos de GPT-Red responde a una pregunta limitada. Mide con qué frecuencia un defensor concreto falla ante un atacante desarrollado específicamente, en una serie de entornos definidos. No contempla a todos los atacantes futuros.

El resultado del 84 por ciento en escenarios reservados ofrece mejores indicios de generalización. Esos entornos diferían del conjunto de entrenamiento de GPT-Red, y equipos humanos de red teaming probaron la misma colección de escenarios.

Aun así, la evaluación utilizó una réplica interna y tuvo como objetivo GPT-5.1. Los equipos independientes no han verificado si GPT-Red mantiene esa ventaja frente a modelos competidores o sistemas de producción desconocidos.

La tercera incertidumbre se refiere a la preservación de capacidades. Un modelo puede parecer más seguro cuando rechaza tareas difíciles, evita herramientas o limita sus acciones. OpenAI afirma que sus evaluaciones no detectaron ninguna pérdida en las capacidades habituales de los modelos de frontera.

La empresa también evaluó los rechazos excesivos e informa de que la capacidad para completar tareas legítimas se mantuvo intacta. Es un resultado alentador, pero los detalles de la evaluación subyacente son importantes. Los usuarios reales suelen descubrir patrones de rechazo que los benchmarks generales de capacidades no detectan.

Un defensor también podría tener éxito volviéndose cauteloso únicamente en contextos adversariales reconocibles. Los atacantes pueden responder disfrazando instrucciones maliciosas de contenido empresarial ordinario. Esta pugna hace imprescindibles las pruebas externas y diversas.

El cuarto problema es la interpretación de las métricas. Una tasa media de éxito de los ataques puede ocultar debilidades concentradas. Incluso una tasa general mínima puede ser relevante si los fallos se agrupan en torno al correo electrónico, el acceso a credenciales o las acciones irreversibles.

El impacto en la seguridad depende tanto de la probabilidad como de las consecuencias. Comprometer una entrada del calendario no es lo mismo que exponer una credencial. Las organizaciones necesitan resultados por escenario antes de trasladar la puntuación de un benchmark al riesgo operativo.

El quinto problema afecta al planteamiento de la automejora. GPT-Red ayuda a los modelos futuros a resistir ataques generados por los sistemas actuales. Sin embargo, utilizar modelos para supervisar a otros modelos puede crear puntos ciegos compartidos.

Atacantes y defensores pueden aprender supuestos similares a partir de fuentes de entrenamiento coincidentes. Pueden volverse hábiles dentro de un juego conocido mientras pasan por alto amenazas ajenas a su estructura de recompensas.

Los evaluadores humanos ofrecen un contrapeso parcial porque aportan experiencias y objetivos diferentes. Los investigadores externos pueden desafiar el sistema sin compartir los supuestos institucionales del desarrollador.

Por eso, el compromiso continuado de OpenAI con el red teaming humano y externo importa tanto como su inversión en capacidad de cómputo. La automatización aporta escala, mientras que las pruebas independientes aportan discrepancia.

El red teaming automatizado de OpenAI GPT-Red debe interpretarse como una prueba de que existe un ciclo de entrenamiento más sólido. No debe convertirse en una garantía de seguridad para todos los productos que utilicen GPT-5.6 Sol.

El estándar práctico sigue siendo la defensa por capas. Los modelos deben resistir instrucciones hostiles, las aplicaciones deben restringir la autoridad y los operadores deben supervisar las acciones de importancia. Cada capa parte del supuesto de que otra puede fallar.

Tres señales mostrarán si GPT-Red cambia la seguridad de los agentes

La siguiente prueba consiste en comprobar si las mejoras internas de GPT-Red resisten la evaluación independiente, un despliegue más amplio y las respuestas decididas de sus competidores.

La primera señal será la reproducción externa en sistemas de agentes desconocidos. Los investigadores necesitan evaluaciones que integren GPT-5.6 Sol en aplicaciones no diseñadas por OpenAI.

Esas pruebas deberían incluir distintos frameworks de herramientas, sistemas de recuperación de información, formatos de archivo y estructuras de permisos. También deberían distinguir entre las inyecciones directas y las instrucciones ocultas en contenido de terceros.

Si GPT-5.6 Sol conserva una ventaja amplia, el método de autojuego de OpenAI ganará credibilidad más allá de su benchmark interno. Si el rendimiento varía considerablemente según la aplicación, la arquitectura del sistema seguirá siendo el factor dominante.

Las pruebas externas deberían comunicar tanto la frecuencia de los ataques como la gravedad de sus consecuencias. Deberían distinguir entre una tarea ignorada y una filtración de datos o una acción externa no autorizada. La precisión agregada no puede reflejar por sí sola esas diferencias.

La segunda señal será si Anthropic, Google y otros proveedores de modelos publican resultados comparables de red teaming automatizado. Una respuesta competitiva demostraría que el entrenamiento adversarial se ha convertido en una inversión estándar en capacidades.

La prueba importante no será otro porcentaje aislado. Los proveedores deberían revelar sus modelos de amenazas, los entornos reservados para evaluación, las compensaciones relacionadas con los rechazos y la relación entre las defensas del modelo y los controles de la aplicación.

Las evaluaciones compartidas o interoperables ofrecerían una señal aún más sólida. Un red teamer desarrollado por una organización debería atacar a los defensores de otra sin recibir una adaptación especial.

Estas pruebas cruzadas pueden revelar si los atacantes se sobreajustan a los modelos de sus creadores. También pueden reducir la ventaja que supone mantener ambos lados de la evaluación dentro de un mismo laboratorio.

Si los competidores igualan a OpenAI utilizando métodos diferentes, el entrenamiento adversarial automatizado parecerá una dirección duradera para el sector. Si los resultados siguen sin ser comparables, a los compradores les resultará difícil distinguir los avances en seguridad de la presentación selectiva de resultados.

La tercera señal será el patrón de fallos de los agentes GPT-5.6 desplegados. OpenAI afirma que GPT-Red ha aportado ataques de entrenamiento a cada modelo de producción sucesivo desde GPT-5.3.

Los incidentes en producción revelarán si esas mejoras cubren flujos de trabajo reales. Entre las pruebas relevantes figuran las inyecciones exitosas, los ataques bloqueados, los rechazos excesivos y los fallos causados por permisos de herramientas demasiado amplios.

La supervisión de OpenAI también puede reincorporar nuevos fallos a los entornos de GPT-Red. Esto completaría el ciclo de mejora continua de la seguridad propuesto, conectando las pruebas obtenidas en los despliegues con el entrenamiento de atacantes y las futuras actualizaciones de los defensores.

El ciclo resulta menos convincente si las mejoras comunicadas permanecen confinadas a lanzamientos internos. Gana solidez cuando incidentes imprevistos producen mejoras medibles en modelos posteriores.

Los desarrolladores no necesitan esperar esas respuestas para actuar. Pueden inventariar todas las fuentes no fiables que entran en el contexto de un agente y todas las herramientas capaces de ejecutar acciones importantes que quedan disponibles después.

También pueden comprobar si el contenido ordinario es capaz de alterar el objetivo del agente. Cada acción crítica debería requerir únicamente el permiso mínimo necesario, con confirmación adicional para los pasos irreversibles.

Los equipos que gestionan grandes colecciones de material de proyectos pueden utilizar la fusión de conocimiento para organizar el contexto relevante. Aun así, deberían tratar los documentos y mensajes importados como datos no fiables y no como autoridad ejecutable.

El red teaming automatizado de OpenAI GPT-Red establece un benchmark más exigente para los proveedores de modelos. Demuestra que los atacantes de IA pueden realizar búsquedas amplias, producir datos de entrenamiento y mejorar a los defensores posteriores en cuestión de meses.

La pregunta pendiente es si esa ventaja defensiva persiste cuando el entorno deja de parecerse al campo de entrenamiento. Los desarrolladores y compradores empresariales deberían pedir a los proveedores pruebas específicas de sus flujos de trabajo, no solo una cifra llamativa.

Revise qué fuentes pueden leer sus agentes, qué acciones pueden ejecutar y dónde sigue siendo obligatoria la aprobación humana. Después, observe atentamente las tres señales. La reproducción independiente, las pruebas cruzadas entre proveedores y los datos sobre fallos en producción determinarán si GPT-Red representa un avance duradero en seguridad o una ronda más de una contienda aún inconclusa.