Cambiar de modelo de IA: al 70% le toma semanas o más

Cambiar de modelo de IA en producción no es cambiar una línea de código

El 70% de las empresas que reemplazó el modelo de IA de un sistema en producción en los últimos 12 meses necesitó semanas o más de trabajo de ingeniería, y el 36% tardó más de un mes. Lo revela la encuesta VB Pulse de octubre de 2026 de VentureBeat Intelligence, realizada entre profesionales que trabajan con IA en compañías de más de 100 empleados.

Para un founder, el dato desarma una premisa muy repetida: que un gateway o un router permite cambiar de modelo cambiando una sola línea de código. Eso es cierto en el prototipo y falso en el producto que ya usan tus clientes o tu equipo. Y como aparece un modelo mejor cada pocos meses, ese trabajo de semanas se repite una y otra vez.

Qué dicen los números de la encuesta de VentureBeat Intelligence

El 47% de los encuestados dijo que su empresa sí reemplazó el modelo en un sistema de IA en producción durante los últimos 12 meses, manteniendo la aplicación que lo rodea.
De ese grupo, el 70% reportó semanas o más de ingeniería adicional más allá del cambio de modelo, y el 36% más de un mes.
Solo el 13% dijo que el cambio fue casi una modificación de configuración.
Los resultados fueron mixtos: el 55% afirmó que el modelo nuevo rindió igual o mejor que el anterior. El 45% restante se dividió entre quienes vieron caer el rendimiento y tuvieron que rehacer la aplicación, y quienes volvieron al modelo original.

La comparación con el relevamiento de septiembre es direccional: entonces el 49% reportaba semanas o más y el 12% más de un mes. VentureBeat aclara que la mezcla de encuestados cambió entre ambos meses, así que conviene leer la tendencia como señal, no como certeza.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Por qué un modelo mejor puede empeorar tu aplicación

El problema no suele estar en el modelo, sino en todo lo que construiste alrededor. Ben Kus, CTO de Box, lo resume así: los ingenieros ajustan el software al modelo con el que empezaron y, cuando lo cambian, un modelo nuevo simplemente puede comportarse distinto. Kus agrega que la mayor diferencia de resultados aparece en el harness —el código que envuelve al modelo, le da instrucciones y controla qué herramientas puede llamar—, más que en la elección entre modelos de frontera, que hoy son todos muy buenos.

Un dato del benchmark FrontierHarness Eval de Runta lo ilustra: el modelo Kimi K3 resolvió el 63,3% de las tareas tanto dentro de Claude Code como en una configuración con DeepSeek Harness, pero el costo mediano por tarea resuelta fue de US$18,34 en el primer caso y US$3,28 en el segundo. El mismo resultado, más de cinco veces el costo. La advertencia de VentureBeat es concreta: prueba el modelo en el harness donde va a correr y, si los resultados decepcionan, prueba otro harness antes de descartar el modelo.

Micah Hill-Smith, cofundador de Artificial Analysis, aporta el matiz que más importa a una startup: en los modelos grandes el harness importó menos de lo esperado, pero los modelos pequeños son menos flexibles y pueden mostrar variaciones de 20, 30 o 40 puntos en pruebas de agentes de código según si fueron entrenados con el estilo de ese harness.

El costo por token es la métrica equivocada

Sudhanshu Bist, vicepresidente de ingeniería de plataforma en Upwork, puso un ejemplo en el summit de VentureBeat: un modelo chico que cuesta 10 centavos por ejecución y acierta el 20% de las veces necesita cinco intentos en promedio, así que sale unos 50 centavos por resultado bueno. Un modelo más grande que cuesta 30 centavos por ejecución y acierta el 90% sale unos 33 centavos por resultado bueno. El modelo grande cuesta tres veces más por corrida y aun así es más barato por resultado.

Esa lógica empieza a permear en la industria. Un análisis interno de HPE difundido por Crypto Briefing encontró que enrutar el trabajo entre modelos de frontera y su nube privada recortó los costos de tokens entre 30% y 50%, con más de 150 aplicaciones internas sobre la plataforma. Y un análisis de la GSMA recogido por Bizwatch Nigeria menciona ahorros de hasta 90% reportados por AT&T con su gateway interno de IA, y de 20% a 30% en la plataforma MoMA de China Mobile mediante enrutamiento inteligente.

El enrutamiento ya no es solo cosa de modelos de lenguaje. Runway lanzó en julio de 2026 su Media Router, un router para modelos generativos de imagen, video y audio, según reportó WWWhat’s New, con clientes como Adobe, Cloudflare, Expedia y Shutterstock. La capa de orquestación se está volviendo un negocio en sí mismo.

Qué hacen PayPal, Uber, Box y T-Mobile antes de cambiar de modelo

PayPal mantiene el conocimiento de negocio fuera del modelo. Su asistente interno de ciencia de datos usa una capa de conocimiento con definiciones, consultas aprobadas y playbooks. Según la compañía, esa capa llevó la precisión de 43% a 95% sin cambiar el modelo. Ren Zhang, VP y head global de producto de IA de PayPal, lo dice sin vueltas: es agnóstico al modelo porque lo hizo así a propósito.
Uber mide antes de mover. Tiene un benchmark de revisión de código que le permite probar cualquier modelo contra cambios de código de años anteriores. Con eso eligió el modelo de su tarea de limpieza de código y recortó el costo por limpieza un 90%, según Uday Kiran Medisetty, ingeniero distinguido de Uber. Para un agente gestionado, dice, el cambio puede tomar un par de días.
Box juzga cada cambio con tres números: precisión, costo y velocidad, medidos sobre un set de evaluación construido con lo que los clientes realmente le piden a sus agentes.
T-Mobile prueba en llamadas reales. Corre la versión vieja y la nueva en paralelo sobre tráfico de clientes y solo escala la nueva si funciona mejor. Además usa un modelo chico que monitorea cada sesión y marca respuestas sospechosas.
JPMorgan Chase hace pasar cada nuevo modelo de Claude por su propio proceso de aprobación antes de que los empleados puedan usarlo, según Anthropic. La gobernanza también suma semanas al calendario.

Qué significa esto para tu startup

La conclusión no es dejar de cambiar de modelo. Es que el cambio se prepara antes, no durante. William Allen, head de producto de los agentes de IA de Snowflake, apunta al obstáculo cultural: la falacia del costo hundido, ese impulso de no rehacer algo en lo que ya invertiste mucho tiempo.

Cuatro acciones concretas que puedes empezar esta semana:

Construye tu set de evaluación con tráfico real. Guarda preguntas y respuestas reales de tus usuarios con su verificación de precisión. Es el paso que más tarda y el que habilita todo lo demás. Sin él, cada cambio de modelo es una apuesta.
Mide costo por resultado bueno, no por token. Cuenta los intentos fallidos y el tiempo humano que corrige la salida. Un modelo barato que falla seguido puede costar más que el caro.
Separa el conocimiento de negocio del modelo. Definiciones, reglas y consultas aprobadas en una capa que tú controlas. Si viven dentro del prompt de un modelo específico, las vas a reescribir en cada migración.
Prueba en el harness real y compara en producción. Corre el modelo nuevo donde va a vivir, idealmente también en un segundo harness, y después compara versiones sobre tráfico real con monitoreo continuo. Los tests no cubren todo lo que un usuario pregunta.

El costo de cambiar de modelo no es la factura de tokens: es el tiempo de ingeniería que no ves en el dashboard. Presupuestarlo desde el diseño es lo que separa a las empresas que se adaptan en días de las que tardan meses.