Cuando el sistema no falla: SLOs, on-call y el nuevo tipo de incidente que la IA introduce.

Llevamos años perfeccionando cómo respondemos a incidentes. Tenemos runbooks, alertas sobre las cuatro golden signals, error budgets bien definidos, escalados automáticos. El on-call tiene estructura. Sabemos qué significa un 500, un timeout, un spike de p99. Sabemos dónde mirar.

Pero hay un tipo de fallo que ninguna de estas herramientas captura bien: el fallo silencioso de un sistema de IA en producción. Y si tu stack ya tiene LLMs o agentes haciendo trabajo real, es probable que ya los estés sufriendo sin saberlo.

El problema de los SLOs no binarios

Un SLO clásico es binario en su evaluación: la petición fue exitosa o no lo fue. Puedes discutir los criterios, pero el resultado es medible de forma objetiva. Un HTTP 200 con latencia dentro del umbral cuenta como éxito. Un timeout cuenta como fallo. El error budget se consume o no.

Un LLM en producción rompe ese contrato. La petición puede devolver HTTP 200, con latencia razonable, sin ningún error en el trace — y la respuesta puede ser completamente incorrecta. O parcialmente correcta. O correcta hoy e incorrecta mañana ante el mismo input, porque los modelos son no deterministas por naturaleza. ¿Cómo defines el SLO de un sistema donde el "fallo" no tiene stacktrace?

La respuesta que está emergiendo en los equipos más avanzados es redefinir qué significa una "request correcta" para estos sistemas. Esto implica instrumentar evaluaciones en línea: ejecutar un segundo proceso que puntúa la calidad de la respuesta del LLM — usando otro modelo como juez, comparando contra un ground truth, o verificando que el output satisface restricciones conocidas. Esa puntuación se convierte en la señal que alimenta tu SLO. No el HTTP status, sino la calidad semántica de la respuesta.

El error budget, entonces, no se consume cuando el servidor cae — se consume cuando el modelo alucina por encima de un umbral aceptable, cuando el agente invoca una tool con parámetros incorrectos, o cuando el reasoning chain rompe un invariante de negocio. Son métricas nuevas que exigen una instrumentación nueva.

El on-call invisible: cuando lo que falla no genera alerta

Este problema se agudiza en el contexto del on-call. El SRE que está de guardia está entrenado para reaccionar a señales. Pero los fallos de un LLM en producción generalmente no generan señal alguna en los sistemas tradicionales de observabilidad.

ClickHouse publicó hace unos meses un experimento muy honesto: intentaron que varios LLMs — Claude Sonnet 4, GPT-o3, GPT-4.1, Gemini 2.5 Pro — hicieran Root Cause Analysis autónomo sobre incidentes reales en una aplicación instrumentada con OpenTelemetry. Los resultados fueron reveladores. El RCA autónomo no funciona todavía de forma fiable. Ninguno de los modelos, incluyendo GPT-5, superó consistentemente a un SRE humano con acceso a los mismos datos. Los modelos a menudo identificaban síntomas correctos pero fallaban en el salto hacia la causa raíz, especialmente cuando el problema cruzaba múltiples servicios o requería correlacionar señales temporalmente dispersas.

Pero el experimento también expone algo más interesante: el propio LLM que está fallando en producción no va a pedirte ayuda. No lanza una excepción. No incrementa un contador de errores. Simplemente devuelve una respuesta plausible que nadie va a cuestionar hasta que un usuario o un auditor detecte el daño — y en ese momento, tampoco habrá un trace que te diga exactamente dónde y por qué ocurrió.

Qué significa esto operacionalmente

Si tienes LLMs en producción, hay tres cosas que deberías tener ya en tu radar:

Primero, definir los "golden signals" para tus workflows de IA. Latencia y error rate siguen siendo relevantes, pero necesitas añadir métricas de calidad: tasa de alucinaciones detectadas, tasa de refusals inesperados, tasa de invocaciones incorrectas de tools en agentes, drift semántico entre versiones de prompt. Sin estas métricas, tu observabilidad es incompleta.

Segundo, tratar los prompts como configuración crítica. Un cambio de prompt en producción tiene el mismo potencial de impacto que un cambio de configuración en un servicio crítico — pero rara vez pasa por el mismo proceso de revisión ni genera el mismo nivel de alarma cuando degrada el comportamiento del sistema. El versionado de prompts y el registro de cambios deberían estar integrados en tu pipeline de despliegue.

Tercero, asumir que el on-call necesita nuevo contexto. Un SRE que recibe una alerta sobre degradación de calidad en un agente necesita poder ver el trace completo de razonamiento: qué llamadas al LLM se hicieron, con qué contexto, qué tools se invocaron y en qué orden, qué devolvió cada paso. OpenTelemetry está trabajando en las convenciones semánticas para esto, pero el estándar todavía está en construcción. En la práctica, hoy tienes que instrumentarlo manualmente o apoyarte en herramientas como Langfuse, Helicone o el SRE Agent de New Relic para tener algo parecido a visibilidad real.

La trampa del hype

Hay una narrativa muy extendida que dice que la IA va a reemplazar al SRE. Que los agentes van a gestionar el on-call solos. Que el RCA autónomo es cuestión de meses. Los datos disponibles hoy no soportan esa narrativa — al menos no en sistemas complejos y con condiciones de producción reales.

Lo que sí está ocurriendo, y es igualmente relevante, es que la IA está introduciendo una nueva clase de sistema que los SREs tenemos que aprender a operar. Un sistema que falla de maneras que no estábamos preparados para detectar, medir ni depurar. Eso no es una amenaza para la profesión — es el siguiente problema interesante que hay que resolver.

La pregunta no es si la IA va a sustituir al on-call. La pregunta es si tu stack de observabilidad está preparado para cuando el que falla silenciosamente es el propio modelo.