Auditar una operación de IA: autorización, resultado y estado verificado

Un rastro de auditoría útil no responde solo a “¿qué dijo el modelo?”. Responde quién solicitó la acción, qué autorizó el sistema, qué herramienta se utilizó, qué ocurrió en el sistema de destino y qué estado quedó después de la operación.

Esa distinción es importante. Un prompt completo y su respuesta pueden ayudar en la depuración, pero no sustituyen a un registro operativo. Además, pueden contener datos que nunca deberían copiarse a un sistema de registro.

Comenzar con la pregunta de reconstrucción del incidente

Supongamos que un agente cambió el presupuesto de una campaña o el permiso de un usuario hace dos semanas. Hoy alguien pregunta:

• quién inició el cambio;
• si el operador estaba autorizado a solicitarlo;
• cómo se clasificó la operación;
• si se requería aprobación humana;
• quién aprobó exactamente qué;
• qué parámetros relevantes se pasaron a la herramienta;
• qué devolvió el proveedor externo;
• si se verificó el estado resultante;
• qué versión de la política de seguridad se aplicó.

Si responder a esas preguntas obliga a combinar manualmente el historial de chat, los logs HTTP, una base de datos y la consola del proveedor, entonces tenemos logs. Aún no disponemos de un buen rastro de auditoría.

Registro mínimo de operación para un agente

Cada sistema será distinto. Para agentes que usan herramientas, un núcleo útil incluye:

Campo	Por qué registrarlo
event_id	identificar de forma única el evento
timestamp	orden y momento
operator_id	persona o entidad que solicita la acción
agent_id / agent_version	identificar el agente/modelo involucrado
task_id / correlation_id	conectar múltiples llamadas dentro de un mismo flujo de trabajo
tool	herramienta o método utilizado
operation_class	lectura / escritura / operación / destructiva o equivalente local
target_resource	cuenta, inquilino, proyecto o recurso afectado
authorization_decision	permitir / denegar más alcances/política usada
approval_id	evidencia de aprobación cuando sea requerida
request_fingerprint	huella digital de los parámetros normalizados cuando no se necesita almacenar los datos completos
provider_result	resultado controlado sin secretos
resulting_state	estado leído después del cambio, o referencia a evidencia
policy_version	conjunto de reglas que se aplicó en el momento de la ejecución

No todos los valores deben almacenarse como texto en el mismo registro; algunos pueden referenciar artefactos de evidencia separados. Lo importante es poder reconstruir la cadena de forma coherente.

Los logs de conversación y los rastros de auditoría resuelven problemas diferentes

Un log de conversación brinda contexto

Muestra lo que el usuario pidió, lo que el modelo respondió y qué información estuvo presente en la sesión.

Un rastro de auditoría brinda evidencia de ejecución

Debe mostrar:

operador
→ decisión de autorización
→ herramienta
→ parámetros materiales a la acción
→ aprobación si se requiere
→ resultado del proveedor
→ estado resultante

Si un modelo escribe “la campaña ha sido pausada” pero no hay un evento de herramienta ni una lectura de estado del sistema de destino, solo tenemos una afirmación. No disponemos de evidencia de ejecución.

Qué suele pertenecer a la lista de redacción o exclusión

Más registro no implica automáticamente mejor auditabilidad. Puede significar una superficie de fuga de datos mayor.

En nuestro Brillnet Ads MCP interno, credenciales, encabezados de autorización e identificadores personales sin procesar se excluyen de los registros de auditoría. La misma dirección es útil en otros contextos.

No registrar secretos

• claves API;
• tokens de acceso o refresco;
• claves privadas;
• contraseñas;
• cookies de sesión;
• encabezados Authorization completos.

Si un registro de auditoría necesita indicar qué identidad o conjunto de credenciales se usó, almacene un identificador de referencia seguro en lugar del secreto mismo.

No copiar automáticamente cada solicitud y respuesta

Una respuesta API cruda puede contener datos personales, campos confidenciales o información irrelevante para el propósito de auditoría. Seleccione los metadatos necesarios para la decisión y el estado resultante en lugar de almacenar todo el payload.

No hacer que los prompts completos sean parte obligatoria del registro de auditoría

Los prompts pueden ser útiles para diagnóstico, pero también pueden contener documentos de clientes, datos personales o un secreto pegado por error. La retención de prompts debe regirse por una política separada de retención y acceso de datos, no por la suposición de que “IA significa registrar todo”.

Redactar antes de persistir

Si primero persistimos una carga completa y luego aplicamos el enmascaramiento, el secreto ya habrá ingresado al sistema de registro.

Un flujo más seguro es:

la herramienta devuelve el resultado
↓
normalización
↓
clasificación de campos
↓
redacción / pseudonimización
↓
persistencia del registro de auditoría

Los datos sensibles pueden permanecer en el sistema de origen, que ya posee sus propios controles de acceso y retención. El sistema de auditoría debe retener el mínimo necesario para reconstruir la decisión y el efecto.

Lectura después de escritura cierra la brecha entre “llamado” y “cambiado”

Para operaciones de escritura, registramos no solo el resultado de la llamada sino —cuando el proveedor lo permite— el estado del recurso objetivo leído después del cambio.

Ejemplo:

14:02:11 solicitud de escritura: estado de campaña → PAUSED
14:02:12 proveedor: éxito
14:02:13 lectura después de escritura: campaign.status = PAUSED

Esto permite distinguir:

• el agente solicitó un cambio;
• el proveedor aceptó la solicitud;
• el recurso tenía el estado esperado cuando se verificó.

No prueba que el estado no cambió un segundo después, pero sigue siendo evidencia mucho más fuerte que un mensaje del modelo diciendo “listo”.

La aprobación debe ser un evento de auditoría independiente

La aprobación humana debe tener su propio identificador y vincularse a una operación específica.

Un registro conceptual podría incluir:

approval_id: apr_...
approved_by: operator_...
approved_at: 2026-09-12T14:01:44+02:00
action_hash: sha256(...)
operation: ENABLE_CAMPAIGN
target: campaign_...
expires_at: ...

El ejecutor puede entonces verificar que la aprobación exista para esa versión exacta de la operación, en lugar de confiar en un mensaje de chat que dice “el usuario estuvo de acuerdo”.

Leer: ¿Cuándo debe un agente de IA requerir aprobación humana?

Integridad: registros solo de anexado y encadenamiento de hashes

En nuestra herramienta interna Ads MCP, los registros de auditoría son solo de anexado y están encadenados mediante hashes. El objetivo es que la alteración silenciosa del historial sea más fácil de detectar.

Conceptualmente:

registro_1 + hash(registro_1)
↓
registro_2 contiene hash(registro_1)
↓
registro_3 contiene hash(registro_2)

Si un registro antiguo cambia, los enlaces posteriores ya no coinciden.

Esto no otorga inmutabilidad mágica. Un administrador con acceso suficientemente amplio aún puede destruir el sistema de registro o todo el almacén. Por ello, la integridad del registro debe combinarse con:

• acceso restringido a los logs;
• retención definida;
• copias de seguridad/exportación cuando sea justificado;
• monitorización de huecos o fallos en la cadena;
• control de tiempo e identificadores.

Telemetría útil para herramientas MCP

Para tools/call o una operación local equivalente, los campos útiles suelen incluir:

• nombre de la herramienta;
• categoría de riesgo;
• identificadores de recursos normalizados;
• alcances evaluados;
• resultado de autorización;
• si se mostró una vista previa de la acción;
• identificador de aprobación;
• hora de inicio y fin;
• estado del proveedor;
• código de error controlado;
• si se realizó un reintento;
• clave de idempotencia o una huella segura de la misma;
• estado resultante después de una escritura;
• identificador del modelo/agente en la medida necesaria para diagnóstico.

No se requiere almacenar cada argumento crudo de la herramienta.

¿Qué pasa con el “chain‑of‑thought”?

No necesitamos la cadena de pensamiento privada del modelo para crear un rastro de auditoría operativo útil. Necesitamos hechos observables:

• entrada relevante para la decisión;
• operación seleccionada;
• política aplicada;
• aprobación;
• resultado;
• estado resultante.

Cuando la justificación es útil, el agente puede escribir un breve decision_reason explícito, diseñado para revisión. Eso difiere de intentar preservar el proceso de razonamiento oculto del modelo.

Retención: “para siempre” suele ser una mala opción predeterminada

Para cada clase de evento, defina:

• propósito del procesamiento;
• período de retención;
• quién puede acceder;
• si los datos pueden agregarse o pseudonimizarse;
• cuándo un registro es evidencia empresarial versus telemetría de ingeniería;
• cómo funciona la eliminación legal/operacional cuando sea requerida.

No mantenga la telemetría de depuración y los registros formales de decisión juntos indefinidamente sin una razón.

Ejemplo de reconstrucción de incidente

Situación: una campaña empezó a generar gasto aunque se esperaba que permaneciera pausada.

Un rastro de auditoría útil debería permitir seguir:

1. task_id — de dónde provino la solicitud;
2. operator_id — quién la inició;
3. tool — qué herramienta se seleccionó;
4. operation_class=operate — por qué se aplicó control adicional;
5. approval_id — si alguien aprobó realmente la activación;
6. parámetros — qué estado y presupuesto cubría la aprobación;
7. provider_result — qué aceptó Google Ads;
8. read-after-write — qué estado se observó después de la ejecución;
9. eventos posteriores — si otro actor cambió nuevamente el estado.

Sin esa cadena, solo nos queda leer el historial de chat y adivinar.

Lista de verificación para rastros de auditoría de agentes de IA

• Cada evento material tiene un ID único y marca temporal.
• La identidad del operador y la del agente son distintas.
• Múltiples llamadas pueden unirse mediante un mismo task/correlation ID.
• Las decisiones de autorización se registran, no solo las llamadas exitosas.
• La aprobación es un evento verificable separado.
• Los parámetros materiales al resultado se almacenan o se les genera una huella.
• Los secretos y encabezados de autorización se excluyen antes de la persistencia.
• Los datos personales se minimizan/redactan.
• Los reintentos y la idempotencia son observables.
• Las escrituras incluyen el resultado del proveedor y, cuando sea práctico, evidencia de lectura después de escritura.
• Se puede reconstruir la versión de la política aplicada.
• El acceso a la auditoría es más restringido que el acceso ordinario a la aplicación.
• La retención está definida y no es accidental.
• Se monitoriza la integridad del rastro.

A quién va dirigida esta guía

Los propietarios de procesos y los desarrolladores necesitan evidencia de ejecución. Acciones de ejemplo incluyen cambiar tickets de calidad en fabricación, enviar avisos a propietarios de inmuebles y gestionar accesos de TI. Estos son escenarios de diseño, no afirmaciones de despliegues existentes; el proceso determina la evidencia requerida.

Ads MCP es un ejemplo de diseño interno para cuentas de Brillnet, no un servicio al cliente ni una evaluación de producción independiente.

Un resultado desconocido debe permanecer visiblemente desconocido

Un timeout no prueba fracaso: el servidor pudo haber completado la escritura antes de perder la respuesta. Distinga requested, accepted, verified y unknown. No informe incertidumbre como éxito.

El propietario de la integración define la conciliación usando el identificador de trabajo del proveedor o la referencia del recurso. Involucre al operador antes de repetir acciones de alto impacto sin resolver. Añada un evento de conciliación enlazado en lugar de reescribir la historia.

La visibilidad tardía de escrituras necesita el mismo cuidado. Un estado antiguo puede reflejar el modelo de consistencia del proveedor. Registre la hora de observación y sus limitaciones. Los reintentos deben tener un límite finito y un estado final comprensible para las personas.

Decidir qué ocurre cuando falla la entrega del registro de auditoría

El registro puede perder conectividad, agotarse el espacio en disco o rechazar registros. OWASP recomienda probar fallos. Decida por separado qué acciones consecuentes pueden continuar durante una entrega retrasada y cuáles requieren evidencia de decisión duradera antes de ejecutarse.

No es necesario detener toda la empresa por un mensaje diagnóstico faltante. Separe la telemetría rutinaria de la evidencia de una operación aprobada. Un cambio de permiso puede requerir evidencia de autorización duradera antes de ejecutarse; leer un manual público puede permitir un búfer limitado de metadatos. Estos son ejemplos de decisiones de diseño, no requisitos universales de OWASP.

Un búfer necesita límites de capacidad, controles de acceso y monitorización de retrasos. Preserve los identificadores originales y las marcas temporales durante la recuperación. Rastree eventos perdidos para distinguir inactividad de visibilidad perdida. Envíe una alerta a quien pueda restaurar el registro o suspender la clase de operaciones afectada.

Una huella digital no elimina automáticamente el riesgo de privacidad

Hashear una dirección de correo electrónico aún puede identificar a una persona mediante comparación con una lista corta de direcciones conocidas. Cuando la identificación del operador es importante, considere un identificador interno aleatorio y un mapeo protegido por separado. Los lectores de auditoría no necesitan automáticamente ese mapeo.

Un request_fingerprint también necesita un método de normalización definido y una versión de esquema. Un hash es insuficiente si nadie puede establecer qué cubría. Defina una ubicación segura de evidencia, pero evite retener todo el documento solo para volver a calcular su hash. El propietario del proceso especifica las necesidades probatorias; la persona responsable de protección de datos revisa los datos retenidos.

Reconstruir un evento sin el agente

Utilice un ticket de servicio ficticio. Un operador aprueba el envío de un aviso a un proveedor especificado. El agente elige la herramienta, la puerta de enlace verifica el alcance y el servidor registra el resultado y el identificador del mensaje. En una segunda ejecución, cambie el destinatario después de la aprobación. La ejecución debe ser rechazada con una razón registrada. Use datos de prueba, no documentos reales de clientes.

Entregue el paquete de evidencia a un revisor no involucrado. Él debe poder establecer el operador, el contenido aprobado, el destinatario, la política aplicada y el efecto real. Si necesita preguntar al agente qué pretendía, el paquete está incompleto. Corrija la relación faltante en lugar de registrar automáticamente toda la conversación.

El propietario del proceso posee la aceptación. El desarrollador proporciona exportaciones y errores controlados. El administrador de registro verifica el acceso y la integridad del paquete. Una pequeña empresa puede asignar varias responsabilidades a una sola persona, pero las responsabilidades siguen necesitando dueños explícitos.

Qué hacer mañana

Elija una acción con consecuencias y identifique cada sistema que la registre. Añada un identificador de correlación común. Liste los campos retenidos y los excluidos. Realice una tentativa permitida y una rechazada usando datos de prueba, luego reconstruya ambas a partir de una exportación.

Mida acciones con rastros completos, resultados no resueltos y el retraso entre la acción y la evidencia disponible. Defina umbrales de proceso. El volumen de logs no prueba utilidad: un paso faltante aún requiere investigación.

Recomendaciones técnicas no determinan la retención legal

NIST SP 800‑92 trata la gestión de logs. La familia de controles AU en NIST SP 800‑53 ayuda a organizar requisitos de auditoría; ninguno de los documentos otorga certificación ni establece un período de retención único para todas las empresas. OWASP no es legislación. Identifique obligaciones legales y contractuales por separado, con su alcance y base aplicables. Esta guía no prescribe un período de retención de datos legislado.

Límite

Un rastro de auditoría no prueba automáticamente que una decisión haya sido correcta. Prueba lo que el sistema registró sobre cómo se autorizó y ejecutó la acción. Los procesos regulados pueden requerir requisitos adicionales de integridad, retención, privacidad y calidad probatoria.

Véase también Least privilege for AI agents y Brillnet Security.

Un ensayo sintético de operación financiera

Utilice un entorno de demostración dedicado con una factura ficticia. La operación del agente propuesta cambia el estado de revisión interna de la factura; no mueve dinero. Dar identidades distintas al operador y al agente, restringir el alcance del registro y exigir que la persona adecuada autorice la operación. Registre la versión de la póliza y la decisión, sin almacenar credenciales ni una transcripción completa y confidencial.

Después de la operación permitida, lea el estado de la factura y el historial de cambios relevantes. Compárelos con el resultado solicitado. Una respuesta técnica que diga aceptado no es prueba de que se haya producido el cambio previsto. Conserve el identificador de la solicitud, el resultado y la referencia al estado marcado para que otra persona pueda reconstruir la secuencia.

Luego intente una operación excluida por la política de demostración. Inspeccione el rechazo y confirme que el estado relevante no cambió. Esto demuestra un límite específico en la configuración ficticia. No es prueba de que cada herramienta de agente, sistema financiero o entorno de cliente tenga el mismo control.

Utilice Pulsar para registrar el requisito de control, propietario, acción de ejercicio y evidencia. La prueba de 14 días prueba ese flujo de trabajo de cumplimiento. No incluye una plataforma completa de auditoría de operaciones de agentes, conexión bancaria ni servicio de autorización de pagos. Una integración real o un piloto necesita un alcance acordado por separado. Revise el método de pago requerido de la prueba, el plan seleccionado y los términos de cancelación antes de comenzar.

Fuentes

Las fuentes técnicas respaldan los principios expuestos. Los escenarios de despliegue y el plan de acción son recomendaciones de diseño del autor.

• OWASP AI Agent Security Cheat Sheet — consultado: 2026-10-02.
• OWASP MCP08:2025 — Lack of Audit and Telemetry — consultado: 2026-10-02.
  Fuentes verificadas: 2026-10-10.
• OWASP — Logging Cheat Sheet — Registros de eventos útiles e información confidencial excluida.
• NIST SP 800-92 — Log Management — Gestión de registros.
• NIST SP 800-53 Rev. 5 — Principios de control de acceso y control de auditoría.
• MCP — security best practices — Límites de autorización y seguridad de integración.
• Pulsar GRC — actual scope — Requisitos, controles, pruebas y juicio..
• Alcance del producto publicado y términos de prueba — Alcance del producto publicado y términos de prueba.

Revise los términos y comience la prueba de 14 días

Mínimo privilegio para los agentes de IA en un SaaS multiinquilino

CAPA sobre producción de alimentos: de un hallazgo a una revisión de su eficacia

Se modificó un POE farmacéutico: verifique la versión fuente y de capacitación