Solución · AI Operations
Tu proveedor de IA se va a caer. La pregunta no es si, es qué hace tu operación esa media hora.
Monitorizar te dice que algo falla. La disponibilidad es lo que hace que el trabajo siga saliendo mientras falla: segunda ruta, modo degradado, colas que aguantan el golpe y un objetivo de recuperación acordado por caso de uso. Montamos esa función y la operamos.
El problema
Tratas a un proveedor externo como si fuera una constante de tu arquitectura.
- Si tu proveedor de modelo tiene media hora mala, tú tienes media hora mala. No hay segunda ruta y nadie ha probado nunca si podría haberla.
- Todos los agentes hablan con el mismo proveedor, con la misma clave y contra la misma cuota. Un pico en el agente de marketing consume el límite del agente que factura.
- Cuando el modelo devuelve error, el proceso no degrada: se para. No hay respuesta parcial, ni cola, ni «esto lo resolvemos en diez minutos»: hay una pantalla en blanco y un cliente esperando.
- Los reintentos, donde existen, son inmediatos y en bucle. Cuando el proveedor está saturado, tu sistema le añade carga y alarga su propia caída.
- Nadie ha escrito cuánto puede estar caído cada caso de uso. El chat de la web y el sistema que emite facturas se tratan igual, y no valen lo mismo ni de lejos.
- Sabes que hubo una incidencia porque lo contó un cliente o porque alguien vio la página de estado del proveedor por casualidad. El aviso llegó por fuera.
- El plan para una caída larga vive en la cabeza de una persona. Si la caída ocurre un viernes por la noche y esa persona está de vacaciones, el plan no existe.
Coste de seguir igual
Has metido en el camino crítico de tu operación a un proveedor externo cuyo estado no controlas, y lo has hecho sin plan B, sin límites y sin acuerdo interno sobre cuánto se puede parar. Eso se paga de tres formas. La primera es directa: cada incidencia del proveedor es una incidencia tuya, con su cola de trabajo atrasado y su cliente enfadado. La segunda es peor porque no se ve: sin aislamiento ni control de cuota, un problema pequeño en un sistema secundario se lleva por delante uno crítico, y el diagnóstico cuesta horas. Y la tercera es de credibilidad: cuando dirección pregunta cuánto puede estar caído esto, la respuesta honesta hoy es «no lo sabemos», y esa respuesta es la que frena el siguiente proyecto de IA.
La solución
Montamos la continuidad como función: segunda ruta, degradación controlada y un objetivo acordado por caso de uso
- 1Empezamos por el acuerdo, no por la arquitectura: qué casos de uso hay en producción, cuánto puede estar caído cada uno sin daño real y qué se hace mientras. Ese objetivo se firma con negocio, no lo decide TI a solas, porque es una decisión de riesgo y de coste —la alta disponibilidad se paga.
- 2Montamos la segunda ruta. Un proveedor alternativo o un modelo alternativo para los casos que lo justifican, con el enrutado preparado y probado, no dibujado en un diagrama. La ruta secundaria puede dar peor calidad: eso se mide de antemano y se decide si compensa, en vez de descubrirlo el día de la caída.
- 3Definimos la degradación controlada, que es la pieza que casi nadie tiene. Qué hace el sistema cuando la IA no está disponible: responder con la parte determinista, encolar y avisar del plazo, pasar a la persona de guardia o devolver una respuesta honesta. Todo antes de la pantalla en blanco.
- 4Ponemos límites y colas con criterio. Cuota y clave separadas por sistema para que un pico no se coma el presupuesto de otro, reintentos con espera creciente en vez de bucles que agravan la caída del proveedor, y una cola que absorbe el golpe y reprocesa cuando vuelve el servicio sin perder trabajo por el camino.
- 5Aislamos los fallos. Un agente que se atasca no debe bloquear el proceso entero: cortacircuitos por dependencia, tiempos máximos por llamada y separación de lo crítico frente a lo accesorio, para que la caída sea de una pieza y no del sistema.
- 6Y lo operamos. Vigilancia del estado de tus proveedores integrada con tus avisos, guardia con manual de incidentes —quién decide cambiar de ruta, cuándo se degrada, cómo se comunica—, y un ensayo periódico: se provoca la caída a propósito y se cronometra la recuperación. Un plan que nunca se ha ejecutado no es un plan.
Lo que cambia
Lo que dejas de perder
Los grandes proveedores de modelos publican página de estado pública con histórico de incidentes y mantenimientos programados. El dato existe y es consultable; lo que falta en casi todas las empresas es que ese dato entre en su propio sistema de avisos en lugar de mirarse a mano cuando algo va mal.
Páginas de estado públicas de los proveedores (p. ej. status.claude.com), consultadas 2026-08
Los acuerdos de nivel de servicio de los planes empresariales de los proveedores compensan con créditos, no con continuidad: recuperas parte de la factura, no las horas de operación parada. La continuidad la tienes que montar tú, en tu lado.
Mecanismo · condiciones estándar de SLA con créditos
La caída deja de ser binaria. Con degradación definida, el sistema pasa de «no funciona» a «funciona peor y lo dice», que es la diferencia entre una incidencia y una crisis.
Mecanismo
El presupuesto y la cuota dejan de ser un recurso común sin dueño: cada sistema tiene su clave y su límite, así que un pico en lo accesorio ya no consume la capacidad de lo crítico.
Mecanismo
Qué medimos: disponibilidad real por caso de uso (no la del proveedor), tiempo de detección y tiempo de recuperación cronometrados en ensayo, % de peticiones servidas por la ruta secundaria durante un incidente, trabajo encolado y reprocesado sin pérdida, y consumo de cuota por sistema frente a su límite.
Qué medimos
Ficha técnica
- Trabajo que elimina
- que una caída del proveedor de IA sea una crisis improvisada —sin segunda ruta, sin modo degradado y sin nadie que sepa cuánto se puede estar parado— y que el aviso llegue por un cliente en vez de por tu propio sistema
- Implementación habitual
- 4–8 semanas
- Entrada
- tus sistemas de IA en producción, sus dependencias de proveedor y modelo, tus colas y tu proceso de incidentes actual
- Salida
- un objetivo de recuperación acordado por caso de uso, segunda ruta probada, degradación definida en vez de pantalla en blanco, colas con reintentos y cuota por sistema, aislamiento de fallos y una guardia con manual e incidentes ensayados
- Compatible con
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralInngestTemporalDatadogPagerDuty
- Puede conectarse con
- Tus proveedores de modelo actuales, sin sustituir a ningunoTu pasarela o router de modelos, si ya lo tienesTu cola de mensajes y tu capa de reintentosTu observabilidad, tus alertas y tu guardia tal como funcionan hoy
- Qué medimos
- disponibilidad real por caso de uso, no la del proveedortiempo de detección y tiempo de recuperación cronometrados en ensayo% de peticiones servidas por la ruta secundaria durante un incidentetrabajo encolado y reprocesado sin pérdida tras una caídaconsumo de cuota por sistema frente a su límite
- Adecuado para
- empresas con IA ya en el camino crítico de una operación real —atención, facturación, logística, back office— donde CIO, COO o Head of AI tienen que responder a cuánto puede estar caído esto y hoy no pueden
- No adecuado para
- quien tiene un piloto interno sin usuarios ni consecuencias —ahí la alta disponibilidad es gasto sin retorno y lo decimos antes de empezar— ni quien busca cambiar de proveedor de modelo por calidad o coste: eso es [elegir y cambiar de modelo en producción](/soluciones/elegir-y-cambiar-de-modelo-de-ia-en-produccion), otra función distinta
Preguntas frecuentes
En que monitorizar responde a «¿qué está pasando?» y disponibilidad responde a «¿y mientras tanto qué?». La monitorización instrumenta, mide y avisa: es la capa de detección y la tienes desarrollada en monitorizar la IA en producción. Sin ella no te enteras, así que es el requisito previo. Pero una alerta no mantiene el trabajo saliendo: eso lo hace la segunda ruta, el modo degradado, la cola que absorbe el golpe y el objetivo de recuperación acordado. Puedes tener un tablero impecable y una operación parada media hora, mirando cómo se pone rojo en tiempo real. La regla práctica: la monitorización te dice cuándo actuar; la disponibilidad decide qué pasa si no actúas a tiempo.
No, y conviene leer qué compra exactamente ese SLA. Los acuerdos de nivel de servicio de los proveedores compensan con créditos sobre la factura cuando no cumplen el objetivo: recuperas dinero, no recuperas las horas en las que tu operación estuvo parada ni los clientes que se fueron. Además, el objetivo se mide sobre el servicio del proveedor, no sobre tu caso de uso: si tu proceso depende de tres llamadas encadenadas más una base de datos, tu disponibilidad real es peor que la de cualquiera de las piezas por separado, y eso ningún contrato lo cubre. El SLA es una garantía comercial; la continuidad es una decisión de arquitectura que se toma en tu lado. Lo que sí hacemos con el SLA es usarlo: sus objetivos y sus preavisos entran en el cálculo de qué necesita segunda ruta y qué no.
Sí, por eso no se duplica todo. La redundancia se aplica solo donde el objetivo acordado con negocio la justifica, y ese acuerdo es el primer paso precisamente para no acabar pagando alta disponibilidad en el chat interno de recursos humanos. En la mayoría de las empresas con las que trabajamos, uno o dos casos de uso justifican segunda ruta y el resto se resuelve mucho más barato: con degradación bien definida y una cola que reprocesa cuando el servicio vuelve. El coste que sí es fijo es el de la disciplina —claves y cuotas separadas, tiempos máximos, cortacircuitos—, y ese se paga una vez y evita la clase de incidencia más cara que existe: la que empieza pequeña en un sistema que no importa y termina tumbando el que factura.
Lo que hayamos decidido antes para ese caso de uso, y esa es la respuesta importante: se decide con anticipación, no en caliente. Los cuatro modos que cubren casi todo son: pasar a la ruta secundaria de forma automática cuando la degradación de calidad es asumible; responder con la parte determinista del proceso y dejar en espera solo lo que necesita el modelo; encolar el trabajo con un plazo comunicado al usuario y reprocesarlo íntegro cuando vuelve el servicio; o escalar a la persona de guardia si el caso es crítico y no admite espera. Cada caso de uso tiene el suyo escrito, con quién lo activa y cómo se comunica. Y se ensaya: provocamos la caída a propósito con una periodicidad acordada y cronometramos la recuperación, porque un manual que nadie ha ejecutado es un documento, no una capacidad.
Lo operamos, porque la disponibilidad no es un entregable: es una función que se degrada sola si nadie la sostiene. Añades un agente y hay que decidir si entra en el alcance; el proveedor cambia sus límites de tasa y hay que reajustar cuotas; sale un modelo nuevo y la ruta secundaria de hace seis meses ya no es la mejor opción; se reorganiza la guardia y el manual se queda con nombres que ya no están. La parte de montaje son las cuatro a ocho semanas iniciales; lo que sigue es la guardia, el mantenimiento de las rutas, la vigilancia del estado de tus proveedores y el ensayo periódico. Si prefieres que lo opere tu equipo, lo montamos, lo documentamos y formamos a la gente —y lo decimos con claridad en la propuesta, sin dejarte atado a nosotros por diseño. El resto del catálogo de esta función está en AI Operations.
¿Lo montamos en tu negocio?
Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.