Evidencia Operativa del EU AI Act: Que Piden Realmente los Auditores

Hay una brecha entre lo que las empresas creen que significa el cumplimiento y lo que los auditores realmente examinan. La mayoria de las organizaciones abordan el EU AI Act como abordan las certificaciones ISO — escriben politicas, crean listas de verificacion, alguien firma, se archiva. Esto funcionaba para los marcos de cumplimiento tradicionales. No funciona para el EU AI Act.

El EU AI Act se basa en evidencia, no en declaraciones. El reglamento requiere que los sistemas de IA de alto riesgo demuestren cumplimiento a traves de evidencia operativa — registros verificables y legibles por maquina que muestren que el sistema cumple ahora mismo, no que alguien lo declaro conforme hace seis meses.

Esta distincion importa enormemente para los pipelines de datos de IA. No puedes declarar que tus datos de entrenamiento son de alta calidad. Debes demostrarlo con metricas, logs y linaje rastreable. No puedes declarar que tu gobernanza de datos es adecuada. Debes mostrarle al auditor el sistema que la implementa.

Esto es lo que los auditores realmente examinan, basado en los requisitos de los Articulos 10, 11, 12 y 30 del reglamento.

Que Examinan Realmente los Auditores

1. Linaje de Datos

La primera pregunta que hara un auditor: "Muestrame como se produjeron los datos de entrenamiento de este modelo."

No es una pregunta conceptual. Quieren ver la cadena real — desde el documento fuente hasta el ejemplo de entrenamiento final, a traves de cada transformacion, con marcas de tiempo e identificacion del operador en cada paso.

Que quieren ver:

• Identificacion de la fuente: ¿De donde vinieron los datos crudos? Nombres de documentos, fechas, metodos de recopilacion, estado de consentimiento/licencia.
• Cadena de transformacion: Cada operacion aplicada a los datos — filtrado, limpieza, etiquetado, aumento, conversion de formato — registrada en secuencia con marcas de tiempo.
• Vinculacion de versiones: ¿Que version de los datos de entrenamiento se uso para que version del modelo? Si el modelo se reentreno en febrero de 2026, ¿que version del dataset se uso?
• Reversibilidad: ¿Puedes volver a una version anterior del dataset y explicar por que se hicieron los cambios?

Que van a probar: El auditor elige una salida aleatoria del modelo, luego te pide rastrearla a traves de la version del modelo, la version del dataset, el historial de transformaciones y los datos fuente. Si la cadena se rompe en algun punto, eso es un hallazgo.

Modo de fallo tipico: El equipo de ingenieria de datos proceso los datos en un notebook de Jupyter, exporto el dataset final y no guardo el notebook ni sus salidas intermedias. Seis meses despues, nadie puede explicar como se produjo el dataset.

2. Logs de Transformacion

Los logs son la columna vertebral de la evidencia operativa. Cada operacion sobre los datos de entrenamiento debe producir un registro inmutable con marca de tiempo.

Como se ve una entrada de log conforme:

{
  "timestamp": "2026-02-14T09:32:17.441Z",
  "operator_id": "anna.schmidt@company.eu",
  "operation": "text_cleaning",
  "parameters": {
    "remove_html_tags": true,
    "normalize_unicode": true,
    "min_text_length": 50,
    "language_filter": ["en", "de"]
  },
  "input_records": 24891,
  "output_records": 22347,
  "records_removed": 2544,
  "removal_reason_distribution": {
    "below_min_length": 1823,
    "unsupported_language": 721
  },
  "pipeline_version": "3.1.2",
  "log_integrity_hash": "sha256:a4f2e8..."
}

Que buscan los auditores en los logs:

• Completitud: ¿Esta registrada cada transformacion, o hay vacios? Si el dataset paso de 50,000 registros a 35,000 registros sin una entrada de log que explique la reduccion, eso es un vacio.
• Granularidad: "Se limpiaron los datos" no es una entrada de log. ¿Que se limpio? ¿Como? ¿Que se elimino? ¿Por que?
• Identificacion del operador: ¿Quien realizo la operacion? "System" o "admin" no es aceptable — el reglamento requiere responsabilidad individual.
• Inmutabilidad: ¿Se pueden modificar las entradas de log despues de su creacion? Si la respuesta es si, el log no tiene valor probatorio.
• Continuidad: ¿Son los logs continuos desde el inicio del pipeline, o el registro comenzo hace tres meses? Vacios en la linea temporal del log sugieren que el sistema no fue monitoreado consistentemente.

Que van a probar: El auditor solicita logs para un periodo de tiempo especifico o un tipo de transformacion especifico. Verifican que las marcas de tiempo sean consistentes, buscan vacios y verifican que los IDs de operador correspondan a personal real.

3. Metricas de Calidad

El Articulo 10 requiere que los datos de entrenamiento sean "relevantes, suficientemente representativos y, en la medida de lo posible, libres de errores y completos." Los auditores necesitan evidencia de que evaluaste estas propiedades, no solo una afirmacion de que los datos son buenos.

Que califica como evidencia de calidad:

• Perfiles estadisticos del dataset: tamano, distribuciones de caracteristicas, balance de clases, analisis de cobertura
• Puntuaciones de calidad en cada etapa del pipeline: confianza de OCR, validacion de limpieza, tasas de acuerdo en etiquetado
• Documentacion de umbrales: ¿Que estandares de calidad se aplicaron? ¿Cual fue la precision minima aceptable? ¿Que paso con los datos que cayeron por debajo del umbral?
• Analisis de tendencias: ¿Como ha cambiado la calidad de los datos con el tiempo? ¿Estan mejorando, degradandose o estables las metricas de calidad?

Que NO califica:

• "Revisamos los datos y se veian bien." Esto es subjetivo y no verificable.
• Una sola evaluacion de calidad de hace seis meses. La calidad debe monitorearse continuamente, no evaluarse una vez.
• Metricas de calidad sin umbrales definidos. Una puntuacion de precision del 92% no significa nada sin un umbral documentado (por ejemplo, "se requiere un minimo de 90% de precision para uso en produccion").

4. Control de Versiones

El reglamento implicitamente requiere reproducibilidad — la capacidad de recrear los datos de entrenamiento exactos utilizados para cualquier version del modelo desplegada. Esto requiere control de versiones para datasets, no solo para codigo.

Que buscan los auditores:

• Identificadores de version del dataset vinculados a identificadores de version del modelo
• La capacidad de obtener o regenerar cualquier version historica del dataset
• Registros de cambios entre versiones del dataset (que cambio y por que)
• Proteccion contra modificaciones accidentales (proteccion de escritura en versiones finalizadas del dataset)

Que van a probar: "Dame el dataset exacto usado para entrenar la version del modelo desplegada el 15 de enero de 2026." Si no puedes producirlo — contenido exacto, no una aproximacion — eso es un hallazgo.

5. Demostracion en Vivo

Esta es la que atrapa a las organizaciones no preparadas. Los auditores no solo revisan documentos — piden una demostracion en vivo del sistema.

Como se ve una demostracion en vivo:

• El auditor observa a un operador procesar nuevos datos a traves del pipeline
• El auditor observa que el sistema genera automaticamente entradas de log
• El auditor verifica que las entradas de log coincidan con lo observado
• El auditor intenta modificar una entrada de log (esperando que falle)
• El auditor sigue una cadena de linaje de datos en tiempo real

Por que importa: Las demostraciones en vivo atrapan el "cumplimiento de papel" — organizaciones que crearon documentacion pero no usan realmente los sistemas descritos. Si el operador duda, abre una herramienta diferente a la documentada, o no puede navegar la interfaz del rastro de auditoria, el auditor ve que la infraestructura de cumplimiento no esta operativamente integrada.

Que NO Es Aceptable

Basado en los requisitos del reglamento y la guia temprana de aplicacion, lo siguiente no constituye evidencia de cumplimiento:

Hojas de calculo manuales: Una Google Sheet o archivo Excel donde los miembros del equipo registran manualmente sus actividades de procesamiento de datos. Las hojas de calculo no tienen proteccion de escritura, no tienen marcas de tiempo garantizadas y no tienen verificacion de integridad. Pueden editarse retroactivamente sin rastro.

Documentacion en unidades compartidas: Una carpeta de documentos que describen el pipeline de datos. Los documentos pueden modificarse, antedatarse o fabricarse. Sin control de versiones y hash de integridad, no tienen valor probatorio.

Auto-certificacion sin logs de respaldo: Una declaracion firmada que dice "Nuestros datos de entrenamiento cumplen los estandares de calidad" sin las metricas, umbrales y registros de monitoreo continuo que la respalden.

Documentacion retroactiva: Documentacion creada en respuesta a una solicitud de auditoria en lugar de como parte de las operaciones continuas. Los auditores verifican los metadatos de los documentos — las fechas de creacion, fechas de modificacion e historiales de versiones revelan cuando se produjo realmente la documentacion.

Certificaciones de terceros por si solas: Un certificado de un proveedor que dice que su herramienta "cumple con el EU AI Act" no transfiere el cumplimiento al usuario. El usuario debe demostrar que utiliza la herramienta de manera conforme con evidencia operativa de su propio despliegue.

Como Prepararse: Ejecutar una Auditoria Simulada

El paso de preparacion mas efectivo es una auditoria simulada. Asi es como ejecutar una.

Seleccionar un auditor: Elige a alguien fuera del equipo de datos — un oficial de cumplimiento, un miembro del equipo legal o un consultor externo. Necesitan suficiente comprension tecnica para evaluar la evidencia pero no deben estar involucrados en producirla.

Definir el alcance de la auditoria: Elige un sistema de IA y su pipeline de datos asociado. La auditoria simulada debe cubrir las cinco categorias de evidencia descritas arriba.

Proporcionar acceso al auditor: Dale al auditor simulado el mismo acceso que tendria un auditor real — acceso de solo lectura a logs, sistemas de linaje, documentacion y la interfaz del pipeline.

Ejecutar la auditoria: El auditor simulado sigue el mismo proceso que un auditor real:

1. Solicitar el linaje de datos para el modelo de produccion actual
2. Solicitar logs de transformacion para un rango de fechas especifico
3. Solicitar metricas de calidad y documentacion de umbrales
4. Solicitar la capacidad de reproducir una version historica del dataset
5. Observar una demostracion en vivo del pipeline en operacion
6. Intentar identificar vacios, inconsistencias o debilidades

Documentar hallazgos: Cada vacio, inconsistencia o pieza de evidencia faltante se documenta con una calificacion de severidad y una recomendacion de remediacion.

Remediar: Corregir cada hallazgo antes de que llegue la auditoria real. Los hallazgos de una auditoria simulada son un regalo — te dicen exactamente que corregir mientras aun hay tiempo para hacerlo.

Planifica 2-3 dias para una auditoria simulada de un solo pipeline. Si tu organizacion tiene multiples sistemas de IA dentro del alcance, ejecuta auditorias simuladas en los sistemas de mayor riesgo primero.

Requisitos de Formato de Evidencia

El reglamento no prescribe un formato de log especifico, pero los requisitos implicitos apuntan a estandares claros.

Legible por maquina: Los logs deben ser parseables por herramientas automatizadas. JSON, CSV estructurado o registros de base de datos — no notas de texto libre.

Con marca de tiempo: Cada registro debe tener una marca de tiempo de una fuente de tiempo confiable. Relojes de sistema sincronizados con NTP son el minimo; las marcas de tiempo de modulos de seguridad de hardware son el estandar de oro para sistemas de alto riesgo.

Inmutable: Una vez escritas, las entradas de log no pueden modificarse ni eliminarse. Bases de datos de solo adicion, almacenamiento de escritura unica o cadenas de logs firmadas criptograficamente proporcionan inmutabilidad.

Atribuible: Cada registro debe identificar al operador (persona o sistema) que realizo la accion. Las cuentas de servicio son aceptables para operaciones automatizadas, pero la persona que configuro y autorizo la operacion automatizada debe ser rastreable.

Conservable: Los registros deben conservarse durante la vida util del sistema de IA mas un periodo razonable (10 anos es la interpretacion estandar para sistemas de alto riesgo). Planifica el almacenamiento en consecuencia — a aproximadamente 1KB por entrada de log, un pipeline que procesa 10,000 registros por dia genera aproximadamente 3.6 millones de entradas de log por ano, o alrededor de 3.6GB de datos de log sin procesar.

Como Ertas Data Suite Genera Evidencia

Ertas Data Suite fue construido con el cumplimiento del EU AI Act como requisito de diseno, no como una idea posterior. Cada operacion en la plataforma — cada filtro, cada etiqueta, cada exportacion — genera automaticamente una entrada de log conforme con marca de tiempo, ID de operador, parametros y conteos de registros.

El linaje de datos se rastrea de forma nativa. Puedes seleccionar cualquier ejemplo de entrenamiento en el dataset exportado y rastrearlo hasta el documento fuente, a traves de cada transformacion, con un grafico de linaje visual.

El versionado de datasets esta integrado. Cada exportacion crea una instantanea versionada. Puedes reproducir cualquier version historica del dataset con una sola accion.

El rastro de auditoria es inmutable. Las entradas de log son de solo adicion con hash de integridad criptografico. Un auditor puede verificar que ninguna entrada ha sido modificada desde su creacion.

Para organizaciones que enfrentan la fecha limite del 2 de agosto de 2026, adoptar una plataforma con generacion de evidencia de cumplimiento integrada es mas rapido que construir infraestructura de cumplimiento desde cero. El cronograma de implementacion baja de 3-4 meses de trabajo de ingenieria a 2-3 semanas de migracion de datos y configuracion.

Lectura Adicional

• Auditoria de Cumplimiento para Flujos de Trabajo de Preparacion de Datos de IA — Como estructurar tu flujo de trabajo de preparacion de datos para estar listo para auditorias desde el primer dia.
• Rastros de Auditoria de IA Empresarial: Que Registrar — Especificacion tecnica de que eventos del pipeline de datos deben generar entradas de log de auditoria.
• Linaje de Datos como Requisito Legal Bajo el EU AI Act — La base legal para los requisitos de linaje de datos y como se traducen en tareas de ingenieria.