El 12 de junio de 2026, dos modelos de Anthropic —Claude Fable 5 y Mythos 5— dejaron de estar disponibles. No para algunos clientes ni en algunas regiones: para todos los usuarios, en todo el mundo. Volvieron el 1 de julio. Dieciocho días.
Lo interesante no es la duración, sino la causa. No fue una caída de infraestructura, ni un impago, ni una deprecación anunciada con seis meses de antelación: fue una decisión regulatoria de un tercer actor sobre la que ni el proveedor ni sus clientes tenían control. Si tu producto dependía de esos modelos, la mañana del 12 de junio tu roadmap dejó de importar.
Este artículo va de eso: qué falló, por qué el riesgo que se materializó no es el que la gente vigila, y cómo se diseña un sistema de IA que sobreviva a que su modelo desaparezca. Spoiler para quien espere la conclusión fácil: la respuesta no es "no uses modelos de proveedor". Son mejores y más baratos que mantener uno propio, y lo seguirán siendo. La respuesta es no acoplarte a uno solo sin una salida probada.
Qué pasó exactamente, con fechas
La cronología es pública y la cuenta la propia Anthropic en su nota sobre el redespliegue de Fable 5:
| Fecha | Qué ocurre |
|---|---|
| 12 de junio de 2026 | El gobierno de EE. UU. impone controles de exportación sobre Fable 5 y Mythos 5, obligando a restringir el acceso a nacionales extranjeros dentro y fuera de EE. UU. |
| 12 de junio de 2026 | Al no ser posible verificar la nacionalidad en tiempo real, Anthropic suspende el acceso a ambos modelos para todos los usuarios |
| 12–30 de junio de 2026 | 18 días de indisponibilidad total |
| 30 de junio de 2026 | Se levantan los controles de exportación |
| 1 de julio de 2026 | Redespliegue global de ambos modelos |
El origen técnico también está documentado: investigadores de Amazon encontraron cómo saltarse las salvaguardas de Fable 5 pidiéndole identificar vulnerabilidades de software. En al menos un caso, el modelo "produjo código que demostraba cómo la vulnerabilidad relevante podía explotarse". Antes de volver a desplegar, Anthropic desarrolló un clasificador específico que bloquea esa técnica en más del 99% de los casos.
La mecánica es donde está la lección de arquitectura: la restricción legal era selectiva (afectaba a determinadas nacionalidades) pero la respuesta técnica solo podía ser total. Un requisito legal parcial se convirtió en indisponibilidad completa por pura imposibilidad de segmentar.
El patrón que conviene interiorizar: una obligación legal que tu proveedor no puede cumplir de forma granular se traduce en un apagón total. Da igual que tu empresa esté en Oviedo y no tenga nada que ver con un control de exportación: el interruptor es único y lo acciona alguien que no eres tú.
El riesgo que vigilas no es el que te tumba
Casi todo el mundo que integra IA vigila el uptime: página de estado en favoritos, alertas de latencia, reintentos con backoff exponencial. Todo eso está bien y no habría servido de nada aquí.
| Riesgo | ¿Se vigila habitualmente? | ¿Lo cubre un SLA típico? | ¿Se materializó en junio de 2026? |
|---|---|---|---|
| Caída de infraestructura | Sí (status page, alertas) | Sí, con créditos de servicio | No |
| Degradación de latencia o rate limits | A veces | Parcialmente | No |
| Deprecación de una versión de modelo | Rara vez | No: es política de producto, no incidencia | No (pero ocurre de continuo) |
| Cambio de comportamiento tras una actualización | Casi nunca de forma sistemática | No | No |
| Retirada por decisión regulatoria ajena | Casi nadie | No | Sí: 18 días |
Lee tu contrato antes de darte por cubierto. Un SLA mide disponibilidad frente a fallos imputables al proveedor; una restricción impuesta por una autoridad no lo es, y las cláusulas de fuerza mayor y cumplimiento normativo suelen dejar fuera precisamente este escenario. Aunque te compensaran, el crédito de servicio no arregla dieciocho días con tu producto degradado.
Y hay un agravante: el aviso fue nulo. Una deprecación planificada te da meses; un incidente de infraestructura dura horas y tiene final previsible. Aquí, el día 12 el modelo estaba, el día 13 no, y nadie podía decirte cuándo volvería. Una arquitectura que necesita una semana para cambiar de modelo, en ese escenario, es una arquitectura sin salida.
Si tu plan de contingencia consiste en "cambiamos el nombre del modelo en la variable de entorno y a ver qué pasa", no tienes un plan: tienes una hipótesis sin probar. La diferencia se descubre siempre en el peor momento.
Los tres tipos de dependencia que tienes ahora mismo
"Depender de un proveedor de IA" es una frase demasiado gruesa para servir de nada. En la práctica son tres dependencias distintas, con costes de salida muy diferentes, y casi todo el mundo solo ve la primera.
1. Dependencia de API propietaria
Es la visible: tu código llama al SDK de un proveedor concreto, con su formato de mensajes, su gestión de herramientas y sus códigos de error. Se manifiesta cuando un grep del nombre del proveedor devuelve resultados repartidos por media docena de módulos de negocio.
Es la más fácil de resolver y la que más gente resuelve mal, porque se arregla con disciplina de diseño de toda la vida: una interfaz propia, una implementación por proveedor, ni una llamada al SDK fuera de esa carpeta. Coste de salida si la trabajas desde el principio: horas. Si no: un refactor transversal en plena crisis.
2. Dependencia de prompt
Mucho más insidiosa. Tus prompts han sido afinados —a menudo sin querer, a base de iterar— contra el comportamiento de un modelo concreto: cómo sigue instrucciones, su verbosidad por defecto, cuánto se ciñe a un JSON sin que se lo repitas tres veces, qué entiende por "sé conciso". Cambias de modelo, el mismo prompt sigue "funcionando" y la calidad cae en silencio. Nadie lo nota hasta que lo nota un cliente.
Se manifiesta en instrucciones que solo tienen sentido para un modelo ("no empieces la respuesta con 'Claro'"), en features propietarias que no todos implementan igual y, sobre todo, en la ausencia de cualquier medida objetiva de calidad. El coste de salida no es de ingeniería: es de confianza. Sin evaluación, cambiar de modelo es un acto de fe.
3. Dependencia de datos
La que no se arregla con código. Si llevas dos años enviando documentación interna, historiales o contratos de clientes a la API de un tercero, la dependencia ya no es técnica: es contractual y jurídica. Cambiar de proveedor implica rehacer el análisis de transferencias, revisar el encargo de tratamiento, actualizar el registro de actividades y, si el caso es sensible, hablar otra vez con tu DPO y quizá con tus clientes. Es la única de las tres que puede llevarte a que el fallback correcto no sea otro proveedor, sino tu propio hardware.
| Tipo de dependencia | Cómo detectarla en 10 minutos | Coste de salida si no la has trabajado |
|---|---|---|
| API propietaria | grep del SDK fuera de la capa de integración | Refactor transversal bajo presión |
| Prompt acoplado | ¿Hay un conjunto de evaluación con resultado numérico? Si no, la tienes | Regresión silenciosa de calidad |
| Datos fuera del perímetro | ¿Qué datos han salido y bajo qué base jurídica? | Semanas de trabajo legal antes de mover nada |
Arquitectura con fallback multi-modelo
Nada de lo que sigue es exótico ni caro: es lo que llevamos treinta años haciendo con bases de datos y pasarelas de pago, aplicado a un componente nuevo.
La capa de abstracción: un contrato, varios proveedores
Define una interfaz propia con las operaciones que tu producto necesita de verdad —generar texto, extraer datos estructurados según un esquema, clasificar, generar embeddings— y ni una más. Cada proveedor es una implementación de esa interfaz; el resto de la aplicación no sabe qué modelo hay detrás.
Tres reglas separan una abstracción útil de una que se rompe el día que la necesitas:
- Normaliza los errores. Rate limit, timeout, filtro de contenido, contexto excedido y fallo de infraestructura son cinco situaciones distintas que tu lógica de reintentos debe distinguir. Si dejas escapar la excepción del SDK, has trasladado el acoplamiento al bloque
except. - No abstraigas lo que no vas a portar. Una capa que intenta cubrir todas las features exclusivas de todos los proveedores acaba siendo peor que el problema que resuelve. Abstrae el mínimo común denominador que usas; lo propietario, excepción consciente y documentada.
- El enrutado es configuración, no código. Qué modelo atiende qué tarea, en qué orden de preferencia y con qué alternativa, se decide en configuración recargable. Cambiar de modelo en producción debe ser una decisión operativa de minutos, no un despliegue.
Los routers y gateways de terceros que venden justo esto ahorran trabajo, pero resuelven el problema añadiendo un proveedor más a la cadena: ganas portabilidad entre modelos y pierdes independencia respecto al router. Buen intercambio si tu capa interna sigue existiendo por debajo.
Prompts portables
Un prompt portable produce resultados equivalentes en varios modelos sin reescritura. En la práctica: instrucciones explícitas en lugar de dar por hecho el comportamiento por defecto; el esquema de salida especificado en el propio prompt y no confiado a una feature propietaria; validación estricta de la respuesta contra ese esquema con reintento acotado; y ninguna instrucción que solo tenga sentido para las manías de un modelo.
Guárdalos versionados, fuera del código de negocio, con su conjunto de evaluación al lado. Un prompt sin evaluación es una cadena de texto que nadie se atreve a tocar.
Evaluación automática: cambiar de modelo sin fe ciega
Esta es la pieza que casi nadie construye y la única que convierte el fallback de aspiración en capacidad real. Sin ella no puedes cambiar de modelo, porque no sabes si el nuevo es peor.
No hace falta montar un laboratorio. Con entre 50 y 200 casos reales de tu dominio y su salida esperada ya tienes señal utilizable. Lo importante es que vengan de tu producción —incluidos los raros y los que un día dieron problemas— y no de un benchmark académico, más un puñado de casos adversariales: entradas vacías, documentos larguísimos, texto en otro idioma, intentos de inyección de prompt.
Qué medir depende de la tarea: exactitud contra la respuesta esperada en extracción y clasificación (medible con código, sin ambigüedad), y validez del esquema, latencia p95 y coste por caso en todas. Para tareas generativas sin respuesta única correcta, un modelo evaluador da una señal comparativa suficiente para decidir.
Ejecútalo en CI, no a mano. Así cumple tres funciones: te avisa cuando el modelo que ya usas cambia de comportamiento tras una actualización, te permite adoptar uno nuevo con datos en lugar de con intuición, y convierte un cambio de proveedor de emergencia en un procedimiento de una tarde.
La prueba de fuego: ejecuta un simulacro. Una vez al trimestre, cambia el proveedor principal por el secundario en preproducción, pasa las evaluaciones y anota cuánto tardas y qué se rompe. Un fallback que nunca se ha ejercitado no es un fallback, es documentación optimista. La primera vez siempre aparecen sorpresas —tokens que se cuentan distinto, un max_tokens que no significa lo mismo, un filtro de contenido que salta con vocabulario clínico— y es infinitamente mejor descubrirlas un martes tranquilo.
El plan B real: pesos abiertos con licencia permisiva
Aquí está la diferencia cualitativa. Cambiar de un proveedor propietario a otro reduce el riesgo de correlación, pero no lo elimina: sigues expuesto a que un tercero decida por ti. Un modelo de pesos abiertos con licencia permisiva cambia la naturaleza del riesgo, porque nadie puede revocarte unos pesos que ya has descargado.
El informe de OpenRouter del 27 de junio de 2026 señala dos que califican como plan B serio:
| Modelo | Parámetros (totales / activos) | Licencia | Contexto | Precio first-party (entrada / salida por millón de tokens) |
|---|---|---|---|---|
| DeepSeek V4 Flash | ~284B / ~13B | MIT | 1M | 0,14 $ / 0,28 $ |
| GLM 5.2 | 744B / 40B | MIT | 1M | — |
Lo relevante no son los parámetros: es la licencia MIT, lo más permisivo que existe en la práctica, sin cláusulas de uso aceptable reinterpretables ni umbrales de usuarios a partir de los cuales toca negociar. Justo lo que se busca en un plan B. Con dos matices honestos, porque aquí es donde el marketing se pasa de frenada:
Uno: pesos abiertos no significa que quepa en tu servidor. Ambos son arquitecturas mixture-of-experts con activación esparsa: activan pocos parámetros por token, pero todos los expertos deben residir en memoria. Un modelo de 284B totales no cabe en la caja con una GPU de la oficina, por muchos que sean los 13B activos. Autohospedarlos es conversación de clúster multi-GPU; el análisis de VRAM por familia y cuantización está en nuestra guía de arquitectura IA on-premise.
Dos: la licencia te da el derecho, no la disponibilidad. Si consumes DeepSeek V4 Flash por la API de su fabricante, tienes la misma dependencia operativa que con cualquier otro proveedor. Lo que te da la MIT es el derecho a irte con los pesos a otro sitio, y ese derecho solo vale algo si los has descargado y sabes en qué hardware los pondrías a correr. Bajar el artefacto, guardarlo con tus copias de seguridad y anotar el procedimiento de arranque cuesta una tarde: es el seguro más barato de esta lista.
La combinación que recomendamos para producto en producción: proveedor propietario como principal (mejor calidad, cero mantenimiento), un segundo proveedor configurado y evaluado (conmutación en minutos ante una caída) y un modelo de pesos abiertos con licencia permisiva, ya descargado (supervivencia si el mercado propietario deja de ser una opción). Tres niveles, coste marginal, y la certeza de que ninguna decisión ajena te deja a cero.
El contrapunto honesto: los modelos de proveedor son buenos y baratos
Sería deshonesto usar los 18 días de junio para venderle autohospedaje a todo el mundo: la economía del mercado propietario ha ido en la dirección contraria durante todo 2026.
El mismo 30 de junio en que se levantaban los controles de exportación, Anthropic lanzaba Claude Sonnet 5 con ventana de contexto de 1M de tokens y un precio introductorio de 2 $ por millón de tokens de entrada y 10 $ de salida hasta el 31 de agosto de 2026, para pasar después a 3 $ y 15 $. Con esas cifras la aritmética de la mayoría de pymes no admite discusión: hace falta un volumen enorme y sostenido para que amortizar GPU, operar el servicio, parchearlo y monitorizarlo salga a cuenta frente a pagar por token. Y eso sin contar la diferencia de calidad en las tareas difíciles.
La conclusión correcta de junio no es "vuelve al servidor propio", sino una más modesta y más útil: el proveedor sigue siendo la opción por defecto, pero la opción por defecto necesita una salida probada. Es la misma lógica de coste total de propiedad que aplicamos al elegir entre software a medida, SaaS y low-code: lo que decide no es el precio del primer mes, es el coste de cambiar de idea dentro de tres años.
Cuándo la salida es on-premise
Para una minoría de casos, el fallback correcto no es otro proveedor: es tu propia infraestructura. Ocurre cuando concurren varias de estas condiciones:
- El dato es el problema, no el modelo. Historiales clínicos, secreto profesional, documentación clasificada. Si lo que te frena es que el dato salga de tu perímetro, cambiar de API no arregla nada.
- El servicio es crítico. Si dieciocho días a medio gas se traducen en incumplimientos contractuales, la disponibilidad deja de ser un problema de proveedor para ser uno de arquitectura.
- La carga es alta, estable y predecible. Es donde la amortización del hardware empieza a tener sentido frente al pago por token.
- Hay capacidad real de operación. Alguien que sepa Docker, GPU y mantener un servicio Linux vivo. La IA autohospedada no es "instalar y olvidar".
Un despliegue local ayuda a cumplir las obligaciones de RGPD y AI Act —elimina la transferencia internacional y te da control sobre pesos, logs y trazabilidad— pero no te exime de nada por sí solo: sigues necesitando tu análisis, tus registros y tu supervisión humana. El detalle completo, en el artículo sobre IA on-premise y soberanía del dato.
Para el resto, el híbrido sensato es el de siempre: proveedor por defecto, capacidad de conmutar demostrada y pesos abiertos en el cajón por si acaso.
Checklist: qué preguntar a cualquier proveedor de IA
Estas son las preguntas que hacemos —y que respondemos cuando nos las hacen— antes de meter un modelo de terceros en un producto que alguien va a pagar.
| Pregunta | Qué buscas en la respuesta | Bandera roja |
|---|---|---|
| ¿Qué pasa con mi producto si tu modelo deja de estar disponible mañana? | Una alternativa concreta, nombrada y ya configurada | "No va a pasar" |
| ¿Cuánto tardáis en cambiar de modelo y cómo lo habéis medido? | Un número respaldado por un simulacro reciente | "Es cambiar una variable" |
| ¿Qué cubre y qué excluye el SLA del proveedor de modelo? | Conocen fuerza mayor y cumplimiento normativo | No lo han leído |
| ¿Hay evaluación de mi caso de uso y qué puntúa hoy? | Casos reales, número, ejecución en CI | "Lo probamos manualmente" |
| ¿Cómo detectaríais un cambio de comportamiento tras una actualización? | Evaluación programada y alerta de regresión | "Se nota enseguida" |
| ¿Qué datos míos salen, hacia dónde y bajo qué contrato? | Inventario preciso y encargo de tratamiento firmado | Respuesta vaga |
| ¿Los prompts y las evaluaciones son míos? | Sí, versionados y en mi repositorio | Viven en la plataforma del proveedor |
| ¿Hay plan B de pesos abiertos y bajo qué licencia? | Modelo concreto, licencia permisiva, pesos descargados | No hay plan B |
| ¿Cuál es el coste de sacarme de aquí dentro de dos años? | Estimación honesta en horas | "Nunca te vas a querer ir" |
Si el proveedor —o tu propio equipo— no sabe responder a la primera pregunta con un nombre de modelo alternativo concreto y una fecha del último simulacro, la respuesta real es que no hay salida. Y en junio de 2026 hemos visto lo que cuesta descubrirlo tarde.
Cierre: diseña con salida, no con miedo
Dieciocho días. Sin caída, sin impago, sin previo aviso y sin que ningún SLA lo cubriera. La causa estuvo tan lejos del control de cualquier cliente que el debate sobre qué proveedor es más fiable pierde buena parte de su sentido: el punto único de fallo no era el proveedor, era la ausencia de alternativa.
El trabajo que evita repetirlo es modesto y aburrido, como suele ser el buen trabajo de arquitectura: una interfaz propia con una implementación por proveedor, prompts que no dependen de las manías de un modelo, cincuenta casos de evaluación en CI, un segundo proveedor configurado, un simulacro trimestral y unos pesos abiertos descargados donde guardas las copias de seguridad. Nada de esto es un proyecto: es una semana bien invertida al principio y unas horas al trimestre después.
La pregunta que deja las cosas claras en cualquier reunión: "si el modelo que usamos desaparece esta noche, ¿qué hacemos mañana por la mañana, quién lo hace y cuánto tarda?". Si la sala se queda callada, ya sabes cuál es la siguiente tarea del backlog.
En Lin-ia diseñamos las integraciones de IA de nuestros clientes con esta arquitectura por defecto: capa de abstracción propia, evaluación automatizada desde el primer sprint y un plan B documentado que se prueba, no que se promete. Si tienes un producto en producción que depende de un solo modelo y quieres saber cuánto costaría darle salida, cuéntanos tu caso y lo miramos contigo.
Lecturas relacionadas: arquitectura IA on-premise y soberanía del dato, software a medida vs SaaS vs low-code y agentes de IA autónomos: qué es real en 2026.
