Anoche el modelo en el que estaba trabajando dejó de existir. No se ralentizó, no fue limitado por cuota. Le pedí a la herramienta algo rutinario y respondió que el modelo "puede no existir, o puede que no tengas acceso a él". Unos minutos después, la noticia lo confirmó: Anthropic había suspendido Claude Fable 5 y Mythos 5 en todo el mundo, esa misma noche, por una directiva del gobierno de EE. UU.
El trabajo no se detuvo. Cambié a Claude Opus 4.8 y seguí, porque nada de lo que importaba vivía dentro de Fable. Vivía en una capa de memoria y en un historial de git que cualquier modelo capaz puede retomar. Esa brecha, entre "el modelo desapareció" y "el trabajo se pausó", es todo el tema de este texto. Para la mayoría de los equipos que hoy dependen de un único modelo de IA, esa brecha es cero. El modelo se va y el trabajo se va con él.
Qué pasó realmente
El 12 de junio de 2026, a las 17:21 hora del Este, Anthropic recibió una directiva de control de exportaciones que le ordenaba suspender el acceso a Fable 5 y Mythos 5 para "cualquier ciudadano extranjero, dentro o fuera de los Estados Unidos". Como ese alcance no se puede aplicar de forma selectiva, ni siquiera contra los propios empleados extranjeros de la empresa, Anthropic desactivó ambos modelos para todos. La justificación declarada fue la seguridad nacional. Según el propio relato de Anthropic, la carta "no proporcionó detalles específicos", y la preocupación se remonta a lo que la empresa llama un "jailbreak potencial y limitado": pedirle al modelo que lea una base de código e identifique fallos de software.
Anthropic respondió en público, algo inusual. La empresa escribió que no está de acuerdo con "que el hallazgo de un jailbreak potencial y limitado deba ser motivo para retirar un modelo comercial desplegado para cientos de millones de personas", y advirtió que ese mismo criterio "esencialmente detendría todos los nuevos despliegues de modelos de todos los proveedores frontera". También dijo que el resto de los modelos de Claude, Opus 4.8 incluido, no están afectados, y que está "trabajando para restaurar el acceso lo antes posible".
Leo esa última frase como una señal de que Fable vuelve. La disputa parece estrecha y la empresa la combate abiertamente. Pero la fecha de regreso no la decide Anthropic. Ese es el punto en el que conviene detenerse. El modelo sobre el que construyes ahora puede ser apagado por un tercero sin aviso y sin calendario, y el proveedor te da la razón en que es poco razonable y aun así no puede hacer nada esta noche.
Esto no es un caso aislado
Es tentador archivar una directiva gubernamental como suceso excepcional. El apagón fue inusual. La desaparición no lo fue.
Los modelos se retiran ya según un calendario. OpenAI retiró GPT-4o el 3 de abril de 2026, un anuncio que afectó a unos 800.000 usuarios semanales, con la Assistants API en agosto. Anthropic declaró obsoleto Claude 3.7 Sonnet en noviembre de 2025 y lo apagó el 11 de mayo de 2026. Claude 3 Haiku va por el mismo camino para agosto. En toda la industria, la ventana de soporte de un modelo se ha comprimido de dieciocho o veinticuatro meses a algo entre seis y doce. A finales del año pasado, un solo cambio de cuota recortó a algunos usuarios de la API de Google en torno a un 80 por ciento, convirtiendo sistemas de producción que funcionaban en bucles de error "resource exhausted" de la noche a la mañana.
Así que un modelo que abandona tu stack no es la excepción. Es lo normal, en un reloj que no controlas, y el caso Fable acaba de añadir una forma más rápida y menos predecible de que ocurra. Algunos ya lo llaman vendor lock-out, para distinguirlo del lento lock-in que ya conocíamos. El lock-in es el coste de irse. El lock-out significa que el irse decide por ti.
Si tu producto, tu herramienta interna o tu trabajo para clientes da por hecho que cierto nombre de modelo responderá cuando lo llames, entonces tienes un punto único de fallo que los últimos seis meses han demostrado repetidamente que no es fiable.
La resiliencia es arquitectura, no elección de modelo
El instinto tras un apagón es preguntar sobre qué modelo es más seguro apostar. Es la pregunta equivocada. No hay apuesta única segura, porque el riesgo no está en el modelo, está en la dependencia. Los equipos que anoche se encogieron de hombros no fueron los que eligieron correctamente. Fueron los que construyeron de modo que elegir importara poco.
Tres cosas separan un stack que sobrevive a la desaparición de un modelo de uno que se apaga con él.
Una capa de abstracción. La lógica de tu aplicación debería hablar con una interfaz interna fina, no directamente con el SDK de un proveedor. Cuando un modelo desaparece, cambias un valor de configuración, no tu código. Los equipos que lo construyeron desde el principio cuentan que añaden o cambian de proveedor con una fracción del esfuerzo de migración frente a quienes estaban cableados directamente a una sola API. Es fontanería poco vistosa y la decisión de mayor impacto que vas a tomar.
Una capa de memoria portable. Es la que me salvó anoche. El contexto que hace útil a un asistente de IA, qué es el proyecto, qué se decidió la semana pasada, qué prefiere el cliente, tiene que vivir fuera del modelo, en un almacén que cualquier modelo pueda leer. Si tu contexto acumulado vive solo en el historial de chat de un proveedor o en un fine-tune propietario, perder el modelo significa perder la memoria institucional con él. Mantén el estado en algo portable y el modelo se vuelve un motor intercambiable en lugar de la caja fuerte.
Un fallback probado. Un segundo modelo contra el que de verdad has ejecutado tu carga de trabajo real, no uno que supones que funcionará. Hay una gran diferencia entre "podríamos cambiar" y "hemos cambiado". Lo primero es una esperanza. Lo segundo es un runbook. El fallback no necesita ser tan fuerte como tu modelo principal, necesita mantener las luces encendidas mientras resuelves el principal.
Nada de esto es exótico. Es la misma disciplina que cualquier negocio acaba aprendiendo sobre procesadores de pago, proveedores de hosting y suministradores. No llevas un restaurante con un único mayorista de verduras que puede dejar de contestar el teléfono sin aviso. La IA se ha sentido distinta porque las herramientas son nuevas y el lock-in se forma de forma invisible, en doce a dieciocho meses, antes de que nadie lo note. El apagón de Fable hizo visible lo invisible durante una noche.
Qué significa si llevas un negocio pequeño
Las grandes empresas estarán bien. Tienen departamentos de compras, contratos secundarios y presupuesto para correr dos proveedores en paralelo. La exposición está en los actores más pequeños, la agencia que cableó todo el flujo de soporte de un cliente a un modelo, el fundador cuyo producto es una envoltura sobre una sola API, el consultor cuya entrega entera depende de que una suscripción siga viva.
No necesitas presupuesto de gran empresa para ser resiliente. Necesitas tres hábitos. Mantén tus prompts y tu lógica detrás de una interfaz que controles. Mantén tus datos y tu contexto en un formato que te pertenezca y que puedas exportar hoy. Y sabe, en concreto, qué harías en la hora siguiente a que tu modelo principal desaparezca, porque en algún momento de este año descubrirás si lo sabías o solo lo suponías.
Construimos así para nuestros propios sistemas y para clientes, no porque predijéramos una directiva gubernamental, sino porque el solo calendario de retiradas ya lo hacía evidente. Anoche convirtió un principio de diseño en una prueba en vivo, y la prueba se superó por una razón aburrida: nada importante estaba atrapado dentro del modelo que se fue.
La parte que sigue siendo cierta incluso después de que Fable vuelva
Fable 5 lo más probable es que vuelva, quizá antes de que este texto cumpla una semana. Cuando lo haga, la tentación será tratar lo de anoche como una interrupción extraña que se resolvió sola y seguir adelante. Esa sería la lección cara de saltarse.
La causa concreta fue inusual. La forma no lo fue, y la forma es lo que se repite. Una capacidad de la que depende tu trabajo puede ser retirada por una decisión en la que no participas, en un calendario que no ves, por un proveedor que quizá hasta te dé la razón y aun así no pueda ayudar en el momento. Eso es ahora un rasgo permanente de construir sobre IA frontera, no un fallo en ella.
La respuesta correcta no es desconfiar de un proveedor concreto. Es dejar de tratar cualquier modelo único como infraestructura sobre la que apoyar tu peso. Trata a los modelos como lo que se han convertido, veloces, potentes y temporales, y construye la parte duradera tú mismo, en la capa de debajo que de verdad te pertenece. Hazlo, y la próxima vez que un modelo desaparezca te costará una hora y una tarde algo molesta. Sáltatelo, y te costará la parte de tu negocio que dabas por hecho que siempre respondería.
Así que aquí está la prueba que vale la pena hacer esta semana, antes de que el ciclo de noticias avance. ¿Podrías cambiar tu modelo principal esta noche, sin aviso, y no perder más que un poco de tiempo? Si la respuesta es sí, lo de anoche fue la emergencia de otro. Si la respuesta es no, acabas de aprender dónde está el trabajo.
