El viernes 12 de junio, un modelo de frontera se apagó. No lo apagó un cliente. No lo apagó un equipo de ingeniería que decidió cambiar de proveedor. Lo apagó un gobierno.

El gobierno de Estados Unidos emitió un control de exportación sobre Claude Fable 5 y Mythos 5, suspendiendo el acceso para cualquier ciudadano extranjero, dentro o fuera del país. Anthropic no podía verificar nacionalidad en tiempo real para cada solicitud, así que hizo lo único que podía hacer para cumplir: desactivó ambos modelos para todos. Usuarios pagos en Estados Unidos incluidos.

Esa es la tesis de este post, y va antes que cualquier detalle: si tu operación corre sobre una capacidad que no controlas, no tienes una herramienta. Tienes un riesgo de continuidad que todavía no se manifestó. La pieza concreta de IQ Source para empresas que ya viven con esa exposición es Socio Tecnológico. El resto del post explica por qué el reflejo de “huir al código abierto” responde a la pregunta equivocada.

Lo que se apagó, y lo que eso prueba

Los hechos importan porque definen el tipo de riesgo. Esto no fue una caída de servidor ni un rate limit. Fue una decisión externa, fuera del contrato entre Anthropic y sus clientes, que volvió inaccesible una capacidad de la noche a la mañana.

Aaron Levie, CEO de Box, lo resumió bien cuando escribió en X que la capa capaz de enrutar al mejor modelo para cada tarea va a subir mucho de valor, y nombró tres razones: optimización de costo, maximización de capacidad y mitigación de riesgo. Las dos primeras ya las conocíamos. La tercera dejó de ser teórica el viernes. En sus palabras, vamos hacia un entorno donde los gobiernos pueden restringir modelos en distintos momentos, y por eso vas a querer flexibilidad para mover cargas entre proveedores como forma de mitigar riesgo.

Yang Li, que construye infraestructura de IA soberana, lo puso más crudo en LinkedIn: la industria habla sin parar de qué tan inteligente es el modelo, y casi nadie habla de quién lo puede apagar. La pregunta más importante dejó de ser “¿qué tan capaz es?” y pasó a ser “¿quién controla el interruptor?”.

No tienes que comprar el discurso de soberanía nacional para que la conclusión operativa te aplique. Una empresa de cincuenta personas en San José que clasifica tickets, redacta propuestas y corre tres agentes internos sobre un solo modelo enfrenta exactamente el mismo problema estructural que un Estado: construyó sobre una capacidad cuyo interruptor está en otra mano.

El error no es usar Claude. Es no tener plan de respaldo.

La reacción más ruidosa esta semana fue “esto prueba que hay que irse a código abierto”. Es la respuesta equivocada al problema correcto.

Migrar todo a un modelo abierto no te da independencia. Te da un proveedor distinto del mismo problema: ahora dependes de quién lo hospeda, de los límites de ese servicio, de su disponibilidad. Cambiaste el dueño del interruptor, no la cantidad de interruptores. La fragilidad no estaba en que el modelo fuera de Anthropic. Estaba en que tu operación tenía un único punto de falla y ninguna alternativa lista para arrancar.

Lo que cambia el cálculo no es la licencia del modelo. Es dónde vive la lógica que decide qué modelo atiende cada tarea.

Esto ya lo dije desde otro ángulo en el post sobre el modelo barato como anzuelo: la diferencia entre elegir tu próximo proveedor y que te lo elijan son, técnicamente, unas cincuenta líneas de código. Si la lógica de enrutamiento está en la consola de tu proveedor, el proveedor controla qué se escala, qué se sirve y qué pasa cuando algo se cae. Si esa lógica está en tu código, una función que evalúa la tarea y decide a qué endpoint mandarla, entonces cambiar de Claude a otro modelo es una variable de configuración, no un proyecto de tres semanas.

La evidencia de que el enfoque multi-modelo ya funciona en producción llegó esta misma semana. OpenRouter publicó su API Fusion y mostró los números: un panel de tres modelos de presupuesto, fusionados, superó a GPT-5.5 en solitario y a Opus 4.8 en solitario, y quedó a menos del uno por ciento de Fable 5 cobrando alrededor de la mitad del precio. No lo cito como recomendación de producto. Lo cito como prueba de que orquestar varios modelos dejó de ser un experimento de laboratorio. La capacidad de mover cargas entre modelos ya está madura. Lo que falta en la mayoría de empresas no es la tecnología, es el diseño.

La abstracción no es gratis

Acá es donde la mayoría de los posts de LinkedIn se detienen, justo antes de la parte incómoda. Si esto fuera tan fácil como “agrega una capa de abstracción”, todo el mundo ya la tendría. No la tiene por razones reales.

Primero, el caché. Buena parte del ahorro en herramientas como Claude Code viene de que el contexto se cachea entre llamadas, y ese caché se rompe en el momento en que cambias de modelo. Mover una carga a otro proveedor de emergencia no es gratis: pagas la reconstrucción del contexto y, a veces, una latencia mayor mientras tanto. Tener la puerta abierta cuesta, aunque no la cruces.

Segundo, la gobernanza. Leon Gordon lo planteó como una pregunta sin respuesta limpia: cuando la postura de cumplimiento de un proveedor puede gatillar un apagón global sin aviso, ¿cómo cabe eso dentro de un SLA o de un marco de riesgo de compras? Mantener integraciones activas con varios proveedores significa varios SDKs, varios formatos de respuesta, varios modelos de precio y varios conjuntos de límites. El objetivo no es usar todos los modelos del mercado todos los días. Es poder cambiar en horas si lo necesitas. Hay una diferencia entre tener redundancia diseñada y tener un caos de tres integraciones que nadie mantiene.

Tercero, y es el que más pesa: alguien tiene que ser dueño de esa capa. Diseñarla, probar el plan de respaldo de cada flujo, parchear el comportamiento cuando un modelo cambia, decidir qué cargas merecen redundancia y cuáles no. La mayoría de las empresas B2B de tamaño medio en LatAm no tienen ese rol internamente. Tienen ingenieros que pueden conectar un modelo y hacerlo funcionar. No tienen a la persona que se sienta encima a vigilar que la operación sobreviva el día que el interruptor lo mueva alguien más.

El costo de esa fragilidad ya se está midiendo del lado de la confianza empresarial. David Eberle, CEO de Typewise, citó en LinkedIn un dato que se vuelve más relevante después de esta semana: la confianza de los equipos en la IA cae de un 82% en la fase de construcción a un 58% al momento de ponerla en producción. Un apagón externo sin aviso es exactamente el tipo de evento que ensancha esa brecha. No castiga la capacidad del modelo. Castiga la suposición de que va a estar ahí mañana.

Lo que IQ Source hace con esto

Socio Tecnológico existe para ser ese dueño. La empresa cliente no nos subcontrata conectar un modelo, eso se volvió accesible. Nos subcontrata el rol que diseña la capa de enrutamiento, mantiene un plan de respaldo por cada flujo crítico, absorbe los cambios cuando un proveedor falla o sube el precio, y mantiene ese conocimiento dentro de un equipo formado en lugar de un único ingeniero con riesgo de salida. Es el rol que tendría un Director de Tecnología bueno, que la mayoría de empresas de tamaño medio no puede pagar a tiempo completo.

El discovery previo lo hace AI Maestro, nuestro programa de dos meses que produce el Mapa de Realidad de Procesos y el Score de Oportunidad de IA. Ahí se decide algo que importa tanto como la redundancia misma: cuáles flujos merecen un plan de respaldo y cuáles no. No todo lo que corre sobre un modelo es crítico. Ponerle redundancia a una tarea que tolera estar caída un día es pagar complejidad sin necesidad. La disciplina es saber dónde la continuidad es negociable y dónde no, y esa decisión la tomas antes de construir, no durante el apagón. La misma lógica la trabajamos desde el ángulo del costo en el post sobre el moat que se movió al flujo de trabajo.

Hazle a tu equipo una pregunta concreta antes de cerrar la semana. Si el modelo sobre el que corre tu flujo más crítico desapareciera mañana por una decisión que no tomaste tú, ¿cuántas horas tardarías en estar operando sobre otro? Si la respuesta se mide en semanas, o si nadie la sabe, no tienes una herramienta de IA. Tienes una dependencia con un interruptor en una mano ajena. Y esta semana quedó claro que esa mano se mueve.

Diseñar el plan de respaldo de tus flujos críticos de IA