La observabilidad te dice qué se salió de umbral. El triage te dice qué hacer en los siguientes 30 minutos para contener el impacto sin convertir cada ping en un change request improvisado. Este artículo es el complemento práctico del marco de observabilidad de IA en producción: un runbook de respuesta on-call cuando suena una alerta de latencia, calidad, drift o costo.
Si tu equipo ya definió métricas y alertas, pero aún “mira el dashboard y discute”, este checklist baja el ruido a un flujo repetible: clasificar, contener, decidir rollback vs change control, y hacer handoff con evidencia.
Qué es triage de alertas de IA (y qué no es)
El triage no es root-cause analysis completo ni un postmortem. Es una ventana corta —típicamente 30 minutos— para:
- Confirmar que la alerta es real y relevante para el negocio.
- Acotar el blast radius (usuarios, canales, prompts o modelos afectados).
- Aplicar contención segura (throttle, fallback, feature flag o rollback).
- Registrar evidencia suficiente para el owner del servicio y, si aplica, abrir un change control.
En esos 30 minutos evita redeploy a ciegas, editar prompts sin bitácora o cerrar la alerta porque “ya volvió” sin umbral ni owner.
Entrada: del ping a la ficha mínima
Antes de tocar configuración, arma una ficha de 2 minutos con estos campos. Si no los tienes en el alert payload, complétalos a mano:
- Señal: latencia p95/p99, tasa de rechazo humano, score de calidad, drift de embedding/prompt, costo por 1k requests, error rate del proveedor.
- Umbral y ventana: valor actual vs umbral; desde cuándo (5, 15, 60 min).
- Alcance: modelo/prompt/versión, endpoint o flujo, segmento de clientes, canal.
- Cambio reciente: ¿hubo deploy, cambio de prompt, umbral o proveedor en las últimas 24–72 h? (cruza con el log de change control).
- Impacto de negocio: volumen afectado, SLA/SLO, riesgo reputacional o de compliance.
Sin esta ficha, el equipo tiende a “tunear” el síntoma. Con ella, el triage se vuelve auditable —alineado al gobierno post-go.
Severidad en 5 minutos: P1 a P4 para IA
Usa una matriz simple. Ajústala a tu scorecard, pero no inventes severidad en caliente:
- P1 — Contención inmediata: degradación severa en flujo crítico (ventas, soporte regulado, pagos) o costo fuera de control que puede quemar presupuesto en horas. Acción: fallback/rollback + war room corto.
- P2 — Contención en <30 min: calidad o latencia fuera de SLO en un segmento material, con workaround parcial. Acción: throttle o modelo/prompt anterior + ticket de change.
- P3 — Monitoreo activo: drift o costo elevado sin impacto inmediato al cliente. Acción: elevar umbral temporal solo con owner, o plan de ajuste en horario laboral.
- P4 — Señal ruidosa: alerta sin correlación de negocio o falso positivo conocido. Acción: documentar y abrir mejora de alerta (no “silenciar para siempre”).
Regla práctica: si no puedes explicar el impacto en una frase de negocio, aún no tienes severidad —sigue acotando alcance antes de escalar.
Checklist de triage en 30 minutos
Minutos 0–5: confirmar y aislar
- ¿La alerta se reproduce en el dashboard canónico (no solo en el canal de Slack)?
- ¿Afecta a un solo prompt/modelo o a todo el gateway?
- ¿Hay incidente del proveedor LLM o de la capa de embeddings?
- ¿Hay spike de tráfico o de un cliente/batch específico?
Minutos 5–15: contención segura
Elige una contención primaria. Evita apilar tres cambios a la vez:
- Fallback determinístico: respuesta plantilla, cola humana o regla de negocio cuando la IA falla calidad/latencia.
- Rollback de versión: volver al último prompt/modelo “known good” aprobado en change control.
- Throttle / circuit breaker: limitar QPS o desactivar el caso de uso no crítico.
- Feature flag off: apagar la variante nueva y dejar el control.
Documenta qué contención aplicaste, a qué hora (CT) y con qué evidencia. Eso alimenta el postmortem y el ritual del scorecard.
Minutos 15–25: rollback vs change control
- Si el síntoma empezó tras un cambio reciente y el rollback restaura el SLO → rollback ahora, change request después para el fix definitivo.
- Si no hay cambio reciente o el rollback no ayuda → contención + investigación; no “parchees” prompts en caliente sin owner.
- Si el umbral claramente está mal calibrado → no “arregles” el modelo: abre ajuste de alerta/umbral con el owner del servicio (eso también es change).
Minutos 25–30: handoff y cierre del triage
Antes de bajar de severidad o cerrar el canal de incidente, deja este paquete:
- Ficha de alerta + severidad asignada.
- Contención aplicada (sí/no) y estado actual del SLO.
- Hipótesis top 1–2 (proveedor, drift de input, cambio de prompt, datos sucios, costo por retry).
- Owner y siguiente ventana de revisión (ej. en 2 h o al inicio del siguiente turno).
- Enlace al ticket de change o al item del backlog de observabilidad.
Cuatro patrones de alerta y primera respuesta
Latencia: verifica cola, timeouts y retries amplificados. Contención típica: bajar max tokens / usar modelo más rápido en el path crítico / circuit breaker. No subas timeouts “para que deje de fallar” sin medir costo y UX.
Calidad / rechazo humano: muestrea 10–20 casos fallidos. ¿Es un segmento nuevo, un idioma, un intent? Contención: fallback HITL o prompt/modelo anterior. Evita reescribir el system prompt en producción durante el triage.
Drift (input o embedding): compara la última semana vs baseline. Contención: aislar el segmento; el fix estructural (datos/umbrales) va por change control, no como hotfix de 3 minutos.
Costo: revisa retries, contextos largos y loops agenticos. Contención: cap diario, menos tools, apagar agentes no esenciales. Si el costo no tiene owner, el triage se repetirá mañana.
Cómo encaja con observabilidad, change control y gobierno
En el artículo de mediodía cubrimos métricas, diseño de alertas y la idea de runbooks. Aquí el runbook se vuelve ejecutable: severidad, contención y handoff en media hora. El change control sigue siendo la puerta para cambios duraderos de modelos, prompts y umbrales; el triage solo autoriza contenciones temporales y rollbacks a versiones ya aprobadas. El gobierno post-go define quién puede declarar P1 y quién aprueba un ajuste de umbral —sin eso, el on-call improvisará.
Plantilla corta para el canal de incidentes
Copia y completa:
- Alerta: [nombre] | Señal: [valor vs umbral] | Desde: [hora CT]
- Severidad: P[1–4] | Alcance: [flujo / modelo / segmento]
- Cambio reciente: sí/no — [link change]
- Contención: [fallback / rollback / throttle / flag] a las [hora CT]
- Estado SLO: recuperado / degradado / desconocido
- Owner + handoff: [nombre] | siguiente check: [hora]
- Siguiente paso: investigar / change request / mejorar alerta
Cierre
Un stack de observabilidad sin triage es un museo de gráficos. Un triage sin umbrales y ownership es teatro operativo. En 30 minutos puedes pasar del ping a la contención con evidencia, sin romper el proceso de change control. Usa este runbook junto al marco de observabilidad de hoy, y actualízalo después de cada P1/P2 real: el mejor playbook es el que tu equipo ya ejecutó bajo presión.
¿Quieres aterrizar alertas, severidad y runbooks de IA en tu operación? En NextWave ayudamos a equipos mid-market en México y LatAm a pasar de dashboards a respuesta operativa con gobierno. Escríbenos a contacto@nextWaveAI.AI o llama al 33 3126 6969.
Add comment