OpenAI ha presentado esta semana sus resultados sobre Deployment Simulation, una metodología de evaluación previa al despliegue pensada para anticipar cómo podría comportarse un modelo de inteligencia artificial antes de salir a producción. Tras la investigación, la compañía la ha planteado como una capa adicional dentro de sus procesos de seguridad.
Uno de los principales motivos del interés de OpenAI en esta metodología ha sido reducir retos tradicionales de la auditoria de IA como el evaluation awareness, o conciencia de evaluación. Se trata de un fenómeno en el que algunos modelos de IA ajustan su comportamiento al detectar que están siendo auditados, lo que dificulta anticipar cómo actuarían en casos reales.
Para abordar este reto, OpenAI utilizó como base para testar sus modelos aproximadamente 1,3 millones de conversaciones desidentificadas obtenidas con permiso de los usuarios de sus modelos Thinking de la serie GPT-5 entre 2025 y 2026. En esos contextos próximos al uso real, los modelos generaron respuestas que después fueron auditadas en busca de fallos, desviaciones o riesgos de seguridad.
Los resultados indican que Deployment Simulation no sustituye a las evaluaciones tradicionales, pero puede aportar señales más próximas al uso real. En los despliegues analizados, la simulación estimó mejor la frecuencia de algunos comportamientos no deseados y permitió detectar antes del lanzamiento del modelo GPT-5.1 Thinking un caso de calculator hacking, una situación de reward hacking donde un modelo parece cumplir la tarea, pero lo hace mediante un atajo no previsto.
Las ‘evaluaciones clásicas’ no son suficientes
Las evaluaciones tradicionales enfrentan tres retos. El primero es la cobertura o coverage: una prueba diseñada a mano difícilmente puede prever todos los comportamientos no deseados que pueden aparecer en producción. El segundo es la selección de sesgo o selection bias: muchas evaluaciones parten de riesgos ya conocidos o previstos, por lo que no siempre reflejan la variedad real del uso. El tercero es la conciencia de evaluación o evaluation awareness: algunos modelos pueden detectar que están siendo probados y modificar su comportamiento.
La simulación de despliegue intenta mitigar esas limitaciones con indicaciones representativas del uso reciente y contextos más próximos al tráfico real. Su ventaja es que permite ampliar la cobertura simulando más tráfico, en lugar de depender solo de nuevas pruebas construidas a mano.
Evaluación de Deployment Simulation
OpenAI evaluó Deployment Simulation sobre aproximadamente 1,3 millones de conversaciones desidentificadas procedentes de despliegues de modelos Thinking de la serie GPT-5, entre agosto de 2025 y marzo de 2026.
Para ello, pre-registró predicciones sobre la frecuencia de 20 tipos de comportamientos no deseados durante el despliegue de GPT-5.4 Thinking y realizó estudios retrospectivos sobre otros modelos de la misma serie. Las categorías incluyeron acciones desalineadas (misaligned actions) y salidas de contenido no permitido (disallowed-content outputs) ya recogidos en sus tarjetas de sistema, como modelos que mentían sobre el uso de herramientas o generaban contenido sexual no permitido.
Entre los criterios de evaluación se encontraron la cobertura de la taxonomía o taxonomy coverage, es decir, si la auditoría posterior detectaba comportamientos importantes que no estaban en la clasificación inicial de riesgos; la precisión direccional o directional accuracy, que medía si la simulación acertaba al prever si un comportamiento aumentaría o disminuiría durante el despliegue, alcanzando un 92% de acierto en cambios significativos; y la calibración de tasas o rate calibration, que comprobaba si las estimaciones previas se acercaban a las tasas observadas después en producción.
Además, se analizó cuántos modelos podían detectar que estaban en una evaluación y se probó la robustez del método ante distintos tipos de tráfico y configuraciones con herramientas.
Resultados de Deployment Simulation
En los despliegues de GPT-5 Thinking, Deployment Simulation estimó mejor la frecuencia real de comportamientos no deseados; no acertó siempre pero se aproximó a los datos reales. De media, si en producción aparecían 10 fallos, el sistema calculaba una cifra cercana: entre 7 y 15. OpenAI señala que, en los casos más desviados, el error podía ser mucho mayor, aunque espera reducirlo con mejoras en el sistema de simulación. También han destacado que el método funcionó mejor cuando la frecuencia de un comportamiento cambiaba de forma clara entre una versión del modelo y la siguiente.
El caso más relevante fue el de un hackeo de calculadora (calculator hacking), una forma de hackeo de recompensa (reward hacking), donde un modelo parece cumplir la tarea, pero lo hace mediante un atajo no previsto. En este caso, el modelo GPT-5.1 Thinking usó la herramienta de navegador como calculadora, pero presentó la acción como una búsqueda. Deployment Simulation habría detectado ese patrón antes del lanzamiento del modelo.
Para detectar si los modelos sabían que estaban siendo evaluados, OpenAI analizó tres señales: si distinguían una conversación real de una prueba, si decían explícitamente que estaban bajo evaluación y si mostraban metagaming, es decir, razonamiento sobre la supervisión o sobre cómo sería juzgada su respuesta.
En las pruebas con GPT-5.2, el modelo apenas distinguió entre tráfico real y tráfico simulado. En cambio, en evaluaciones tradicionales basadas sobre todo en ejemplos sintéticos, casi siempre detectó que estaba ante una prueba, acercándose al 100% de los casos. Las ejecuciones simuladas mejoradas también fueron mucho más difíciles de distinguir de las reales, con un resultado del 49,5%, muy cerca del azar.
Según OpenAI, las evaluaciones tradicionales siguen siendo más útiles para riesgos de baja prevalencia y alta gravedad, es decir, riesgos poco frecuentes, pero con consecuencias potencialmente graves; Deployment Simulation permite analizar riesgos vinculados al uso real y reciente de los modelos, aunque solo resulta útil para comportamientos que aparecen con una frecuencia suficiente en las muestras disponibles. En todo caso, no hay motivos para que las pruebas de red teaming, adversarial testing y pentestings sean sustituidos.
WildChat como apoyo para auditorías externas
OpenAI también probó si esta metodología podía servir a auditores externos que no tienen acceso al tráfico privado de producción. Para ello utilizó WildChat, un conjunto público de 100.000 conversaciones reales con modelos de lenguaje, como base para simular despliegues.
Los resultados fueron menos precisos que cuando OpenAI usó conversaciones recientes del uso real de sus propios modelos debido a las diferencias demográficas del tráfico, pero mantuvieron cierta utilidad. El error multiplicativo mediano fue de 2,44 veces con WildChat, frente a 1,75 veces con los datos internos recientes.
Aun así, las estimaciones con WildChat se mantuvieron a menudo dentro de un margen aproximado de 3 veces respecto a las tasas reales y también sirvieron para comparar modelos y señalar, con más acierto que una elección al azar, cuál podía tener menos errores en producción.
Limitaciones del método
OpenAI sitúa este tipo de evaluación como un complemento prometedor para auditorías externas, pero son conscientes de que existen varias limitaciones: depende de que los comportamientos no deseados aparezcan con suficiente frecuencia en las muestras, quedando el sistema condicionado por el floor detection ante eventos que ocurren menos de una vez cada 200.000 mensajes, de que el razonamiento del modelo pueda ser monitorizado y de que los datos usados reflejen el uso real.
A esto se añaden el environment fidelity error, que ocurre cuando las herramientas virtuales no replican perfectamente las respuestas del mundo real o enlaces que cambian con el tiempo, y el distribution shift error, derivado de las nuevas tendencias de comportamiento que adoptan los usuarios tras un lanzamiento. Un fallo que aparece una vez cada diez millones de conversaciones difícilmente aparecerá en una muestra de un millón. Por ese motivo, siguen siendo necesarios el red teaming, el adversarial testing y pentestings.
A esto se suma el reto computacional: simular 1,3 millones de conversaciones enteras utilizando modelos avanzados de la serie GPT-5 y simular 120.000 trayectorias de código requiere un poder de cómputo (GPUs) masivo y un coste económico brutal. La simulación de despliegue es muy efectiva, pero representa un lujo técnico que pocas empresas aparte de OpenAI pueden permitirse a esa escala.
