Nuevos modelos de IA en Make: cómo evitar que tus escenarios se rompan

En septiembre de 2026, Make avisó que dejaría de funcionar un grupo de modelos legacy de OpenAI y que retiraría los módulos de video de OpenAI por el cierre de Sora. Los escenarios que no se actualizaron a tiempo empezaron a fallar.

No fue un caso aislado. Entre enero y julio de 2026, Make publicó novedades de IA en más de 20 fechas distintas: nuevos modelos, nuevas versiones y retiros, tanto de OpenAI como de Anthropic y Google.

El ritmo responde a cómo trabajan los proveedores: lanzan modelos nuevos y dan de baja los anteriores para concentrar su infraestructura. Make acompaña esos cambios, pero no puede mantener vivo un modelo que el proveedor apagó.

El impacto suele notarse tarde. Piensa en un escenario que clasifica los correos de soporte y los asigna al equipo correcto. Si el modelo deja de responder, los tickets se acumulan sin asignar y nadie lo advierte hasta que un cliente reclama. El costo real de un retiro no es técnico, es operativo.

La conclusión es simple: cada módulo de IA tiene fecha de vencimiento. Mantenerlo actualizado es una tarea recurrente, no algo que se resuelve una vez.

<<<GPT-6 Astra, Sol y Luna: qué modelo de ChatGPT usar en tu empresa>>>

Cómo es el ciclo de retiro de un modelo en Make

Un retiro suele seguir tres etapas. Conocerlas te permite actuar en la primera y no en la última.

1. Aviso. Make publica en sus release notes la fecha de baja, los modelos o módulos afectados y, cuando existen, los reemplazos recomendados.
2. Modelo oculto. El modelo desaparece del selector: ya no puedes elegirlo en módulos nuevos ni cambiar un módulo existente para que lo use. Los escenarios que ya lo tenían configurado siguen funcionando, lo que genera una falsa sensación de normalidad.
3. Baja definitiva. Llegada la fecha, el proveedor deja de responder y el módulo devuelve error en cada ejecución.

Hay un caso más delicado: el retiro sin reemplazo directo. Ocurrió con los módulos de video de OpenAI, porque el proveedor eliminó toda la funcionalidad. En ese escenario no alcanza con cambiar de modelo: hay que rediseñar el paso con otro servicio.

Por eso, la etapa clave es la primera. El tiempo entre el aviso y la baja suele ser de semanas, no de meses: alcanza para actualizar con calma si el equipo se entera a tiempo, pero no si lo descubre cuando el escenario ya falló.

Dos formas de conectar la IA, dos tipos de mantenimiento

Make permite usar modelos de IA de dos maneras, y cada una cambia quién gestiona qué.

Con el proveedor de Make, la gestión es más simple, pero dependes del catálogo y de los tiempos que define Make. Con una conexión propia, también debes seguir los anuncios del proveedor, porque un cambio en tu cuenta (claves, límites o permisos) puede romper el escenario aunque el modelo siga vigente.

En ambos casos, el modelo se elige en cada módulo. Por eso, el mantenimiento se hace escenario por escenario.

Si combinas las dos vías, por ejemplo el proveedor de Make para pruebas y una conexión propia para producción, regístralo. Es común actualizar el escenario de prueba y olvidar el que está en producción, que es justamente el que se rompe.

<<<Cómo integrar IA a tus aplicaciones sin romper tus procesos con Make>>>

Cómo detectar y actualizar los escenarios afectados

Cuando Make anuncia un retiro, este proceso reduce el riesgo de que algo falle en producción.

1. Inventariar los módulos de IA

Lista todos los escenarios que usan módulos de IA: OpenAI, Anthropic Claude, Google Gemini, Make AI Agents y otros. Si tienes muchos escenarios, Make Grid ayuda: genera un mapa de dependencias de toda la cuenta y permite buscar dentro del contenido de los escenarios, incluidos los valores de los módulos.

2. Identificar el modelo y la conexión

Para cada módulo, registra qué modelo usa y con qué conexión (proveedor de Make o cuenta propia). Cruza esa lista con el aviso de retiro para saber qué está en riesgo.

3. Elegir el reemplazo

Parte del reemplazo que recomienda Make en el aviso. Si no lo hay, evalúa alternativas según la tarea del módulo (en la siguiente sección).

4. Probar con datos reales

Duplica el escenario o prueba el módulo con ejecuciones manuales sobre casos reales. Compara la salida del modelo nuevo con la del anterior: formato, extensión y precisión. Un cambio de modelo puede alterar la estructura de la respuesta y romper los módulos siguientes, aunque el módulo de IA no dé error.

Por ejemplo, si el modelo anterior devolvía solo la categoría ("Ventas") y el nuevo agrega una explicación ("La categoría es Ventas porque..."), el filtro que enruta el registro dejará de coincidir. Ajusta las instrucciones del prompt para pedir un formato exacto y valida el resultado en al menos diez o veinte casos representativos.

5. Aplicar el cambio y monitorear

Actualiza el escenario en producción y revisa el historial de ejecuciones durante los primeros días. Si aparecen errores o resultados inesperados, vuelve a la configuración probada mientras ajustas.

Cómo elegir el modelo de reemplazo

El modelo más nuevo o más potente no siempre es el adecuado. El criterio es la tarea, no la versión.

Además de la tarea, considera tres factores:

• Volumen de ejecuciones. En escenarios que corren miles de veces al mes, la diferencia de costo entre modelos se multiplica. Con el proveedor de IA de Make, los tokens de entrada y de salida se cobran por separado, así que conviene estimar ambos.
• Formato de salida. Si los módulos siguientes esperan un JSON o campos específicos, prioriza modelos que respeten estructuras de forma consistente.
• Estabilidad. Las versiones preview o experimentales suelen cambiar o retirarse antes. Evítalas en procesos críticos.

Un criterio práctico: si una tarea funcionaba bien con un modelo liviano que se retira, empieza probando su sucesor liviano. Sube a un modelo de mayor capacidad solo si las pruebas muestran una caída de calidad que afecte el proceso.

<<<Claude Opus 5.5: qué cambia con este nuevo modelo>>>

Buenas prácticas para que no vuelva a pasar

• Documenta qué modelo usa cada escenario. Usa las notas del escenario o un registro central con el modelo, la conexión, el responsable y la fecha de la última revisión.
• No ates procesos críticos a un solo modelo. En Make AI Agent puedes configurar conexiones de respaldo, que permiten seguir operando si la conexión principal falla. En escenarios clásicos, una ruta alternativa con otro modelo cumple un rol similar.
• Agrega manejo de errores a los módulos de IA. Una ruta de error puede notificar al equipo, guardar la ejecución incompleta o reintentar, en lugar de detener el proceso sin aviso.
• Prueba antes de cambiar. Ningún reemplazo se aplica directo en producción, aunque Make lo recomiende.
• Revisa las release notes de Make con frecuencia. Asigna un responsable que las lea, por ejemplo una vez por semana, y que traslade los avisos a tu registro.
• Agenda una revisión periódica. Aunque no haya avisos, revisa cada trimestre los escenarios con IA: qué modelo usan, cuánto consumen y si existe una alternativa más eficiente.
• Mapea dependencias de forma continua. Herramientas como Make Grid permiten ver qué escenarios comparten apps y conexiones, y detectar a tiempo los que muestran errores.

Conclusión

Los modelos de IA cambian más rápido que cualquier otra pieza de una automatización. Eso no es un problema en sí: el problema es no saber qué depende de cada modelo cuando llega un retiro.

Con un inventario actualizado, un proceso de prueba y rutas de respaldo, cada aviso de Make se convierte en una tarea planificada. Mantener los módulos de IA al día es parte del mantenimiento normal de tus escenarios, como revisar conexiones o permisos.