Solución · AI Operations
El modelo que compraste va a desaparecer. La pregunta es si te vas a enterar antes o después que tu cliente.
Elegir modelo no es una decisión que se toma una vez: los proveedores retiran versiones con preaviso, actualizan por debajo y mueven precios, y tu sistema sigue en producción mientras tanto. Montamos la función que convierte cambiar de modelo en una operación aburrida —con banco de pruebas propio, comparación real y vuelta atrás— en lugar de un salto de fe.
El problema
Tu proveedor de modelo es un proveedor. Lo tratas como si fuera una constante.
- El modelo que usáis se eligió una tarde, hace año y medio, porque era el que estaba bien en ese momento. Nadie ha vuelto a revisar la decisión y nadie sabe si sigue siendo la correcta.
- Llegó un correo de retirada del proveedor con una fecha. Nadie sabe cuántos sistemas vuestros dependen de esa versión concreta, así que tampoco sabe cuánto trabajo hay detrás de esa fecha.
- Alguien probó un modelo nuevo con cinco ejemplos escritos a mano, le pareció mejor y se subió. La comparación fue una impresión, no una medida.
- Una mañana la calidad cambió sin que nadie tocara nada. Se discutió si era el modelo, el prompt o el dato, se decidió por sensación y se siguió.
- El mismo modelo caro atiende la tarea que requiere criterio y la que solo clasifica un correo en tres cajones, porque decidir cuál va dónde nunca fue el trabajo de nadie.
- Si el proveedor se cae media hora, os caéis media hora. No hay segundo camino y nadie ha probado nunca si lo habría.
- Cambiar de modelo se percibe como un proyecto de seis semanas, así que no se hace —y la decisión de hace año y medio se queda congelada por miedo, no por criterio.
Coste de seguir igual
Tienes un proveedor crítico cuyo producto cambia bajo tus pies y ninguna forma de medir el efecto. Eso se paga de tres maneras. La primera es la sorpresa: llega una fecha de retirada y la migración se hace corriendo, sin banco de pruebas, con el riesgo repartido entre los clientes. La segunda es la deriva silenciosa, que es peor: el sistema no da error, simplemente empieza a responder un poco distinto —más largo, con otro formato, rechazando cosas que antes aceptaba— y como nadie mide, se descubre por una queja. Y la tercera es el coste de oportunidad: como cambiar da miedo, no cambias, y sigues pagando modelo caro para tareas baratas y aguantando un modelo peor del que ya está disponible.
La solución
Convertimos el cambio de modelo en una operación medida, reversible y aburrida
- 1Primero el inventario, que casi nadie tiene: qué sistemas tuyos llaman a qué modelo y en qué versión exacta, qué tarea hace cada llamada y qué pasaría si esa versión desapareciera mañana. Sin eso, cualquier aviso de retirada es una emergencia en vez de una tarea planificada.
- 2Construimos tu banco de casos dorados: un conjunto congelado de casos reales de tu operación —los normales, los raros y los que salieron mal— con el resultado que consideras correcto. Es el activo que hace que comparar modelos deje de ser una impresión y pase a ser una medida, y es tuyo aunque mañana nos despidas.
- 3Definimos el enrutado por tarea: qué llamadas necesitan de verdad el modelo bueno y cuáles se resuelven con uno más barato o más rápido sin que el resultado empeore. La decisión se toma con el banco de pruebas delante, no con la intuición del que más habla.
- 4Montamos el proceso de migración: candidato contra el banco, comparación lado a lado sobre tu trabajo real, despliegue gradual a una parte del tráfico, comparación de salidas en vivo y solo entonces el cambio completo. Con la vuelta atrás preparada y probada antes de empezar, no improvisada el día malo.
- 5Instalamos la detección de deriva. Los proveedores también actualizan sin cambiar el nombre de la versión, y eso no da error: cambia el formato, la longitud, la adherencia al JSON o dónde el modelo dice que no. El banco se ejecuta de forma periódica para que esa deriva la detecte una alerta y no un cliente.
- 6Y lo dejamos en calendario. Las fechas de retirada de tus proveedores entran como avisos con tiempo —no como un correo que alguien archivó—, y la decisión de modelo pasa a revisarse con una cadencia acordada, con el coste por tarea y la calidad medida delante.
Lo que cambia
Lo que dejas de perder
Anthropic se compromete a un preaviso mínimo de 60 días para retirar modelos públicos y OpenAI a un mínimo de seis meses para sus modelos en disponibilidad general. Ese preaviso solo sirve si alguien sabe qué sistemas tuyos dependen de la versión afectada: el inventario convierte una fecha en un plan.
Políticas públicas de deprecación de los proveedores (Anthropic, OpenAI), consultadas 2026-08
Cambiar de modelo deja de ser un salto de fe: el candidato se mide contra tus propios casos, con tu criterio de correcto, antes de tocar a un solo cliente.
Mecanismo
La deriva silenciosa deja de descubrirse por una queja. Cuando el proveedor actualiza por debajo, las salidas cambian sin dar error —formato, longitud, adherencia al JSON, dónde rechaza—; el banco periódico convierte eso en una alerta.
Mecanismo
El coste baja por diseño y no por recorte: cuando cada tarea va al modelo que necesita, la caída de gasto no viene de usar peor IA sino de dejar de pagar criterio donde solo hacía falta clasificar.
Mecanismo
Qué medimos: sistemas con versión de modelo inventariada, calidad del candidato contra el banco de casos dorados, desviación detectada por ejecución periódica, coste por tarea antes y después del enrutado, tiempo de vuelta atrás probado y días de margen sobre cada fecha de retirada anunciada.
Qué medimos
Ficha técnica
- Trabajo que elimina
- que la decisión de qué modelo usa tu empresa se congele por miedo y que cada retirada, actualización o cambio de precio del proveedor se resuelva corriendo, sin medir y con los clientes de por medio
- Implementación habitual
- 4–8 semanas
- Entrada
- tus sistemas de IA en producción, las versiones de modelo que llaman hoy y los casos reales de tu operación —incluidos los que salieron mal
- Salida
- un inventario vivo de qué depende de qué versión, un banco de casos dorados tuyo, enrutado por tarea, un procedimiento de migración con vuelta atrás probada y alertas de deriva y de fechas de retirada
- Compatible con
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralLangSmithLangfuseBraintrust
- Puede conectarse con
- Tus registros de producción, de donde salen los casos del bancoTu capa de evaluación y tu gestión de prompts, si ya existenTu pasarela o enrutado de modelos, para que cambiar sea configuraciónTu panel de costes por modelo y por tareaTu proceso de cambios y tu calendario de guardia
- Qué medimos
- % de sistemas con versión de modelo inventariada y dueño asignadocalidad del candidato contra el banco de casos doradosdesviaciones de comportamiento detectadas por ejecución periódicacoste por tarea antes y después del enrutadotiempo de vuelta atrás probado en simulacrodías de margen sobre cada fecha de retirada anunciada
- Adecuado para
- empresas con IA ya en producción y dependencia real de uno o varios proveedores de modelo —CIO, CTO o responsable de IA— que necesitan que la decisión de modelo sea revisable, medible y reversible en vez de un compromiso a ciegas
- No adecuado para
- quien todavía está en piloto y aún no tiene tráfico real —ahí no hay banco que construir, hay que llegar primero a producción—, ni quien busca que le digamos cuál es el mejor modelo del mercado: eso depende de tu trabajo, y precisamente por eso se mide en vez de opinarse
Preguntas frecuentes
Y lo seguimos diciendo: cambiar de modelo porque algo no rinde es casi siempre mover el problema de sitio, porque el cuello de botella suele ser el proceso mal definido o el dato sucio. Esto es lo contrario de aquello. Aquí no se cambia de modelo para arreglar nada: se cambia porque el proveedor retira la versión que usas, porque la actualiza por debajo, porque sale una opción que hace lo mismo por una fracción del coste o porque la decisión que tomaste hace año y medio ya no es la que tomarías hoy. Son cambios que van a ocurrir quieras o no. Lo que montamos es la capacidad de absorberlos sin drama y con evidencia —y, de paso, la que te dice cuándo el modelo no es el problema, que es justo el caso en el que conviene no tocarlo.
Es un conjunto congelado de casos reales de tu operación con el resultado que tú consideras correcto: los casos normales, los raros, los ambiguos y sobre todo los que en su día salieron mal. Suele bastar con decenas o pocos cientos bien elegidos, no hacen falta miles. Es lo importante porque es lo único que convierte «este modelo parece mejor» en un número comparable: pasas el candidato por el mismo conjunto que el modelo actual y ves exactamente dónde mejora y dónde empeora, en tu trabajo y no en un examen genérico. Y es lo más valioso que te llevas del proyecto, porque no depende de ningún proveedor: sirve igual el año que viene con modelos que hoy no existen. Por eso lo construimos contigo y se queda en tu casa.
Porque miden otra cosa. Un benchmark público te dice cómo se comporta un modelo en un examen estandarizado que no se parece a tu operación: ni tus documentos, ni tu vocabulario, ni tus casos límite, ni tu definición de correcto. Es información útil para descartar candidatos manifiestamente peores y para saber por dónde va el mercado, y para eso los usamos. Pero la decisión no la puede tomar un ranking: un modelo puede puntuar mejor en abierto y rendir peor en una tarea concreta con documentos concretos, y al revés. El proveedor, además, tiene un interés evidente en la comparación. Tu banco de casos no lo tiene.
Ejecutando el banco de forma periódica contra el mismo endpoint y comparando con la línea base. Ese es el único método fiable, porque una actualización silenciosa no produce un error: produce una deriva. El formato de las llamadas a herramientas cambia un poco, la adherencia al JSON afloja, las respuestas se alargan o se acortan, y la frontera de lo que el modelo rechaza se mueve. Nada de eso rompe la integración, así que la monitorización clásica —disponibilidad, latencia, tasa de error— lo da todo por verde mientras la calidad se desliza. Con la ejecución periódica del banco, esa deriva sale como una alerta con casos concretos delante, y entonces la conversación es «esto cambió el martes y son estos casos» en lugar de «me parece que últimamente responde raro».
Menos que cualquier alternativa, y es fácil de comprobar: los entregables son tuyos y no dependen de nosotros. El inventario de versiones, el banco de casos dorados, las reglas de enrutado, el procedimiento de migración y el calendario de retiradas quedan documentados y en tus sistemas. Lo montamos sobre tu stack y sobre las herramientas de evaluación que ya tengas; si no tienes ninguna, elegimos con vosotros y os explicamos el porqué, sin capa propietaria de la que después haya que salir. La forma normal de terminar es que tu equipo lo opere —eso es formar al equipo, que es un servicio distinto— o que lo operemos nosotros mientras esa capacidad madura. Las dos salidas están escritas desde el principio.
¿Lo montamos en tu negocio?
Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.