Audita tu mapa de conmutación de IA para detectar capacidad compartida oculta
Trata la conmutación multi-proveedor como correlacionada hasta que puedas demostrar que las rutas de capacidad, nube y región son independientes.
La capacidad compartida es la dependencia oculta
El 3 de septiembre de 2026, ChatGPT, Claude y Grok registraron cada uno una caída confirmada en su panel de estado del servicio. La conmutación multi-proveedor intercambia costo y complejidad por disponibilidad, pero solo si los proveedores son independientes. Si las rutas de inferencia comparten un pool de capacidad, tu disponibilidad efectiva es la disponibilidad de ese pool, no el producto de rutas separadas.
Los paneles de los proveedores no son mapas de dependencias. Te dicen que un servicio está caído, no por qué. La interrupción de Claude del 3 de septiembre de 2026 comenzó cerca de las 6:23 a. m. hora del Pacífico y terminó cerca de las 9:16 a. m. hora del Pacífico, afectando a claude.ai, la API de Claude y Claude Code.
Grok estuvo fuera de línea desde aproximadamente las 6:30 a. m. hora del Pacífico del 3 de septiembre de 2026 durante unas tres horas y media.
La superposición es el detonante de la auditoría: una hora de inicio cercana no es prueba de una causa compartida, pero sí es una pista verificable. Registra las horas de inicio y fin, las superficies afectadas y las causas declaradas en una sola tabla, y luego compara proveedores. Mantén esa tabla como línea base del mapa de dependencias.
Microsoft no registró un incidente de salud del servicio de Azure para la ventana de caída del 3 de septiembre de 2026 y rechazó la afirmación de que Azure causó las interrupciones.
El CTO de Cloudflare afirmó que la red de Cloudflare no sufrió ninguna interrupción significativa del servicio durante la ventana de caída del 3 de septiembre de 2026.
Esas negaciones no demuestran independencia. Inclúyelas en la misma tabla que la falla observada.
La aritmética cambia cuando la dependencia es común
El diseño de conmutación asume probabilidades de falla independientes. Si dos rutas comparten una fuente de alimentación, un circuito de refrigeración, una región de nube o una ruta de red, el componente compartido es el punto de falla. Cuando ambas rutas dependen de D, el componente compartido establece un piso para la probabilidad conjunta de falla: P(D), no P(A) × P(B).
Trata el componente compartido como una dependencia de primer nivel. Los acuerdos de capacidad pueden hacer que ese componente compartido sea lo suficientemente grande como para importar. En mayo de 2026, Anthropic aseguró la producción completa del centro de datos Colossus 1 de SpaceX en Memphis, Tennessee.
Se informó que el acuerdo de Colossus 1 otorgaba a Anthropic más de 300 MW de capacidad, más de 220,000 GPUs de Nvidia y un costo mensual de aproximadamente $1,25 mil millones hasta mayo de 2029.
Esa escala es una concentración, no una falla. Cuando tu objetivo de conmutación depende del mismo proveedor, la misma nube o el mismo sitio físico, no has añadido independencia. Has añadido otra exposición al mismo riesgo.
Instrumenta la dependencia compartida antes de instrumentar la conmutación de respaldo. Monitórala en el mismo panel que el estado del proveedor y genera una alerta cuando ambos fallen a la vez. Una conmutación de respaldo que comparte una dependencia no reduce la probabilidad de una caída correlacionada.
La auditoría de conmutación por capacidad compartida es un mapa de dependencias
Construye el mapa a partir de la capacidad declarada y la falla observada. Ejecútalo antes de la próxima caída correlacionada, no después, y mantenlo actualizado tras cada incidente de proveedor.
Cada elemento es verificable rápidamente, porque la auditoría necesita encontrar el salto compartido antes de que falle.
- Inventario cada contrato de capacidad declarado y anota la región, la nube, la fuente de alimentación y el plazo.
- Mapea las dependencias físicas y de nube de cada proveedor, incluidos los centros de datos compartidos, las rutas de red y la capacidad aguas arriba.
- Verifica una ruta de segunda región o segunda nube que no reutilice la dependencia declarada.
- Genera alertas ante caídas correlacionadas de proveedores comparando las marcas de tiempo de los paneles y las notas de incidentes entre proveedores.
El inventario te obliga a ver el contrato, la región y el plazo antes de declarar un proveedor independiente. Un contrato que nombra un sitio es una dependencia, no un respaldo.
El mapeo convierte la documentación del proveedor en un grafo de dependencias. Si los proveedores comparten una región de nube, una ruta de red o una fuente de alimentación, marca esa arista como compartida.
La verificación prueba si tu conmutación de respaldo puede sobrevivir a la concentración declarada. Una ruta que reutiliza la misma dependencia declarada no es una ruta; añade una ruta independiente de segunda región o segunda nube que no lo haga.
Las alertas te dan una señal cuando la independencia se rompe. Las caídas correlacionadas son visibles en las marcas de tiempo y las notas de incidentes antes de que se admita una causa común.
Si no puedes producir el mapa, trata la conmutación como correlacionada. Si puedes, instrumenta los saltos compartidos y genera alertas ante la superposición.