# Cómo auditar las decisiones de un agente de IA > Cómo auditar agentes de IA: qué debe registrar la traza, cómo reconstruir un caso, cómo se revisa por muestreo y qué te pedirá un auditor. - Canonical: https://arkatai.com/auditar-decisiones-de-agentes/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: es - Published: 2026-07-19 --- Auditar un agente de IA es poder coger cualquier decisión que tomó, de cualquier semana, y reconstruir qué recibió, qué regla aplicó, qué hizo y quién lo autorizó. Si no puedes hacer eso con un caso concreto en minutos, no tienes un problema de auditoría: tienes un problema de sistema, porque el registro que lo permite se diseña antes de arrancar, no se recupera después. Este artículo explica qué debe guardar esa traza, cómo se revisa sin mirar caso a caso y qué te pedirá un auditor cuando pregunte. ## Qué debe registrar la traza de un agente Una traza útil no es un volcado técnico ilegible, sino el relato reconstruible de cada decisión, escrito para que lo entienda quien tenga que responder por él, que será un directivo o un auditor, no un ingeniero. Para cada acción del agente debería quedar registrado: | Elemento | Qué contesta | |---|---| | Entrada y contexto | Qué recibió el agente y qué información consultó para decidir | | Regla aplicada | Qué criterio del proceso usó y por qué encajaba el caso | | Acción ejecutada | Qué hizo exactamente, sobre qué sistema y con qué resultado | | Escalado o aprobación | Si pasó por una persona, quién y cuándo firmó | | Identidad y momento | Qué agente actuó, con qué credencial y en qué instante | La columna que más se olvida es la regla aplicada. Registrar que el agente hizo algo es fácil; registrar por qué lo hizo, contra qué criterio del proceso, es lo que convierte el log en auditoría. Esta traza la produce la capa técnica que trato en [observabilidad y trazabilidad de agentes](/observabilidad-y-trazabilidad-de-agentes/). Aquí me ocupo de qué se hace con ella cuando toca revisar. ## La prueba de una buena traza: reconstruir un caso cualquiera El examen que aplico es simple. Elijo una acción con consecuencias de hace unos meses (un pago, una nota de crédito, una respuesta a un cliente) y pido que me la expliquen entera: qué documento la originó, qué regla la validó, quién la aprobó si tocaba, qué resultado tuvo. Un sistema bien diseñado devuelve esos elementos en el plazo acordado. Si la respuesta exige que un técnico "interprete los logs" o reconstruya a mano lo que pasó, la traza está incompleta, por muy detallada que parezca. Este examen distingue dos cosas que se confunden: guardar datos y poder auditar. Muchos sistemas guardan cantidades enormes de información y aun así no permiten responder a una pregunta concreta sobre un caso concreto. La medida de una buena traza no es su volumen, es que un caso cualquiera se reconstruya de punta a punta sin arqueología. ## Cómo se revisa: por muestreo, no caso a caso Auditar no es mirar todas las decisiones, algo que ni se puede ni haría falta. Se revisa por muestreo, con una lógica parecida a la de una auditoría de cuentas. Tomas una muestra de casos, la reconstruyes entera y buscas tres cosas: que la regla aplicada fuera la correcta, que los límites se respetaran y que los escalados ocurrieran cuando tocaba. La tasa de muestreo se ajusta al riesgo: más densa en las acciones irreversibles y en los procesos nuevos, más ligera donde meses de historial muestran un comportamiento estable. Lo que buscas no es solo el error suelto, sino el patrón: una regla que falla en cierta clase de casos, un límite que se está rozando demasiado a menudo, escalados que no se disparan cuando deberían. Cada hallazgo se traduce en un ajuste del proceso o de los [permisos y controles del agente](/permisos-y-controles-de-agentes/). La auditoría no es un trámite de cierre, sino el mecanismo por el que el sistema aprende dónde afinar. Y es la evidencia que justifica ampliar la autonomía, porque sin registro revisado cualquier ampliación de permisos es un acto de fe. ## Qué te pedirá un auditor Cuando un auditor, interno o externo, mira un proceso operado por agentes, sus preguntas no son técnicas, sino las de siempre, aplicadas a un actor nuevo. Conviene llegar con la respuesta preparada: - **Quién responde del proceso.** Un nombre, una persona con autoridad para cambiar la regla y para responder por el resultado. El agente es una herramienta, no un sujeto al que trasladar la responsabilidad. - **Un caso reconstruido de punta a punta.** El que ellos elijan, no el que tú prepares. Es la prueba de la sección anterior, y la que más rápido revela si el sistema es auditable de verdad. - **La evidencia de los controles.** Que los límites existieron y se aplicaron: un caso que superó un tope y se escaló, un permiso que el agente no tenía y por eso no ejecutó. - **El registro de cambios.** Cuándo cambió una regla, un permiso o el modelo, quién lo aprobó y qué efecto tuvo. Un agente sin historial de cambios es tan opaco como uno sin traza de decisiones. - **El tratamiento de datos personales.** Qué datos toca el agente y con qué base, un terreno que se solapa con [la IA y la protección de datos](/ia-y-proteccion-de-datos/) y que conviene tener resuelto antes de que lo pregunten. Si tu proveedor no puede enseñarte todo esto sobre un caso cualquiera de la semana pasada, la conversación sobre cumplimiento sobra, porque el problema es anterior. ## Cómo encaja con los permisos, la seguridad y la gobernanza La auditoría es la pata de la evidencia. Los límites que audita se diseñan en los [permisos y controles](/permisos-y-controles-de-agentes/). Las amenazas que la traza permite detectar están en la [seguridad del agente](/seguridad-de-agentes-de-ia/). Y el marco que decide qué se audita, cada cuánto y quién responde es el de la [gobernanza de agentes](/gobernanza-de-agentes/). Si el comité quiere una referencia certificable para ese sistema de gestión, es lo que estandariza la [ISO/IEC 42001](https://www.iso.org/standard/81230.html). Diseñar la traza desde el principio, y no después del primer incidente, es lo que convierte una operación con agentes en algo que un comité serio puede aprobar, y es parte de lo que se ve al [preparar una empresa para agentes](/preparar-tu-empresa-para-agentes/). El contexto completo de qué ejecuta un agente y con qué garantías está en [agentes de IA para empresas](/agentes-de-ia-para-empresas/). ## Preguntas frecuentes ### ¿Puedo auditar un agente si yo no soy técnico? Sí, igual que auditas cuentas sin ser contable: exigiendo el registro y muestreándolo. Pides casos concretos reconstruidos de punta a punta (qué miró el agente, qué regla aplicó, quién revisó los escalados) y verificas que los controles funcionaron. La legibilidad de la traza para una persona sin formación técnica es, de hecho, uno de los requisitos que debes exigir. ### ¿Qué diferencia hay entre guardar logs y poder auditar? Guardar logs es acumular información, y auditar es poder responder a una pregunta concreta sobre un caso concreto. Un sistema puede almacenar cantidades enormes de datos y aun así no permitir reconstruir por qué tomó una decisión. La prueba no es cuánto guarda, sino si un caso cualquiera se reconstruye entero sin trabajo manual. ### ¿Cada cuánto conviene revisar las decisiones de un agente? De forma continua por muestreo, con densidad ajustada al riesgo: más frecuente en acciones irreversibles y procesos recién desplegados, más ligera donde el historial muestra estabilidad. Además, una revisión al completo cada vez que cambia el modelo o una regla importante, porque un cambio puede alterar el comportamiento en casos que antes funcionaban. ### ¿Qué es lo primero que pedirá un auditor? Que le reconstruyas de punta a punta un caso que elija él, y que le digas quién responde del proceso. Con esas dos respuestas se hace una idea inmediata de si el sistema es gobernable. El resto (evidencia de controles, registro de cambios, tratamiento de datos) se apoya en que esas dos primeras existan.