No dependas de un único proveedor de IA: el vendor lock-in ya no es teórico

El apagón que nadie puso en el roadmap

El 12 de junio de 2026 el Departamento de Comercio de Estados Unidos sacó una orden bajo la ley ECRA. No era un comunicado de marketing ni un incidente de capacidad. Era una orden legal: Anthropic tenía que desactivar Claude Fable 5 y Mythos 5 para todo el mundo. El motivo técnico-político era simple, no podían filtrar usuarios por nacionalidad, así que apagaron el grifo entero.

Opus, Sonnet y Haiku siguieron vivos. Fable 5 y Mythos 5, no.

Diez días después, el 22 de junio, Fable 5 seguía offline. Sin fecha de regreso. Y eso a pesar de que la política ya había girado: reuniones con Comercio el 16, el CEO de Anthropic en el G7 el 17, y Trump el 19 diciendo que ya no veía a Anthropic como amenaza. Chris Ciauri, ejecutivo de la casa, predicó el 18 que los modelos volverían "en los próximos días". No era un compromiso. La directiva legal no se rescindió. Lo político se mueve en titulares; lo legal se mueve en papeles. Y tu producto en producción no corre sobre titulares.

Este no es un cuento de "y si un día…". Es un caso real con fecha, con modelo concreto y con equipos que tuvieron que decidir en caliente si su stack sobrevivía o no. La lección no es "Anthropic es el malo". La lección es más incómoda: la continuidad la tuvo quien tenía un plan B, no quien eligió la mejor herramienta.

Quien no dependía de un solo proveedor activó alternativas y siguió facturando. Quien había cableado prompts, pipelines y lógica de negocio a un único endpoint se quedó con un 503 existencial.

Tres riesgos que el caso deja al desnudo

El apagón de Fable 5 no inventa el vendor lock-in. Lo enseña con luz de quirófano. Hay tres modos de fallo que se repiten en casi todo proyecto que "va muy bien con Claude" hasta que deja de ir.

1. Rigidez ante el cambio de modelo

Cuando tu sistema asume un modelo concreto, no asume solo un endpoint. Asume un estilo de respuesta, una ventana de contexto, unos fallos conocidos y un ritmo de latencia. Cambias el modelo, o te lo cambian a la fuerza, y de repente fallan parsers, se rompen los JSON "siempre bien formados", sube la tasa de alucinación en el paso que nunca tocaste y el agente que ayer cerraba tickets hoy inventa campos.

Eso no es magia negra. Es acoplamiento. Si el orquestador conoce el nombre del modelo, si los prompts tienen trucos específicos de esa familia, si los tests de aceptación se escribieron contra las manías de Fable 5, no tienes un sistema de IA: tienes un monumento a un snapshot de junio.

Pero hay algo peor que depender de un endpoint de API: depender de cuentas de suscripción. Equipos enteros de oficina que usan Claude.ai o ChatGPT Team con sus cuentas de usuario, sin API, sin integración técnica, con flujos de trabajo enterrados en conversaciones del navegador. Aquí el acoplamiento no es solo al modelo: es a la cuenta, al plan de suscripción, a los términos de uso del consumidor y a la interfaz. El día que el proveedor cambia las condiciones, sube el tier, depreca funciones o simplemente cae, no tienes un endpoint que redirigir ni una clave que cambiar. Tienes a veinte personas que no saben trabajar de otra forma y un proceso de negocio que vive en el historial de chat de alguien.

El apagón lo deja claro: aunque el resto de la familia Anthropic siguiera online, quien había apostado el producto a Fable 5 no podía "cambiar una variable de entorno y listo" si el resto del stack no estaba diseñado para eso. Cambiar de modelo sin arquitectura de intercambio no es un deploy. Es un proyecto.

2. Dependencia económica con patrón AWS

Ya lo vimos con la nube: primero te enganchan barato, construyes encima, y cuando el coste estructural deja de ser absorbible por el proveedor, te llega la factura. En IA el patrón se repite más rápido porque el coste de GPU e inferencia no es un Excel abstracto: es silicio que alguien paga cada mes.

En abril de 2026, OpenAI subió el precio de GPT-5.2 de 1,15 € a 5,30 € por token de entrada, y Anthropic aplicó subidas del mismo estilo, según el análisis de wildbreeze.io. Los proveedores ya no regalan el margen para comprar cuota. Lo trasladan a clientes que, de repente, descubren que no tienen alternativa operativa.

Aquí el dato que duele no es solo la subida. Es la asimetría de poder. Si el 100% de tu inferencia crítica pasa por un único contrato, la negociación es teatro. Ellos tienen tu carga de trabajo; tú tienes una migración de cientos de miles de euros y un equipo que no quiere reescribir prompts a las tres de la madrugada.

Y si encima no tienes API sino cuentas de suscripción por cabeza, la trampa es doble: el proveedor puede cambiar de precio, de plan o de funcionalidades con un aviso de treinta días en los términos de uso que nadie leyó, y tú no tienes ni un contrato de API que invocar ni una capa técnica que mover.

3. Obsolescencia del prompt engineering como activo

Hay un tercer riesgo que la gente confunde con skill y que en realidad es deuda: el culto al prompt perfecto atado a un modelo. Ese system prompt de 400 líneas, afinado durante meses, con few-shots que solo funcionan porque el modelo X "entiende el tono", no es un activo portable. Es un pasivo disfrazado de craft.

Cuando el modelo desaparece, se depreca o cambia de comportamiento en un silent update, ese trabajo se evapora. No porque el prompting sea inútil, lo es, y mucho, cuando se trata de razonar e iterar, sino porque convertir el prompt en la arquitectura es poner los cimientos sobre arena de proveedor.

Si tu ventaja competitiva está en un txt sagrado y no en datos propios, evaluación, validadores y rutas intercambiables, no tienes moat. Tienes una suscripción con fanfiction.

Los números: lo que crees que puedes hacer vs lo que pasa de verdad

Aquí es donde el discurso de "si pasa algo, cambiamos en un fin de semana" se estrella contra la encuesta y la factura.

Zapier preguntó a 542 ejecutivos. Casi el 90% creía poder cambiar de proveedor de IA en menos de 4 semanas. Solo el 42% de quienes lo intentaron reportó éxito. El 58% fracasó o necesitó mucho más esfuerzo del que había puesto en la slide de riesgos. Casi nueve de cada diez se creían ágiles; más de la mitad se pegó el batacazo.

El coste medio de migración entre plataformas de IA ronda los 290.000 € por proyecto, sin contar la pérdida de productividad por reaprendizaje. Y eso no es solo "reescribir cuatro prompts". Hay dependencia técnica (pipelines, schemas, fine-tunes, evaluadores) y dependencia comportamental: el modelo ya conoce la operativa de la empresa en el sentido práctico de que todo el flujo humano-máquina se ha moldeado a sus rarezas. Sacarlo es como cambiar el motor con el coche en marcha y el cliente mirando el cuentakilómetros.

IDC aporta el contraste de fondo: para 2027, más del 70% de los proyectos de IA empresarial involucrarán a tres o más proveedores de infraestructura, frente a menos del 40% en 2023. Ejecutivos de Dell y Nutanix lo dicen sin poesía: el modelo de proveedor único se ha acabado; la "fábrica de IA" pide la mejor combinación de chips, marcos y nubes, no una camiseta de marca. El mercado institucional ya se mueve hacia la diversificación. La pyme, muchas veces, no.

Y ojo con la trampa de la adopción silenciosa: el 68% de las pequeñas empresas emplea IA con regularidad, pero la mayoría sin políticas formales, sin formación y sin medición. Eso no es agilidad. Eso es dependencia oculta, tres APIs metidas por tres equipos distintos, sin inventario, sin owner y sin plan de salida. O peor: quince personas con cuentas de suscripción de consumidor usando la herramienta como si fuera Gmail, con flujos de trabajo críticos enterrados en conversaciones que nadie cataloga. El día que uno de esos servicios se apaga, nadie sabe ni qué proceso de negocio se cae.

El 90% cree que migra en menos de 4 semanas. El 58% de quien lo intenta fracasa o se pasa de plazo. La confianza no es un plan de continuidad.

El caso Fable 5 y los datos de Zapier/IDC no se contradicen: se completan. Uno es el cisne negro con nombre y fecha. Los otros son la foto estadística de un mercado que se cree líquido y opera viscoso. Quien solo lee el apagón dice "mala suerte regulatoria". Quien lee los tres juntos dice "el single-vendor era una apuesta, no una arquitectura".

Qué hicieron los que no se quedaron tirados

No hay heroísmo aquí. Hay aburrimiento bien ingenierizado.

Equipos que ya trataban el proveedor como un detalle de infraestructura, no como religión, hicieron tres cosas en cuanto Fable 5 cayó:

1. Activaron el plan B donde la calidad de la tarea lo permitía: algunos con modelos de pesos abiertos en infraestructura propia, otros enrutando a otros proveedores frontera (Gemini, GPT-5, modelos de Mistral o de xAI según el momento). La clave no fue qué alternativa concreta eligieron. Fue que tenían una.
2. Enrutaron por capacidad, no por marca. Las tareas que aguantaban un modelo más pequeño o de otro vendor se fueron ahí. Las que no, se degradaron con mensaje controlado en vez de tumbar el producto entero.
3. Dejaron de debatir en Slack si "Anthropic volverá el martes". Una predicción de un ejecutivo no es un SLA. El legal va más lento que el tuit. Diseñar continuidad sobre declaraciones políticas es mala ingeniería con traje.

El matiz que no vamos a vender: diversificar no significa usar todo a la vez ni que todas las opciones sean equivalentes. Hay tareas donde un modelo frontera concreto gana de calle en calidad, herramientas o latencia gestionada. Hay otras donde un modelo de pesos abiertos más pequeño, ejecutado en tu propia infraestructura, resuelve suficientemente bien y te da soberanía. La tesis no es "fúgate a local y olvídate" ni "usa cinco proveedores a la vez". La tesis es: no dejes que un único punto de fallo legal, comercial o técnico te apague el negocio.

Sobre los modelos de pesos abiertos hay que decir una cosa sin suavizarla: no son un archivo de Word que te descargas y corres en el portátil. Un modelo de frontera de pesos abiertos como Kimi K2, LLaMA 405B o DeepSeek V3 necesita infraestructura seria: múltiples GPUs de alta gama, gestión de memoria y latencia, pipelines de serving como vLLM o TGI, y alguien que sepa operarlo. El coste de infraestructura puede superar con creces el de la API comercial si el modelo es grande. Los pesos abiertos son una opción legítima de soberanía y plan B, pero solo si has hecho las cuentas de infraestructura y tienes la capacidad técnica para operarlos. Para quien no tiene eso, la diversificación entre proveedores de API frontera es el primer paso más realista.

Quien quiera el ángulo regulatorio del mismo clima político tiene el hilo de cómo las restricciones convierten el open source / open-weight en apuesta de continuidad en 90 minutos para apagar la IA. Y quien confunda "pesos descargables" con "código abierto de verdad" debería mirar qué esconden las licencias antes de montar el plan B sobre una cláusula que no ha leído.

La arquitectura que reduce la superficie de dependencia

Aquí entra el material que separa el artículo de opinión del artículo útil. No basta con decir "hay que diversificar". Hay que nombrar el mecanismo.

Router de modelos por tier, proveedor intercambiable por config

La abstracción correcta no es el modelo. Es el tier.

En un sistema multiagente real de informes y agenda para directivos, el requisito era multimodelo por calidad-coste: basura trivial a modelos baratos y rápidos; razonamiento a modelos grandes. La pieza que lo sostiene:

• Un ModelSpec con el proveedor como enum.
• Un router en Python puro que mapea cada tier a (proveedor, modelo, precios) leyendo de configuración.
• Orquestador y subagentes que solo conocen una interfaz LLMClient. Nunca los SDKs. Nunca el nombre mágico del modelo de moda.

Cambiar el modelo de un tier, o el proveedor entero, es solo config. Sin PR de pánico en quince servicios.

Menos clientes que proveedores: si varios exponen capa compatible con OpenAI, un mismo cliente con base_url + key te cubre varios. Añadir proveedor nuevo = una implementación de LLMClient + una línea de dispatch. No un rewrite.

Alrededor del router, no dentro del prompt, van los guardrails de verdad:

• generate_with_fallback: ejecuta el modelo del tier con timeout por nodo; si falla o expira, degrada al tier inferior (cadena de fallback) con tope de intentos.
• Si se agota la cadena: error tipado (AllModelsFailed), no un except genérico que se traga el fallo.
• Bloqueo por presupuesto diario por usuario (BudgetExceeded), igual de estricto en chat que en tareas programadas.

Un matiz honesto de producción: el streaming del chat suele quedarse en el tier primario; hacer fallback a mitad de stream implica re-emitir tokens y ensucia la UX. Dejarlo como mejora explícita es mejor que improvisar un Frankenstein a las dos de la noche. Si te estás peleando con la decisión de router propio en Python frente a OpenRouter, la regla es simple: cuando el routing es ventaja competitiva y el presupuesto/fallback son lógica de negocio, lo quieres en tu código; cuando es commodity, no reinventes el proxy.

Routing por dificultad, no por marca

"Usamos Claude para todo" es una frase de demos. En producción es un antipatrón de costes y de riesgo.

La pregunta correcta no es "¿qué marca es mejor en Twitter esta semana?". Es "¿qué dificultad tiene esta tarea y qué tier la resuelve con el margen de calidad que el negocio exige?". Clasificar por dificultad (extracción simple, clasificación, razonamiento multi-paso, generación larga con herramientas) te permite:

• quemar menos dinero en lo trivial,
• reservar el frontier para lo que de verdad lo necesita,
• y, el día que un frontier cae, saber exactamente qué porcentaje del tráfico se va al plan B sin adivinar.

Cada tier puede tener tanto un proveedor frontera de respaldo como, si la tarea lo justifica y tienes la infra, un modelo de pesos abiertos. La decisión es por tarea y por capacidad, no por dogma.

Eso también mata el teatro del prompt engineering ornamental: si la tarea es fácil, no necesitas un system prompt de novela. Necesitas un schema, un validador y un modelo barato.

Arquitectura determinista + LLM con validator

La forma más efectiva de reducir dependencia del proveedor no es tener tres LLMs. Es dejar de emplear el LLM donde no hace falta.

Patrón que aguanta apagones:

1. Capa determinista para lo que es reglas, permisos, cálculos, rutas, paginación, auth. Si se puede escribir con código y tests, no se delega al modelo.
2. LLM solo en el cuello de embudo ambiguo (lenguaje natural, clasificación sucia, borradores).
3. Validator a la salida: schema, reglas de negocio, checks de citas, límites. Si el modelo alucina un campo, lo pillas tú antes que el cliente.

Cuando la superficie que toca el LLM se encoge, el radio de explosión de un apagón o de una subida de precio también se encoge. El apagón de Fable 5 duele mucho más en un sistema que es "LLM all the way down" que en uno donde el modelo es un worker más detrás de una interfaz y un validador.

La misma filosofía de "decisiones explícitas, no olvidos" que en backend se traduce en tests de inventario, ninguna ruta nace abierta, toda colección pagina, ningún error escapa del sobre, aplica al stack de IA: ningún call a proveedor sin tier, sin timeout, sin fallback declarado y sin presupuesto. Si no está en config y en test, no existe. Es un olvido con factura.

La trampa (porque un caso sin pegas es publirreportaje)

Hay que soltarlas sin vaselina.

No todo el mundo puede permitirse multi-proveedor el día uno. Mantener dos rutas calientes tiene coste de evaluación, de observabilidad y de disciplina. Para un prototipo de tres semanas, acoplarte a un modelo puede ser racional. El error no es empezar simple; el error es confundir el prototipo con la arquitectura del producto y llegar a facturación real sin plan de salida.

El 90% que "podría migrar en 4 semanas" no es tonto: está desinformado sobre su propio acoplamiento. Los prompts están en el repo, sí. Pero también hay convenciones de tool-calling, formatos de memoria, evaluadores que asumen un estilo de respuesta, y gente del equipo que ya no recuerda por qué el tercer few-shot existe. El coste de 290.000 € no sale de la API key. Sale del reaprendizaje organizacional.

Para las configuraciones más precarias, las de equipos con cuentas de suscripción de consumidor, el problema es todavía más profundo: no hay código que migrar, hay hábitos que cambiar. El flujo de trabajo está en la cabeza y en el historial de chat. Migrar no es un proyecto técnico; es un cambio de comportamiento organizacional. Y eso es lo más caro de todo.

Los modelos de pesos abiertos no te salvan con un chasquido de dedos. Primero: necesitas evaluarlos en tus propios datos y tareas antes de confiar en ellos para producción; cambiar de proveedor "porque es soberano" y degradar en silencio la precisión del proceso de negocio es otro tipo de incidente, más lento y más difícil de diagnosticar. Segundo: si el modelo es grande, necesitas infraestructura seria y alguien que la opere. Sin pipeline de evaluación con datos propios y sin la capacidad técnica para servir el modelo, el plan B de pesos abiertos es fe ciega con factura de GPU.

La distensión política no garantiza el regreso del servicio. Fable 5 siguió apagado después de sonrisas en el G7 y de frases suaves en rueda de prensa. Diseñar continuidad sobre el humor del ciclo político de Washington es una forma creativa de auto-sabotaje.

Seamos justos: para una startup de tres personas con un solo producto y sin inversión, el multi-proveedor el día uno puede ser un lujo que mata el time-to-market. Si tu diferenciación no está en la infraestructura sino en la experiencia de usuario o en el acceso a un nicho, tiene sentido apostar por un solo modelo, asumiendo el riesgo de forma consciente y con un plan de migración documentado, aunque no implementado, para cuando el negocio lo justifique. El problema no es empezar con un solo proveedor; es no saber que estás apostando.

No afirmamos que la suspensión fuera permanente ni que Anthropic actuara de mala fe. Cumplieron una orden. Otros modelos suyos siguieron. El problema estructural no es la moral del proveedor; es tu concentración de riesgo.

Qué se puede copiar lunes por la mañana

Si solo vas a hacer tres cosas después de leer esto, que sean estas:

1. Inventario brutal. Lista cada feature que llama a un LLM, con proveedor, modelo, coste estimado y qué pasa si devuelve 503 durante 10 días. Incluye las cuentas de suscripción: si alguien de tu equipo tiene un flujo de trabajo crítico en Claude.ai o ChatGPT, eso también entra en el inventario. Si no puedes llenar la tabla, ya tienes el diagnóstico.
2. Tier + interfaz única. Una LLMClient, tiers en config, fallback encadenado, presupuesto diario. El nombre del proveedor no se le escapa al dominio. El tier primario puede apuntar a un frontera; el secundario, a otro frontera distinto o, si tienes la infra, a pesos abiertos.
3. Validator y código determinista primero. Reduce la superficie que el modelo toca. Cada regla que sacas del prompt y metes en código testable es menos vendor lock-in y menos teatro.

El caso Fable 5 no va de tener miedo a Anthropic. Va de no construir tu empresa como un plugin de la hoja de ruta, el departamento legal o la política de precios de nadie. El mejor modelo del mundo es una ventaja. El único modelo del mundo es un single point of failure con buena prensa.

Diez días sin Fable 5 no fueron un aviso abstracto sobre el futuro de la IA. Fueron un test de arquitectura en producción, con clientes reales al otro lado. Unos lo suspendieron. Otros ni se enteraron porque el router ya había degradado de tier y el validador seguía tirando del carro.

La diferencia no fue el hype del modelo. Fue si alguien, meses antes, había escrito el plan B en código en vez de en un slide de riesgos.

Preguntas frecuentes

¿Qué es el vendor lock-in en IA y por qué importa?

Cuando toda la inferencia crítica de tu producto pasa por un único proveedor, sea API o cuentas de suscripción, cualquier cambio de precio, apagón regulatorio o deprecación de modelo te deja sin opciones reales. El coste de cambiar supera los 290.000 € de media y el 58% de quienes lo intentan fracasa o se pasa de plazo. Tener un solo proveedor no es una decisión de arquitectura: es una apuesta.

¿Qué pasó con Claude Fable 5 en junio de 2026?

El 12 de junio de 2026, el Departamento de Comercio de EE.UU. obligó a Anthropic a desactivar Claude Fable 5 y Mythos 5 en todo el mundo al no poder filtrar usuarios por nacionalidad. Otros modelos (Opus, Sonnet, Haiku) siguieron activos. A 22 de junio, diez días después, Fable 5 seguía apagado sin fecha de regreso pese a la distensión política.

¿Qué diferencia hay entre diversificar con otros proveedores frontera y usar modelos de pesos abiertos?

Diversificar entre proveedores frontera (Anthropic, OpenAI, Google, Mistral…) es el primer paso más accesible: cambias config, no infraestructura. Los modelos de pesos abiertos dan soberanía total pero requieren infra seria, varias GPUs de alta gama, sistemas de serving como vLLM, y capacidad técnica para operarlos. Un modelo grande de pesos abiertos no es algo que corras en local como si descargaras Word. Ambas estrategias son compatibles y complementarias; la elección depende de la tarea, el presupuesto y la capacidad del equipo.

¿Qué es un router de modelos por tier y para qué sirve?

Es una capa que no habla de "Claude" o "GPT", sino de tiers (barato/rápido, medio, razonamiento). Un router en config asigna cada tier a proveedor + modelo + precio, con fallback si falla el primario y tope de presupuesto. Orquestadores y agentes solo ven una interfaz común. Cambiar de proveedor es cambiar configuración, no reescribir el producto.