“Somos agnósticos de modelo” suele significar que hay una interfaz común delante de dos APIs. La prueba real llega cuando se intenta cambiar: las herramientas tienen otro esquema, el formato estructurado se comporta distinto, la seguridad necesita nuevas reglas y las evaluaciones caen diez puntos.
La forma práctica de reducir el bloqueo consiste en aislar aquello que cambia y conservar fuera del proveedor lo que define el producto. Cada diferencia entre modelos debe quedar visible y medirse.
Lo que realmente queda atrapado
El identificador del modelo es la dependencia más visible y, a menudo, la menos costosa. El acoplamiento aparece en otros lugares: roles de mensaje, caché, formato de herramientas, archivos, razonamiento, respuestas estructuradas, eventos de streaming, moderación, límites, reintentos y semántica de errores.
También hay dependencias más profundas. Un prompt se ajusta al comportamiento de un modelo. Una evaluación acepta su estilo. Los usuarios aprenden sus tiempos. La contabilidad asume una estructura de precios. Cambiar la API sin revisar esas piezas puede dejar el sistema funcionando y el producto empeorando.
Separar el producto del proveedor
La lógica de negocio debería hablar en términos propios: “buscar expedientes permitidos”, “proponer una devolución” o “solicitar aprobación”. Cada adaptador traduce esos contratos al formato concreto del proveedor. La autorización y la ejecución permanecen fuera del modelo.
Protocolos abiertos como MCP estandarizan la exposición de recursos, prompts y herramientas (Model Context Protocol). Ayudan a reducir integraciones repetidas, aunque no eliminan diferencias de planificación, permisos ni calidad de uso de herramientas.
Un núcleo común con capacidades visibles
Una abstracción demasiado fina puede ocultar justo aquello por lo que se elige un modelo: contexto muy largo, audio en tiempo real, ejecución de código, razonamiento configurable o caché específica.
Núcleo común
Mensajes, identidad, herramientas de negocio, resultados estructurados, errores y telemetría comparables.
Capacidades opcionales
Streaming avanzado, razonamiento, multimodalidad o caché se declaran y se activan solo donde existen.
Ruta específica
Una función diferencial puede usar integración nativa sin contaminar el resto de la aplicación.
Degradación explícita
Si falta una capacidad, el sistema cambia de flujo, solicita ayuda o rechaza la tarea; no simula compatibilidad.
El objetivo consiste en poder sustituir el modelo donde resulte razonable y saber qué funcionalidad se pierde o se gana. En muchos flujos, mantener una integración específica seguirá siendo la mejor decisión.
Los seis contratos que conviene poseer
| Contrato | Debe definir la aplicación | Puede adaptar el proveedor |
|---|---|---|
| Entrada | objetivo, contexto permitido, prioridad | roles, bloques y límites de API |
| Herramientas | nombre de negocio, esquema, permisos, idempotencia | sintaxis de llamada y eventos |
| Salida | campos, evidencia, estado y errores | formato nativo o modo estructurado |
| Estado | sesión, memoria, expiración y propietario | identificadores remotos temporales |
| Política | acciones permitidas y aprobaciones | filtros complementarios del proveedor |
| Telemetría | tarea, modelo lógico, coste y resultado | tokens, caché y códigos específicos |
OpenTelemetry ya diferencia atributos como proveedor y nombre de modelo en sus convenciones de IA generativa (OpenTelemetry). Mantener esa distinción permite comparar sin perder detalle.
Los prompts también son código dependiente
Una instrucción que funciona con un modelo puede ser redundante, ineficaz o contraproducente con otro. Conviene separar contenido estable —políticas, definición de la tarea, tono— de ajustes concretos del modelo. Ambos se versionan, pero no se mezclan en una única cadena imposible de atribuir.
Los ejemplos y esquemas merecen el mismo tratamiento. Si una salida estructurada falla al migrar, la solución no debería ser parsear texto libre con expresiones cada vez más frágiles. El adaptador debe validar el contrato y devolver un error reconocible a la orquestación.
Las evaluaciones son el mecanismo de portabilidad
Una interfaz que compila con dos proveedores solo demuestra compatibilidad técnica. La migración necesita un conjunto de tareas representativas que mida calidad final, uso de herramientas, seguridad, latencia, coste por resultado y comportamiento en los casos límite.
Las plataformas y productos cambian incluso dentro del mismo proveedor. En junio de 2026, OpenAI anunció la retirada futura de componentes de AgentKit y recomendó rutas de continuidad distintas según el caso (OpenAI). Es un recordatorio útil: un producto administrado puede acelerar la salida, pero su ciclo de vida forma parte del riesgo.
Ejemplo: cambiar el modelo de un revisor contractual
El equipo ejecuta el candidato en sombra sobre contratos reales anonimizados. Ambos modelos reciben el mismo paquete de cláusulas y llaman a las mismas herramientas. Un conjunto de verificadores compara cláusulas detectadas, citas, falsos positivos, tiempo y coste de revisión humana.
Durante dos semanas, el nuevo modelo procesa el 10% sin mostrar su salida al usuario. Después atiende casos de bajo riesgo con revisión obligatoria. Solo aumenta tráfico cuando supera la barra acordada. Los contratos sensibles conservan la ruta anterior hasta que exista evidencia suficiente.
La migración no requiere un corte total ni confiar en una media global.
Un simulacro vale más que otra capa de abstracción
Una vez por trimestre, elegir un flujo y cambiarlo temporalmente de modelo revela dependencias ocultas: un campo no documentado, un límite de archivo, un prompt incrustado o un panel que no reconoce al nuevo proveedor.
- Inventariar. Modelos, endpoints, almacenamiento, herramientas y funciones específicas utilizadas.
- Ejecutar en sombra. Enviar una muestra sin afectar al usuario ni duplicar acciones.
- Comparar. Calidad, coste total, latencia, seguridad y revisión necesaria.
- Desplegar por segmentos. Empezar por tareas reversibles y usuarios controlados.
- Conservar reversión. Mantener el modelo anterior hasta completar el periodo de estabilidad.
- Documentar diferencias. Registrar qué capacidades son portables y cuáles permanecen nativas.
Preguntas frecuentes
¿Hace falta contratar dos proveedores desde el primer día?
No. La duplicidad tiene coste. Es más importante poseer los contratos, evaluaciones y datos necesarios para incorporar una alternativa cuando haya una razón real.
¿Un gateway de modelos resuelve el bloqueo?
Resuelve parte de la conexión, credenciales y observabilidad. No normaliza por sí solo calidad, prompts, herramientas, políticas o almacenamiento.
¿Debemos evitar funciones exclusivas de un proveedor?
No. Pueden crear una ventaja clara. Conviene aislarlas y aceptar explícitamente su coste de sustitución.
¿Qué datos no deberían quedar encerrados?
Historial de tareas, feedback, evaluaciones, documentos procesados, trazas de negocio y decisiones. Su exportación y conservación deben estar definidas por contrato.
¿Cuándo merece la pena cambiar?
Cuando la mejora esperada en calidad, coste, disponibilidad, privacidad o capacidad supera el coste y riesgo de migración demostrado por las evaluaciones.
La portabilidad se demuestra cambiando
Una arquitectura preparada localiza las diferencias entre modelos y evita que se propaguen por todo el producto.
La portabilidad solo queda demostrada cuando se ejecuta una ruta alternativa. Un simulacro pequeño permite descubrir dependencias ocultas y calcular el coste real del cambio.
Fuentes consultadas
- Model Context Protocol: server overview
- Gen AI semantic conventions — OpenTelemetry
- Introducing AgentKit — OpenAI, actualización de 2026
- Building effective agents — Anthropic
- A practical guide to building agents — OpenAI
Fuentes y vigencia técnica revisadas el 7 de septiembre de 2026.