Cómo cambiar de modelo de IA sin perder lo construido

El día que el proveedor cambia el modelo y el equipo se entera por los reclamos

Un lunes cualquiera, el proveedor manda un correo con fecha de corte: el modelo que usa tu automatización de soporte, tu clasificador de leads o tu asistente interno deja de estar disponible en tres meses. Nadie en el equipo lo pidió, nadie lo vio venir, y de golpe hay una fecha límite encima de un sistema que llevaba meses funcionando solo, sin que nadie le pusiera atención porque “funcionaba”. La reacción típica, bajo presión de tiempo, es abrir el archivo del prompt, cambiar el nombre del modelo en la llamada y probar a ver qué pasa.

El resultado casi nunca es bueno. Las respuestas salen con otro formato, el resumen que antes venía en tres puntos ahora viene en un párrafo corrido, el tono cambia de directo a más genérico, y algunos casos límite que antes se resolvían bien ahora fallan sin que nadie sepa explicar exactamente por qué. El equipo de soporte empieza a recibir quejas de que “el bot ya no entiende”, y nadie tiene forma de comparar objetivamente el comportamiento de antes contra el de ahora, porque nunca se guardó un registro de cómo respondía el sistema en su versión buena.

Ahí aparece el verdadero problema, y no es el modelo nuevo. Es que nadie diseñó el sistema pensando en que algún día habría que cambiarlo. El prompt tenía lógica de negocio metida a mano, los datos se formateaban pensando en las rarezas de ese modelo específico, y no existía ninguna forma de decir con datos si el modelo nuevo responde mejor, igual o peor. La migración se vuelve una apuesta a ciegas, con el negocio deteniendo el aliento a ver si el sistema sigue funcionando o si hay que apagarlo mientras alguien lo arregla a mano, caso por caso.

La dependencia que nadie construyó a propósito

Esto casi nunca es un error de diseño consciente. Un equipo prueba un modelo, funciona razonablemente bien, y en las semanas siguientes va ajustando el prompt a punta de prueba y error hasta que las respuestas quedan como se necesitan para el caso de uso. Ese ajuste fino, hecho a mano y casi nunca documentado, termina calzando con las particularidades exactas de un modelo en particular: cómo interpreta una instrucción ambigua, cómo formatea una lista quien no le pediste formato, qué tan literal es con un ejemplo que le diste de referencia.

Nadie decidió un día “vamos a depender de este modelo para siempre”, pero seis meses después esa es la situación real, y el negocio no tiene ni idea de cuánto le costaría salir de ahí. La dependencia se construyó por acumulación de parches, no por decisión, y las decisiones que nadie toma a propósito son las más caras de deshacer, porque no hay documento ni reunión que explique por qué las cosas quedaron así.

La prueba de que existe esa dependencia no es teórica: aparece exactamente el día que hay que migrar. Si cambiar de modelo implica reescribir el prompt desde cero, adivinar de nuevo el formato de los datos y cruzar los dedos con los casos límite, el sistema nunca fue un sistema. Fue una solución hecha a la medida de un proveedor, y eso es justo lo que se conoce como vendor lock-in en proveedores de IA: quedar atado a una decisión técnica que en su momento nadie tomó como decisión, sino como comodidad del momento.

Qué hay que tener desacoplado desde el inicio: prompt, datos y circuito de revisión

Esto no se arregla el día de la migración, se decide antes de escribir la primera línea del sistema. Hay tres piezas que tienen que poder cambiar de modelo sin arrastrar a las otras dos, y en la práctica son las tres que casi siempre aparecen mezcladas cuando reviso un sistema con problemas para migrar:

• El prompt como pieza versionada, no como texto pegado en el código. Vive aparte, con historial de cambios y una razón documentada detrás de cada ajuste, para que cambiar de modelo sea editar un archivo con criterio y no arqueología de por qué alguien escribió esa línea hace ocho meses.
• Los datos con un formato propio, no el que le acomoda a un modelo en particular. La forma en que se estructura la información de entrada y de salida depende de lo que el negocio necesita leer, guardar y auditar, no de la manía de formato de un proveedor específico que hoy existe y mañana puede cambiar de comportamiento sin avisar.
• El circuito de revisión como capa aparte del modelo. Quién aprueba una respuesta, qué pasa cuando el sistema no está seguro, y cómo se corrige un error tiene que funcionar igual sin importar qué modelo esté detrás. Si ese circuito asume el comportamiento particular de un modelo puntual, se rompe apenas cambias de proveedor, justo cuando más falta hace que funcione.

Cuando estas tres piezas están separadas, implementar un LLM en una empresa deja de ser una apuesta a un solo proveedor y pasa a ser una arquitectura que sobrevive al proveedor que la originó. Es más trabajo al inicio, y es exactamente el trabajo que se paga después con intereses si se salta.

El set de evaluación: la red de seguridad que dice si el modelo nuevo sirve

Un set de evaluación es, en su forma más simple, una colección de casos reales (los más representativos y también los más difíciles que el sistema haya enfrentado) con un criterio claro de qué cuenta como respuesta aceptable en cada uno. No hace falta que sea sofisticado: hace falta que exista, que esté guardado en algún lugar fuera del modelo, y que alguien lo revise cada vez que algo cambia.

Sin ese set, migrar de modelo se convierte en una discusión de impresiones: “a mí me parece que responde mejor”, “se siente más lento”, “el tono me gusta menos”. Ninguna de esas frases es falsa, pero ninguna sirve para decidir con la cabeza fría si el modelo nuevo puede reemplazar al anterior sin que el negocio pierda calidad en el proceso. Evaluar un modelo de lenguaje en tu empresa antes de decidir si migrar es exactamente este ejercicio: correr el candidato contra los mismos casos y comparar con números, no con sensaciones.

La parte que casi nadie hace, y que marca la diferencia real, es mantener el set de evaluación vivo. Cada vez que un caso nuevo rompe el sistema en producción, ese caso entra al set. Así, con el tiempo, el set de evaluación deja de ser una lista inicial y se convierte en la memoria acumulada de todo lo que el sistema ya aprendió a manejar bien, algo que ningún modelo guarda por sí solo.

La migración en paralelo: correr los dos modelos antes de apagar el anterior

La forma más segura de migrar no es apagar el modelo viejo y encender el nuevo de un solo golpe, por más presión de fecha que exista. Es correr ambos en paralelo durante un tiempo: el modelo actual sigue atendiendo el tráfico real, y el modelo candidato recibe las mismas entradas por detrás, sin que el resultado le llegue todavía al usuario final. Sus respuestas se comparan contra el set de evaluación y contra lo que respondió el modelo anterior en los mismos casos.

Solo cuando el candidato queda parejo o mejor en ese comparativo, empieza a recibir una porción pequeña del tráfico real, con posibilidad de revertir de inmediato si algo sale mal. De ahí se sube el porcentaje por etapas, nunca de cero a cien. Esto no es exclusivo de una empresa con equipo grande de ingeniería: es una disciplina que también aplica cuando una empresa decide usar varios modelos de IA en lugar de estandarizar en uno solo, porque la lógica de comparar antes de reemplazar es la misma.

El plan de reversión (volver al modelo anterior sin drama si el nuevo falla en producción) es parte del diseño, no un parche de emergencia. Si no existe esa opción documentada y probada, la migración en paralelo pierde buena parte de su sentido: seguirías sin poder recular con confianza, y volverías al mismo salto a ciegas que se quería evitar desde el principio.

Lo que siempre se rompe al cambiar de modelo: formato, tono y casos límite

Por más desacoplado que esté el sistema, hay tres cosas que casi nunca sobreviven intactas a un cambio de modelo, y conviene esperarlas en vez de sorprenderse cuando aparecen:

• El formato de salida. Un modelo que antes devolvía listas cortas y consistentes puede empezar a devolver párrafos, o viceversa. Si algún proceso automático depende de esa forma exacta (un sistema que lee la respuesta para actuar sobre ella), el cambio de formato rompe cosas que ni siquiera tocan al usuario final.
• El tono. El registro que un equipo afinó durante meses (directo, cercano, sin relleno) no se transporta solo. Cada modelo tiene un tono por defecto distinto, y hay que volver a pedirle explícitamente el que la marca necesita, no asumir que lo va a adivinar solo.
• Los casos límite. Las excepciones raras, las preguntas ambiguas, los pedidos fuera de guion son justo donde los modelos difieren más entre sí. Es exactamente ahí donde sirve un set de evaluación que incluya esos casos y no solo los ejemplos fáciles del día a día.

Ninguno de estos tres puntos es un defecto del modelo nuevo. Es la consecuencia lógica de que cada modelo se entrenó distinto y responde distinto, y de que ninguna migración sale gratis por más cuidadoso que sea el proveedor con la compatibilidad hacia atrás. La pregunta correcta no es si algo se va a romper, es si hay forma de detectarlo antes de que lo note un cliente.

Cuánto tarda de verdad cambiar de modelo

Con la base desacoplada y un set de evaluación vivo, el trabajo propiamente de migración (correr el candidato, comparar resultados, ajustar el prompt donde falle, subir el tráfico por etapas) suele resolverse en un puñado de semanas. Es observación propia de lo que veo repetirse en proyectos reales, no un número de estudio: el tiempo se concentra en revisar con calma los casos donde el modelo nuevo se comporta distinto, no en la mecánica de cambiar una llamada.

El problema aparece cuando nada de esa base existe todavía. Ahí el “cambio de modelo” en realidad es un proyecto de construir el set de evaluación, separar el prompt de la lógica de negocio y definir el circuito de revisión, todo bajo la presión de una fecha de corte que ya está encima. Esa es la razón real por la que tantas migraciones se sienten eternas: no es que cambiar de modelo sea lento, es que se está pagando de una sola vez la deuda de no haber desacoplado nada desde el principio, en el peor momento posible para empezar a hacerlo con calma.

Por eso el criterio para qué LLM elegir para una empresa no debería mirar solo qué tan bien responde hoy, sino qué tan caro saldría reemplazarlo mañana. Un modelo levemente mejor pero que exige rehacer todo el sistema para aprovecharlo casi nunca justifica el cambio.

Cuándo no vale la pena cambiar de modelo

No toda mejora de modelo justifica una migración. Si el sistema actual cumple con el criterio de calidad que el negocio necesita, si el modelo nuevo ofrece una ventaja marginal que ningún cliente notaría, y si el costo de validar la migración (armar el set de evaluación, correr el paralelo, revisar casos límite) supera el beneficio esperado, la decisión sensata es quedarse donde estás y esperar una razón más contundente.

También hay una señal de alerta en sentido contrario: si un sistema lleva años sin que nadie se atreva a tocarlo por miedo a romperlo, y la razón es que el prompt tiene lógica de negocio enterrada que nadie documentó, eso no es un argumento para no migrar nunca. Es la evidencia de que el desacople se debió hacer hace tiempo, y cuanto más se posterga, más caro sale cuando ya no hay opción.

El criterio que decide la migración, no la novedad del modelo

La pregunta que de verdad importa nunca es “¿este modelo nuevo es mejor?”. Es “¿mi sistema está armado de forma que pueda comprobarlo, probarlo en paralelo y adoptarlo sin apagar el negocio en el intento?”. Un equipo que puede contestar que sí tiene un sistema. Un equipo que tiene que revisar código a mano, adivinar el formato y rezar por los casos límite tiene una dependencia disfrazada de sistema, y esa diferencia se decidió meses atrás, no el día que llegó el correo del proveedor.

Esto no es exclusivo de un chatbot de soporte: aplica igual a los agentes de IA empresariales que ejecutan tareas completas dentro de un proceso, porque ahí el costo de una migración mal hecha no es una respuesta rara, es una acción de negocio ejecutada sobre un criterio equivocado. El criterio final es sencillo de enunciar y difícil de improvisar el mismo día: desacopla antes de necesitarlo, mide con un set de evaluación real, migra en paralelo, y decide cambiar de modelo por una razón de negocio concreta, nunca por moda.