Trazas de Auditoría para Acciones Execute de AI: Qué Registrar y Por Qué

Un sistema de AI emite un reembolso incorrecto a 200 clientes. O actualiza un contrato de proveedor con los términos de pago incorrectos. O enruta un lead de alto valor a un representante que dejó la empresa hace dos meses.

Estas cosas suceden. Cuando ocurren, tres preguntas siguen inmediatamente: ¿Qué pasó? ¿Cuándo pasó? ¿Quién o qué lo autorizó?

Una traza de auditoría es el mecanismo que responde esas preguntas. Sin ella, la investigación post-incidente se convierte en arqueología forense, y sus respuestas a reguladores, clientes y su propio directorio se convierten en conjeturas.

Este artículo trata sobre construir trazas de auditoría que sean realmente útiles, legalmente defendibles y proporcionales al riesgo de las acciones que se registran. Se basa en Clasificación de Datos para Acceso de AI y funciona en conjunto con el Playbook de Respuesta a Incidentes de AI.

La frontera Generate-Execute como línea de gobernanza

Key Facts: Requisitos de Gobernanza para AI Execute

• SOX Section 404 requiere que las organizaciones mantengan registros relevantes para los controles internos sobre los informes financieros durante un mínimo de siete años; los sistemas de AI que influyen o ejecutan transacciones financieras caen dentro de este alcance (orientación de la SEC/PCAOB)
• GDPR Article 33 impone un plazo de notificación de 72 horas desde el momento en que una organización toma conocimiento de una violación de datos personales; las exposiciones de datos causadas por AI activan este reloj inmediatamente al descubrirse, no después de que se complete la investigación (GDPR Article 33)
• Gartner predice que más del 40% de los proyectos de AI agéntica serán cancelados para fines de 2027 principalmente porque los frameworks de gobernanza, incluyendo la infraestructura de auditoría, no han seguido el ritmo de la ambición de despliegue (Gartner, 2025)

La frontera Generate vs. Execute es el concepto más importante en la gobernanza de AI. Cuando la AI produce un artefacto, un borrador de correo, una acción recomendada, un informe, un humano puede revisarlo antes de que algo cambie en el mundo. Eso es Generate. Sin daño si el output es incorrecto. Una persona lo detectará.

Cuando la AI ejecuta una acción directamente, algo real sucede. El dinero sale de una cuenta. Un correo llega a la bandeja de entrada de un cliente. Un registro de CRM se actualiza. Se activa un flujo de trabajo. Eso es Execute. Las consecuencias existen en el mundo ahora, y deshacerlas requiere esfuerzo real.

Los errores de Generate avergüenzan. Los errores de Execute cuestan dinero, dañan la confianza y a veces crean exposición legal.

"Los errores de Generate avergüenzan. Los errores de Execute cuestan dinero. La diferencia entre un sistema de AI que redacta un reembolso incorrecto y uno que lo emite es la diferencia entre una corrección incómoda y un fallo de control financiero. Las trazas de auditoría existen para Execute, no para Generate, porque Execute es donde el mundo real cambia." (Rework)

El Estándar de Auditoría de Acciones Execute

Una especificación estructurada para los campos de trazas de auditoría que hace que las acciones Execute de AI sean legalmente defendibles y operativamente investigables. El estándar requiere siete campos por acción registrada: (1) Disparador (qué inició la acción: automatización programada, instrucción del usuario, evento o decisión autónoma del agente), (2) Versión del modelo y plantilla de prompt (qué modelo y versión se ejecutó, qué prompt produjo el output), (3) Output de AI (qué generó la AI antes de la ejecución, incluyendo razonamiento y puntuaciones de confianza), (4) Acción tomada (detalles específicos: monto, destinatario, ID de registro, sistema), (5) Paso de aprobación humana (quién aprobó, a qué hora, o qué regla de umbral autorizó la ejecución automática), (6) Marca de tiempo UTC y contexto del sistema (entorno, ID de trabajo, versión de la aplicación), (7) Resultado (confirmación del sistema posterior: éxito, fallo, error). Una traza de auditoría que carezca de cualquiera de estos siete campos no puede responder la pregunta "¿qué pasó?" durante una investigación de incidentes.

Las trazas de auditoría existen específicamente para gobernar Execute. No importan mucho para Generate, donde el paso de revisión humana es el mecanismo de responsabilidad. Importan enormemente para Execute, donde la acción sucede antes de la revisión humana, o donde la revisión humana se limita a aprobar una acción en lugar de reconstruir por qué ocurrió.

Qué debe capturar una traza de auditoría de Execute de AI

Una traza de auditoría útil no es solo una marca de tiempo y un ID de acción. Para las acciones Execute de AI, necesita siete campos para tener un registro defendible.

1. El disparador. ¿Qué inició la acción? ¿Fue una automatización programada, una instrucción del usuario, un evento entrante (por ejemplo, llegó un mensaje de cliente) o una decisión autónoma del agente? Conocer el disparador es el primer paso en el análisis de causa raíz cuando algo sale mal.

2. La versión del modelo y la plantilla de prompt. ¿Qué modelo de AI se ejecutó? ¿Qué versión? ¿Qué prompt o plantilla de prompt produjo el output que llevó a esta acción? Las actualizaciones del modelo pueden cambiar el comportamiento sin que nadie lo note. Si su AI empieza a enrutar leads incorrectamente en marzo, necesita saber si la actualización del modelo de marzo cambió algo.

3. El output de AI. ¿Qué generó o decidió realmente la AI antes de la ejecución? Para una acción Execute de reembolso, este es el monto de reembolso recomendado y el razonamiento que proporcionó el modelo. Para una decisión de enrutamiento de lead, esta es la clasificación del modelo y la puntuación de confianza. Este campo le permite distinguir entre "la AI tomó la decisión correcta y la ejecución falló" y "la AI tomó una decisión incorrecta y se ejecutó."

4. La acción tomada. ¿Qué se ejecutó exactamente en el sistema externo? No "emitió reembolso" sino "emitió reembolso de $340 al cliente ID 44821 a través de cargo de Stripe ID ch_xyz en factura INV-2026-04122." La especificidad es la diferencia entre un registro útil y uno inútil.

5. El paso de aprobación humana, si lo hay. ¿Quién aprobó la acción, en qué rol, a qué hora? Si la acción fue aprobada automáticamente bajo una regla de umbral, regístrelo: "aprobado automáticamente bajo regla de umbral: reembolsos inferiores a $500 no requieren revisión humana." Si no ocurrió ninguna revisión humana, regístrelo explícitamente también. La ausencia de aprobación es en sí misma información importante. El framework de Puertas de Aprobación de AI define qué reglas de umbral se requieren para cada nivel de herramienta.

6. La marca de tiempo y el contexto del sistema. Marca de tiempo UTC, versión del sistema, entorno (producción vs. staging) y el ID del trabajo o ejecución del flujo de trabajo. Esto le permite correlacionar su registro de auditoría con sus registros de aplicación al depurar.

7. El resultado. ¿Confirmó el sistema externo la acción? ¿Tuvo éxito, falló o produjo un error? ¿Cuál fue la respuesta del sistema externo? Una traza de auditoría que solo registra las decisiones de AI sin confirmar lo que realmente sucedió en el sistema posterior está incompleta.

Requisitos de retención por contexto regulatorio

Cuánto tiempo necesita guardar estos registros depende de lo que está haciendo la AI y en qué industria.

SOX Section 404 (controles de informes financieros). Si sus sistemas de AI están influyendo, aprobando o ejecutando transacciones financieras o informes financieros, probablemente está en territorio de SOX 404. La orientación de la SEC sobre SOX Section 404 requiere que la gerencia evalúe e informe sobre la efectividad de los controles internos sobre los informes financieros. Los registros relevantes para esos controles deben retenerse durante siete años como mínimo. Para cualquier acción Execute de AI que toque datos financieros, una retención mínima de siete años es prudente, no opcional.

GDPR Article 22 (toma de decisiones automatizadas). GDPR Article 22 prohíbe las decisiones automatizadas que producen efectos legales o significativos sobre los individuos, a menos que la organización haya obtenido consentimiento explícito o la decisión sea necesaria para un contrato. Donde se permiten tales decisiones automatizadas, el Article 22 requiere que los individuos tengan el derecho a revisión humana, el derecho a una explicación y el derecho a impugnar la decisión. Su traza de auditoría para las decisiones de AI que afectan a residentes de la UE debe ser lo suficientemente completa para reconstruir la lógica de cualquier decisión si un interesado solicita una explicación o impugna el resultado. El horizonte práctico de retención para las decisiones relevantes para el GDPR es el plazo de prescripción para reclamaciones en su jurisdicción, típicamente de tres a seis años.

Decisiones empresariales generales. Para las acciones Execute de AI que no son financieras y no involucran decisiones individuales (enrutamiento de tareas internas, actualización de registros internos, activación de flujos de trabajo internos), una retención mínima de tres años es razonable para la mayoría de las industrias.

Salud. HIPAA requiere trazas de auditoría para el acceso a información de salud protegida (PHI). Si los sistemas de AI están accediendo, procesando o tomando decisiones basadas en PHI, se aplican mínimos de retención de seis años bajo los requisitos de mantenimiento de registros de HIPAA.

Opciones de implementación técnica

Tiene tres enfoques principales para la implementación de trazas de auditoría, cada uno con ventajas y desventajas.

Tablas de auditoría de solo adición en su base de datos de aplicación. El enfoque más simple. Cuando cualquier acción Execute de AI se completa, escriba un registro en una tabla de auditoría dedicada con los siete campos anteriores. La tabla es de solo adición: no se permiten operaciones UPDATE o DELETE en las filas de auditoría. Esto es alcanzable con seguridad de fila a nivel de base de datos o controles a nivel de aplicación.

Ventajas y desventajas: económico de implementar, fácil de consultar, pero el mismo equipo que mantiene la aplicación puede modificar el esquema de la base de datos. No es totalmente resistente a la manipulación. Apropiado para la mayoría de los despliegues del mercado medio.

Servicios de registro inmutable. AWS CloudTrail, GCP Cloud Audit Logs, o servicios de registro de auditoría de propósito específico como Datadog o Sumo Logic pueden almacenar registros en formato de escritura única y lectura múltiple. Los registros están firmados criptográficamente; cualquier modificación es detectable. Mejor resistencia a la manipulación que una tabla de base de datos dentro de la aplicación.

Ventajas y desventajas: cuesta más por GB que una base de datos relacional, la capacidad de consulta depende de qué tan bien estructure sus entradas de registro. Mejor para entornos regulados donde la resistencia a la manipulación es un requisito.

Herramientas de auditoría de terceros. Herramientas como Vanta, Drata o plataformas de cumplimiento específicas de la industria pueden ingerir eventos de aplicaciones y mantener evidencia de auditoría. Estas son particularmente útiles si está buscando la certificación SOC 2 Type II o ISO 27001, donde auditores externos evalúan la integridad de las trazas de auditoría.

Ventajas y desventajas: mayor costo, agrega una dependencia del proveedor, pero reduce significativamente la carga interna de cumplimiento. Considérelo si ya está usando una plataforma de automatización de cumplimiento.

Una nota práctica sobre los costos de almacenamiento: una entrada de registro de auditoría bien estructurada para una acción Execute de AI es típicamente de 2 a 5 kilobytes de JSON. A 1.000 acciones Execute por día, eso es aproximadamente de 2 a 5 GB por año antes de la compresión. Para la mayoría de los despliegues del mercado medio, el costo de almacenamiento no es la restricción. La restricción es el diseño del esquema y garantizar que los registros sean realmente consultables cuando los necesite.

La clasificación de la puerta de revisión humana

No todas las acciones Execute necesitan aprobación humana antes de ejecutarse. Requerir revisión humana de cada actualización de campo de CRM o de cada creación de tarea interna crea parálisis, no gobernanza.

La decisión sobre qué acciones Execute requieren aprobación humana antes de la ejecución (en lugar de revisión de auditoría posterior) debe ser explícita y documentada.

Una clasificación práctica:

Siempre requieren aprobación humana antes de la ejecución:

• Comunicaciones orientadas al cliente (correo electrónico, SMS, notificaciones de aplicaciones)
• Transacciones financieras por encima de un umbral definido
• Decisiones de personal (cualquier decisión generada por AI que afecte la contratación, compensación o despido)
• Modificaciones de contratos o documentos legales
• Eliminaciones de cualquier tipo

Usar reglas de umbral con revisión de auditoría posterior:

• Transacciones financieras por debajo del umbral (por ejemplo, reembolsos inferiores a $100 aprobados automáticamente)
• Actualizaciones de etapa de CRM basadas en puntuación de AI
• Decisiones internas de enrutamiento y asignación

Ejecución automática con solo registro:

• Creación de tareas internas
• Eventos de calendario internos
• Actualizaciones de estado en registros internos
• Notificaciones internas no orientadas al cliente en canales internos

El punto es que la clasificación debe estar escrita y aplicada en la configuración del sistema, no dejada implícita. "Decidimos aprobar automáticamente los reembolsos pequeños" no es una política de gobernanza. "Los reembolsos inferiores a $100 a clientes con antigüedad de cuenta mayor a 90 días se aprueban automáticamente bajo la regla de umbral T-2026-03, revisada trimestralmente por el equipo de Operaciones Financieras" es una política de gobernanza.

Documente las reglas de umbral en el mismo lugar que la documentación de su traza de auditoría. Cuando un regulador pregunte por qué se tomó una decisión automatizada específica sin revisión humana, quiere poder señalar la regla, la aprobación de esa regla y la evidencia de que estaba funcionando según lo previsto.

La traza de auditoría como evidencia regulatoria

Si está en una industria regulada, la traza de auditoría es la evidencia que presenta cuando un regulador, auditor o cliente pregunta "qué pasó."

Para SOX 404, la pregunta es: ¿puede demostrar que sus controles internos sobre los informes financieros están diseñados y funcionan efectivamente? Si los sistemas de AI toman o influyen en decisiones financieras, su traza de auditoría es parte de la evidencia de controles efectivos. Un sistema de AI que aprobó 40.000 facturas de proveedores el año pasado, sin una traza de auditoría que muestre cuáles fueron aprobadas automáticamente y cuáles se marcaron para revisión humana, es una deficiencia de control.

Para GDPR Article 22, la pregunta es: si un cliente impugna una decisión automatizada que le afectó, ¿puede explicar la base para esa decisión y demostrar que fue consistente con su base legal para el procesamiento? Un modelo de puntuación de AI que categorizó una solicitud de crédito sin un registro de auditoría de los atributos de entrada y la versión del modelo no puede satisfacer el derecho a la explicación.

Para SOC 2 Type II, la pregunta es: ¿su evidencia de control de acceso y monitoreo demuestra que los sistemas de AI están actuando dentro de su alcance autorizado? Los auditores buscarán evidencia de que existen registros de auditoría, que capturan suficiente detalle y que alguien los revisa.

La traza de auditoría no es opcional en contextos regulados. Es un requisito fiduciario.

Construir la conexión de gobernanza

La función Manage del NIST AI RMF describe el monitoreo continuo y la respuesta como fundamentales para el despliegue responsable de AI, y su traza de auditoría es el fundamento de datos para ambos. La traza de auditoría apoya tres documentos de gobernanza más:

La política de uso de AI define qué están autorizados a hacer los sistemas de AI. La traza de auditoría es la evidencia de que los sistemas de AI se mantuvieron dentro de esa autorización.

El playbook de respuesta a incidentes de AI define cómo responde cuando algo sale mal. La traza de auditoría es lo primero que su equipo de respuesta a incidentes busca cuando una acción Execute de AI causa daño.

El registro de riesgos de AI documenta los riesgos conocidos de cada despliegue de AI. Cuando identifica un nuevo riesgo durante una revisión de incidentes, la traza de auditoría le da los datos para entender su frecuencia y severidad.

Y el artículo sobre la frontera Generate vs. Execute es el fundamento conceptual de por qué las acciones Execute específicamente requieren este nivel de responsabilidad. Los errores de Generate son recuperables. Los errores de Execute están en el mundo.

Diseñar para la investigación que necesitará ejecutar

El marco más útil para diseñar una traza de auditoría es: ¿qué necesitaría saber si esta acción causara un problema?

Si su sistema de AI emitió un reembolso incorrecto, necesitaría saber: qué cliente, qué monto, qué versión del modelo, qué vio la AI cuando tomó la decisión, si un humano lo revisó y cuál fue el resultado en Stripe. Diseñe su traza de auditoría para responder esas preguntas.

Si su modelo de puntuación de AI empezó a enrutar leads incorrectamente, necesitaría saber: cuándo comenzó el comportamiento, si se correlacionó con una actualización del modelo, qué leads se vieron afectados y qué criterios de puntuación usó el modelo. Diseñe su traza de auditoría para responder esas preguntas.

El punto no es registrar todo. Es registrar las cosas que importarán cuando algo salga mal. Y para las acciones Execute de AI, esos siete campos son lo que necesita.

Comience a registrar antes de necesitarlo. El momento de construir una traza de auditoría no es durante una investigación de incidentes.

Porque cuando llega el incidente, la pregunta no es solo "¿qué hizo la AI?" Es "¿qué va a hacer al respecto en las próximas 72 horas?"

Rework Analysis: Basado en los patrones de incidentes de gobernanza de AI, los tres campos de trazas de auditoría que más frecuentemente faltan durante las investigaciones de incidentes son: la versión del modelo (los equipos descubren que no saben qué versión del modelo estaba ejecutándose cuando ocurrió el incidente), el paso de aprobación humana (si un humano revisó antes de la ejecución no está registrado, solo el resultado), y el output de AI antes de la ejecución (los equipos saben qué acción se tomó pero no qué razonamiento proporcionó la AI que la llevó a ello). Los tres son económicos de registrar. Los tres se vuelven costosos cuando están ausentes. El Estándar de Auditoría de Acciones Execute en este artículo está secuenciado para garantizar que estos campos de alto valor se capturen primero.

Vea también:

• Cómo Construir su Política de Uso de AI: define qué acciones Execute de AI están autorizadas; la traza de auditoría demuestra que se mantuvieron dentro de los límites
• Etapa 3 a 4: De Escalado a Integrado: por qué los requisitos de trazas de auditoría se expanden considerablemente a medida que la AI se integra en los flujos de trabajo centrales
• Por Qué Fracasan la Mayoría de las Transformaciones con AI: cómo el retraso de gobernanza (infraestructura de auditoría ausente) es uno de los cinco modos de fracaso de causa raíz
• ¿Qué Es un AI Sales Operator?: un ejemplo práctico del tipo de acciones Execute que requieren trazas de auditoría en un contexto de ventas