El error visible rara vez es el incidente completo
Un cliente recibe una actualización incorrecta. El agente generó el mensaje, una persona aprobó la excepción y una integración entregó un estado antiguo. Es tentador culpar al modelo o al revisor. Ambas explicaciones pueden contener parte de la verdad, pero ninguna describe el sistema que permitió que el resultado llegara al cliente.
En una squad híbrida, el trabajo pasa por personas, agentes, reglas, herramientas y sistemas empresariales. Un fallo puede comenzar en un componente, atravesar un control débil y hacerse visible en otro. La investigación debe reconstruir el camino completo, incluido lo que cada participante sabía, las opciones disponibles y las señales ausentes en ese momento.
Estabilice la operación antes de buscar un culpable
Primero contenga el impacto. Suspenda la acción afectada, preserve el trabajo pendiente, active un camino manual seguro e identifique la población expuesta. No cambie prompts, políticas e integraciones al mismo tiempo mientras se reúnen evidencias, pues esas modificaciones pueden borrar las condiciones que produjeron el incidente.
Conserve trazas del agente, entradas y salidas de herramientas, versiones de modelo y prompt, aprobaciones, documentos fuente, eventos de sistemas y resultado empresarial. Proteja los datos sensibles y defina quién accede al material. La evidencia debe permitir reconstruir el evento sin convertir la revisión en vigilancia irrestricta de empleados o clientes.
Construya una cronología de trabajo humano y digital
Cree una cronología común con horarios empresariales, no relatos separados para tecnología y operación. Registre cuándo entró la solicitud, qué contexto recuperó el agente, qué herramienta eligió, qué resultado recibió, qué vio la persona, qué decisión tomó y qué llegó al sistema de destino.
OpenAI describe una traza como el registro de punta a punta de llamadas al modelo, herramientas, controles y transferencias. La evaluación de trazas puede asignar etiquetas a partes del camino para analizar corrección y cumplimiento. En una investigación empresarial, combine la traza técnica con decisiones humanas y resultados posteriores, pues una llamada exitosa puede producir un resultado operativo inaceptable.
Separe el detonante de las condiciones contribuyentes
El detonante es el evento que expuso el problema, no necesariamente su causa fundamental. Una solicitud inusual puede activar una acción incorrecta, mientras las condiciones incluyen datos antiguos, política ambigua, permiso excesivo, pantalla de revisión incompleta y una alerta tardía.
Pregunte qué control debía prevenir, detectar o limitar el resultado y por qué no funcionó. Registre también lo que sí funcionó: una persona puede haber detenido parte del flujo, una cola puede haber conservado trabajo o una auditoría puede haber acelerado la recuperación. Comprender las defensas exitosas ayuda a fortalecer el sistema sin reemplazar todo después de un evento.
Evite la culpa sin eliminar la responsabilidad
Google SRE recomienda análisis sin culpa, enfocados en causas contribuyentes en lugar de acusar a individuos. El principio supone que las personas actuaron con la información y las condiciones disponibles. Esto facilita revelar señales débiles, soluciones informales e interfaces confusas que una revisión punitiva ocultaría.
Sin culpa no significa sin responsable. La revisión debe indicar quién decide el retorno del agente, quién corrige registros afectados, quién se comunica con clientes y quién ejecuta cada mejora. Tampoco justifica violaciones deliberadas de políticas. La responsabilidad consiste en reparar la operación y cambiar las condiciones, no en elegir una persona que absorba un fallo sistémico.
Convierta los hallazgos en controles verificables
Una recomendación como capacitar al equipo o mejorar el prompt es demasiado vaga. Prefiera acciones con responsable, plazo, criterio de aceptación y reducción esperada del riesgo. Algunos ejemplos son añadir una regla determinista, mostrar la fecha de la fuente, restringir una herramienta, crear un caso de regresión y alertar cuando una transferencia no incluye evidencias obligatorias.
Divida las acciones entre corrección inmediata, prevención de recurrencia y detección o recuperación más rápida. Añada el escenario a conjuntos de evaluación y ejercicios operativos. El Playbook del AI RMF de NIST recomienda documentar, practicar y medir planes de respuesta, usando eventos de producción para ampliar las condiciones en que el sistema puede fallar de forma segura.
Ejemplo hipotético: retención de un envío
Considere un distribuidor hipotético, que no es un caso de cliente de NM Solutions. Un agente acompaña pedidos y solicita retener un envío cuando el riesgo de crédito supera un límite. Un cliente paga una factura atrasada, pero la integración financiera sigue demorada. El agente ve el saldo anterior, solicita la retención y un analista la confirma porque la pantalla no muestra la fecha del dato.
La revisión reconstruye el pago, la demora de integración, el saldo recuperado, la decisión del agente, la vista del analista y la acción del almacén. El pago fue el cambio empresarial, pero el incidente dependió de varias condiciones: la antigüedad del dato no era visible, el agente podía solicitar una acción relevante y la confirmación no tenía una verificación independiente de vigencia.
La squad corrige el pedido, añade un límite de antigüedad, muestra la fecha de la fuente y exige consulta directa a finanzas antes de confirmar retenciones sobre el umbral. El escenario es hipotético y no demuestra que estos controles sirvan para toda operación de crédito, pero muestra cómo mejorar el flujo completo en vez de culpar a un participante.
Reconozca los límites y mantenga la práctica
Los registros pueden estar incompletos, el comportamiento del modelo puede no ser totalmente reproducible y las personas pueden recordar el mismo momento de forma diferente. Reglas de privacidad o contratos pueden limitar la conservación de evidencias. Una revisión puede encontrar factores plausibles sin probar una causa única. Declare el nivel de confianza y la incertidumbre.
Acompañe modos de fallo repetidos, acciones atrasadas, tiempo para reconstruir eventos, recurrencia y uso real de los controles. Revise acciones importantes después de implantarlas. Un documento de incidente solo crea valor cuando modifica la operación y cuando otros equipos pueden encontrar el aprendizaje.
NM Solutions ayuda a diseñar trazabilidad, análisis de incidentes, evaluación y gobierno para squads híbridas. Un diagnóstico permite identificar dónde desaparecen evidencias entre personas y agentes y qué controles harían más confiables la recuperación y el aprendizaje.