Por qué cada acción de un agente de IA necesita un registro de auditoría, y qué debe contener

Qué es en realidad una acción de un agente

Una persona que pulsa "cerrar incidencia" realiza una acción. Un agente que cierra una incidencia desencadena una cadena: una persona (o una programación) inició una ejecución del agente, la ejecución llamó a una herramienta, la herramienta comprobó un alcance, el alcance estaba ligado a un token, el token a una persona, y solo entonces cambió el estado de la incidencia. Cualquiera de esos eslabones puede ser el que falló.

Por eso "lo hizo el agente" no es una respuesta. La pregunta que un registro de auditoría debe contestar es: qué ejecución, con el token de quién, llamó a qué herramienta, sobre qué registro y con qué resultado. Si falta cualquiera de esos cinco datos, el registro es un consuelo, no un control.

Por qué un registro de aplicación normal no basta

Casi todos los productos ya registran algo. Los servidores web registran peticiones. Las bases de datos registran cambios. Las herramientas de chat conservan el historial. La tentación es decir que las acciones del agente "están ahí en alguna parte". Tres cosas hacen que eso falle en la práctica:

• La atribución se pierde en la frontera. Una petición de un agente suele llegar como petición del usuario de integración o de la persona cuyo token lleva el agente. El registro de aplicación muestra "Moeid cerró la incidencia 412". No muestra que Moeid estaba comiendo y que lo hizo una ejecución lanzada por una programación nocturna.
• Las lecturas son invisibles. Los registros de aplicación guardan escrituras. Un agente que leyó el valor de todos los tratos y los resumió en un mensaje de chat no dejó rastro de la lectura, y la fuga está en el resumen, no en la base de datos.
• Los registros no son revisables. Un registro que mezcla acciones del agente con diez mil líneas de ruido de peticiones no es algo que un fundador abra un viernes para ver qué hizo el agente esta semana. Si nadie lo lee, no es supervisión.

La guía de Anthropic sobre construcción de agentes lo dice con claridad: prioriza la transparencia mostrando explícitamente los pasos de planificación del agente, haz pausas para recibir opinión humana en puntos de control e incluye condiciones de parada, como un número máximo de iteraciones. El registro de auditoría es la forma en que esa transparencia sobrevive cuando la ejecución ha terminado y la ventana de chat está cerrada.

Qué piden los estándares

Conviene conocer tres documentos, porque definen qué significa "suficiente" y porque los equipos de compras de tus clientes te los citarán.

• OWASP Top 10 para aplicaciones agénticas (2026). Publicado el 9 de diciembre de 2025 por el OWASP GenAI Security Project, con más de 100 colaboradores. El registro insuficiente es uno de los diez riesgos nombrados, junto con la agencia excesiva, el mal uso de herramientas y el envenenamiento de memoria. Las reseñas secundarias no coinciden en la numeración de las categorías, así que cítalo por nombre, no por identificador.
• Ley de IA de la UE, artículo 12. "Los sistemas de IA de alto riesgo permitirán técnicamente el registro automático de acontecimientos (archivos de registro) a lo largo de la vida útil del sistema." El registro debe permitir una trazabilidad "adecuada a la finalidad prevista": detectar situaciones que puedan presentar un riesgo, la vigilancia poscomercialización y la supervisión del funcionamiento. Se aplica desde el 2 de diciembre de 2027 para los sistemas del anexo III y desde el 2 de agosto de 2028 para los del anexo I. El gestor de incidencias de un equipo pequeño no es un sistema de alto riesgo, pero la redacción es una buena definición de para qué sirve un registro.
• Anthropic, "Building effective agents" (diciembre de 2024). No es un estándar, pero sí la guía práctica más citada: transparencia de los pasos de planificación, puntos de control humanos, pruebas en entornos aislados con barreras. Escrita antes de que existiera la mayoría de las herramientas actuales, y sigue siendo correcta.

El hilo común: el registro debe ser automático (no un informe manual a posteriori), continuo (cada acción, no una muestra) y ajustado a su fin (suficiente para reconstruir lo ocurrido, no una copia de todo).

Los cinco campos, y lo único que hay que dejar fuera

Este es el registro que guardamos por cada llamada que hace un agente, y defendemos que es el mínimo para cualquier equipo:

Y lo que hay que dejar fuera: el contenido. Ni el valor del trato, ni el cuerpo de la incidencia, ni el texto del mensaje. Por dos razones. Primera, el registro debe poder mostrarse a cualquiera autorizado a ver el registro; si contiene el contenido, hereda los permisos de todo lo que registra, y acabas sin poder enseñárselo a quien más lo necesita. Segunda, el contenido ya vive en el registro de datos. El id del sujeto apunta a él; su propio historial de versiones muestra qué cambió.

Un registro con herramienta, actor, sujeto, resultado y hora responde a todas las preguntas de este artículo. Uno que además guarda contenido es una segunda copia de tu base de datos con un control de acceso más débil.

Las lecturas importan tanto como las escrituras

El reflejo es registrar solo las escrituras, porque son las que rompen cosas. Los agentes cambian ese cálculo. Un agente con acceso de lectura al CRM puede recibir, en una ventana de chat y de cualquiera con acceso al agente, la petición de listar todos los tratos con su valor. El sistema de permisos del CRM se construyó asumiendo que leer valores de tratos requiere un permiso concreto; si el token del agente lo tiene y la persona que pregunta no, el registro de esa lectura es la única prueba de la fuga.

Nuestra regla: registrar las lecturas con la misma granularidad que las escrituras, pero mantener honesto el campo de resultado. Una lectura rechazada ("refused: crm.value.view") es más útil para un revisor que mil lecturas correctas, porque demuestra que la capa de permisos funciona y muestra quién estaba tanteando.

Los límites de velocidad forman parte de la auditoría

Un registro te dice qué pasó. Un límite impide que lo incorrecto ocurra diez mil veces antes de que alguien lea el registro. Van juntos. Un límite por token de llamadas, y otro más estricto de escrituras, hace que un agente en bucle o un token robado cause un daño acotado, y el registro muestra los 429 como un pico que una persona puede ver.

En Atrix, cada token MCP está limitado a 120 llamadas y 30 escrituras por minuto. Es bajo a propósito: un agente que ayuda a una persona en su jornada nunca se acerca, y un bucle lo alcanza en menos de diez segundos.

Cómo registra Atrix las acciones de los agentes

Atrix AI expone su espacio de trabajo a los agentes mediante un servidor MCP con 85 herramientas tras OAuth 2.1. Cada llamada se audita con exactamente los cinco campos anteriores: herramienta, resultado, tipo e id del sujeto, y el token y la persona detrás. El contenido nunca se escribe en el registro de auditoría. Lo mismo se aplica a las llamadas a través de la API REST, documentada en /developers.

Tres decisiones de diseño hacen la mayor parte del trabajo:

1. Los alcances son estrechos y nunca se amplían. A un token se le conceden alcances concretos (49 son concedibles en octubre de 2026). Un alcance de escritura implica su lectura; nada más se implica. Nueve alcances exigen además el permiso correspondiente en la propia cuenta de la persona, así que un token nunca alcanza más que quien lo creó, y los permisos se comprueban en cada llamada. Revoca el acceso de una persona y todos los tokens que creó pierden alcance en ese instante.
2. Las escrituras que notifican a personas están controladas. Publicar una actualización en el feed es un alcance con nombre propio, nunca implicado por un alcance general de escritura, porque envía notificaciones al teléfono de todos. Un agente no puede heredarlo por accidente.
3. El registro es de la persona, no del agente. La entrada de auditoría nombra el token y a la persona que lo creó. "Lo hizo el agente" se resuelve en un compañero con nombre, responsable de lo que dejó hacer al agente.

Los límites, dichos con claridad: esto es una auditoría de las llamadas hechas a través de MCP y de la API. Atrix no escanea código, no ejecuta análisis estático, y la "auditoría de requisitos" del agente es una comprobación de cobertura frente a una base congelada, no una herramienta de seguridad. El registro de auditoría responde a quién hizo qué en el espacio de trabajo; no evalúa si el razonamiento del agente fue acertado.

Cómo montar la supervisión en un equipo pequeño

No necesitas un equipo de seguridad. Necesitas cinco campos, un hábito semanal y una regla sobre quién puede conectar un agente.

1. Que una persona sea dueña de cada conexión de agente. Nada de usuarios de integración compartidos. Si se crea un token, lo crea una persona con nombre en su propia cuenta, de modo que los permisos que lleva son los suyos y el registro la nombra.
2. Concede primero lectura. Conecta el agente solo con alcances de lectura durante una semana. Lee el registro. Después añade el único alcance de escritura que el agente necesita de verdad.
3. Lee el registro cada semana, filtrado por escrituras y rechazos. Veinte minutos un viernes. Buscas dos cosas: escrituras que no esperabas y rechazos que muestran que alguien pidió más de lo que debía.
4. Mantén las escrituras que notifican bajo un disparador humano. Todo lo que publique para todo el equipo, envíe un correo a un cliente o mueva dinero debe ser un alcance que una persona conceda explícitamente y revise aparte.
5. Pon el límite de velocidad por debajo de lo que una persona podría hacer a mano. Si una persona no podría hacer 30 cambios en un minuto, un agente tampoco debería.
6. Decide la retención antes de necesitarla. Noventa días de entradas cubren casi cualquier pregunta de "qué pasó el mes pasado". Más tiempo está bien si el registro no contiene contenido, una razón más para no meterlo.

Comparación de enfoques de registro de agentes

La transcripción del chat merece una nota. Es tentador tratar el propio resumen del agente ("he movido tres tratos a Ganado") como el registro. Es una declaración de la parte examinada. El registro de auditoría es el independiente.

Preguntas frecuentes

¿Qué debe contener un registro de auditoría de agentes de IA?

Como mínimo: la herramienta llamada, el token y la persona a la que pertenece, el tipo e id del sujeto, el resultado (ok, rechazado, error) y la hora. Deja fuera el contenido; el id del sujeto apunta al registro, y el historial propio del registro guarda el cambio.

¿Hay que registrar las lecturas del agente o solo las escrituras?

Ambas. Un agente puede filtrar datos mediante una lectura que luego resume en el chat, y la lectura es la única prueba. Registra las lecturas con la misma granularidad que las escrituras y presta especial atención a las lecturas rechazadas.

¿Es obligatorio por ley un registro de auditoría de agentes de IA?

Para la mayoría de los equipos pequeños, no. El artículo 12 de la Ley de IA de la UE exige el registro automático de acontecimientos en sistemas de IA de alto riesgo, desde el 2 de diciembre de 2027 para los sistemas del anexo III. Un agente sobre un gestor de incidencias o un CRM no es de alto riesgo. El OWASP Top 10 para aplicaciones agénticas (2026) enumera el registro insuficiente como riesgo con nombre, que es orientación y no ley, pero es lo que citarán los cuestionarios de compras.

¿En qué se diferencia un registro de auditoría del historial de chat del agente?

El historial de chat es la versión del agente sobre lo que hizo, escrita por el agente. El registro de auditoría lo escribe el sistema sobre el que actuó el agente, en el momento de la acción, nombrando el token y la persona. Cuando ambos discrepan, el registro de auditoría tiene razón.

¿Atrix registra el contenido de lo que un agente lee o escribe?

No. Atrix guarda la herramienta, el resultado, el tipo e id del sujeto, y el token y la persona detrás de cada llamada MCP y de API. El contenido nunca se escribe en el registro de auditoría. Los cambios en un registro de datos se ven en su propio historial de versiones.

¿Cuánto tiempo deben conservarse las entradas de auditoría de agentes?

Noventa días responden a casi cualquier pregunta práctica. Como una entrada bien diseñada no contiene contenido, conservarla más tiempo supone poco riesgo; lo que importa más es que alguien la lea cada semana.

Siguiente paso

Si conectas un agente a tu trabajo por primera vez, empieza con alcances de lectura, un único responsable con nombre y una revisión semanal del registro. El agente de Atrix AI funciona dentro de esos mismos límites, y la documentación de MCP enumera cada alcance y qué implica, para que decidas qué conceder antes de concederlo.

Fuentes

Consultadas en octubre de 2026: OWASP Top 10 for Agentic Applications for 2026, Ley de IA de la UE, artículo 12: Registro, Anthropic, Building effective agents.