Un agente no tiene una sola falla: tiene cuatro modos de continuidad
Por Equipo Quantum Developers
Resumir:
Una alerta que dice “el agente falló” no es un diagnóstico operativo. Si el equipo responde igual cuando cambió el comportamiento del modelo, expiró una credencial, llegó un archivo incompleto o nadie atendió una aprobación, perderá tiempo y puede agravar el incidente. La continuidad de un agente debe separar cuatro modos de falla —modelo, herramienta, datos y operador— porque cada uno exige una contención y una prueba de recuperación distintas.
La distinción no es semántica. Define quién toma el mando, qué se inmoviliza, qué evidencia se conserva y qué puede reanudarse. El NIST AI Risk Management Framework Core recomienda mapear riesgos de todos los componentes, incluidos software y datos de terceros, y diferenciar las responsabilidades humanas en la supervisión. Un playbook único borra justamente esas fronteras.
El triage comienza con una pregunta causal
Antes de reiniciar nada, el responsable debe identificar cuál de estas afirmaciones explica mejor el síntoma:
| Clase | Pregunta de triage | Primer límite de seguridad |
|---|---|---|
| Modelo | ¿La respuesta dejó de cumplir el contrato aunque entradas y herramientas estén sanas? | Detener decisiones no reversibles |
| Herramienta | ¿Falló la lectura o escritura en un sistema externo? | Bloquear reintentos con efectos duplicables |
| Datos | ¿La entrada está ausente, atrasada, mal formada o fuera de alcance? | Poner el lote en cuarentena |
| Operador | ¿La decisión humana, el relevo o la capacidad de atención no están disponibles? | Escalar y congelar vencimientos de alto impacto |
No siempre habrá certeza inmediata. Por eso el evento puede empezar como “no clasificado”, pero debe adquirir una clase antes de autorizar la recuperación. Reiniciar por intuición es peligroso: una herramienta intermitente puede repetir un pago; un dato corrupto puede volver a producir la misma decisión; un modelo degradado puede seguir respondiendo con apariencia convincente.
Playbook 1: falla de modelo
Señales. Aumentan las salidas que violan el esquema, cambia la distribución de razones de decisión, aparecen contradicciones frente a reglas conocidas o una evaluación de control deja de pasar. La indisponibilidad total del proveedor también pertenece aquí, aunque su síntoma parezca técnico.
Contención. Retire al modelo de las acciones materiales, conserve funciones determinísticas y pase a recomendación humana o a una versión aprobada previamente. No cambie simultáneamente prompt, modelo y política: perdería la capacidad de atribuir la causa.
Evidencia. Guarde versión de modelo, configuración, política, entrada sanitizada, salida, validaciones fallidas y correlación con ejecuciones anteriores. La evidencia debe permitir reproducir la evaluación sin copiar datos sensibles innecesarios.
Recuperación. Ejecute el conjunto de pruebas conocido y después observe el candidato en sombra con entradas representativas. El criterio de salida no es “ya responde”; es “vuelve a cumplir el contrato de comportamiento y los límites de decisión”. El dueño es producto o ingeniería de IA, con riesgo y negocio como autorizadores cuando cambia la frontera de acción.
Playbook 2: falla de herramienta
Señales. Tiempo de espera, autenticación rechazada, cuota agotada, respuesta con esquema inesperado, confirmación ausente o diferencia entre lo que el agente solicitó y lo que el sistema registró.
Contención. Abra el circuito para escrituras riesgosas, cambie a solo lectura si aporta valor y envíe solicitudes recuperables a una cola. Antes de reintentar, determine si la operación es idempotente. “No recibí respuesta” no significa “no ocurrió”.
Evidencia. Conserve identificador de solicitud, herramienta y versión, parámetros permitidos, respuesta, estado remoto observado, clave de idempotencia y número de intento. Nunca deje que el diálogo del agente sea el único registro de una escritura.
Recuperación. Verifique credenciales y contrato, haga una prueba sin efecto o en entorno seguro, concilie solicitudes dudosas contra el sistema de registro y solo entonces libere la cola. Integraciones y propietario del sistema externo lideran; el dueño del agente valida que la degradación no cambió el significado de la decisión.
Playbook 3: falla de datos
Señales. Fuente fuera de su ventana de frescura, campos obligatorios vacíos, duplicados, cambio de esquema, identidad que no concilia o volumen incompatible con la cohorte esperada.
Contención. Inmovilice la partición afectada, no todo el servicio, si puede aislarla. Marque como desconocidas las conclusiones derivadas y bloquee acciones que dependan de ellas. Sustituir un dato ausente por cero o por el último valor sin política explícita convierte una falla visible en una decisión falsa.
Evidencia. Registre fuente, versión de esquema, instante de observación, controles de calidad, linaje, objetos afectados y transformaciones ejecutadas. La recuperación debe poder demostrar cuáles decisiones necesitan recalcularse.
Recuperación. Corrija o reimporte, vuelva a validar y reproduzca solo los objetos alcanzados. Después concilie resultados previos y nuevos. El propietario de datos decide cuándo la fuente vuelve a ser confiable; el proceso de negocio decide si las acciones acumuladas siguen siendo oportunas.
Playbook 4: falla de operador
Señales. Cola de aprobación sin dueño, ausencia de relevo, rechazo sin razón, decisión fuera del alcance autorizado o personal que no puede interpretar la evidencia presentada.
Contención. Reasigne según la matriz de escalamiento, detenga acciones irreversibles y preserve las opciones disponibles. No convierta una falta de capacidad humana en aprobación automática: eso elimina el control precisamente cuando se necesita.
Evidencia. Guarde asignación, alcance de autoridad, reconocimiento, decisión, razón, relevo y comunicaciones. El capítulo de gestión de incidentes de Google SRE enfatiza roles separados, un documento vivo y relevos explícitos; esa disciplina es tan útil para una cola de decisiones como para una caída técnica.
Recuperación. Confirme un responsable capaz, entregue contexto, pruebe el relevo y procese primero los casos cuyo vencimiento cambie el resultado. Operaciones de negocio lidera, mientras plataforma garantiza que permisos y evidencia acompañen la reasignación.
Un sobre común de incidente
Los cuatro playbooks deben compartir una ficha mínima: objeto de negocio, impacto, clase de falla, hora de detección, última acción segura, cambios congelados, responsable actual, evidencia enlazada, decisión de recuperación y verificación final. Compartir el sobre permite una vista única sin fingir que todas las reparaciones son iguales.
En Quantum Automation Center, ese sobre puede representarse mediante estado de ejecución, línea de tiempo, artefactos, logs y aprobaciones vinculados al mismo objeto. La documentación de agentes ayuda a separar la actuación del agente de los controles del plano operativo. La plataforma no reemplaza el playbook: hace visible si se ejecutó y quién autorizó la salida.
Practique la continuidad antes del incidente
La guía de AWS sobre Operational Readiness Reviews propone revisar arquitectura, procesos, eventos y calidad antes del lanzamiento, e incorporar lecciones de incidentes. Para un agente, la revisión debería seleccionar un caso de cada clase, simular la señal y pedir al equipo que encuentre evidencia, contenga y recupere sin improvisar privilegios.
El ejercicio no necesita fingir un desastre. Puede retirar temporalmente una herramienta de prueba, enviar un esquema incompatible, bloquear una aprobación o ejecutar una evaluación conocida contra una versión candidata. Lo importante es descubrir si el equipo sabe qué no debe reiniciar.
El contrapunto: cuatro playbooks también pueden estorbar
Un equipo pequeño puede terminar manteniendo documentos largos que nadie consulta. La separación pierde valor si cada playbook repite contactos, severidades y comunicaciones. La respuesta es modular: una ficha común y cuatro tarjetas de decisión, cada una con señales, contención, evidencia, propietario y salida. Si una tarjeta no cambia ninguna acción, elimínela.
Cuándo no usar esta separación completa
Un asistente sin herramientas, memoria persistente ni capacidad de modificar sistemas puede operar con un runbook más simple centrado en disponibilidad y calidad de respuesta. Tampoco use estos playbooks para ocultar que el proceso fuente carece de continuidad: si el ERP está caído, el agente no inventa un plan de recuperación del ERP.
La prueba final es concreta: frente a una alerta, el equipo debe poder nombrar la clase probable, detener el daño compatible con esa clase y demostrar por qué reanudar es seguro. Si solo sabe “reiniciar el agente”, todavía no tiene continuidad operativa.
Sources
Temas del artículo
