Trazabilidad de Auditoria de AI: Que Necesitas Registrar y Por Que los Reguladores Lo Pediran

Una trazabilidad de auditoria no se trata de registrar todo. Se trata de poder responder preguntas especificas despues del hecho: que decision se tomo, por que sistema, basandose en que entradas, en que momento, con que supervision humana y que sucedio despues.

Los reguladores en la UE, EE.UU. y el Reino Unido estan convergiendo en preguntas similares. Pueden usar diferente lenguaje legal, pero el requisito central es el mismo: si tu AI tomo una decision consecuente, deberias poder reconstruirla completamente.

La mayoria de los despliegues de AI empresarial no pueden hacer esto hoy. Aqui esta lo que necesitas y lo que cada marco regulatorio requiere.

Lo Que Dicen Realmente las Regulaciones

EU AI Act

El EU AI Act tiene tres articulos que impactan directamente en los requisitos de logging:

Articulo 13 (Transparencia) requiere que los sistemas de AI de alto riesgo sean lo suficientemente transparentes para permitir que los desplegadores interpreten y usen las salidas apropiadamente. El sistema debe proporcionar salidas interpretables — no solo una decision, sino la base para ella.

Articulo 17 (Sistema de Gestion de Calidad) requiere que los proveedores de sistemas de AI de alto riesgo implementen un sistema de gestion de calidad que incluya procedimientos de mantenimiento de registros, gobernanza de datos y monitoreo post-mercado. El sistema de gestion de calidad en si debe estar documentado y ser auditable.

Anexo IV (Documentacion Tecnica) especifica lo que debe documentarse: descripcion general del sistema, descripcion detallada del diseno y desarrollo incluyendo metodologia de entrenamiento y datos de entrenamiento, medidas de monitoreo y evaluacion, y medidas de gestion de riesgos. Esta documentacion debe mantenerse y actualizarse.

Articulo 30 es el requisito de logging mas especifico: los proveedores y desplegadores de sistemas de AI de alto riesgo deben mantener los registros generados automaticamente por el sistema de AI durante un periodo apropiado al proposito previsto, con un minimo de 10 anos. Los registros deben ser suficientes para permitir la investigacion post-hoc de decisiones.

Diez anos es un periodo de retencion largo. La mayoria de los equipos de ingenieria piensan en la retencion de logs en terminos de semanas o meses. Para los sistemas de AI clasificados como de alto riesgo bajo el EU AI Act, la obligacion es de una decada.

Salvaguardas Tecnicas de HIPAA (45 CFR seccion 164.312)

Los requisitos de salvaguardas tecnicas de HIPAA aplican a cualquier sistema que crea, recibe, mantiene o transmite informacion de salud protegida electronica (ePHI). Si tu sistema de AI toca datos de pacientes, estos aplican:

• Controles de acceso: identificacion unica de usuario, cierre de sesion automatico, cifrado
• Controles de auditoria: mecanismos de hardware, software y procedimientos que registran y examinan la actividad en sistemas de informacion que contienen ePHI
• Controles de integridad: mecanismos para autenticar que el ePHI no ha sido alterado ni destruido
• Seguridad de transmision: cifrado de ePHI en transito

El requisito de control de auditoria es el relevante aqui. HIPAA no especifica exactamente que registrar, pero la guia del HHS deja claro que los registros deben capturar quien accedio a que datos, cuando y con que proposito. Retencion: 6 anos desde la creacion o la ultima fecha efectiva.

SR 11-7 (Federal Reserve / OCC Gestion de Riesgo de Modelos)

La guia SR 11-7 de la Federal Reserve sobre gestion de riesgo de modelos requiere que los modelos usados en banca tengan documentacion que cubra:

• Proposito del modelo y uso previsto
• Descripcion de teoria y logica
• Entradas de datos y supuestos
• Limitaciones del modelo
• Procedimientos de validacion
• Monitoreo continuo de rendimiento

Para modelos de AI/ML especificamente, los reguladores han enfatizado la importancia de registrar entradas del modelo, salidas y metricas de rendimiento para permitir el monitoreo continuo y la investigacion de fallas. El principio clave es que los validadores independientes deben poder reproducir las salidas del modelo — lo cual requiere logging completo de entradas y version del modelo al momento de la inferencia.

Los 8 Elementos Minimos de una Trazabilidad de Auditoria de AI

Estos ocho elementos cubren el minimo que cualquier trazabilidad de auditoria de grado cumplimiento debe capturar. Omitir cualquiera de ellos crea una brecha que los reguladores encontraran.

1. Datos de Entrada con Hash de Integridad

Registra la entrada que se presento al modelo — o una representacion de ella si la entrada cruda es demasiado grande. Criticamente, incluye un hash criptografico (SHA-256 es el estandar) de los datos de entrada. Esto te permite verificar posteriormente que la entrada registrada coincide con lo que realmente se proceso. Sin un hash de integridad, un registro de entrada puede ser disputado.

Para entradas que contienen ePHI, registra una referencia al registro de datos en lugar de los datos mismos — pero asegurate de que la referencia sea inequivoca y el hash cubra el contenido referenciado.

2. Version y Configuracion del Modelo

Este es el elemento que mas comunmente falta. Registra la version exacta del modelo que proceso la solicitud: no "GPT-4" sino la version especifica, checkpoint o ID del modelo. Incluye la configuracion de inferencia: temperature, top-p, max tokens, hash del system prompt.

Si no puedes especificar la version exacta del modelo en el momento de una inferencia historica, no puedes reconstruir que comportamiento estaba produciendo el sistema en ese momento. Esta es una brecha critica para cualquier revision regulatoria.

3. Salida con Confianza o Probabilidad Cuando Este Disponible

Registra la salida completa del modelo. Para tareas de clasificacion, registra el puntaje de confianza o la distribucion de probabilidad, no solo la prediccion principal. Una salida de clasificacion binaria de "aprobado" es mucho menos util que "aprobado (0.73 de confianza)" — lo segundo te dice si fue una decision segura o marginal.

Para salidas generativas, registra el texto completo. El almacenamiento es barato. No poder producir la salida exacta que impulso una accion posterior durante una investigacion regulatoria es costoso.

4. Timestamp en UTC

Registra timestamps en UTC, no en hora local. Las investigaciones regulatorias frecuentemente cruzan fronteras de zonas horarias. UTC con precision de milisegundos elimina la ambiguedad. Asegurate de que tu infraestructura de logging tenga sincronizacion NTP — la integridad del timestamp importa.

Registra tanto el momento en que se recibio la solicitud como el momento en que se devolvio la respuesta. Los datos de latencia pueden ser relevantes para investigaciones de rendimiento.

5. Identidad del Usuario o Sistema Actuante

Quien o que disparo esta inferencia? Registra el ID de usuario autenticado para solicitudes iniciadas por humanos, o el identificador de sistema/servicio para solicitudes de pipelines automatizados. Esto permite analisis de patrones de acceso e identifica que usuarios o sistemas estuvieron involucrados en una decision bajo revision.

No registres credenciales compartidas. Cada actor en tu pipeline de AI deberia tener una identidad unica y auditable.

6. Decision de Revision Humana Donde Aplique HITL

Si tu sistema incluye revision humana en el ciclo — un humano que revisa las salidas de AI antes de que impulsen acciones consecuentes — registra el resultado de la revision explicitamente. Quien la reviso, cuando, que decision tomo y si anulo la recomendacion de la AI.

La revision humana es frecuentemente lo que mas interesa a los reguladores en decisiones de alto impacto. "La AI lo marco como de alto riesgo" es incompleto sin "y un profesional licenciado lo reviso y estuvo de acuerdo/en desacuerdo."

7. Accion Posterior Tomada

Registra lo que sucedio como resultado de la salida de AI. Una clasificacion no tiene sentido en aislamiento — que hizo tu sistema con ella? Registra la accion posterior: reclamacion aprobada, solicitud marcada para revision, documento enrutado al departamento X, alerta enviada a Y.

Esto cierra el ciclo entre la decision de AI y la consecuencia del mundo real. Es lo que te permite responder "que hizo el sistema para el paciente 12345 el 5 de marzo?"

8. Cualquier Anulacion o Escalamiento

Cuando un humano anula una decision de AI, o cuando se activa un proceso de excepcion, registralo explicitamente como un evento de anulacion. Incluye la razon si tu flujo de trabajo la captura. Estos datos son valiosos tanto para propositos regulatorios como para mejora del modelo — las anulaciones sistematicas indican donde el modelo esta mal calibrado.

La Brecha de Linaje

La mayoria de los equipos que han pensado en este problema tienen cubierto el logging de entradas y salidas. La brecha esta en el medio: el pipeline de transformacion.

La salida de tu AI no es solo una funcion de la entrada cruda del usuario. Es una funcion de resultados de recuperacion, pasos de preprocesamiento, ensamblaje de contexto, plantillas de prompts e instrucciones del sistema — ninguno de los cuales puede estar registrado.

El EU AI Act Articulo 30 requiere documentacion del pipeline completo, no solo entradas y salidas. Si tu sistema de AI involucra generacion aumentada por recuperacion, los documentos recuperados son parte de la entrada que determino la salida. Si el preprocesamiento normaliza o transforma la entrada, esa transformacion es parte del linaje.

Mapea cada paso de transformacion entre la entrada cruda y la llamada al modelo, y registra cada uno. Esto es mas dificil que registrar los extremos — pero es lo que los reguladores buscan cuando investigan una decision especifica.

Lo Que los Reguladores Realmente Miran en una Auditoria

Los reguladores que conducen una auditoria de AI no leen cada entrada del log. Muestrean y hacen preguntas especificas.

El patron es: una decision especifica esta bajo revision (una reclamacion denegada, una transaccion marcada, una clasificacion de alto riesgo). El regulador quiere reconstruir esa decision completamente. Pedira el registro de esa inferencia especifica — la entrada, la version del modelo, la salida, la revision humana, la accion posterior. Luego verificara la completitud: estan los 8 elementos presentes? Son consistentes los timestamps? Esta documentada la version del modelo? Hay evidencia de supervision humana?

Si falta algun elemento para una decision especifica bajo revision, eso es un hallazgo. Si la trazabilidad de auditoria no puede confirmar que version del modelo estaba ejecutandose en una fecha especifica, eso es un hallazgo. Si la revision humana era requerida por politica pero no esta documentada en el log, eso es un hallazgo.

La implicacion practica: tu infraestructura de trazabilidad de auditoria necesita hacer que la busqueda de registros individuales sea rapida, y necesita asegurar la completitud al momento de escritura — no como una verificacion periodica por lotes.

Almacenamiento y Retencion

Los requisitos de retencion varian por marco:

• HIPAA: 6 anos desde la creacion o la ultima fecha efectiva
• EU AI Act (sistemas de alto riesgo): 10 anos minimo
• SR 11-7: Ningun periodo explicito declarado, pero los ciclos de examinacion bancaria sugieren 5-7 anos en la practica
• FDA SaMD: Consistente con el ciclo de vida del producto, tipicamente el mayor entre 2 anos o la vida util del producto

Disena para el periodo aplicable mas largo en tu contexto regulatorio. Almacenamiento escalonado (caliente para registros recientes, frio para los mas antiguos) gestiona costos mientras mantiene accesibilidad. Asegurate de que el almacenamiento frio este indexado para recuperacion de registros especificos — almacenamiento de archivo masivo que requiere una restauracion completa para consultar no esta listo para auditoria.

Ertas Data Suite: Logging de Auditoria Integrado

Para pipelines de preparacion de datos de AI — el trabajo previo que produce datos de entrenamiento, datasets de fine-tuning y corpus etiquetados — Ertas Data Suite registra cada paso de transformacion con timestamp, ID del operador y un registro completo de la operacion aplicada. Cada accion de ingest, clean, label, augment y export es parte de una cadena de auditoria inmutable.

La plataforma exporta documentacion tecnica conforme al EU AI Act Articulo 30 directamente. Para empresas reguladas donde el pipeline de preparacion de datos esta sujeto a auditoria, esto significa que el linaje se captura por defecto — no se reconstruye despues del hecho.

Agenda una llamada de descubrimiento con Ertas

Las trazabilidades de auditoria no son algo que agregas despues de haber construido el sistema. Necesitan disenarse desde el inicio. El costo de retrofittear logging comprensivo en un sistema de AI en produccion es consistentemente mas alto que construirlo correctamente la primera vez — y el costo de no tenerlo durante una investigacion regulatoria es aun mas alto.