Un sistema de IA no está listo para producción porque tenga un endpoint desplegado. Está listo cuando un ingeniero de guardia puede saber si la calidad está degradando, qué cambió, quién es dueño de la decisión y cómo hacer rollback sin esperar al equipo que lo construyó.
Por eso el runbook no es papeleo. Es parte del producto.
Qué se rompe después del demo
El demo suele probar una respuesta exitosa. Producción prueba el borde del sistema todo el día:
- Una ruta de retrieval devuelve la fuente equivocada con alta confianza.
- Un proveedor de modelo se vuelve lento o cambia comportamiento.
- Un cambio de prompt mejora el happy path y rompe los rechazos.
- Un cliente sube datos que los ejemplos originales no cubrían.
- Un flujo empieza a costar 4x porque usa un modelo frontier donde uno menor pasaría la evaluación.
- Un usuario pide algo que el sistema debe escalar, no responder.
El monitoreo común de uptime no detecta la mayor parte de esto. El endpoint puede estar verde mientras el producto está equivocado.
La alerta tiene que nombrar la falla operativa
Un runbook de IA que dice "tasa de error LLM alta" no alcanza. La persona de guardia necesita saber qué tipo de falla tiene enfrente.
- Drift de calidad: la evaluación o la revisión muestreada cae por debajo de un umbral conocido.
- Falla de retrieval: el sistema responde desde fuentes débiles, obsoletas o faltantes.
- Falla de tool: un tool call está mal formado, lento, rate-limited o devuelve un schema inesperado.
- Falla de política: el sistema responde una solicitud que debería rechazar o escalar.
- Falla de costo: una ruta consume tokens fuera del presupuesto escrito para ese workflow.
- Falla de latencia: el sistema es técnicamente correcto pero demasiado lento para que el usuario siga en el flujo.
Son incidentes distintos. Tienen dueños, rollbacks e impacto distinto. El runbook tiene que separarlos.
Qué va en el runbook
Cada handover de IA en producción debería incluir:
- Señales de calidad: umbrales de evaluación, rutas de revisión muestreadas e indicadores de drift.
- Modos de falla: miss de retrieval, respuesta alucinada, output inseguro, tool call mal formado, pico de latencia, pico de costo, caída de proveedor.
- Rutas de escalación: cuándo despertar a ingeniería, producto, legal, seguridad o un revisor humano.
- Instrucciones de rollback: versión de prompt, ruta de modelo, índice de retrieval, feature flag y estado de migración de datos.
- Límites conocidos: los casos que el sistema no está autorizado a manejar.
El objetivo no es predecir cada incidente. El objetivo es que la primera respuesta sea aburrida.
Los primeros quince minutos
En la mayoría de los incidentes de IA, la primera respuesta no debería ser editar el prompt. Debería responder las mismas cinco preguntas cada vez:
- La falla está en output del modelo, retrieval, ejecución de tools, política, costo o latencia.
- Cambió recientemente un prompt, ruta de modelo, índice de retrieval, schema de tool o fuente de datos.
- Existe un feature flag o rollback por ruta.
- Hace falta un revisor humano o dueño de dominio antes de reanudar servicio.
- Los ejemplos fallidos deben entrar al set bloqueante, al set de monitoreo o al backlog.
La última pregunta importa. Cada incidente es ruido o entrenamiento para el sistema operativo. El runbook decide cuál.
La prueba de handover
Antes de irnos de un build, tu equipo debería poder usar el sistema en vivo mientras nosotros estamos detrás. Si no pueden diagnosticar una mala respuesta, volver a correr la evaluación, identificar al owner y hacer rollback de la ruta riesgosa, el handover no está terminado.
La IA en producción no es un prompt. Es una superficie operativa.