El proveedor cambió el modelo y se rompió: cómo sobrevive tu automatización a una versión nueva

Qué se rompe de verdad cuando cambia el modelo (y qué no)

Lo primero es quitarse de encima la palabra «se rompió», porque manda a buscar en el sitio equivocado. Cuando el proveedor cambia el modelo, tu automatización no falla: cambia de opinión. La conexión sigue intacta y el fallo, si aparece, aparece tres pasos más abajo y disfrazado de otra cosa.

• La forma de la salida. El JSON trae un campo de más, el mismo campo llega como texto en vez de como número, o la respuesta viene envuelta en un bloque de código que antes no venía. El nodo que parseaba deja de parsear, y en el peor caso no revienta: devuelve vacío y sigue.
• El tono y la longitud. El borrador de correo que cabía en tres líneas ahora abre con dos frases de cortesía. Nadie lo nota en una semana. Se nota cuando alguien de comercial dice que «los correos automáticos suenan raro desde hace un mes».
• Dónde el modelo dice que no. Una versión nueva puede rechazar casos que la anterior procesaba —datos personales en un documento, lenguaje de una reclamación agresiva— y esa negativa llega como texto en prosa, no como error. Tu flujo la guarda tan contento en el campo «resumen».
• Lo que NO se rompe: la conexión. Mismo endpoint, misma clave, respuesta 200. Por eso el nodo sale en verde y por eso ninguna alerta se dispara. Es la parte más importante de todo esto.

Y el cambio llega de tres maneras distintas, que conviene distinguir porque se defienden distinto. Retirada anunciada: el proveedor comunica que una versión concreta deja de estar disponible en una fecha; hay aviso, hay tiempo y hay culpable si nadie lo leyó. Alias flotante: tu configuración apunta a algo tipo «la última» y la última ya es otra; te has suscrito al cambio sin saberlo. Actualización por debajo: el nombre de la versión no cambia pero el comportamiento sí. Esta última es la mala, porque no genera ningún evento al que engancharse.

Por qué la deriva no dispara ninguna alerta técnica

La monitorización que tienes montada —la que trae de serie n8n, Make o Zapier— responde a una pregunta: ¿terminó la ejecución? No responde a la única que importa aquí: ¿terminó bien? Y como el modelo devuelve algo plausible siempre, la respuesta a la primera pregunta es que sí, incluso cuando la salida no vale.

• El monitor mide finalización, no calidad. Cero ejecuciones fallidas es compatible con un mes entero de resúmenes malos. El panel verde es, en este caso concreto, información falsa.
• Cuando el parseo sí falla, avisa tarde y sesgado. Solo cazas la deriva que además rompe la estructura. La que mantiene la estructura y cambia el criterio —clasificar en la categoría de al lado, extraer el importe del pie en vez del total— pasa entera.
• La cola de revisión humana es tu detector barato. Si tienes un paso con humano en el bucle, un salto brusco en el volumen que llega a revisión sin que haya subido el volumen de entrada es la señal más fiable y gratuita que vas a tener.
• El detector caro es la queja del cliente. Es el que usa casi todo el mundo, y por eso el problema se descubre semanas después y con público delante.

Conviene situar esto en su sitio: el cambio de modelo es uno de los frentes del mantenimiento continuo de cualquier automatización con IA, junto con las APIs que cambian y los datos que se ensucian. Aquí abrimos solo ese frente, porque es el único de los tres en el que la avería no la provoca nadie de tu lado.

La batería de casos propios: tu red de seguridad antes de aceptar una versión nueva

La única defensa que funciona es tener una opinión escrita sobre qué es una salida correcta para ti. No un benchmark público, no la nota que saca el modelo en un examen genérico: veinte o treinta casos reales de tu operación, con el resultado que tú das por bueno. Eso es la batería, y se construye una vez.

• Sale de tu histórico, no de tu imaginación. Coge ejecuciones reales de los últimos meses: los casos normales, los raros y sobre todo los que salieron mal y alguien corrigió a mano. Esos últimos son los que más valen.
• Cada caso guarda tres cosas. La entrada exacta, la salida que consideras correcta y una línea explicando por qué es correcta. Sin la tercera, dentro de seis meses nadie sabrá si un cambio es una regresión o una mejora.
• No se compara letra por letra. El modelo casi nunca escribe lo mismo dos veces y eso está bien. Se comprueban propiedades: estructura, valores clave, decisión tomada, longitud dentro de un rango.
• Vive fuera de la plataforma. Un fichero versionado en tu repositorio o en tu unidad compartida, no un escenario dentro de la herramienta. Si mañana cambias de herramienta, la batería se viene contigo.

Un matiz que evita el error contrario: tener batería no significa que la respuesta a cada problema sea cambiar de modelo. Si tus casos salen mal con la versión nueva y con la vieja, el modelo no era el cuello de botella —esa discusión la tiene entera el argumento de por qué cambiar de modelo no arregla un proceso mal diseñado, que va del cambio que eliges tú por optimismo—. Esta guía va del caso opuesto: el cambio que te llega impuesto y contra el que solo puedes prepararte.

Aislar la llamada al modelo para poder cambiarlo sin tocar el resto del flujo

La pregunta que decide si un cambio de modelo te cuesta una tarde o dos semanas es de fontanería, no de estrategia: ¿en cuántos sitios está escrito el nombre del modelo? Si la respuesta es «en catorce nodos repartidos por seis escenarios», cada aviso de retirada es una excavación arqueológica. El trabajo de aislarlo se hace una vez y se cobra solo en el primer susto.

• Un único sitio donde vive el nombre y la versión. Una variable de entorno en n8n, un registro en una hoja de configuración, una constante en tu script. Cambiar de modelo tiene que ser editar un valor, nunca abrir flujos uno a uno.
• Un solo sub-flujo que hace la llamada. El resto de escenarios lo invocan y reciben la respuesta ya validada. En Make es un escenario con webhook interno; en n8n, un workflow con «Execute Workflow»; en un script, una función.
• El prompt fuera del nodo. Guardado y versionado aparte, no incrustado en el cuerpo de una petición HTTP. Muchas veces, adaptarse a un modelo nuevo es tocar el prompt, y quieres poder ver qué tocaste.
• Un contrato de salida explícito. El sub-flujo valida la respuesta contra un esquema antes de devolverla. Si no cumple, reintenta una vez y si vuelve a fallar manda el caso a revisión humana. Así una deriva de formato se convierte en un aviso ruidoso en vez de en un dato basura circulando por tu ERP.
• Fija la versión, no el alias. Apuntar a «la última» es cómodo hasta el día en que la última es otra y nadie se enteró. Fijar versión significa que tú decides cuándo cambias, y ese es todo el asunto.

Este aislamiento es también lo que hace posible probar cualquier cambio sin romper la automatización: con la llamada en un solo punto, probar una versión nueva es apuntar el sub-flujo a otro valor en un entorno de pruebas, no clonar medio sistema. Y con el prompt versionado aparte, documentar lo que hace tu automatización deja de ser un ejercicio de memoria.

El día del cambio: de una versión a otra sin apagar nada

Con la batería montada y la llamada aislada, migrar de versión deja de ser un salto de fe y pasa a ser una secuencia aburrida. El orden no es negociable, porque cada paso solo tiene sentido si el anterior salió bien.

• En seco. Pasas la batería contra la versión candidata sin tocar producción. Lo que se rompa aquí se arregla aquí, y casi siempre es el prompt y el esquema de salida, no la lógica del flujo.
• En sombra. Unos días llamando a las dos versiones con el mismo caso real y guardando las dos salidas, pero entregando todavía la vieja. Es donde aparecen las diferencias que ningún caso de prueba tenía previstas.
• Por tramos. Primero el tipo de caso de menor impacto, o un porcentaje del tráfico. El proceso que toca dinero o que habla directamente con un cliente va el último, nunca el primero.
• Con la vuelta atrás preparada antes de empezar. Si volver a la versión anterior es editar un valor y guardar, la migración es reversible. Si implica un despliegue y una llamada a alguien, no lo es.
• Con la fecha en el calendario. Los grandes proveedores —OpenAI, Anthropic, Google— publican políticas de retirada con preaviso y notas de versión donde anuncian los cambios. Pero el preaviso llega por correo y el correo se archiva. La fecha vale cuando está en el calendario del equipo con un recordatorio, no en una bandeja de entrada.

La parte incómoda: la versión vieja también se apaga, no se borra. Déjala configurada y desactivada durante el solape. Un cambio de modelo que sale mal a las once de la noche se arregla en dos minutos si el camino de vuelta sigue ahí, y en dos horas si hay que reconstruirlo de memoria.

No depender de un solo proveedor: qué significa a tu escala

Aquí es donde la mayoría de artículos se ponen grandilocuentes y recomiendan una arquitectura multi-proveedor con conmutación automática. Para un equipo que opera unas cuantas automatizaciones eso es sobreingeniería cara: te da un sistema más complejo de mantener a cambio de un riesgo que casi nunca se materializa así. Lo que sí paga es mucho más modesto.

• Tener un segundo modelo probado una vez. No en caliente: probado. Pasar la batería contra un candidato de otro proveedor y guardar el resultado. El día que necesites moverte, ya sabes qué se rompe y cuánto cuesta.
• Que la llamada no hable el dialecto de nadie. Si tu sub-flujo usa una capa fina de traducción o un SDK compatible entre proveedores, cambiar es configuración. Si usa parámetros exclusivos de uno, cambiar es reescribir.
• Que el prompt no dependa de una peculiaridad. Instrucciones claras y un formato de salida pedido explícitamente viajan bien entre modelos. Los trucos afinados para una versión concreta no viajan: son deuda.
• Lo que NO hace falta a tu escala. Enrutado automático por coste, dos proveedores calientes en paralelo o una capa de abstracción propia. Eso resuelve un problema de tamaño empresarial, no el tuyo.

Y una frontera honesta para cerrar. Todo lo anterior está pensado para el operador que tiene unos cuantos flujos y quiere dormir tranquilo. Cuando lo que hay debajo son decenas de sistemas, varios equipos y un inventario que nadie tiene, el problema deja de ser un flujo y pasa a ser una función de empresa: qué sistema llama a qué versión, qué tarea merece qué modelo y quién vigila las fechas de retirada. Eso es elegir y cambiar de modelo de IA en producción, y es el paso siguiente cuando quieres que te lo operen en vez de operarlo tú. Si lo que quieres es dejar la llamada al modelo aislada, la batería montada y el procedimiento de cambio escrito sobre tu stack actual, eso es infraestructura IA empresarial: la fontanería que hace que la próxima versión sea una tarde de trabajo y no una semana mala.