El 31 de octubre de 2026 es la fecha que OpenAI fija para que las evaluaciones existentes de su plataforma Evals pasen a solo lectura. El cierre del panel y de la API de Evals está previsto para el 30 de noviembre. Si una aplicación depende de ese servicio para decidir qué versión puede desplegar, conviene trasladar sus pruebas y comprobar que el nuevo sistema conserva el criterio de aceptación.
El anuncio original fue el 3 de junio, según el calendario oficial de retiradas. Recuperamos ahora este plazo; no es un anuncio nuevo de octubre. La documentación establece las fechas, pero Puntoes no ha comprobado el cambio de estado con una cuenta ni una hora exacta de corte.
Qué servicio cambia
La transición afecta al producto Evals y a los evaluadores, o graders, documentados para esos flujos. La misma fuente separa los plazos de ajuste fino de modelos, conocido como fine-tuning. Este aviso no significa que desaparezca toda la API de OpenAI ni que deje de ser posible evaluar una aplicación con otras herramientas.
El itinerario recomendado por OpenAI hacia Promptfoo propone recrear manualmente las evaluaciones. Promptfoo es una herramienta de código abierto con interfaz de línea de comandos y biblioteca. Permite mantener la configuración junto al código y ejecutarla localmente o en integración continua, el sistema que comprueba los cambios antes del despliegue.
Migrar la prueba, además del archivo
La unidad que hay que conservar es la prueba completa: instrucciones, modelo o proveedor, entradas y criterio que puntúa las respuestas. En Promptfoo se representan mediante configuración, casos y comprobaciones —assertions—, entre otros elementos. La guía utiliza un archivo promptfooconfig.yaml.
El documento no necesita un exportador de Evals para seguir sus pasos. Tampoco promete una conversión automática del historial: una ejecución nueva en Promptfoo produce resultados separados de los que ya se completaron en Evals. Los flujos con herramientas, agentes o proveedores personalizados pueden necesitar configuración adicional.
Nuestro criterio es conservar también la versión del modelo, las instrucciones del evaluador y los umbrales utilizados. Tener el mismo conjunto de preguntas no garantiza que el nuevo sistema esté midiendo exactamente lo mismo.
Un ejemplo de soporte: respuesta y abstención
Ejemplo hipotético, no ejecutado por Puntoes: un equipo prueba un asistente de soporte con consultas que tienen respuesta documentada y otras que deberían terminar en una abstención. Antes de sustituir el sistema de evaluación, conservaría las entradas, las respuestas esperadas y las instrucciones que distinguen ambos casos.
Después revisaría ejemplos individuales: una respuesta correcta, una inventada y una abstención adecuada. Si un juez basado en un modelo empieza a aceptar respuestas antes rechazadas, investigaría el cambio antes de permitir que esa puntuación desbloquee publicaciones. Un porcentaje global parecido puede ocultar errores distintos.
La guía oficial advierte que las puntuaciones de similitud pueden variar entre sistemas y que un evaluador recreado necesita validación. Nuestro artículo sobre calibración de un LLM como juez desarrolla ese problema. Copiar las instrucciones del juez es un punto de partida; su comportamiento aún debe contrastarse.
Qué preparar antes del cierre
Inventariar las pruebas que sostienen decisiones de producción, conservar sus materiales disponibles y recrear primero una evaluación pequeña facilita detectar diferencias. La instalación de Promptfoo y las credenciales del proveedor son requisitos del recorrido oficial; usar una herramienta abierta no elimina el coste de las llamadas a modelos.
Antes de confiarle el control de un despliegue, hay que revisar resultados, fallos y criterios. Esa comprobación es la parte decisiva de la migración, aunque el archivo de configuración ya sea válido.