Un sistema de IA no está listo para producción por tener un endpoint desplegado. Lo está cuando el ingeniero de guardia puede saber si la calidad se está degradando, qué cambió, de quién es 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 de la demo
La demo suele probar una respuesta exitosa. Producción prueba el borde del sistema durante todo el día:
- Una ruta de retrieval devuelve la fuente equivocada con altísima confianza.
- Un proveedor de modelo se pone lento o cambia de 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 pasa a costar 4× porque usa un modelo frontier donde uno menor pasaría el eval.
- Un usuario pide algo que el sistema debería escalar, no responder.
El monitoreo de uptime de toda la vida no ve casi nada de esto. El endpoint puede estar en verde mientras el producto está equivocado.
La alerta tiene que nombrar el fallo operativo
Un runbook de IA que dice «tasa de error del LLM alta» no sirve. Quien está de guardia necesita saber qué clase de fallo tiene delante.
- Drift de calidad: el eval o la revisión por muestreo cae por debajo de un umbral conocido.
- Fallo de retrieval: el sistema responde desde fuentes débiles, obsoletas o inexistentes.
- Fallo de tool: una tool call va mal formada, lenta, con rate limit o devuelve un schema inesperado.
- Fallo de política: el sistema atiende una petición que debía rechazar o escalar.
- Fallo de costo: una ruta consume tokens por encima del presupuesto escrito para ese workflow.
- Fallo de latencia: el sistema es técnicamente correcto, pero demasiado lento para que el usuario siga dentro del flujo.
Son incidentes distintos. Tienen dueños distintos, rollbacks distintos e impacto distinto. El runbook tiene que separarlos.
Qué va dentro del runbook
Todo handover de IA en producción debería incluir:
- Señales de calidad: umbrales del eval, rutas de revisión por muestreo e indicadores de drift.
- Modos de fallo: fallo de retrieval, respuesta alucinada, output inseguro, tool call mal formada, pico de latencia, pico de costo, caída del proveedor.
- Vías de escalación: cuándo despertar a ingeniería, producto, legal, seguridad o a un revisor humano.
- Instrucciones de rollback: versión de prompt, ruta de modelo, índice de retrieval, feature flag y estado de la migración de datos.
- Límites conocidos: los casos que el sistema no está autorizado a atender.
El objetivo no es anticipar todos los incidentes. El objetivo es que la primera respuesta sea aburrida.
Los primeros quince minutos
En la mayoría de los incidentes de IA, lo primero que se hace no debería ser editar el prompt. Debería ser responder siempre las mismas cinco preguntas:
- ¿El fallo está en el output del modelo, en el retrieval, en la ejecución de tools, en la política, en el costo o en la latencia?
- ¿Cambió hace poco un prompt, una ruta de modelo, un índice de retrieval, un schema de tool o una fuente de datos?
- ¿Hay un feature flag o un rollback para esa ruta?
- ¿Hace falta un revisor humano o el dueño del dominio antes de restablecer el servicio?
- ¿Los ejemplos que fallaron van al set bloqueante, al de monitoreo o al backlog?
La última importa más de lo que parece. Cada incidente es ruido o es entrenamiento para el sistema operativo. El runbook decide cuál de los dos.
La prueba del handover
Antes de irnos de un build, tu equipo tiene que poder operar el sistema en vivo con nosotros mirando por detrás. Si no puede diagnosticar una mala respuesta, volver a ejecutar el eval, identificar al responsable y hacer rollback de la ruta arriesgada, el handover no está terminado. Y un piloto sin un handover operable es exactamente como mueren los proyectos de IA en producción.
La IA en producción no es un prompt. Es una superficie operativa.