La retirada de GPT-4o del menú de ChatGPT ya es efectiva: desde el 13 de febrero de 2026 el modelo deja de estar disponible para usuarios de la app. En paralelo, la compañía se encamina a cortar en cuestión de días el acceso al snapshot chatgpt-4o-latest para desarrolladores, un movimiento que obliga a revisar integraciones y planes de continuidad.
El debate público se ha teñido de un componente emocional —especialmente visible en comunidades que atribuían al modelo un “estilo” conversacional propio—, pero para empresas y equipos de producto el asunto es, ante todo, operativo: migraciones urgentes, cambios potenciales de calidad y coste, y riesgo de interrupciones si se llega tarde.
QUÉ HA CAMBIADO Y CUÁNDO
OpenAI anunció a finales de enero la retirada de GPT-4o, GPT-4.1, GPT-4.1 mini y o4-mini de ChatGPT, aclarando que “en la API no hay cambios por ahora”. El Help Center lo confirma: esos modelos “continuarán disponibles” vía API, al menos por el momento.
La clave, sin embargo, está en la distinción entre “GPT-4o” (como modelo base accesible por API) y el snapshot chatgpt-4o-latest, una variante asociada al acceso “tipo ChatGPT” que sí figura con fecha de retirada: OpenAI documenta su eliminación de la API el 17 de febrero de 2026 y recomienda migrar a gpt-5.1-chat-latest.
WIRED, que adelantó el impacto social de la medida, sitúa el corte “para desarrolladores” el lunes posterior a la retirada en la app (en calendario, el 16 de febrero), y explica que ya en noviembre se avisó de un fin del acceso “developer” a GPT-4o-latest. La discrepancia aparente (16 vs. 17) puede deberse a husos horarios o a un apagado por fases; en cualquier caso, la ventana es de días, no de semanas.
QUÉ MODELOS AFECTA Y QUÉ “SE APAGA” REALMENTE
En ChatGPT (la app y la web), la retirada afecta al selector de modelos: GPT-4o deja de poder elegirse y OpenAI empuja a los usuarios hacia modelos más recientes (en particular, GPT-5.1 y GPT-5.2). Para clientes de empresa, hay matices: ChatGPT Business/Enterprise/Edu mantendrá acceso a GPT-4o en Custom GPTs hasta el 3 de abril de 2026, según la documentación de ayuda.
En la API, lo inminente es el fin de chatgpt-4o-latest —un identificador que muchas integraciones han usado para “parecerse” a la experiencia de ChatGPT—, no necesariamente la desaparición de todo lo que lleve la etiqueta “4o”. Aun así, el efecto práctico es similar para quien dependía de ese snapshot: hay que cambiar identificadores y, sobre todo, revalidar comportamiento.
POR QUÉ IMPORTA A PRODUCTO Y DESARROLLO
La retirada de un modelo no es solo un cambio de “nombre” en una llamada. En equipos con producto en producción, suele desencadenar tres frentes:
1. Continuidad de servicio. Si el modelo desaparece, las peticiones empiezan a fallar. Sin un “fallback” probado, el resultado puede ser una interrupción visible para usuario final.
2. Calidad y comportamiento. El salto a otro modelo puede alterar tono, estilo, capacidad para ciertas tareas (redacción, soporte, clasificación), o la forma en que interpreta instrucciones y herramientas. OpenAI, de hecho, vincula la retirada a cambios de “personalidad” y a la posibilidad de ajustar el estilo en modelos más nuevos.
3. Coste y rendimiento. Un sustituto puede tener distinta latencia, consumo de tokens o estructura de precios. Aunque OpenAI no detalla en estos avisos el impacto económico exacto, la recomendación estándar es reevaluar presupuesto y métricas con tráfico real antes de mover el 100% de usuarios.
CÓMO ENCARAR UNA MIGRACIÓN URGENTE (CHECKLIST PRÁCTICA)
Con un corte que se mide en días, lo razonable es aplicar una migración “de contención” primero y una optimización después:
1. Inventario inmediato. Localiza dónde se llama a chatgpt-4o-latest (backend, mobile, funciones serverless, herramientas internas) y qué porcentaje de tráfico pasa por ahí.
2. Sustitución mínima viable. OpenAI recomienda gpt-5.1-chat-latest como reemplazo del snapshot. Empieza por igualar parámetros (system prompt, temperature, top_p) y evita “tocar” el producto más de lo imprescindible hasta estabilizar.
3. Canary + rollback. Lanza el modelo nuevo a un porcentaje pequeño (por ejemplo, 1–5%), monitoriza errores, tiempos y satisfacción; y prepara un retorno rápido a una alternativa si aparecen regresiones.
4. Pruebas de regresión con casos reales. No basta con un set sintético. Reproduce conversaciones y entradas reales (anonimizadas) y mide: exactitud, cumplimiento de instrucciones, seguridad, longitud de respuesta y tasa de escalado a humano (si aplica).
5. Gestión de riesgo contractual. Si vendes SLAs o integras en flujos críticos (atención al cliente, moderación, compliance), documenta el cambio y actualiza evaluaciones internas: el modelo es un componente de terceros con ciclo de vida propio.
6. Comunicación interna y externa. En productos B2B, conviene avisar a clientes: “cambio de modelo”, “posibles diferencias”, “fecha” y canal de soporte. La transparencia reduce tickets y evita lecturas de “incidencia” cuando en realidad es una migración.
EL CONTEXTO: DEPRECACIONES COMO NORMA (Y EL CASO AZURE)
La pauta de OpenAI es mantener un registro de deprecaciones con fechas y reemplazos, precisamente para que los equipos planifiquen. El caso de chatgpt-4o-latest es ilustrativo: notificación en noviembre de 2025, retirada en febrero de 2026 y sustituto recomendado.
Para quienes operan en nubes “intermediadas” (por ejemplo, Azure OpenAI), el calendario puede diferir: Microsoft publica su propia tabla de retiradas y, para algunas variantes de gpt-4o, marca retirada en marzo de 2026 (para despliegues estándar), con auto-actualizaciones programadas. La implicación es sencilla: conviene leer el aviso del proveedor con el que realmente ejecutas el modelo, no solo el anuncio general.
