Respaldos y recuperación de tu stack de IA: qué hacer cuando la API de Anthropic no responde

Tiempo: unos 30 min de lectura + 40 min de práctica

Lo esencial

Un stack de IA en producción es como la instalación eléctrica de tu casa. Mientras funciona, ni la notas. La luz prende, el refrigerador enfría, la laptop carga. Pero una vez al año hay un apagón.

Y ahí las casas se dividen en dos tipos:

• La casa sin planta de luz: te quedas a oscuras, la comida del refrigerador se echa a perder, el trabajo se detiene. Esperas a que lo arreglen. Horas. A veces un día entero.
• La casa con planta de luz: en un par de minutos se hace el cambio, vuelve la luz y el trabajo sigue. Los vecinos a oscuras, tú trabajando.

Un stack de IA funciona igual. La API de Anthropic se cae. OpenAI se cae. Cloudflare se cae. No es "si pasa", es "cuándo pasa". La única pregunta es si tienes un plan para cambiar de proveedor o si te vas a enterar del problema al mismo tiempo que tus clientes.

En esta lección: 7 escenarios típicos de desastre, una estrategia de respaldo con varios proveedores (multi-provider fallback), respaldos 3-2-1 para tus datos de IA y un plan de acción (playbook) de 10 minutos para cuando todo se rompe.

🎨 Imagínalo así: un piloto de aviación comercial practica la falla de un motor en pleno vuelo. No porque pase seguido, sino porque cuando pasa, el piloto debe tener el movimiento aprendido, no pánico. El simulacro trimestral (drill) es tu práctica de falla de motor.

🎯 Árbol de decisión: qué nivel de preparación necesitas

Uso personal (solo para ti):

• ✓ Basta con respaldar en Git tus configuraciones y prompts
• ✓ Recuperar a mano está bien: aguantar 4 horas de caída no es crítico
• ✗ Varios proveedores de respaldo son demasiado

Pyme (tienes clientes que pagan, de $1K a $10K de MRR, ingreso mensual recurrente):

• ✓ Respaldo con varios proveedores, obligatorio
• ✓ Respaldos automáticos cada noche
• ✓ Monitoreo básico (disponibilidad + errores del LLM)
• ✓ Plantillas de comunicación listas

Profesional (de $10K a $50K de MRR, los clientes dependen de ti):

• ✓ Respaldo 3-2-1 completo
• ✓ Rotación automática de claves
• ✓ Simulacro trimestral
• ✓ Página de estado pública

Empresa (más de $50K de MRR, contratos con SLA, acuerdos de nivel de servicio):

• ✓ Despliegue en varias regiones
• ✓ Cambio automático de proveedor (failover)
• ✓ Monitoreo 24/7 + guardias (on-call)
• ✓ Respaldos que cumplan SOC 2

Para quienes toman el curso, el nivel por defecto es el de pyme. Alcanza para la mayoría de los casos reales.

Conceptos clave

• RTO (Recovery Time Objective, objetivo de tiempo de recuperación): cuánto tiempo puedes estar caído. Para una pyme suele ser 30 minutos; para una empresa, de 5 a 15 minutos
• RPO (Recovery Point Objective, objetivo de punto de recuperación): cuántos datos puedes perder. Respaldo nocturno = RPO de 24 horas; replicación en tiempo real = RPO cercano a cero
• Cadena de proveedores de respaldo: la lista de proveedores de LLM en orden de prioridad, con cambio automático si uno falla
• Respaldo 3-2-1: 3 copias de los datos, 2 tipos distintos de almacenamiento, 1 copia fuera del sitio (otra región u otra nube)
• Plan de respuesta a incidentes (incident playbook): instrucciones escritas de antemano sobre qué hacer cuando X falla. No "ya veremos en el momento"
• Simulacro (drill): una simulación de desastre para comprobar que el plan de verdad funciona
• Radio de impacto (blast radius): a qué afecta una falla concreta. Se cae un proveedor de LLM = radio de impacto "todas las funciones que lo usan"
• Página de estado (status page): una página pública con el estado actual del servicio. Los clientes lo ven de inmediato y no escriben a soporte

Teoría

7 escenarios típicos de desastre

No son teóricos: a proveedores y desarrolladores les pasan con regularidad. Fechas y detalles concretos están en los historiales públicos de incidentes (enlaces al final de la lección).

Escenario 1: Caída de la API de Anthropic

Historia: Anthropic tiene a veces ventanas cortas de servicio degradado, con más latencia y errores 5xx, y también incidentes más largos. El historial real está en status.claude.com.

Impacto: todo lo que depende de la API de Claude deja de funcionar. Si tu stack depende de un solo proveedor, tu producto se cae.

Tiempo de recuperación:

• Sin plan: de horas a días (esperas a que Anthropic lo arregle + cambio manual si tienes a dónde)
• Con plan: 10 minutos (cambio automático a OpenAI/Gemini; los clientes ni lo notan)

Cómo mitigarlo: cadena de proveedores de respaldo + página de estado + comunicación con los clientes.

Escenario 2: Caída de la API de OpenAI

Historia: OpenAI ha tenido caídas grandes en las que ChatGPT y la API estuvieron fuera varias horas. El historial actual está en status.openai.com.

Impacto: un respaldo basado en GPT no te salva si está primero en la cadena. Peor aún: proveedores distintos pueden caerse al mismo tiempo por dependencias compartidas (por ejemplo, las mismas regiones de nube).

Cómo mitigarlo: no pongas como respaldo solo a OpenAI. Mínimo 3 proveedores distintos en la cadena, en regiones de nube distintas.

Escenario 3: Incidente global de Cloudflare/Vercel

Historia:

• Cloudflare, 21 de junio de 2022: un error en la configuración de enrutamiento apagó 19 centros de datos durante más o menos una hora y cuarto (análisis de Cloudflare)
• Cloudflare, 18 de noviembre de 2025: una falla en el sistema de protección contra bots provocó errores 5xx en la CDN y fallas en Workers KV, el Dashboard y Access; el tráfico principal se recuperó en unas tres horas (análisis de Cloudflare)
• Vercel y otras plataformas también tienen incidentes con los despliegues y la infraestructura edge

Impacto: tu Worker o tu Edge Function se cae aunque el LLM funcione bien. Las solicitudes no llegan a tu código.

Cómo mitigarlo: no pongas todos los huevos en la canasta de una sola CDN. Un despliegue de respaldo en otro proveedor (AWS Lambda como secundario), y cambio de DNS con Cloudflare Health Checks o AWS Route 53.

Escenario 4: Suspensión de la cuenta (violación de los términos de servicio)

Causas típicas:

• Una revisión automática de violaciones de las reglas del servicio se dispara por error (falso positivo)
• Un patrón de cobro sospechoso o una disputa de pago
• Una violación de las condiciones de uso (a veces sin querer)

Impacto: corte inmediato. Nada de "tiene 30 días". La cuenta deja de estar disponible al instante.

Tiempo de recuperación sin una cuenta de respaldo: de días a semanas (tickets de soporte, revisión manual).

Cómo mitigarlo: una cuenta secundaria en cada proveedor crítico. Emails distintos, tarjetas distintas, direcciones de facturación distintas si se puede. Las claves de reserva ya guardadas y probadas. La segunda cuenta es de respaldo, no para evadir un bloqueo por violar las reglas: revisa las condiciones del proveedor.

Escenario 5: Falla en el pago

Escenarios:

• La tarjeta venció → falla la renovación automática → servicio en pausa
• El sistema antifraude del banco bloquea el cargo → cuenta suspendida
• Se rebasa el límite de la tarjeta corporativa por un pico repentino de uso

Impacto: normalmente pasan de 24 a 48 horas antes de que los clientes vean la caída. Pero es malo enterarte por un cliente.

Cómo mitigarlo:

• Dos tarjetas en cada cuenta (principal + respaldo)
• Alertas por email ante cualquier cargo fallido
• Alertas de gasto cuando el uso se acerca al límite de la tarjeta

Escenario 6: Corrupción de la base de datos o del KV

Causas típicas:

• Un error del proveedor de almacenamiento (KV, bases vectoriales, Postgres)
• Una migración mal hecha o un error en tu código
• Borrar o sobrescribir datos por accidente

Impacto: se pierden datos de clientes y hay que restaurar desde un respaldo. Si no hay respaldo, los datos se pierden para siempre.

Cómo mitigarlo: respaldos automáticos cada noche, recuperación a un punto en el tiempo (point-in-time recovery) si el proveedor la ofrece, probar el procedimiento de restauración cada trimestre.

Escenario 7: Brecha de seguridad

Casos reales:

• Claves de API subidas por accidente a un repositorio público de GitHub (pasa con regularidad)
• Un archivo .env que terminó dentro de una imagen de Docker publicada
• Una laptop de desarrollador robada y sin cifrado

Impacto: un salto brusco en la factura en cuestión de horas (solicitudes ajenas con tu clave de API), daño a la reputación y posiblemente una filtración de datos.

Procedimiento de recuperación:

1. Detectar (monitoreo de gasto anómalo o una alerta de secret scanning de GitHub)
2. Rotar de inmediato TODAS las claves (no solo la filtrada: también las relacionadas)
3. Auditar a qué se accedió
4. Avisar a los clientes si sus datos pudieron verse afectados
5. Análisis posterior (postmortem) + prevención

Cómo mitigarlo: hooks de pre-commit (gitleaks, trufflehog), rotación trimestral de secretos, detección de anomalías en la facturación.

Estrategia con varios proveedores de respaldo

El patrón base: una cadena de proveedores con cambio automático.

# Pseudocódigo: cadena de proveedores con respaldo
providers = [
    # los nombres de modelos son de ejemplo; modelos y precios vigentes en la página «Lo vigente» del curso
    {"name": "anthropic", "model": "claude-sonnet-5-5", "priority": 1},
    {"name": "openai", "model": "gpt-6.1-sol", "priority": 2},
    {"name": "google", "model": "gemini-3.8-flash", "priority": 3},
    {"name": "local_ollama", "model": "qwen3:8b", "priority": 4}  # último recurso
]

def call_llm(prompt, max_retries_per_provider=2):
    errors = []
    for provider in providers:
        try:
            response = call(
                provider=provider["name"],
                model=provider["model"],
                prompt=prompt,
                timeout=10
            )
            log_success(provider["name"])
            return response
        except (Timeout, ServerError, RateLimit) as e:
            log_failure(provider["name"], str(e))
            errors.append((provider["name"], e))
            continue
        except AuthenticationError:
            # Clave revocada: la saltamos sin reintentar
            alert_engineer("API key invalid", provider["name"])
            continue

    # Todos los proveedores caídos: caso extremo
    raise AllProvidersDown(errors)

Matices importantes:

1. Capacidades distintas de los modelos: los modelos de distintos proveedores rinden distinto según la tarea (texto, razonamiento, multimodal). El respaldo puede bajar la calidad, y está bien: el cliente recibe un producto que funciona en lugar de un error.

2. Portabilidad de los prompts: tus prompts para Claude pueden funcionar mal en modelos de otro proveedor (otro formato de system prompt, otra reacción a las etiquetas XML). Prueba cada prompt con todos los proveedores de la cadena.

3. Variación de costos: caer en un modelo más caro puede disparar la factura. Pon un tope de presupuesto a cada proveedor por separado.

4. Un modelo local como último recurso: Ollama con un modelo abierto (por ejemplo, de la familia Qwen) en tu Mac o tu VPS. La calidad es menor que la de los modelos en la nube, pero funciona aunque se caiga todo internet. Sirve para rutas críticas donde "alguna respuesta" > "un error".

Respaldo 3-2-1 para tus datos de IA

Un principio clásico de TI, adaptado al stack de IA:

• 3 copias de los datos: producción + respaldo 1 + respaldo 2
• 2 tipos distintos de almacenamiento (evita la corrupción ligada a un solo proveedor)
• 1 copia fuera del sitio (otra región u otra nube)

Qué respaldar y cómo:

Consejo sobre los embeddings: no respaldes los embeddings: ocupan mucho almacenamiento y se pueden recalcular. Respalda los textos crudos + los metadatos; en un desastre recalculas los embeddings en una hora.

Manejo de claves de API

Reglas de almacenamiento:

• ❌ Nunca en el código, ni siquiera de forma temporal
• ❌ Nunca en un .env subido a Git (aunque pienses "luego lo borro")
• ✅ Cloudflare Secrets / Vercel Env / AWS Secrets Manager
• ✅ 1Password CLI para el desarrollo local
• ✅ Revisión con un hook de pre-commit (gitleaks)

Calendario de rotación:

• Mínimo cada trimestre para todas las claves de producción
• De inmediato después de: detectar una filtración, la salida de un empleado, cualquier incidente de seguridad
• Después de una versión grande (si la clave pudo quedar dentro de un artefacto de compilación)

Procedimiento de rotación de emergencia (documentado y probado):

# rotate_all.sh — pseudocódigo
# 1. Genera claves nuevas en el panel de cada proveedor
# 2. Actualiza los secretos en producción
wrangler secret put ANTHROPIC_API_KEY  # Cloudflare Workers
wrangler secret put OPENAI_API_KEY

# 3. Verifica que producción use las nuevas
curl https://api.yoursite.com/health/llm

# 4. Revoca las claves viejas en los paneles de los proveedores (clic manual)

# 5. Log de auditoría: qué se usó entre la filtración y la rotación
# Revisa los logs de uso del proveedor en ese periodo

Este script debe correr en menos de 10 minutos. Se prueba cada trimestre.

Estrategia de varias cuentas:

• Cuenta principal + cuenta de respaldo en cada proveedor crítico
• Métodos de pago distintos (si suspenden la tarjeta principal, la de respaldo funciona)
• Las claves de respaldo ya guardadas en 1Password y probadas (no "algún día lo hago")

Detección de anomalías:

• Gasto diario > 2 veces el promedio → alerta + investigación
• Gasto > tope mensual de presupuesto → pausa automática de la clave de API
• Origen geográfico raro (una solicitud desde un país donde no tienes clientes) → marcar

Plan de respuesta a incidentes: 4 pasos

Cuando algo se rompe, tienes adrenalina, pánico y un montón de impulsos. El plan pone orden.

DETENER (1 a 3 minutos)

• Apaga la función afectada (feature flag → off)
• Evita más daño (si hay corrupción de datos, pausa las escrituras)
• Avisa al equipo: "incidente en curso" (si no estás solo)
• NO empieces a depurar de inmediato: primero detén la hemorragia

CLASIFICAR (5 a 10 minutos)

• ¿Qué pasó? (una falla concreta, no "algo se rompió")
• ¿Cuándo empezó? (la hora exacta en los logs)
• Alcance: ¿qué clientes están afectados? (1 cliente / un segmento / todos)
• Radio de impacto: ¿qué funciones están afectadas?
• Hipótesis de la causa raíz (puedes no saberla con certeza todavía, pero sí la dirección)

ESTABILIZAR (10 a 30 minutos)

• La mejor opción: regresar al despliegue anterior que funcionaba (rollback)
• La segunda: cambiar al proveedor o la función de respaldo
• La tercera: una corrección temporal (un parche rápido, no la solución ideal)
• Comunícate con los clientes (actualiza la página de estado + email si es grave)
• El mensaje del equipo: "el producto funciona, sabemos qué pasó, lo estamos corrigiendo"

ANÁLISIS POSTERIOR (1 a 3 horas, después de estabilizar)

• Análisis de la causa raíz (los 5 porqués o un diagrama de espina de pescado)
• Reconstrucción de la línea de tiempo
• Qué salió bien / qué salió mal / qué hacer distinto
• Acciones: ¿agregar monitoreo? ¿prevención? ¿mejorar el proceso?
• Cultura sin culpables: enfócate en corregir el sistema, no en "quién tuvo la culpa"

Plantillas de comunicación: listas para cuando te caes

En pleno incidente no tienes tiempo de escribir un email bonito. Las plantillas se preparan antes.

Email a clientes durante una caída:

Asunto: [Actualización del servicio] Falla temporal en [función] — Estado

Hola, [cliente]:

Detectamos una falla temporal en [función/servicio] que empezó a las [hora UTC].
El problema está relacionado con [causa general: un problema en una API de terceros, un incidente de infraestructura].

Qué estamos haciendo:
- [la corrección o solución alternativa actual]
- El equipo técnico está trabajando para restablecer el servicio

Tiempo estimado de recuperación: [un tiempo conservador; mejor sobrestimar que no cumplir]
Qué puede hacer ahora: [una alternativa si la hay, o "solo esperar"]

Le enviaremos la siguiente actualización en [30 minutos / 1 hora].
Si necesita ayuda urgente: [contacto].

Una disculpa por las molestias.
[Tu nombre]

Entrada en la página de estado:

[Investigando] Problemas con la API del LLM — 2026-02-15 14:23 UTC
Estamos investigando un aumento de errores en [función]. Parte de las solicitudes termina con error.
Publicaremos actualizaciones.

[Actualización 14:45] Identificado: la causa raíz está relacionada con una caída del proveedor externo.
Activamos el respaldo con el proveedor secundario. Algunos usuarios todavía ven errores.

[Monitoreando 15:10] Respaldo activo. La tasa de errores volvió a lo normal.
Seguimos monitoreando; publicaremos el análisis del incidente en menos de 24 horas.

[Resuelto 16:00] Problema resuelto. Análisis del incidente: [enlace]

Alerta interna en Slack o en tu app de mensajería:

INCIDENTE: [función] degradada
Severidad: [P1 / P2 / P3]
Inicio: [hora]
Responsable: [tu nombre]
Página de estado: [enlace]
Clientes afectados: ~[número] o [segmento]
Acción actual: [estabilizando / investigando / monitoreando]

Esquema de simulacros: probar cada trimestre

Un plan no es plan si nunca se ejecutó. Simulacro trimestral.

T1: Simula que la API de Anthropic está caída

• Bloquea el tráfico de salida hacia api.anthropic.com en el entorno de pruebas (staging)
• Comprueba que el respaldo de OpenAI se active solo
• Mide: tiempo hasta el cambio, impacto en los clientes, tasa de éxito del respaldo
• Documenta las fallas → corrígelas → vuelve a probar

T2: Simula la corrupción de la base de datos

• Toma una copia (snapshot) de la base de datos de pruebas
• Corrompe una tabla a propósito
• Practica la restauración desde el respaldo
• Comprueba la integridad de los datos después de restaurar
• Mide: RTO, RPO, datos perdidos si los hubo

T3: Simula una filtración de clave

• Haz como si ANTHROPIC_API_KEY se hubiera filtrado en Slack
• Ejecuta el procedimiento de rotación de emergencia
• Comprueba que todos los sistemas de producción usen la clave nueva
• Comprueba que la clave vieja esté revocada en el panel del proveedor
• Mide: tiempo total de rotación (meta: menos de 10 min)

T4: Simulación de desastre completo

• Producción caída + proveedor de LLM caído + la cuenta de respaldo no disponible
• Restablece el servicio en infraestructura nueva (una cuenta nueva de Cloudflare, claves nuevas)
• Mide: tiempo de restauración, % de datos conservados, comunicación con clientes enviada

Un simulacro cuesta 4 horas por trimestre. Te ahorrará días cuando llegue un incidente real.

Herramientas para recuperarte de desastres

No es publicidad: son opciones prácticas. Precios y condiciones cambian, así que revísalos en sus sitios (pueden ser distintos de lo que había a octubre de 2026).

El stack mínimo para una pyme: almacenamiento para respaldos + UptimeRobot + Langfuse + Sentry + página de estado. Algunos son gratis; el total depende de los planes que elijas.

El costo del desastre vs. el costo de estar preparado

Un cálculo convencional para un SaaS con $10K de MRR. Las cifras son ilustrativas: no son estadísticas ni un pronóstico; pon las tuyas.

El costo del desastre (sin preparación):

El costo de estar preparado (anual):

En resumen: en este ejemplo convencional, $130 a $280 al mes de "seguro" para un negocio con $10K de MRR = 1.3% a 2.8% del ingreso, mientras que un desastre real sin plan cuesta lo mismo que varios meses de ese seguro.

No es "si conviene". Es más bien "por qué no lo has hecho todavía".

Qué necesitas según tu perfil

Principiante (uso personal, proyectos por hobby):

• ✅ Respaldo en Git de prompts y configuraciones
• ✅ Hook de pre-commit para secretos
• ❌ No necesitas varios proveedores
• ❌ Una página de estado sobra
• Costo: $0/mes

Intermedio (pyme, de $1K a $10K de MRR):

• ✅ Respaldo con varios proveedores (mínimo 2)
• ✅ Respaldo nocturno de los datos de clientes
• ✅ Monitoreo básico (disponibilidad + errores del LLM)
• ✅ Plantillas de comunicación listas
• ✅ 1 simulacro sencillo al año
• Costo: $30 a $50/mes

Profesional (clientes que pagan, de $10K a $50K de MRR):

• ✅ Respaldo 3-2-1 completo
• ✅ Cadena de 3 a 4 proveedores
• ✅ Rotación automática de claves
• ✅ Simulacro trimestral
• ✅ Página de estado pública
• ✅ Cultura de análisis posteriores
• Costo: $100 a $200/mes

Empresa (más de $50K de MRR, contratos con SLA):

• ✅ Despliegue en varias regiones
• ✅ Cambio automático de proveedor
• ✅ Guardias 24/7
• ✅ Respaldos que cumplan SOC 2
• ✅ Capacitación dedicada en respuesta a incidentes
• Costo: más de $500/mes

Antipatrones

❌ Un solo proveedor de LLM en producción: solo Anthropic o solo OpenAI. Cuando se cae, te caes. En 2026, tener varios proveedores es higiene básica, no un lujo.

❌ Respaldos sin probar nunca la restauración: un clásico. El respaldo existe, pero nadie intentó restaurarlo. El día X resulta que el respaldo está dañado o el procedimiento no sirve.

❌ No comunicarte con los clientes durante una caída: el silencio es peor que una mala noticia. El cliente escribe a soporte → recibe una respuesta automática → ve que el producto está caído → no sabe qué pasa → pierde la confianza.

❌ Claves de API en un .env que quedó en el historial de Git: aunque después borres el commit, queda para siempre en el historial de Git. Si alguna vez se subió, considérala filtrada y rótala de inmediato.

❌ Regresar versiones a mano sin un procedimiento documentado: "yo me acuerdo de cómo se hace" funciona con la mente tranquila. En un incidente, con adrenalina a las 2 de la mañana, se te va a olvidar un paso. La documentación = una lista de verificación.

❌ "Eso casi nunca pasa": hasta que pasa una vez y pierdes un contrato empresarial. Probabilidad × impacto, no probabilidad × buenos deseos.

❌ El respaldo en el mismo proveedor que producción: Cloudflare KV como principal + Cloudflare R2 como respaldo. Se cae Cloudflare → ambos inaccesibles. El respaldo debe estar en un proveedor independiente.

❌ Ocultar el incidente a los clientes ("lo arreglamos rápido y nadie se da cuenta"): se van a dar cuenta. Y cuando sepan que lo escondiste, el daño a la confianza será 10 veces mayor que con una explicación honesta.

❌ Confiar en el SLA del proveedor como garantía: el SLA te da un reembolso (a menudo proporcional al tiempo caído), no evita la caída. Un SLA de 99.9% = unas 8.8 horas de caída al año permitidas por contrato (0.1% × 8760 horas).

Lista de preparación

✅ El respaldo con varios proveedores funciona (probado el trimestre pasado) ✅ Respaldos automáticos cada noche ✅ La última prueba de restauración fue hace menos de 90 días ✅ Plantillas de comunicación escritas para los 3 tipos de incidente más comunes ✅ Página de estado configurada y probada ✅ Procedimiento de rotación de emergencia documentado ✅ Todas las claves de API en un gestor de secretos, ninguna en el código ✅ Un hook de pre-commit revisa los secretos ✅ El monitoreo alerta ante picos de errores del LLM ✅ Detección de gasto anómalo activa ✅ Simulacro programado para el próximo trimestre ✅ Plantilla de análisis posterior lista

Si tienes 6 ✅ o menos: estás en zona de riesgo. 9 ✅ o menos: preparación estándar de pyme. 12/12: nivel profesional.

Práctica

Paso 1: Respaldo con varios proveedores en Python

# llm_router.py — un enrutador de respaldo sencillo
import os
import time
from typing import Optional
import anthropic
import openai
from google import genai

class LLMRouter:
    def __init__(self):
        self.anthropic_client = anthropic.Anthropic(
            api_key=os.getenv("ANTHROPIC_API_KEY")
        )
        self.openai_client = openai.OpenAI(
            api_key=os.getenv("OPENAI_API_KEY")
        )
        self.gemini_client = genai.Client(
            api_key=os.getenv("GOOGLE_API_KEY")
        )

        self.providers = [
            # los nombres de modelos son de ejemplo; los vigentes están en la página «Lo vigente»
            ("anthropic", "claude-sonnet-5-5"),
            ("openai", "gpt-6.1-sol"),
            ("gemini", "gemini-3.8-flash"),
        ]

    def call(self, prompt: str, max_tokens: int = 1000) -> dict:
        errors = []

        for provider_name, model in self.providers:
            try:
                start = time.time()
                response = self._call_provider(
                    provider_name, model, prompt, max_tokens
                )
                latency = time.time() - start

                return {
                    "provider": provider_name,
                    "model": model,
                    "text": response,
                    "latency_ms": int(latency * 1000),
                    "fallback_used": provider_name != "anthropic"
                }
            except Exception as e:
                errors.append({
                    "provider": provider_name,
                    "error": str(e),
                    "type": type(e).__name__
                })
                # Registramos la falla para el monitoreo
                print(f"[FAIL] {provider_name}: {e}")
                continue

        raise Exception(f"All providers failed: {errors}")

    def _call_provider(self, name, model, prompt, max_tokens):
        if name == "anthropic":
            r = self.anthropic_client.messages.create(
                model=model,
                max_tokens=max_tokens,
                messages=[{"role": "user", "content": prompt}],
                timeout=10
            )
            return "".join(b.text for b in r.content if b.type == "text")

        elif name == "openai":
            r = self.openai_client.chat.completions.create(
                model=model,
                max_completion_tokens=max_tokens,  # en los modelos GPT-5 y posteriores, en lugar de max_tokens
                messages=[{"role": "user", "content": prompt}],
                timeout=10
            )
            return r.choices[0].message.content

        elif name == "gemini":
            r = self.gemini_client.models.generate_content(
                model=model,
                contents=prompt
            )
            return r.text

# Uso
router = LLMRouter()
result = router.call("Explica qué es la recuperación ante desastres en 3 oraciones")
print(f"Provider used: {result['provider']}")
print(f"Fallback used: {result['fallback_used']}")
print(result['text'])

Paso 2: Script de respaldo para prompts y configuraciones

#!/bin/bash
# backup_ai_stack.sh — respaldo nocturno de la infraestructura de IA

set -e

BACKUP_DIR="/backups/$(date +%Y-%m-%d)"
B2_BUCKET="my-ai-backup"

mkdir -p "$BACKUP_DIR"

# 1. Respaldo de prompts/configuraciones (Git ya los cubre, pero una copia extra)
tar czf "$BACKUP_DIR/prompts.tar.gz" ./prompts ./.claude

# 2. Respaldo de los datos de clientes de Cloudflare D1
wrangler d1 export my-database --remote --output="$BACKUP_DIR/db.sql"

# 3. Respaldo del almacenamiento KV: primero la lista de claves, luego los valores
# (el formato del archivo para kv bulk get está en la documentación de Wrangler)
wrangler kv key list --namespace-id=$KV_ID --remote > "$BACKUP_DIR/kv-keys.json"
wrangler kv bulk get "$BACKUP_DIR/kv-keys.json" --namespace-id=$KV_ID --remote > "$BACKUP_DIR/kv.json"

# 4. Subida a Backblaze B2 (fuera del sitio)
rclone copy "$BACKUP_DIR" "b2:$B2_BUCKET/$(date +%Y-%m-%d)"

# 5. Retención: borrar los respaldos locales de más de 30 días
find /backups -type d -mtime +30 -exec rm -rf {} +

# 6. Verificar la integridad del respaldo
SIZE=$(du -sh "$BACKUP_DIR" | cut -f1)
echo "Backup completed: $BACKUP_DIR ($SIZE)"

# 7. Aviso de éxito o falla
if [ $? -eq 0 ]; then
    echo "Backup OK $(date)" >> /var/log/ai-backup.log
else
    echo "Backup FAILED $(date)" | mail -s "ALERT: Backup failed" admin-notifications
fi

Se programa con cron: 0 3 * * * /scripts/backup_ai_stack.sh

Paso 3: Lista rápida de respuesta a incidentes (imprímela y tenla a la mano)

# RESPUESTA A INCIDENTES — 10 minutos para recuperarte

## DETENER (minuto 0-3)
[ ] Feature flag → off para la función afectada
[ ] Avisar al equipo en Slack: "INCIDENTE en curso, responsable: [yo]"
[ ] Abrir un borrador en la página de estado

## CLASIFICAR (minuto 3-10)
[ ] ¿Qué se rompió? (falla concreta)
[ ] ¿Cuándo empezó? (hora en los logs)
[ ] ¿A quién afecta? (segmento / cantidad)
[ ] Severidad: P1 / P2 / P3
[ ] Hipótesis de la causa raíz (puede no saberse con certeza todavía)

## ESTABILIZAR (minuto 10-30)
[ ] Opción A: regresar al despliegue anterior que funcionaba
[ ] Opción B: activar el respaldo (proveedor, región)
[ ] Opción C: corrección temporal (un parche rápido)
[ ] Actualizar la página de estado: "Investigando" → "Identificado" → "Monitoreando"
[ ] Enviar email a clientes si es P1

## ANÁLISIS POSTERIOR (después de estabilizar, en menos de 48 h)
[ ] Reconstruir la línea de tiempo
[ ] Análisis de los 5 porqués
[ ] Qué salió bien / mal / qué cambiar
[ ] Acciones con responsable y fecha límite
[ ] Actualizar el plan si encontraste un hueco

Paso 4: Prueba tu respaldo (simulacro)

# Simulación de la API de Anthropic caída: bloquear la salida
# En desarrollo local, con /etc/hosts:
echo "127.0.0.1 api.anthropic.com" | sudo tee -a /etc/hosts

# Arranca tu app
python app.py

# Haz una solicitud: debe pasarse a OpenAI/Gemini
curl -X POST http://localhost:8000/api/generate \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Test fallback"}'

# Revisa:
# - ¿Llegó la respuesta? (criterio de éxito)
# - ¿Qué proveedor se usó? (no debe ser anthropic)
# - ¿La latencia es aceptable? (meta: menos de 30 s en total)
# - ¿El log registró la falla + el respaldo? (rastro de auditoría)

# Regresa /etc/hosts a como estaba:
sudo sed -i '' '/api.anthropic.com/d' /etc/hosts

Si esta prueba no funciona en tu entorno de desarrollo, seguro no va a funcionar en un incidente real en producción.

Herramientas y recursos

• Claude Status: la página oficial del estado de Claude y de la API de Anthropic
• OpenAI Status: el estado de los servicios de OpenAI
• Cloudflare Status: el estado global de Cloudflare
• AWS Well-Architected — DR Objectives: el marco de RTO/RPO de AWS
• 3-2-1 Backup Strategy: la explicación del principio, de Backblaze
• Backblaze B2: almacenamiento en la nube compatible con S3
• Statuspage.io: páginas de estado alojadas
• Gitleaks: búsqueda de secretos, código abierto
• Langfuse: observabilidad de LLM, código abierto, con plan gratis en la nube
• UptimeRobot: monitoreo de disponibilidad, plan gratis

Ideas clave

No es "si" se cae tu proveedor de LLM, sino "cuándo". Los grandes proveedores (Anthropic, OpenAI y otros) tienen caídas serias: revisa el historial en sus páginas de estado. Un stack con un solo proveedor = cuestión de tiempo para tu primera caída.

El respaldo 3-2-1 no es paranoia, es higiene. 3 copias, 2 tipos de almacenamiento, 1 fuera del sitio. En el ejemplo convencional de arriba son unas decenas de dólares al mes para una pyme, mientras que un desastre real sin respaldo cuesta miles en ingresos perdidos, clientes perdidos y trabajo de reparación.

Plan + simulacro trimestral > heroísmo improvisado. Un plan escrito de antemano y probado 4 veces al año convierte un incidente de 4 horas en un cambio de 10 minutos. Los pilotos practican la falla de motor no porque pase seguido, sino para saber manejarla cuando pase.

Siguiente lección

→ Bots con la API de Claude. Sobre cómo optimizar el gasto de tu stack de IA: Cost Engineering