Error budget agotado: checklist de freeze, rollback y renegociación de SLOs de IA

Es martes, 11:07. El dashboard de error budget del flujo de clasificación B2B pasa de ámbar a rojo: presupuesto agotado. No es un “casi”; la ventana de 28 días ya consumió el margen que producto y operaciones habían negociado. El impulso natural es discutir si el SLO estaba mal calibrado. El impulso correcto es activar un protocolo: freeze, decidir rollback vs hot-fix, y —solo después— renegociar con negocio.

Este texto es el complemento práctico del marco de SLOs y error budget para servicios de IA. No vuelve a definir qué es un SLO. Asume que ya tienes umbrales, ventana y dueños. Aquí el foco es qué hacer cuando el presupuesto se quema en producción.

Señales de burn: qué mirar antes de declarar freeze

Un error budget agotado casi nunca aparece de la noche a la mañana sin avisos. Combina dos señales: el nivel restante (¿cuánto presupuesto queda en la ventana?) y el burn rate (¿a qué velocidad se consume respecto al ritmo “sostenible”?). Una alerta de burn rápido (por ejemplo, 2× o 5× el ritmo que agotaría el presupuesto al cierre de la ventana) debe disparar atención aunque aún quede holgura numérica.

En servicios de IA, el burn suele venir de un cambio reciente (prompt, modelo, umbral, retrieval), de un pico de tráfico con peor mix de casos, o de drift silencioso en calidad. Antes de congelar, confirma en 10–15 minutos: ¿el indicador del SLO está bien calculado?, ¿hay exclusiones mal aplicadas (pruebas, mantenimiento)?, ¿un solo flujo o segmento concentra el gasto? Si la telemetría es dudosa, contén primero y audita el medidor en paralelo —no uses la duda del medidor como excusa para seguir desplegando features.

Checklist de freeze: qué se congela y qué sí se permite

El freeze no es “apagamos la empresa”. Es una política temporal de change control más estricta mientras recuperas presupuesto o renegocias el contrato operativo. Decláralo por escrito (canal on-call + ticket de gobierno) con hora de inicio, dueño y criterio de salida.

Se congela por defecto:

• Cambios de modelo, proveedor o versión mayor/menor no urgentes.
• Ediciones de prompts, system messages, few-shots y plantillas de salida orientadas a features o experimentos.
• Ajustes de umbrales de clasificación, scoring o auto-aprobación que expandan automatización.
• Deploys de features, A/B tests y liberaciones de canary de innovación.
• Ampliación de tráfico a nuevos segmentos, idiomas o canales.

Sí se permite (con doble revisión y registro):

• Hotfixes de seguridad, privacidad o cumplimiento (fuga, jailbreak, PII).
• Rollbacks a versión/prompt/umbral previamente verde.
• Fixes de regresión demostrada que reducen burn (no “mejoras” especulativas).
• Aumentos de muestreo, guardrails más estrictos y degradación controlada documentada.
• Cambios de capacidad/infra estrictamente para estabilidad (timeouts, colas, rate limits) sin alterar la semántica del modelo.

Excepciones al freeze requieren un aprobador explícito (producto + owner técnico del servicio) y una fecha de revisión. Sin eso, el freeze se diluye en “solo este prompt chiquito”.

Rollback vs contención vs renegociación: criterios de decisión

Cuando el presupuesto está en cero, tienes tres caminos. El error más caro es mezclarlos sin orden: renegociar el SLO mientras sigues desplegando, o hacer rollback ciego sin evidencia de causalidad.

• Rollback. Elige si hay un cambio reciente correlacionado (deploy, prompt, umbral, índice) y puedes volver a un artefacto conocido en minutos u horas. Criterio: burn acelerado post-cambio + artefacto previo con baseline estable. No hagas rollback de “todo el mes” sin hipótesis.
• Contención / hot-fix. Elige si no hay un único culpable reversible, o si el rollback empeoraría (dependencias nuevas, datos, contratos). Contén: más HITL, umbrales más conservadores, menos tools, modelo de respaldo, rate limit. El objetivo es frenar el burn, no “innovar bajo presión”.
• Renegociación de SLO. Solo después de estabilizar o cuando la evidencia muestra que el umbral era irreal frente al baseline real de negocio. Renegociar sin freeze previo convierte el error budget en un adorno.

Regla práctica: primero deja de sangrar, después discute el contrato. El runbook de triage cubre la contención inicial; aquí el freeze formaliza que la ventana de innovación se cierra hasta nueva orden.

Ritual de renegociación (30–45 min) con producto y negocio

Agenda mínima, con dueño y decisión al cierre:

1. Hechos (8 min). SLO incumplido, burn rate, ventana, segmento afectado, cambios recientes, impacto en clientes/P&L (reproceso, CSAT, costo).
2. Estado operativo (5 min). ¿Freeze activo? ¿Rollback o contención ya aplicados? ¿Riesgo residual?
3. Opciones (12 min). (A) Mantener SLO y priorizar solo confiabilidad X días; (B) ajustar umbral/ventana con evidencia de baseline; (C) reducir alcance del servicio (menos automatización) hasta recuperar calidad.
4. Decisión y owners (8 min). Qué cambia, quién firma, desde cuándo, cómo se comunica a on-call y a stakeholders.
5. Criterio de salida del freeze (5 min). Ej.: “presupuesto >30% por 7 días rodantes” o “muestreo verde ≥ umbral por N días”.

Trae números, no narrativas. Si negocio pide “relajar el SLO para seguir lanzando”, documenta el riesgo aceptado: más errores visibles, más HITL, o peor experiencia. El error budget existe precisamente para que esa negociación sea explícita.

Plantilla de decisión en 5 bullets

Copia esto al ticket cuando declares presupuesto agotado:

• Declaración: error budget del servicio/flujo [X] agotado a las [hora] CT; freeze de cambios no urgentes activo.
• Causa probable: [cambio / pico / drift / medidor]; evidencia: [enlace a dashboard + diff].
• Acción inmediata: [rollback a rev Y / contención Z / ambos]; ETA de estabilización: [horas].
• Impacto de negocio: [qué no se lanza, qué se degrada, qué clientes ven]; comunicación a [roles].
• Próximo ritual: reunión de renegociación [fecha]; criterio de salida del freeze: [métrica + umbral + duración].

Cierre

Un error budget en cero no es un fracaso del equipo de IA: es el sistema de gobierno haciendo su trabajo. Lo que diferencia a un equipo maduro es la velocidad con la que congela con criterio, elige rollback o contención con evidencia, y renegocia el contrato con negocio sin diluir la señal. Si aún estás armando el marco de SLOs, empieza por el artículo de mediodía; si ya lo tienes, ensaya este checklist en un simulacro de on-call antes del próximo martes a las 11.

En NextWave (de Punto Reactivo) ayudamos a equipos mid-market en México y LatAm a pasar de métricas sueltas a SLOs, error budget y rituales de gobierno que el board entiende. Si quieres revisar el diseño de freeze y renegociación para un flujo concreto, escríbenos en nextwave.mx.