Registros de auditoría de agentes de IA: cómo registrar cada acción del chatbot

El 9 de julio, OpenAI agregó llamadas de herramientas programáticas y orquestación multiagente en beta a GPT-5.6. Ese lanzamiento sigue una tendencia más amplia: pasar de respuestas cortas a agentes que trabajan con herramientas durante mucho más tiempo. OpenAI reportó que, para mayo de 2026, el 70.2% de los usuarios de Codex de la muestra había solicitado al menos una tarea que se estimaba le tomaría a una persona más de una hora. Cuantas más acciones haya por tarea, más lugares hay donde la intención, la ejecución y el resultado pueden desalinearse.

Las fallas suelen ser algo cotidiano, no algo malicioso. Tras revisar un millón de tareas de agentes de programación, Google DeepMind encontró que la mayoría de los eventos marcados se debían a malas interpretaciones o a un exceso de iniciativa. Por eso, un registro de auditoría útil para un agente de IA tiene que poder reconstruir cada acción relevante del chatbot, incluidos esos reintentos que parecen inofensivos pero que generan reembolsos, tickets, reservas o correos duplicados.

Empieza con este registro mínimo de eventos. Guarda un evento por cada cambio de estado, agrega eventos nuevos en lugar de sobrescribir los anteriores, y vincula cada evento a la misma traza.

Separa la intención, el intento y el efecto

Una transcripción de chat suele capturar la intención: "Reembólsame mi último pedido". Un registro HTTP captura un intento: POST /refunds. Un procesador de pagos captura el efecto: el reembolso rf_8421 cambió el saldo de la cuenta. Ninguno de esos registros prueba los otros dos.

Trátalos como tres hechos relacionados entre sí:

• Intención registra la solicitud del usuario, la interpretación del agente, la herramienta seleccionada y los parámetros propuestos.
• Intento registra la operación exacta enviada, la decisión de la política, el destino, el tiempo de espera y la clase de respuesta.
• Efecto registra el resultado externo duradero, como un ID de reembolso y su monto, el estado de una reserva o el cambio de estado de un ticket.

Esta separación importa cada vez que una solicitud agota el tiempo de espera. Un tiempo de espera agotado significa que el sistema que hizo la llamada no recibió respuesta, pero el destino puede haber completado la acción de todos modos. Si el registro de auditoría reduce "sin respuesta" a "falló", el chatbot puede reintentar una operación que ya se ejecutó con éxito.

El mismo límite ayuda a definir permisos con más precisión. La lista de verificación de permisos de herramientas para chatbots ayuda a decidir si un bot puede o no invocar una capacidad. El registro de auditoría aporta la evidencia de lo que pasó después de esa decisión.

Dale cuatro ID a cada acción

Un solo ID de conversación no alcanza para sostener una investigación en producción. Una conversación de soporte puede disparar varias acciones, y cada acción puede tener varios intentos.

Usa cuatro identificadores con distintos ciclos de vida:

ID de conversación. Agrupa los mensajes visibles para el usuario. Mantenlo estable durante toda la sesión de chat.

ID de traza. Agrupa el trabajo necesario para completar una solicitud. Una nueva solicitud dentro de la misma conversación debería recibir una traza nueva.

ID de acción. Identifica la operación de negocio que el agente intenta completar, como "reembolsar $48 del pedido 10492". Los reintentos conservan el mismo ID de acción.

ID de intento. Identifica una llamada de red. Cada reintento recibe un nuevo ID de intento, para que los operadores puedan ver cuántas veces lo intentó el sistema.

Propaga el ID de traza y el ID de acción a través de webhooks, colas, servicios conectores y pantallas de aprobación. Si una API de terceros acepta metadatos, inclúyelos ahí también. Un investigador debería poder partir de un mensaje del cliente, de un job fallido o de una transacción externa, y llegar a la misma traza.

Caso resuelto: el reembolso que se ejecutó dos veces

Supongamos que un cliente escribe: "Por favor reembolsa el cobro duplicado de $48 en el pedido 10492." El chatbot encuentra dos pagos capturados, propone reembolsar el más reciente y recibe la aprobación de una persona. La API de pagos procesa el reembolso, pero su respuesta supera un tiempo de espera de 10 segundos. Un worker reintenta la solicitud sin una clave de idempotencia, y crea un segundo reembolso.

El primer intento debería producir un evento append-only como este:

{
  "event_type": "tool.attempt.finished",
  "trace_id": "tr_7f2c",
  "action_id": "act_refund_10492_48usd",
  "attempt_id": "att_01",
  "conversation_id": "conv_5198",
  "actor": {
    "type": "chatbot",
    "id": "billing-support"
  },
  "tool": "payments",
  "operation": "create_refund",
  "decision": "approved",
  "approval_event_id": "apr_6630",
  "input_summary": "Refund $48.00 to payment ending 8812",
  "input_hash": "sha256:4cb3...91e0",
  "idempotency_key": null,
  "result": "timeout_unknown",
  "external_reference": null,
  "occurred_at": "2026-07-15T09:42:18.511Z"
}

El resultado timeout_unknown es la pista clave. El worker debe consultar al procesador usando los identificadores estables de la acción antes de reintentar. Si encuentra el reembolso rf_8421, agrega un evento effect.confirmed y cierra la acción. Si no puede consultar, la acción pasa a revisión en lugar de ejecutarse de nuevo a ciegas.

Ahora imagina que el duplicado ya ocurrió. Una traza completa muestra el mismo ID de acción, dos ID de intento, ninguna clave de idempotencia y dos ID de reembolso externos. La corrección puede registrarse como una acción compensatoria por separado. Los operadores pueden responderle al cliente, los ingenieros pueden corregir el comportamiento de reintento, y el equipo de finanzas puede conciliar el libro contable a partir de la misma evidencia.

Esto también explica por qué los registros de aprobación deben contener más que un simple clic. La guía de flujos de aprobación para chatbots explica cómo mostrar la consecuencia y los parámetros antes de ejecutar. Tu registro de auditoría debería vincular ese payload aprobado con el payload ejecutado mediante un hash canónico.

Haz que reintentar sea aburrido

Los reintentos son normales en los sistemas distribuidos. Las redes se traban, las colas reentregan jobs, los workers se reinician y los proveedores devuelven errores ambiguos. Un diseño seguro asume que cada acción puede intentarse más de una vez.

Genera la clave de idempotencia a partir de la acción de negocio estable, no a partir del intento. Para el reembolso del ejemplo, la clave podría derivarse del ID del tenant, el ID del pago, el monto del reembolso, el motivo y el ID de acción. Cada reintento envía la misma clave. Si cambia el monto o el destino, se convierte en una acción nueva que requiere una nueva decisión.

Luego define las reglas de reintento según el resultado:

• Falla definitiva antes de la aceptación: reintenta automáticamente con la misma acción y la misma clave de idempotencia.
• Tiempo de espera agotado o pérdida de conexión después del envío: consulta el estado primero; reintenta solo cuando el destino demuestre que no existe ningún efecto.
• Falla de validación o de permisos: detente y muestra la corrección específica que se necesita.
• Límite de frecuencia o falla temporal del proveedor: respeta la señal de backoff del proveedor y conserva la misma identidad de la acción.
• Resultado desconocido cuando no se puede consultar el estado: exige revisión para las acciones con consecuencias relevantes.

Registra el motivo que dio el planificador para cada reintento. "Intento 2 iniciado" es una evidencia débil. "Intento 2 iniciado después de que la consulta de estado no encontró un reembolso coincidente" es evidencia revisable.

Vincula las aprobaciones al payload ejecutado

Una aprobación solo es válida para la acción que la persona vio. Si un chatbot pide reembolsar $48 y luego ejecuta $96, la presencia de un evento de aprobación da una falsa sensación de seguridad.

Canonicaliza el payload propuesto, elimina los campos volátiles como las marcas de tiempo, y calcula el hash del resultado. Guarda ese hash junto con la aprobación. Justo antes de ejecutar, vuelve a calcular el hash. Si no coincide, la aprobación debería invalidarse y la propuesta modificada debería volver a quien la aprueba.

Registra estos datos junto con el evento de aprobación:

• identidad y rol de quien aprueba;
• política o regla que exigió la aprobación;
• la consecuencia mostrada, en un formato legible para personas;
• hash canónico del payload;
• vencimiento de la aprobación;
• decisión y motivo opcional;
• ID de traza y de acción.

Conserva también los eventos de rechazo y de vencimiento. Una secuencia append-only muestra si un agente respetó la decisión o intentó un camino distinto después de ser bloqueado.

Redacta sin destruir la evidencia

Los payloads sin procesar de las herramientas pueden contener tokens de acceso, datos de pago, información de salud, mensajes privados e identificadores personales. Copiar todo eso en un registro consultable crea una segunda base de datos sensible.

Usa un registro por capas. Pon un resumen redactado en el evento operativo. Guarda un hash de la entrada canónica para detectar cambios. Si realmente hace falta conservar el payload completo, cífralo en un almacén de evidencia restringido, con un período de retención más corto y controles de acceso separados.

Define la redacción por campo, no solo mediante expresiones regulares. Un token bearer nunca debería entrar al pipeline de eventos. Las direcciones de correo pueden enmascararse en las vistas operativas generales, y seguir disponibles para un grupo reducido de soporte. Las entradas de texto libre necesitan límites de tamaño y detección de secretos, porque los usuarios pegan credenciales en las ventanas de chat.

La privacidad también afecta a los proveedores de observabilidad. Antes de exportar trazas, decide qué campos salen de tu entorno, en qué región se almacenan y si las solicitudes de eliminación se propagan. La guía de seguridad de administración de chatbots cubre los cambios de configuración privilegiados; aplica la misma separación de funciones al acceso a los registros de auditoría y a los cambios de retención.

Convierte las trazas en preguntas operativas

Los paneles deberían responder preguntas concretas, no solo celebrar el volumen de eventos. Empieza con consultas que revelen un daño real al cliente:

• ¿Qué efectos de negocio exitosos vinieron después de una respuesta con tiempo de espera agotado?
• ¿Qué ID de acción produjeron más de una referencia externa?
• ¿Qué hashes de payload aprobado difieren de los hashes de payload ejecutado?
• ¿Qué herramientas tienen la tasa más alta de resultados desconocidos?
• ¿Qué usuarios o tenants disparan más reintentos?
• ¿Qué acciones se completaron después de que venciera una aprobación?
• ¿Qué acciones denegadas fueron seguidas por una acción similar a través de otra herramienta?

Revisa una muestra de trazas normales junto con cada incidente. Los ejemplos normales muestran si el esquema es comprensible antes de que llegue la presión. También revelan transferencias faltantes, etiquetas de resultado engañosas y campos que los equipos daban por hecho que otro servicio registraba.

Para las acciones de bajo riesgo, una revisión diferida puede ser suficiente. La hoja de ruta de control de Google DeepMind hace una distinción similar entre el monitoreo retrospectivo para comportamientos reversibles y el bloqueo en tiempo real para acciones graves. Asigna a cada herramienta un modo de revisión según su consecuencia: muestreo asíncrono, alerta ante anomalías, aprobación antes de ejecutar, o aplicación síncrona de la política.

Prueba el registro de auditoría como una superficie de producto

Un registro de auditoría puede fallar aunque el chatbot parezca estar funcionando bien. Agrega pruebas de lanzamiento que generen deliberadamente estados incómodos:

1. Fuerza un tiempo de espera agotado después de que el destino acepte una acción.
2. Entrega el mismo mensaje de cola dos veces.
3. Cambia un parámetro aprobado antes de la ejecución.
4. Rota una credencial de conector durante una tarea de varios pasos.
5. Devuelve un estado HTTP exitoso con un resultado de negocio rechazado.
6. Ejecuta dos subagentes contra la misma solicitud del cliente.
7. Elimina o enmascara datos de clientes y verifica las reglas de retención en las exportaciones.

Para cada prueba, parte desde tres puntos: la conversación, el job interno y la transacción externa. Los tres deberían llevar a una única traza coherente. Alguien que no haya construido la integración debería poder explicar qué pidió el usuario, qué decidió el agente, qué intentó el sistema y qué cambió realmente.

La descripción de Anthropic sobre agentes confiables enfatiza la transparencia a medida que los agentes planifican, actúan, observan y repiten el ciclo a través de las herramientas. El estándar práctico es una traza que sobreviva a ese ciclo, incluidas las transferencias entre subagentes y las intervenciones humanas.

El comprobante es parte de la acción

La respuesta visible para el cliente, "Tu reembolso está completo", debería generarse a partir de un efecto confirmado, no de la intención del chatbot ni del envío exitoso de una herramienta. La misma referencia externa que ve el equipo de soporte debería aparecer en el comprobante del usuario cuando corresponda.

A medida que las tareas del chatbot se extienden a más herramientas, modelos, workers y aprobaciones, el registro de auditoría de un agente de IA se vuelve parte del contrato de la acción. Le da al cliente un comprobante defendible, y le da al operador un camino desde un resultado inesperado hasta la decisión y el intento exactos que lo produjeron.

En Agentkit, los registros de conversación aportan la capa de revisión legible para personas, y las acciones de API personalizada conectan a los chatbots con los sistemas de negocio; mantén los comprobantes del sistema de registro vinculados junto a esas conversaciones.

Crea tu chatbot gratis →

No se necesita tarjeta de crédito.