Retiran el modelo de IA que usa tu negocio: el calendario de apagones de 2026

El 26 de agosto de 2026 —dentro de diez días— OpenAI apaga la Assistants API. El 23 de octubre apaga gpt-3.5-turbo y gpt-4. Si tu negocio tiene un chatbot, un clasificador de correos o cualquier automatización con IA que te montaron en 2023 o 2024, hay una probabilidad muy alta de que esté cableado a uno de esos dos modelos. Y el día del apagón no va a degradarse: va a devolver un error y a dejar de funcionar.

Esto no es una especulación ni una noticia de sector. Son fechas publicadas por los propios proveedores en sus páginas de deprecaciones, con seis meses de aviso. El problema es que ese aviso llega por correo a la cuenta de desarrollador que creó la clave de API — que en la mitad de los casos es la de una agencia que ya no trabaja contigo.

Este artículo es el calendario completo, cómo averiguar en tres minutos si te afecta, y qué hacer si te afecta. Si lo que buscas es cuánto cuesta cada modelo, eso está en la guía de precios de la API de OpenAI, Claude y Gemini; aquí vamos a lo que se apaga y cuándo.

Lo que casi nadie te contó cuando compraste

Los modelos de IA no son software que compras una vez. Son un servicio con fecha de caducidad, y la caducidad la decide el proveedor.

OpenAI lo dice sin rodeos en su documentación: «el software que depende de modelos de OpenAI puede necesitar actualizaciones ocasionales para seguir funcionando». Anthropic escribe la misma frase casi palabra por palabra. Traducido al lenguaje de quien paga: el chatbot que te entregaron “terminado” tiene mantenimiento obligatorio, y nadie lo puso en el presupuesto.

Esto cambia una decisión que muchos negocios tomaron mal. Cuando pediste presupuesto para automatizar algo con IA, comparaste el precio de la implementación y el costo mensual de tokens. Lo que no comparaste —porque nadie te lo enseñó— fue cada cuánto te va a tocar pagar una migración. Y ahí los proveedores no se parecen en nada, como veremos.

---

Primero: ¿esto te afecta? La comprobación de tres minutos

Antes de leer el calendario, averigua qué modelo usas de verdad. No lo que crees que usas: lo que hay escrito en el código.

Si tienes acceso al panel de OpenAI

1. Entra a platform.openai.com con la cuenta que paga la API.
2. Ve a Usage y cambia la vista para agrupar por modelo.
3. Mira los últimos 30 días. Los nombres que aparezcan ahí son los que estás usando de verdad.

Si tienes acceso a la consola de Anthropic

1. Entra a la página de Usage de la consola de Claude.
2. Pulsa Export.
3. El CSV te da el uso desglosado por clave de API y por modelo. Anthropic documenta este procedimiento precisamente para auditar modelos deprecados.

Si no tienes acceso a nada

Esto es lo más común, y es en sí mismo el hallazgo. Si nadie en tu empresa puede entrar al panel del proveedor:

• La clave de API está a nombre de un tercero. El aviso de retirada le llega a él, no a ti.
• No puedes auditar el gasto, así que tampoco sabes si estás pagando de más.
• No puedes migrar sin él, lo que significa que la continuidad de un proceso de tu negocio depende de que esa persona conteste el teléfono.

Los tres son problemas de gobernanza, no técnicos, y se arreglan igual: la cuenta del proveedor de IA se abre a nombre de la empresa, la paga la empresa, y el proveedor externo entra como usuario invitado. Si estás en esta situación, ese es el primer trabajo — antes que cualquier migración.

---

El calendario de apagones de OpenAI

Estas son las fechas publicadas en la página oficial de deprecaciones de OpenAI, consultadas el 16 de agosto de 2026. Marco en negrita las que afectan a más negocios pequeños.

Tres lecturas de esa tabla que importan más que la tabla misma:

1. El 23 de octubre es el día grande. gpt-3.5-turbo y gpt-4-0613 son los modelos que aparecen literalmente en todos los tutoriales de 2023 y 2024. Cualquier integración copiada de un blog, un curso o la documentación de aquella época los tiene escritos a mano. Y como funcionaron sin quejarse durante tres años, nadie los ha tocado.

2. Se apagan APIs enteras, no solo modelos. La Assistants API, el Agent Builder, la plataforma de Evals y los reusable prompts desaparecen. Eso no se arregla cambiando una cadena de texto: es reescribir la integración. Quien construyó sobre Assistants tiene un trabajo de días, no de minutos.

3. Las versiones fijadas mueren aunque el modelo “siga vivo”. Fíjate en gpt-5-2025-08-07. GPT-5 no desaparece como familia, pero ese snapshot concreto sí. Si tu código fija la fecha —que es la buena práctica para tener resultados reproducibles— entonces estás en el calendario de apagones aunque uses un modelo que sientes moderno.

---

El calendario de Anthropic, que funciona distinto

Anthropic publica lo mismo en su página de deprecaciones de modelos, pero con una diferencia que cambia la planeación.

La diferencia está en el plazo de aviso, y es grande:

Sesenta días es poco. claude-opus-4-1 se anunció el 5 de junio y se apagó el 5 de agosto: dos meses exactos. Si tu negocio cierra en agosto, o tu desarrollador está de vacaciones, o simplemente nadie lee ese correo, el aviso se te pasa entero.

Esto no significa que Anthropic sea mala opción — sus modelos son excelentes y el ritmo de retirada es la contrapartida de un ritmo de publicación muy alto. Significa que el plazo de aviso es una característica del producto que hay que comparar antes de elegir, igual que el precio o la latencia. Y no aparece en ninguna comparativa de las que circulan.

---

La trampa que se lleva a más gente: dónde lo ejecutas cambia la fecha

Este es el detalle que no está contado en español en ningún sitio, y el que produce las sorpresas más caras.

Las fechas de arriba son las del proveedor original. Si consumes el mismo modelo a través de la nube de otro, las fechas son otras.

• Anthropic lo dice explícitamente: sus fechas aplican a la Claude API, a la Claude Platform en AWS y a Microsoft Foundry. Amazon Bedrock y Google Cloud Vertex AI fijan sus propios calendarios de retirada, así que el estado y la fecha del mismo modelo pueden no coincidir.
• Con OpenAI pasa lo mismo: Azure OpenAI publica su propia tabla de retirements, que no siempre va sincronizada con la de OpenAI directo.

flowchart TB
    A["El mismo modelo,<br/>tres fechas distintas"] --> B["API directa del proveedor"]
    A --> C["Azure OpenAI / Microsoft Foundry"]
    A --> D["Amazon Bedrock / Google Vertex"]
    B --> B1["Fecha de la página<br/>de deprecaciones oficial"]
    C --> C1["Calendario propio de Microsoft"]
    D --> D1["Calendario propio del<br/>operador de la nube"]
    B1 --> E["⚠️ Consulta la tabla de<br/>DONDE EJECUTAS,<br/>no la del proveedor del modelo"]
    C1 --> E
    D1 --> E

La consecuencia práctica: si tu integración va por Bedrock o por Azure, la tabla que tienes que mirar no es la que acabo de poner. Es la de tu nube. Poner la alarma con la fecha equivocada es tan malo como no ponerla.

---

Lo que también se rompe y no es un modelo

Además de los apagones, hay retiradas silenciosas que rompen código sin que muera ningún modelo.

El ejemplo vivo ahora mismo: Anthropic deprecó los parámetros temperature, top_p y top_k a partir de Claude Opus 4.7. No los ignora — devuelve un error 400 si los mandas con un valor distinto del predeterminado. Cualquier integración que ajustase la “creatividad” del modelo con temperature: 0.7, que es prácticamente todas las de 2023-2024, deja de funcionar al cambiar a un modelo moderno.

Esto es importante porque desmonta el plan ingenuo. Mucha gente piensa que migrar es cambiar "gpt-4" por "gpt-5.6-sol" y ya. A veces lo es. Pero también puede tocarte:

• Parámetros que ya no se aceptan (el caso de arriba).
• Formatos de respuesta distintos, si usabas salida estructurada.
• APIs completas reescritas (Assistants → Responses).
• Prompts que dejan de rendir igual. Un modelo nuevo no es el viejo pero mejor: es otro. Los prompts afinados a base de prueba y error contra gpt-4 pueden dar peores resultados en gpt-5.6-sol hasta que se reajustan.

Ese último punto es el que más presupuesto se come y el que nunca se cotiza.

---

El procedimiento de migración

Si tienes equipo técnico, este es el orden que funciona. Si no lo tienes, salta a la sección siguiente.

1. Inventaría antes de tocar nada

Busca en todo el código las cadenas de los modelos, no solo en el archivo obvio:

# Modelos de OpenAI cableados en el código
grep -rn "gpt-3.5-turbo\|gpt-4-0613\|gpt-4-turbo\|gpt-4o-2024" \
  --include="*.php" --include="*.js" --include="*.ts" --include="*.py" .

# Modelos de Anthropic
grep -rn "claude-3\|claude-sonnet-4-2025\|claude-opus-4-2025" .

# Y lo que casi siempre se olvida: variables de entorno y configuración
grep -rn "MODEL" .env .env.example config/ 2>/dev/null

Revisa también los sitios donde el nombre del modelo no está en el repositorio: paneles de n8n o Make, funciones serverless, cron jobs, y cualquier automatización de terceros que consuma tu clave.

2. Fija la versión, no uses el alias

Si tu código dice "gpt-4" a secas, estás usando un alias que el proveedor mueve cuando quiere. Eso parece cómodo y es exactamente lo contrario: significa que el comportamiento de tu sistema puede cambiar un martes sin que tú hayas tocado nada.

La práctica correcta es fijar el snapshot con fecha (gpt-5.6-sol en su versión fechada) y llevar tú el control de cuándo subes. Sí, eso te mete en el calendario de apagones — pero te mete de forma predecible, que es justo lo que quieres.

3. Compara en paralelo antes de cambiar

No sustituyas el modelo en producción y esperes a ver qué pasa. Toma 30 o 50 casos reales de tu histórico, pásalos por el modelo viejo y por el nuevo, y compara las salidas lado a lado. Es una tarde de trabajo y es la diferencia entre una migración y un incidente.

4. Aísla el proveedor detrás de una capa propia

Este es el trabajo que hace que el próximo apagón sea aburrido. En vez de llamar al SDK del proveedor desde veinte sitios, llámalo desde uno:

// Un único punto donde vive la decisión de qué modelo se usa.
// El resto de la aplicación pide "razonamiento" o "clasificación",
// no pide "gpt-5.6-sol".

const MODELOS = {
  razonamiento:  { proveedor: 'openai',    modelo: 'gpt-5.6-sol' },
  clasificacion: { proveedor: 'openai',    modelo: 'gpt-5.6-terra' },
  resumen:       { proveedor: 'anthropic', modelo: 'claude-sonnet-5' },
} as const;

export async function completar(tarea: keyof typeof MODELOS, prompt: string) {
  const { proveedor, modelo } = MODELOS[tarea];
  return proveedor === 'openai'
    ? llamarOpenAI(modelo, prompt)
    : llamarAnthropic(modelo, prompt);
}

Con esto, el siguiente apagón es editar una línea de un objeto y volver a correr la comparación del paso 3. Sin esa capa, es buscar y reemplazar en veinte archivos y rezar.

No hace falta un framework para esto. LangChain o LlamaIndex resuelven el mismo problema y traen mucho más equipaje del que una PyME necesita; treinta líneas propias suelen bastar y no añaden una dependencia que también se puede deprecar.

---

Si no tienes equipo técnico: qué exigir y a quién

Para el dueño o el responsable de operaciones que no va a tocar el código, el trabajo es otro, y es más importante.

Lo que hay que pedir por escrito a quien mantiene tu integración:

1. Qué modelo exacto usa cada proceso, con el nombre completo y la fecha del snapshot. «Usamos ChatGPT» no es una respuesta.
2. En qué plataforma se ejecuta — API directa, Azure, Bedrock, Vertex — porque de eso depende la fecha real.
3. La fecha de apagón de cada uno, sacada de la tabla de esa plataforma.
4. Quién recibe los correos de deprecación. Si es una cuenta que no controlas, eso se cambia esta semana.
5. Cuánto cuesta la migración y quién la paga. Esta es la pregunta incómoda y hay que hacerla ahora, no en octubre.

Y lo que conviene meter en el contrato de aquí en adelante: el mantenimiento por deprecación de modelos no es una mejora ni un capricho — es lo que mantiene el sistema encendido. O está incluido en una cuota, o está tarifado de antemano. Descubrirlo el día del apagón, con el proceso caído, es la peor posición negociadora posible.

Lo digo desde el lado incómodo de la mesa: yo vivo de construir estas integraciones. Y aun así, un cliente que no entiende que esto tiene mantenimiento es un cliente que se va a sentir estafado dentro de un año, con razón.

---

Lo que cuesta el cambio (y por qué a veces sales ganando)

Migrar no siempre es un gasto neto. Los modelos nuevos suelen ser bastante más baratos por token que los que sustituyen, y bastante más capaces, así que hay tres efectos que se compensan:

• A favor: el precio por millón de tokens del reemplazo suele ser menor. Un proceso que costaba X con gpt-4 puede costar una fracción con su sustituto.
• A favor: modelos más capaces necesitan prompts más cortos para la misma calidad, y prompt más corto es menos tokens.
• En contra: los modelos de razonamiento consumen tokens internos que también se pagan. Cambiar a uno de esos sin querer puede multiplicar la factura aunque el precio unitario baje.

La única forma honesta de saberlo es medirlo con tus datos reales antes de cambiar. Los números y el método están en la guía de precios de la API de OpenAI, Claude y Gemini, y si quieres estimar el consumo de un prompt concreto antes de mandarlo, el contador de tokens de aquí al lado lo hace sin registro.

---

La salida radical: que no te lo puedan apagar

Hay una manera de que este artículo no te aplique nunca: ejecutar el modelo tú.

Un modelo abierto corriendo en tu propio hardware no lo puede retirar nadie. Sigue funcionando exactamente igual dentro de tres años, con los mismos resultados, sin correos de deprecación y sin fecha en el calendario. Para procesos internos estables —clasificar correos, extraer datos de documentos, resumir— es una opción real y hoy corre en hardware asequible.

No es gratis: pagas en hardware, en electricidad y en que la calidad va por detrás de los modelos punteros. Escribí el análisis completo, con la máquina que uso y los números medidos, en IA sin mandar datos fuera: LLM local para despachos y PyMEs. El apartado de continuidad de ese artículo es exactamente este problema visto desde el otro lado.

La decisión sensata para casi todo el mundo no es elegir un bando, sino repartir: modelos de proveedor para lo que necesita calidad puntera, modelo propio para los procesos estables que no quieres que dependan del calendario de nadie.

---

Preguntas frecuentes

¿Qué pasa exactamente el día del apagón?

La petición falla. No hay degradación ni sustitución automática: el modelo deja de estar accesible y la API devuelve un error. Anthropic lo dice literalmente — «las peticiones a modelos retirados fallarán»—, y OpenAI que el modelo o el endpoint «dejará de estar accesible». Si tu aplicación no maneja ese error, lo que ve el usuario final es una pantalla rota.

Uso ChatGPT desde el navegador, no la API. ¿Me afecta?

Mucho menos. Las fechas de este artículo son de la API, que es lo que usan las integraciones. En la aplicación de ChatGPT los modelos también se retiran del selector, pero te sustituyen por el vigente automáticamente y como mucho notas que responde distinto. El riesgo serio es para lo que está automatizado.

¿Cómo sé si mi chatbot usa la Assistants API?

Pregúntale a quien lo montó, y si no puedes, revisa el panel de OpenAI: si en Assistants aparecen asistentes creados, se está usando. También delata el código, que llamará a endpoints con /v1/assistants o /v1/threads. Esa migración es la más urgente de la lista: se apaga el 26 de agosto de 2026.

¿Migrar es cambiar el nombre del modelo y ya?

A veces sí y a veces no. Cambia la cadena si solo usabas texto simple. Pero puede tocarte reescribir si usabas la Assistants API, si mandas parámetros ya deprecados —temperature da error 400 en los Claude modernos— o si tus prompts estaban afinados contra el modelo viejo. Presupuesta la comparación de salidas, que es la parte que de verdad lleva tiempo.

¿Cada cuánto va a volver a pasar esto?

Es permanente. OpenAI da al menos 6 meses de aviso para modelos generales; Anthropic, 60 días. Con ese ritmo, lo realista es contar con una revisión de modelos cada seis meses y una migración pequeña al año. Es mantenimiento recurrente, como actualizar el framework o renovar el certificado SSL.

¿Me protege usar un intermediario como LangChain o un SaaS de chatbots?

Parcialmente y con letra pequeña. Una capa de abstracción hace el cambio más barato, pero no evita que el modelo de abajo muera ni que haya que revalidar la calidad. Y si el intermediario es un SaaS, heredas su calendario y el riesgo de que deprecie funciones por su cuenta — que es exactamente lo que hizo OpenAI con Agent Builder, un producto suyo que retira el 30 de noviembre de 2026.

---

Conclusión: ponlo en el calendario hoy

Resumido en lo que hay que hacer esta semana:

1. Averigua qué modelo usas de verdad. Panel de OpenAI agrupado por modelo, o export del CSV de la consola de Claude. Tres minutos.
2. Comprueba en qué plataforma se ejecuta, porque de eso depende la fecha buena.
3. Pon dos alarmas: el 26 de agosto de 2026 si tocas la Assistants API, y el 23 de octubre de 2026 si aparece cualquier gpt-3.5-turbo o gpt-4 en tu inventario.
4. Verifica quién recibe los correos de deprecación. Si no es alguien de tu empresa, arréglalo antes que nada.
5. Y pregunta cuánto cuesta la migración, mientras todavía hay margen para negociarla con calma.

Los apagones de modelos no son un problema técnico exótico: son el mantenimiento normal de una tecnología que se mueve rápido. Lo que sí es un problema es descubrirlos el día que el chatbot deja de contestar.

Si tienes una integración de IA en producción y no sabes contestar la pregunta 1 de esa lista, escríbeme y la revisamos. La auditoría de qué modelos usas y cuándo mueren es corta, y es mejor hacerla en agosto que en octubre.