OpenAI prueba Deployment Simulation: evals más realistas para agentes antes de soltarlos
OpenAI publicó el 16 de junio de 2026 Deployment Simulation, una técnica para estimar comportamiento de modelos con contextos parecidos a producción. Para builders de agentes, la señal útil es medir tool use y riesgo con trayectorias realistas, no solo con prompts sintéticos.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
OpenAI publicó el 16 de junio de 2026 una técnica llamada Deployment Simulation para contestar una pregunta que muchos equipos de agentes todavía tratan con demasiada fe: ¿cómo se va a comportar un modelo cuando deje de estar en el banco de pruebas y empiece a recibir tráfico parecido al real?
La idea base es directa. En vez de evaluar solo con prompts sintéticos o casos adversariales diseñados a mano, OpenAI toma conversaciones previas, quita la respuesta del modelo antiguo y deja que un modelo candidato responda en ese contexto. Luego compara esas respuestas para buscar conductas no deseadas y estimar frecuencias antes del release.
Por qué importa para agentes
En chat simple, ya es difícil saber si una evaluación representa uso real. En agentes es peor. Una trayectoria puede depender de cientos de tool calls, estado de repositorio, respuestas de red, archivos, permisos y fallos transitorios.
OpenAI dice que probó la técnica también en despliegues agentic de coding. Para hacerlo sin tocar sistemas vivos, simuló tool calls con otro modelo y le dio contexto adicional: el rollout original, el repositorio de ese momento, una base de pares tool-call/respuesta y conectores de solo lectura. En una prueba de realismo, el resultado se acercó al azar frente a rollouts reales, que es justo lo que quieres si intentas que el candidato no “huela” que está siendo evaluado.
Eso deja una lección práctica: si tu evaluación de agente no incluye entorno, tools y estado, probablemente está midiendo una demo, no el sistema.
El avance no reemplaza red teaming
OpenAI es claro en los límites. Deployment Simulation sirve mejor para conductas que aparecen con suficiente frecuencia en muestras grandes. Si una falla ocurre una vez en diez millones de conversaciones, no conviene esperar que salga por muestreo general. Para riesgos raros, adversariales o catastróficos, sigues necesitando red teaming, evals dirigidas y revisión humana.
También hay un problema de fidelidad. Simular tools con suficiente realismo es difícil. Si el entorno simulado no se parece al entorno real, la estimación puede salir bonita y equivocada.
Qué copiaría un equipo builder
No necesitas tener tráfico de OpenAI para aprender del patrón. En un equipo pequeño, lo aterrizaría así:
- guarda trazas reales de tareas de agente con inputs, decisiones, tool calls y resultado final;
- elimina datos sensibles antes de reutilizarlas;
- reejecuta una muestra con el modelo o harness candidato;
- compara éxito, costo, latencia, intervenciones humanas y errores de tool use;
- conserva evals adversariales separadas para riesgos de baja frecuencia.
La parte importante es no mezclar todo en un score único. Un agente puede mejorar en resolución de tareas y empeorar en permisos, trazabilidad o costo. Deployment Simulation empuja a mirar el comportamiento completo, no solo accuracy.