OpenAI apaga la Assistants API y retira modelos: cómo migrar tus automatizaciones antes del 23 de octubre

Una API retirada no avisa al usuario final. El primero en avisar suele ser un cliente molesto.

El 26 de agosto de 2026 OpenAI apagó la Assistants API. Lo había anunciado un año antes, el 26 de agosto de 2025, y cumplió la fecha. Cualquier chatbot, asistente interno o flujo de n8n que siguiera creando threads y runs contra ese endpoint devuelve error desde ese día. Los sustitutos oficiales son la Responses API y la Conversations API, según la página de deprecaciones de OpenAI.

Detrás vienen más. El 23 de octubre de 2026 se apagan gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-turbo, o1, o1-pro, o3-mini y los fine-tunes hechos sobre modelos antiguos. El 30 de noviembre caen Evals, Agent Builder y la Reusable prompts API. El 1 de diciembre, varios modelos de GPT Image. El 26 de febrero de 2027 le toca a whisper-1 y a los modelos de transcripción de la familia gpt-4o.

Si montaste automatizaciones con OpenAI en 2023 o 2024 y nadie las ha revisado desde entonces, alguna está en esa lista. Este artículo explica cómo migrar la Assistants API de OpenAI y los modelos retirados con un método de cuatro pasos: inventario, tabla de sustitutos, orden por riesgo y prueba antes de tocar producción.

Los proveedores retiran modelos. Es parte del contrato. Lo que sale caro es enterarse tres semanas tarde.

Qué ha apagado OpenAI y qué viene: calendario de agosto de 2026 a febrero de 2027

Primero, el mapa completo. Esta tabla junta lo que tiene fecha entre agosto de 2026 y febrero de 2027 y afecta a automatizaciones típicas de pyme.

Tres notas sobre esta tabla.

Los alias "latest" ya cayeron. Make publicó un aviso para sus usuarios: gpt-5.2-chat-latest y gpt-5.3-chat-latest se apagaron el 10 de agosto de 2026 y los escenarios que los usaban dejaron de ejecutarse. Si tu escenario lleva desde agosto con errores y nadie lo ha visto, ese es el síntoma.

El 23 de octubre se lleva más de lo que parece. El aviso es del 22 de abril de 2026 y la lista oficial incluye modelos que mucha gente cree recientes, como gpt-4o-2024-05-13, gpt-4.1-nano u o4-mini. Si tu flujo usa uno de esos con la fecha escrita en el nombre, está afectado.

La columna de sustituto es un punto de partida. Para la Assistants API y para Whisper hay poco que decidir. Para los modelos del 23 de octubre, el sustituto que te conviene depende de para qué usabas cada uno. Eso se decide en el paso 2, flujo por flujo.

Por qué tus automatizaciones pueden fallar sin que nadie se entere

Una automatización con IA vive en segundo plano. Nadie la mira mientras funciona. Para eso se automatiza, y ahí está también el riesgo.

Casi todas estas integraciones nacieron igual en 2023 y 2024. Alguien conectó el formulario de la web a un asistente de OpenAI, o una grabación de Teams a Whisper para sacar el acta. Funcionó a la primera. Se quedó así.

Cuando el endpoint o el modelo desaparece, pasan cosas como estas:

• El chatbot de la web responde con un mensaje genérico. "Lo siento, ha ocurrido un error. Inténtalo más tarde." El visitante se va. Nadie de la empresa pregunta a su propio chatbot.
• El flujo de n8n se detiene en un nodo. Si no hay un workflow de error configurado, la ejecución fallida queda en el histórico. El histórico no lo abre nadie.
• El escenario de Make se desactiva tras varios errores seguidos. Con un disparador programado, Make lo apaga por defecto a los tres errores consecutivos. El aviso llega por correo a quien tenga activadas las notificaciones, que a veces es alguien que ya no trabaja en la empresa.
• La transcripción devuelve vacío. El acta de la reunión llega sin contenido o no llega. Durante un par de semanas todo el mundo asume que ya la mandará alguien.

Ejemplo: una asesoría laboral de 14 personas en Sabadell tiene en su web un asistente sobre calendario laboral y plazos de nómina, montado en 2024 con la Assistants API. El 26 de agosto deja de responder. En agosto nadie de la asesoría entra a su propia web. El primer aviso llega a mediados de septiembre, de un cliente que comenta por teléfono que el chat de la web no va.

Traducción: el error técnico se produce en un segundo y el agujero de proceso lo alarga tres semanas. El agujero es no saber qué depende de qué.

Paso 1: inventario de integraciones antes de migrar la Assistants API de OpenAI

Antes de cambiar nada, necesitas una lista. Sin lista, migras lo que recuerdas y te dejas el resto.

Dónde buscar

Panel de uso de OpenAI. Empieza por aquí. En la plataforma de OpenAI puedes ver el consumo desglosado por modelo y por clave de API. Si ves consumo asociado a una clave que no reconoces, apúntala: esa es la que más guerra te va a dar.

Lista de claves de API. Revisa todas las claves de la organización y de cada proyecto. Para cada una, pregunta dónde está pegada. Una clave que nadie sabe ubicar es una dependencia sin dueño.

n8n. Busca todos los workflows con nodos de OpenAI. Ojo con los que eligen el modelo con una expresión. Lo más rápido es exportar los workflows a JSON y buscar texto dentro. Si montaste n8n siguiendo la guía de automatización con n8n sin servidores propios, tus flujos están todos en un solo sitio y el inventario sale en una tarde.

Make. Revisa los escenarios con módulos de OpenAI. Los escenarios desactivados también cuentan: alguno se apagó solo por errores y nadie se dio cuenta.

Zapier. Mismo ejercicio con los zaps que usan la app de OpenAI o de ChatGPT. Revisa el historial de ejecuciones de cada uno buscando errores desde agosto.

Código propio. Si tienes scripts en Python, Node o Apps Script de Google Sheets, busca en los repositorios los nombres de modelos y las llamadas a assistants, threads y runs. Una búsqueda de texto basta:

grep -rnE "assistants|threads|runs\.create|gpt-4-turbo|gpt-4-0613|gpt-4-1106|gpt-3\.5-turbo|gpt-4o-2024-05-13|gpt-4\.1-nano|o1|o3-mini|o4-mini|gpt-image-1|whisper-1|transcribe|ft:" .

Saldrán falsos positivos. Mejor revisar veinte líneas de más que dejarse una.

Revisa también los archivos de configuración y las variables de entorno. Muchas veces el modelo no está en el código: está en un .env o en una hoja de cálculo que el script lee al arrancar.

Plugins y SaaS de terceros. Plugins de WordPress para chatbots, herramientas de atención al cliente, CRMs con "IA integrada" a los que pegaste tu clave. El modelo lo elige el proveedor o lo elegiste tú en un desplegable hace dos años. Si no hay forma de verlo, pregunta al soporte del proveedor qué modelo y qué endpoint usan con tu clave.

La hoja de inventario

Una hoja de cálculo sencilla. Nada más. Estas columnas:

La última columna ordena el trabajo después. Un fallo que ve un cliente pesa más que uno que ve un compañero.

Regla: si un flujo no tiene responsable, el responsable eres tú hasta que se asigne otro.

Paso 2: tabla de sustitutos por endpoint y modelo

Dos tipos de cambio muy distintos: de endpoint y de modelo.

Cambio de endpoint: de la Assistants API a la Responses API

La Assistants API funcionaba con cuatro piezas: asistente, thread, mensajes y runs. En la Responses API cada llamada es una respuesta, y el historial, si lo necesitas, se guarda con la Conversations API.

La correspondencia práctica queda así:

Nota crítica: no migres las instrucciones del asistente a un prompt reutilizable guardado en la plataforma de OpenAI. La Reusable prompts API se retira el 30 de noviembre de 2026. Si lo haces, en diciembre vuelves a estar migrando. Las instrucciones, en tu repositorio o en tu flujo.

Si tu asistente respondía a partir de archivos subidos (el típico PDF de preguntas frecuentes), comprueba que siguen accesibles desde la nueva configuración. Es el detalle que más se olvida: el chatbot sigue respondiendo, pero se inventa lo que antes leía del PDF.

Cambio de modelo: los retirados el 23 de octubre

OpenAI asigna un sustituto a cada modelo en su tabla de deprecaciones: gpt-5.6-sol para gpt-4-0613, gpt-4-1106-preview, gpt-4-turbo, gpt-4o-2024-05-13, o1, o1-pro y o3-mini, gpt-5.6-terra para gpt-3.5-turbo-0125 y o4-mini, y gpt-5.6-luna para gpt-4.1-nano. Es el primer candidato. Antes de aplicarlo, pregúntate para qué usabas ese modelo.

Muchos flujos de 2023 usaban gpt-3.5-turbo para tareas que no necesitan un modelo de lenguaje: normalizar provincias, detectar si un correo es una factura, asignar una categoría de una lista cerrada. La migración es buen momento para quitar el modelo de en medio. En el artículo sobre determinismo antes que LLM explico cuándo una función o un catálogo hacen ese trabajo mejor y más barato.

Si el flujo sí necesita IA, elige el modelo según la tarea que resuelve. La costumbre no es un criterio. La guía de modelos por tarea separa OCR, extracción, clasificación y razonamiento. Un flujo que usaba o1 para extraer cuatro campos de un albarán probablemente pagaba un razonamiento que no usaba.

Transcripción: de whisper-1 a gpt-transcribe o gpt-live-transcribe

El 26 de febrero de 2027 se retiran whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe y gpt-4o-transcribe-diarize. OpenAI da dos sustitutos: gpt-live-transcribe y gpt-transcribe.

Si tu flujo transcribe grabaciones ya terminadas (el acta de la reunión del lunes, las llamadas grabadas de la centralita), empieza probando con gpt-transcribe. Si transcribe en directo, el candidato natural es gpt-live-transcribe. Confírmalo en la ficha de cada modelo antes de decidir.

Si usabas gpt-4o-transcribe-diarize, es porque necesitabas saber quién habla en cada momento. Comprueba que el sustituto separa hablantes. Un acta sin nombres vale bastante menos.

Imágenes: GPT Image en dos tandas

gpt-image-1 cae el 23 de octubre. gpt-image-1-mini, gpt-image-1.5 y chatgpt-image-latest, el 1 de diciembre de 2026, con gpt-image-2.5-sunburst o gpt-image-2.5-flare como sustitutos. Aquí la prueba es visual: las mismas diez imágenes con el modelo antiguo y con el nuevo, una al lado de la otra.

Evals, Agent Builder y prompts reutilizables

Estas tres piezas se retiran el 30 de noviembre de 2026. Si alguien de tu equipo montó un agente en Agent Builder o tiene baterías de evaluación en Evals, copia ya todo lo que puedas: instrucciones, casos de prueba, configuraciones. Un agente sencillo cabe en un flujo de n8n. Unas evaluaciones caben en una hoja con entradas, salidas esperadas y un script que las compare.

Lo que no saques antes de la fecha, lo reconstruyes de memoria.

Paso 3: en qué orden migrar la Assistants API de OpenAI y el resto, según riesgo

Falta el orden. Dos criterios: cuándo se apaga y quién nota el fallo.

Prioridad 1: lo que ya está roto. Todo lo que dependía de la Assistants API o de los alias gpt-5.2-chat-latest y gpt-5.3-chat-latest. Si en el inventario aparece algo así y parece que funciona, compruébalo. Puede que lleve fallando en silencio desde agosto.

Prioridad 2: flujos de cara al cliente con modelos del 23 de octubre. Chatbots, respuestas automáticas, generación de presupuestos o de documentos que salen hacia fuera. Si fallan, lo nota el cliente antes que tú.

Prioridad 3: fine-tunes. También caen el 23 de octubre, pero van aparte porque piden más tiempo: localizar el conjunto de entrenamiento, reentrenar y probar. Si el conjunto se perdió, reconstruirlo lleva días.

Prioridad 4: flujos internos con modelos del 23 de octubre. Clasificación de correos, resúmenes para el equipo, extracción de datos que alguien revisa después. Si fallan, lo nota un compañero. Molesta, pero no sale fuera.

Prioridad 5: Evals, Agent Builder y prompts reutilizables. Fecha: 30 de noviembre. Empieza por sacar la información, aunque la migración la hagas después.

Prioridad 6: GPT Image. Fecha: 1 de diciembre. Si usas gpt-image-1, súbelo a la prioridad 2 o 4.

Prioridad 7: transcripción. Fecha: 26 de febrero de 2027. Es la última, pero no la dejes para febrero. Las actas suelen depender de la dirección, y a la dirección le sienta fatal que falte el acta de un consejo.

Ejemplo: una distribuidora de material eléctrico de 40 empleados en Zaragoza hace el inventario y encuentra seis flujos. Un chatbot en la web sobre la Assistants API (prioridad 1, caído desde agosto sin que nadie lo supiera). Un flujo de Make que redacta respuestas a solicitudes de presupuesto con gpt-4-turbo (prioridad 2). Un fine-tune de 2023 que clasifica referencias de producto (prioridad 3). Un flujo de n8n que resume incidencias de almacén con gpt-3.5-turbo-0125 (prioridad 4). Un agente de prueba en Agent Builder que nadie usa (prioridad 5). Y las actas del comité semanal con whisper-1 (prioridad 7).

Con esa lista, el plan cabe en seis semanas entre dos personas: el chatbot y la copia de salidas de referencia en la primera, presupuestos y fine-tune en la segunda y la tercera, el resto después.

Paso 4: probar antes de cambiar en producción

Cambiar el modelo en un desplegable lleva un momento. Descubrir que el nuevo devuelve el JSON con otra estructura lleva bastante más.

El método de prueba es sencillo:

1. Reúne casos reales. Entradas de verdad del último mes, incluidas las raras: el correo en catalán, el PDF escaneado torcido, el audio con ruido de fondo. Los casos fáciles funcionan con cualquier modelo.
2. Guarda las salidas del sistema antiguo. Si el modelo antiguo aún responde (los del 23 de octubre, hasta esa fecha), ejecuta los casos y guarda el resultado. Es tu referencia. Después del apagado ya no podrás generarla.
3. Duplica el flujo. En n8n, duplica el workflow y fija los datos de entrada para repetir la misma prueba. En Make, clona el escenario. En código, una rama aparte. Nunca pruebas sobre el flujo que está en producción.
4. Compara salida contra salida. Revisa formato, longitud, tono y exactitud. Si el flujo espera un JSON con campos concretos, comprueba que salen los mismos campos con los mismos nombres. Y prueba el flujo entero: un modelo que responde "Factura." con punto final rompe un filtro que esperaba "Factura" tres pasos más abajo.
5. Mira el coste y el tiempo de respuesta. El panel de uso de OpenAI te da el consumo. Un modelo con razonamiento puede tardar más y costar más que el que tenías. En un chatbot, unos segundos de espera se notan.
6. Cambia en producción con alguien mirando. El día del cambio, alguien revisa las primeras ejecuciones reales. No un viernes por la tarde.

Perspectiva real: la mayoría de migraciones de modelo son aburridas. Cambias el nombre, pruebas, funciona. Dan guerra las que tenían un formato de salida muy ajustado o un prompt escrito para las manías del modelo antiguo. Esas se descubren en la prueba o en producción. Tú eliges.

Errores frecuentes

Error 1: Confiar en los alias "latest". Síntoma: un escenario que nadie ha tocado deja de funcionar el 10 de agosto. Nadie cambió nada. El modelo detrás del alias desapareció. Solución: en producción, versión fija de modelo siempre. El alias "latest" sirve para probar. Para un flujo del que depende tu negocio, versión fija y una fecha de revisión en el calendario.

Error 2: Fine-tunes olvidados. Síntoma: en un nodo aparece un modelo que empieza por ft: y nadie recuerda quién lo entrenó ni con qué datos. El 23 de octubre deja de responder. Solución: localiza ya el conjunto de entrenamiento. Si existe, reentrena sobre un modelo base vigente y prueba. Si no existe, valora si la tarea necesita de verdad un fine-tune o si un modelo actual con buenas instrucciones y unos cuantos ejemplos lo resuelve.

Error 3: Claves compartidas sin dueño. Síntoma: una única clave de API pegada en el chatbot, en n8n, en Make y en un script de Sheets. La creó alguien que ya no está. No puedes rotarla sin romperlo todo y no sabes qué gasta cada cosa. Solución: una clave por proyecto o por flujo, con nombre descriptivo y responsable. Así el panel de uso te dice qué flujo usa qué modelo, y el inventario se mantiene casi solo.

Error 4: Migrar a otra pieza que también se retira. Síntoma: en septiembre pasas las instrucciones del asistente a un prompt reutilizable en la plataforma de OpenAI o montas el sustituto en Agent Builder. El 30 de noviembre vuelve a fallar. Solución: antes de elegir destino, crúzalo con la página de deprecaciones. Las instrucciones y la lógica, en tu código o en tu flujo.

Cómo no volver a pasar por esto: registro de dependencias y capa intermedia

Los proveedores retiran modelos y endpoints de forma periódica. Volverá a pasar. Dos piezas te permiten enterarte a tiempo.

Un registro de dependencias de IA con responsable

La hoja del paso 1 no se tira después de migrar. Se queda como registro vivo: cada flujo nuevo que llame a un modelo entra en la hoja el día que entra en producción.

Además del registro, un responsable. Una persona con nombre y apellidos que:

• Revisa la página de deprecaciones de OpenAI (y la de cualquier otro proveedor que uséis) una vez al mes.
• Cruza las fechas nuevas con el registro.
• Abre una tarea para cada flujo afectado con su fecha límite.
• Comprueba que los avisos de los proveedores llegan a un buzón que alguien lee, y no al correo personal de quien dio de alta la cuenta.

Basta con que la tarea tenga dueño. En una empresa pequeña es un rato al mes.

Y cada flujo, con una alerta de error que llegue a alguien: un workflow de error en n8n, avisos a un buzón compartido en Make, un registro con alerta en código. Un fallo se tiene que ver el mismo día.

Una capa intermedia entre tus flujos y el proveedor

El problema de fondo es que el nombre del modelo está escrito en veinte sitios: cada nodo de n8n, cada módulo de Make, cada script. Cuando el modelo cae, hay que ir a los veinte.

La solución estructural es que tus flujos llamen a una capa intermedia que decide qué modelo usar para cada tarea, en lugar de ir directos a OpenAI. Si un modelo se retira o quieres probar otro proveedor, cambias la configuración en un solo sitio. Lo explico con detalle en el artículo sobre gateway de modelos de IA sin lock-in, incluida la migración de un flujo en producción sin cortar el servicio.

Para una pyme con tres o cuatro flujos, la capa intermedia puede ser tan simple como un único workflow de n8n al que llaman todos los demás, con el modelo definido en una variable. Para empezar, sobra.

No es complicado. Es disciplina.

Preguntas frecuentes

¿Qué pasa con la Assistants API de OpenAI después del 26 de agosto de 2026?

Deja de funcionar. OpenAI la retiró ese día, un año después de anunciarlo, y las llamadas que crean asistentes, threads o runs devuelven error. Para migrar la Assistants API de OpenAI hay que pasar a la Responses API, con la Conversations API si necesitas guardar el historial de la conversación.

¿Qué modelos de OpenAI se retiran el 23 de octubre de 2026?

Entre otros, gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-1106-preview, gpt-4-turbo, gpt-4o-2024-05-13, gpt-4.1-nano, o1, o1-pro, o3-mini, o4-mini y gpt-image-1, además de los fine-tunes de gpt-3.5-turbo, gpt-4, gpt-4.1-nano, babbage-002 y davinci-002. Cualquier flujo que los llame por su nombre dará error desde esa fecha. OpenAI propone gpt-5.6-sol, gpt-5.6-terra o gpt-5.6-luna como sustitutos, según el modelo.

¿Por qué ha dejado de funcionar mi automatización de OpenAI en n8n o Make?

Lo más probable es que use un modelo o un endpoint ya retirado. Si falló el 10 de agosto de 2026, revisa si usaba los alias gpt-5.2-chat-latest o gpt-5.3-chat-latest. Si falló el 26 de agosto, usaba la Assistants API. Abre el historial de ejecuciones, busca el primer error y mira qué modelo o qué operación aparece en el nodo que falla.

¿Cuándo se retira Whisper de la API de OpenAI y qué lo sustituye?

whisper-1 se retira el 26 de febrero de 2027, junto con gpt-4o-transcribe, gpt-4o-mini-transcribe y gpt-4o-transcribe-diarize. Los sustitutos son gpt-live-transcribe y gpt-transcribe. Si necesitabas separar hablantes, comprueba que el sustituto que elijas lo cubre antes de migrar.

¿Cómo migrar de la Assistants API a la Responses API?

Guarda las instrucciones del asistente en tu propio código o flujo, sustituye cada run por una llamada a la Responses API y usa la Conversations API para el historial. Declara las herramientas en la propia llamada. No muevas las instrucciones a un prompt reutilizable de la plataforma, porque esa API también se retira el 30 de noviembre de 2026.

¿Cómo saber qué modelos de OpenAI usan mis automatizaciones?

Empieza por el panel de uso de OpenAI, que muestra el consumo por modelo y por clave de API. Después revisa n8n, Make y Zapier, busca nombres de modelos en tu código y apunta todo en una hoja con flujo, modelo, clave y responsable.

Lo que toca hacer esta semana

El 23 de octubre queda a 17 días de la fecha de este artículo. Si no has hecho inventario, abre hoy el panel de uso de OpenAI. Enseguida sabrás si algo tuyo llama a gpt-4-turbo, a o1 o a gpt-3.5-turbo-0125. Con eso ya sabes si tienes trabajo.

Después, los cuatro pasos. Ninguno exige un equipo técnico grande. Todos exigen que alguien se siente a hacerlos.

Si prefieres revisarlo conmigo, en servicios tienes cómo trabajo este tipo de encargos: inventario de dependencias de IA, plan de migración por prioridades y una capa intermedia para que la próxima retirada de modelos se resuelva cambiando una línea de configuración.

Fuentes:

• OpenAI: página de deprecaciones de la API
• Make: aviso de deprecación de modelos GPT el 10 de agosto de 2026
• Make: ajustes de escenario y errores consecutivos