SLOs para servicios de IA: latencia, calidad y error budget en producción

Después de definir métricas, alertas y un runbook de triage, la pregunta de negocio es otra: ¿cuánta degradación podemos tolerar antes de que el servicio deje de cumplir su promesa? Ahí entran los SLOs (Service Level Objectives) y el error budget. No sustituyen la observabilidad de IA en producción ni el triage en 30 minutos; los convierten en un contrato operativo entre producto, datos y operaciones.

Este artículo propone un marco práctico de SLOs para servicios de IA en empresas mid-market de México y LatAm: latencia, calidad y disponibilidad, con un error budget que gobierna cuándo acelerar cambios y cuándo congelar experimentos. El tono es deliberadamente operativo: sin hype, con umbrales que un equipo puede defender en una reunión de gobierno.

Qué es un SLO de IA (y qué no es un KPI de demo)

Un SLO es un objetivo medible del servicio durante un periodo (por ejemplo, 28 o 30 días). Un SLA es el compromiso externo; el SLO es el objetivo interno con el que operas. Un KPI de piloto (“80% de precisión en el set de oro”) no es un SLO hasta que:

• se mide sobre tráfico o muestreo de producción, no solo offline;
• tiene ventana temporal y método de agregación claros;
• dispara decisiones: congelar deploys, priorizar confiabilidad o liberar capacidad para innovación.

En IA conviene separar tres familias de SLO. La primera es de servicio (disponibilidad del endpoint, tasa de error de infraestructura, timeouts). La segunda es de experiencia (latencia percibida por el usuario o por el proceso). La tercera es de calidad de decisión (utilidad, corrección, cumplimiento de política). Mezclarlas en un solo porcentaje “de salud” suele ocultar el fallo real.

Latencia: del p95 del modelo al tiempo de ciclo del proceso

La latencia de inferencia importa, pero el negocio siente el tiempo de ciclo completo: retrieval, herramientas, guardrails, post-proceso y, si aplica, espera en cola humana. Define SLOs en capas:

1. Latencia técnica p95 del camino feliz automatizado (sin HITL), por flujo.
2. Latencia de fallback: cuánto tarda el sistema en devolver una respuesta degradada o en enrutar a humano cuando el modelo falla.
3. Tiempo de ciclo de negocio: desde el trigger (ticket, lead, factura) hasta resolución útil, incluyendo excepciones.

Ejemplo de formulación útil: “En los últimos 28 días, el 95% de las clasificaciones automatizadas del flujo X completan en ≤ 4 s (camino feliz) y el 99% de los fallbacks a cola humana inician en ≤ 15 s”. Evita un único “el modelo responde en 800 ms” si el orquestador añade 6 s de tools.

Ajusta umbrales por franja horaria si tu operación es cíclica. Un p95 aceptable a mediodía puede romper el SLA del contact center en el pico de la tarde. Documenta la fuente (APM, logs del orquestador) y el dueño del indicador junto al change control: un cambio de prompt que alarga el contexto suele ser la causa silenciosa de incumplir latencia.

Calidad: SLOs auditables, no “accuracy” genérico

La calidad de un servicio de IA debe expresarse en lenguaje de proceso. Tres patrones que funcionan en operaciones reales:

• Tasa de aceptación humana. En flujos con revisión, % de salidas aceptadas sin edición mayor en ventana móvil. Útil para copilots y borradores.
• Muestreo con rúbrica. Cada día o semana, N casos (aleatorios + críticos) evaluados con criterios escritos: factualidad, tono, política, completitud. El SLO puede ser “≥ 92% de muestras en verde en 28 días”.
• Outcome de negocio. Resolución en primer contacto, reproceso, tasa de recontacto, o % de clasificaciones que no generan disputa. Conecta con el scorecard de decisiones.

Complementa con un SLO de seguridad/política: tasa de bloqueos correctos, incidentes de contenido o fuga de datos sensibles. Un servicio “rápido y barato” que incumple política no está en verde, aunque la latencia luzca perfecta.

Importante: la calidad offline (set de oro) y online (muestreo) deben poder divergir de forma visible. Si el set de oro está verde y producción se degrada, tienes un problema de representatividad o drift —no solo de “el modelo empeoró”. Ese vínculo ya lo anticipa el marco de observabilidad; el SLO solo formaliza el umbral que dispara gobierno.

Disponibilidad y degradación controlada

Para IA, “disponible” no siempre significa “el modelo principal responde”. Define estados:

• Servicio pleno: modelo/prompt de producción activos, sin throttle anormal.
• Degradado aceptable: modelo de respaldo, menos tools, respuestas más cortas, o más HITL —dentro de un presupuesto de calidad acordado.
• No disponible: el flujo no puede completar ni degradar con seguridad.

Un SLO de disponibilidad puede leerse así: “99.5% de las solicitudes del flujo Y reciben respuesta plena o degradada documentada en ≤ T segundos; menos del 0.1% terminan en error duro sin handoff”. Esto alinea al on-call: el triage busca recuperar el estado pleno o quedar en degradado aceptable, no “apagar y esperar”.

Error budget: la moneda que conecta innovación y confiabilidad

El error budget es la holgura que te queda respecto al SLO. Si tu objetivo de calidad es 95% de muestras en verde en 28 días, el 5% restante es presupuesto de error. Cada incidente, regresión de prompt o pico de latencia “gasta” ese presupuesto.

Reglas de gobierno simples y defendibles:

1. Presupuesto sano (>50% restante). Puedes promover experimentos, A/B y cambios de prompt con el ritmo normal de change control.
2. Presupuesto tenso (20–50%). Prioriza fixes de confiabilidad; limita cambios no esenciales; aumenta muestreo.
3. Presupuesto agotado (<20% o incumplido). Congela cambios de features/prompts no urgentes; solo hotfixes, rollbacks y mejoras de estabilidad. El producto no “pierde” —protege al cliente y al P&L.

El error budget evita discusiones eternas entre “hay que innovar” y “hay que estabilizar”. La decisión se ancla en evidencia del periodo, no en la intuición del último incidente. Enlázalo al ownership del gobierno post-go: quién declara presupuesto agotado y quién autoriza excepción debe estar escrito.

Cómo definir SLOs en dos semanas (checklist)

Si aún no tienes SLOs formales, un camino corto:

1. Elige un flujo. Uno solo: el de mayor impacto o el que ya tiene observabilidad y triage.
2. Lista 3–5 indicadores candidatos (latencia p95, aceptación humana, muestreo verde, disponibilidad degradada, costo por transacción exitosa).
3. Mira 2–4 semanas de baseline real. No inventes un 99.99% si hoy operas al 94%.
4. Escribe la fórmula (numerador, denominador, exclusiones: mantenimiento, tráfico de prueba, ataques).
5. Fija ventana (28 días rodantes es un buen default) y umbral inicial un poco más exigente que el peor percentil reciente, no que el mejor día.
6. Conecta alertas y runbooks a “presupuesto bajo” y a “incumplimiento sostenido”, no solo a picos puntuales.
7. Acuerda en gobierno qué se congela cuando el presupuesto se agota. Sin esa regla, el SLO es decorativo.

Publica cada SLO en una página viva: dueño, fuente de datos, umbral, acciones por banda de error budget, y enlace al change control. Revisa el umbral cada trimestre o tras un cambio mayor de modelo —no cada semana, o el indicador pierde credibilidad.

Anti-patrones que vacían el error budget sin darse cuenta

• Un solo SLO de “accuracy”. Esconde latencia, costo y violaciones de política.
• Umbrales de demo. Copiar el 99% de un whitepaper cuando tu baseline es 91% genera fatiga de alertas o cinismo.
• Ignorar el HITL. Si el fallback satura a las personas, el servicio “disponible” ya falló para el negocio.
• Gastar presupuesto en cambios no versionados. Sin ID de prompt/modelo en logs, no sabrás qué comió el presupuesto.
• Alertar el 100% del tiempo. El triage de ayer ya lo decía: pocas alertas de página, más señales de tendencia ligadas al presupuesto.

Cómo se encaja con observabilidad, triage y change control

La observabilidad provee las señales; el triage decide contención en minutos; el change control autoriza cambios duraderos; el gobierno define ownership. Los SLOs y el error budget son la capa que dice cuánto puedes fallar y cuándo debes priorizar estabilidad sobre novedad. En la práctica:

• Una alerta P2 de latencia alimenta el gasto de presupuesto de latencia.
• Un muestreo en rojo sostenido gasta presupuesto de calidad y puede forzar freeze de prompts.
• Un rollback por triage puede recuperar servicio y “detener el sangrado” del presupuesto, pero el post-análisis sigue el camino de change control.

Si tu equipo ya opera el runbook de 30 minutos, añade una línea al handoff: “estado del error budget (28d): sano / tenso / agotado”. Esa frase alinea al siguiente turno y a producto.

Plantilla mínima de SLO para un servicio de IA

Copia y completa por flujo:

• Servicio / flujo: [nombre] | Owner: [rol]
• SLO latencia: p95 camino feliz ≤ [T] s en [ventana]
• SLO calidad: ≥ [%] muestras en verde (rúbrica) o aceptación humana ≥ [%]
• SLO disponibilidad: ≥ [%] respuestas plenas o degradadas documentadas
• Exclusiones: [mantenimiento, tests, …]
• Error budget: 100% − cumplimiento; bandas sano/tenso/agotado
• Acciones: tenso → [más muestreo / menos cambios]; agotado → [freeze + solo rollbacks/hotfixes]
• Fuentes: [dashboard / logs / muestreo] | Revisión: [cadencia]

Cierre

Un servicio de IA sin SLO opera a pulso: cada incidente reinicia el debate. Con latencia, calidad y disponibilidad explícitas —y un error budget que congela o libera cambios— el equipo deja de discutir opiniones y empieza a administrar riesgo. Usa este marco como complemento del tablero de observabilidad y del triage on-call; luego amárralo al change control para que ningún prompt “urgente” se coma en silencio el presupuesto del mes.

¿Quieres definir SLOs, error budget y gobierno operativo para tus flujos de IA en producción? En NextWave ayudamos a equipos mid-market en México y LatAm a pasar de métricas sueltas a contratos de confiabilidad accionables. Escríbenos a contacto@nextWaveAI.AI o llama al +52 (33) 3126 6969.