Solución · AI Operations
Gestión de incidencias de agentes de IA: la función que responde cuando algo se rompe en producción —triaje, guardia, rollback y postmortem— y no cuando el cliente reclama
Monitorizar detecta que algo va mal; alguien tiene que responder. Sin una función de gestión de incidencias, cada fallo de un agente en producción es una carrera improvisada: nadie sabe quién responde, qué severidad tiene, si se revierte o se aguanta, ni por qué volvió a pasar la semana siguiente. Esto no es apagar un fuego una noche; es la función que corre —severidades, guardia, runbooks, rollback, causa raíz y acciones correctivas— para que un incidente de IA se resuelva rápido y no se repita.
El problema
Cuando un agente falla en producción, nadie sabe quién responde, con qué prioridad ni cómo se cierra para que no vuelva
- El incidente lo resuelve quien estaba mirando, a mano y de memoria: no hay severidades, ni guardia, ni runbook, así que el mismo fallo se responde distinto según quién lo coja.
- La decisión de revertir o aguantar se toma en caliente y sin criterio: a veces se deja un agente roto dando respuestas malas horas, a veces se tira producción entera por un fallo menor.
- No hay causa raíz ni postmortem: se apaga el fuego, se respira y se sigue —hasta que el mismo incidente vuelve la semana que viene porque nadie cerró la acción correctiva.
- El coste del incidente es invisible hasta que es enorme: respuestas malas a clientes, un bucle de agente que dispara la factura, o una acción equivocada sobre un sistema real, sin nadie que mida cuánto tarda en detectarse y en resolverse.
Coste de seguir igual
Un agente en producción sin gestión de incidencias no es que no falle —es que cuando falla, el daño corre libre mientras alguien improvisa la respuesta. La diferencia entre un incidente de diez minutos y uno de dos días no es la suerte: es tener o no la función que responde. Y un incidente que no se cierra con causa raíz no es un incidente, son todos los que vienen: lo que no se aprende, se repite, y cada repetición es la misma factura otra vez —en confianza del cliente, en coste y en el tiempo del equipo que vuelve a apagar el mismo fuego.
La solución
Una función de respuesta a incidentes para tus agentes: severidades, guardia, runbook, rollback y postmortem —montada y operando
- 1Definimos severidades y clasificación: qué es un incidente crítico (un agente que actúa mal sobre un sistema real o dispara el coste) frente a uno menor, para que la respuesta sea proporcional y no dependa de quién lo coja.
- 2Montamos la guardia y el escalado: quién responde, en qué orden y con qué runbook por tipo de incidente —incluido el rollback seguro del agente, el prompt o el modelo a la última versión buena— con el contexto ya recogido de la monitorización.
- 3Cerramos cada incidente con causa raíz y postmortem: qué pasó, por qué, qué acción correctiva evita que vuelva, y quién la tiene. La acción se sigue hasta que está hecha, no hasta que se olvida.
- 4Lo dejamos con cuadro de mando: tiempo hasta detectar, tiempo hasta resolver (MTTR), incidentes por severidad y % de recurrencia. Una función que corre, no un héroe de guardia quemándose.
Lo que cambia
Lo que dejas de perder
El incidente se resuelve por proceso, no por quién estaba mirando: severidad, runbook y guardia hacen que el mismo fallo tenga siempre la misma respuesta rápida.
Mecanismo
El fallo deja de repetirse porque cada incidente se cierra con causa raíz y una acción correctiva con dueño y seguimiento, no con un «ya está, sigamos».
Mecanismo
Qué medimos: tiempo hasta detectar, tiempo hasta resolver (MTTR), incidentes por severidad y % de incidentes recurrentes.
Qué medimos
Ficha técnica
- Trabajo que elimina
- responder a los fallos de los agentes en producción a lo loco, sin severidad, sin runbook y sin cerrar la causa raíz
- Implementación habitual
- 2–4 semanas
- Entrada
- una alerta de la monitorización o un fallo de un agente en producción
- Salida
- incidente triado, respondido por runbook (con rollback si toca) y cerrado con causa raíz y una acción correctiva con dueño
- Compatible con
- PagerDutyOpsgenieJira
- Puede conectarse con
- Tus agentes y sus registros de producciónTu monitorización / observabilidad de IATu gestor de incidencias o ticketingTu canal de alertas y tu guardia
- Qué medimos
- tiempo hasta detectar un incidentetiempo hasta resolver (MTTR)incidentes por severidad% de incidentes recurrentes
- Adecuado para
- empresas con agentes de IA en producción que ya monitorizan pero responden a los incidentes de forma improvisada, sin severidades, guardia ni postmortem
- No adecuado para
- la detección en vivo del problema (eso es la monitorización, aguas arriba) y la decisión de negocio de qué hace el agente, que se queda en tu equipo
Preguntas frecuentes
Son complementarias y consecutivas, no lo mismo. La monitorización es aguas arriba: vigila en vivo latencia, coste, fallos y deriva, y lanza la alerta cuando algo se desvía. La gestión de incidencias es lo que pasa después de esa alerta: quién responde, con qué severidad, qué runbook se sigue, si se hace rollback y cómo se cierra con causa raíz para que no vuelva. Monitorizar sin gestión de incidencias es tener alarmas que nadie sabe atender; gestionar incidencias sin monitorización es responder a ciegas. Se montan juntas y por eso las dos apuntan al paraguas de AI Operations.
Estar atento no es una función; es una persona quemándose y un proceso que se rompe el día que esa persona está de vacaciones. Una función de incidencias real da lo que la buena voluntad no: severidades para que la respuesta sea proporcional, guardia para que siempre haya quién responde, runbooks para que el fallo se resuelva igual lo coja quien lo coja, y postmortem para que se aprenda. La diferencia entre un incidente de diez minutos y uno de dos días no es la atención; es tener el proceso montado antes de que ocurra.
Corre. No te entregamos un PDF de «política de incidencias» y adiós: montamos las severidades, la guardia y el escalado en tu gestor de incidencias, los runbooks de respuesta y el rollback seguro conectados a tus agentes, y el ciclo de postmortem con las acciones correctivas seguidas hasta cerrarse. Y lo dejamos con cuadro de mando —MTTR, incidentes por severidad, recurrencia— para que veas que la función opera, no que existe en un documento. Una función con dueño, no un manual en un cajón.
¿Lo montamos en tu negocio?
Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.