Lista de Verificacion de Documentacion del Articulo 30 del EU AI Act: Que Deben Registrar los Proveedores de IA de Alto Riesgo

El EU AI Act impone sus requisitos de documentacion mas detallados a los sistemas de IA de alto riesgo. El Articulo 30, especificamente, aborda el registro — la grabacion automatica y continua de eventos que permite a las autoridades competentes auditar el comportamiento de un sistema, rastrear decisiones hasta entradas y versiones de modelo especificas, e investigar incidentes.

Si desarrollas, despliegas o importas sistemas de IA de alto riesgo en o hacia la UE, el Articulo 30 aplica a ti. Esta lista de verificacion cubre cada requisito, explica lo que significa en la practica e identifica las brechas comunes de implementacion que crean exposicion de cumplimiento.

A Quien Aplica

El EU AI Act distingue entre dos roles que ambos llevan obligaciones:

Proveedores son organizaciones que desarrollan un sistema de IA de alto riesgo y lo colocan en el mercado de la UE o lo ponen en servicio. Si construiste el modelo o el sistema, eres un proveedor. Los proveedores llevan la carga principal de documentacion bajo el Articulo 11 (documentacion tecnica) y el Articulo 17 (sistema de gestion de calidad), y las obligaciones de registro bajo el Articulo 12 (que alimenta el Articulo 30 para los implementadores).

Implementadores son organizaciones que usan un sistema de IA de alto riesgo en el curso de sus actividades profesionales. Puedes ser un implementador incluso si no construiste el modelo — si estas usando el sistema de IA de alto riesgo de un proveedor en tus operaciones, eres un implementador. El Articulo 26 establece las obligaciones del implementador, y el Articulo 30 aborda especificamente lo que los implementadores deben registrar sobre su uso del sistema.

Muchas organizaciones son tanto proveedor como implementador — construyen sistemas de IA (proveedor) y tambien despliegan sistemas de IA construidos por otros (implementador).

Sistemas de IA de alto riesgo se definen principalmente en el Anexo III de la Ley. Estos incluyen sistemas utilizados en:

• Identificacion y categorizacion biometrica
• Gestion de infraestructura critica
• Educacion y formacion profesional (admision, evaluacion)
• Empleo y gestion de trabajadores (reclutamiento, rendimiento, promocion)
• Acceso a servicios privados esenciales y beneficios publicos (scoring crediticio, seguros, beneficios sociales)
• Aplicacion de la ley
• Migracion, asilo y control fronterizo
• Administracion de justicia y procesos democraticos

Si tu sistema opera en cualquiera de estos dominios, es casi seguro de alto riesgo. En caso de duda, tratalo como alto riesgo y consulta a asesoria legal.

Entendiendo el Panorama de Articulos

El EU AI Act tiene multiples requisitos de documentacion que frecuentemente se confunden. Asi es como se relacionan:

El Articulo 30 trata sobre lo que registras durante la operacion. Es distinto de — y adicional a — los requisitos de documentacion tecnica del Articulo 11 y los requisitos de gestion de calidad del Articulo 17.

Fecha de Aplicabilidad

Para la mayoria de los sistemas de IA de alto riesgo (los cubiertos por el Anexo III), los requisitos completos se volvieron aplicables en agosto de 2026. Los sistemas cubiertos por el Anexo I (productos regulados como dispositivos medicos, equipos de aviacion) tienen un periodo de transicion mas largo.

Si estas leyendo esto a principios de 2026, tienes tiempo limitado para implementar infraestructura de registro conforme antes de la fecha limite.

---

Lista de Verificacion de Cumplimiento del Articulo 30

Articulo 30(1): Registro Automatico de Eventos

La Ley requiere que los sistemas de IA de alto riesgo sean capaces de generar automaticamente registros de eventos "durante toda la vida operativa del sistema."

Requisitos de implementacion:

[ ] El sistema de IA (o tu infraestructura de despliegue alrededor de el) es capaz de registrar automaticamente eventos — esto no puede ser un proceso manual

[ ] El registro es continuo durante toda la vida operativa del sistema, no basado en muestras o activado solo ante errores

[ ] Los registros se almacenan de forma segura con controles de acceso que restringen quien puede leerlos

[ ] Existe un mecanismo de prevencion de manipulacion — cadenas de hash, almacenamiento de escritura unica o equivalente — para que los registros no puedan modificarse despues de escritos sin deteccion

[ ] El registro esta activo en produccion desde el dia uno del despliegue, no se agrega despues

Brecha comun: Las organizaciones que dependen completamente de una API proporcionada por un proveedor a menudo asumen que el proveedor maneja el registro. Verifica tu acuerdo explicitamente — muchos proveedores proporcionan registros basicos de uso pero no los registros detallados, atribuibles al implementador, de entrada/salida que requiere el Articulo 30. Es posible que necesites implementar registro en tu propia capa de integracion.

---

Articulo 30(2): Requisitos de Trazabilidad

Los registros deben ser suficientes para rastrear eventos hasta entradas especificas, versiones de modelo especificas y periodos de uso especificos.

Requisitos de implementacion:

[ ] Cada salida de IA se registra con: marca de tiempo (UTC), version o identificador del modelo, y las entradas relevantes que la produjeron

[ ] Los registros contienen informacion suficiente para identificar el periodo de uso (fechas de inicio y fin de una configuracion de despliegue)

[ ] Los registros identifican al implementador responsable para cada evento registrado (relevante si multiples implementadores comparten infraestructura)

[ ] Para sistemas usados sobre individuos especificos (decisiones de empleo, decisiones crediticias, etc.): los registros deben permitir la identificacion de que individuos fueron procesados y cuando

[ ] La granularidad del registro es suficiente para identificar cuando el sistema opero fuera de su proposito previsto o fuera de sus condiciones normales de operacion

[ ] Los registros capturan no solo inferencias exitosas sino tambien: errores, tiempos de espera agotados, entradas rechazadas y casos extremos

Brecha comun: Los sistemas que registran solo salidas exitosas y no fallos pierden los eventos mas probables de ser relevantes en una investigacion de incidentes. Una entrada que causo que el sistema fallara silenciosamente — devolviendo una salida por defecto en lugar de un error — es particularmente dificil de detectar sin registro completo.

---

Articulo 30(3): Almacenamiento y Acceso

Los registros deben almacenarse de manera duradera, accesible a las partes autorizadas y protegida contra perdida.

Requisitos de implementacion:

[ ] Los registros se almacenan por un periodo apropiado al proposito previsto y la regulacion aplicable

La Ley en si no especifica un unico periodo de retencion — hace referencia al proposito previsto del sistema de IA. Orientacion practica: para sistemas que toman decisiones consecuentes a nivel individual (credito, empleo, beneficios), un minimo de 5-10 anos es defendible dados los periodos de prescripcion aplicables y los plazos de investigacion regulatoria. Para sistemas de menor consecuencia, 6 meses es el minimo sugerido por la orientacion temprana del EU AI Act.

[ ] Los controles de acceso aseguran que los registros sean accesibles solo para: personal interno autorizado (auditoria, cumplimiento, legal), la autoridad nacional competente (bajo solicitud) y auditores externos autorizados

[ ] Los registros son accesibles para las autoridades nacionales competentes bajo solicitud sin demora indebida — "solicitud" aqui significa una consulta regulatoria, no solo reporte rutinario

[ ] Los registros estan protegidos contra perdida o destruccion accidental — procedimientos de respaldo, almacenamiento redundante y politicas de retencion de datos aplican

[ ] El acceso a los registros se audita — quien accedio a los registros, cuando y con que proposito deberia registrarse a su vez

Brecha comun: Las organizaciones almacenan registros en sistemas que se purgan en cronogramas de retencion cortos heredados de politicas de datos operativos. Asegurate de que los registros de decisiones de IA se clasifiquen por separado y no esten sujetos a la gestion general del ciclo de vida de datos que los purgaria en un cronograma mas corto.

---

Articulo 30(4): Requisitos Especificos del Implementador

Incluso cuando un proveedor suministra el sistema de IA subyacente, el implementador tiene obligaciones de registro independientes para su contexto de despliegue especifico.

Requisitos de implementacion:

[ ] El implementador mantiene registros que cubren su despliegue especifico: que sistema se desplego, en que configuracion, para que caso de uso

[ ] Los registros del implementador incluyen: fecha de inicio del despliegue, fecha de fin del despliegue (o "en curso") y cualquier cambio de configuracion realizado durante el despliegue (cambios de prompts, ajustes de umbrales, cambios de integracion)

[ ] Los registros del implementador capturan eventos de monitoreo de salud del sistema: alertas de rendimiento, tasas de error, cambios en metricas de precision

[ ] El implementador mantiene registros de todas las medidas de supervision humana aplicadas — para sistemas HITL, esto significa registros de cada decision de revision humana (consulta la HITL Workflow Design Worksheet para los campos de registro requeridos)

[ ] Si el implementador modifico el comportamiento del sistema respecto a las instrucciones del proveedor (diferentes prompts, diferentes umbrales, diferente preprocesamiento de entrada), esto se documenta y su impacto en el rendimiento se evalua

Brecha comun: Los implementadores a veces tratan la supervision humana como un compromiso de politica en lugar de un control registrado. "Tenemos HITL" sin registros con marca de tiempo y auditables de cada decision de revision humana no satisface el Articulo 30(4). Las decisiones de revision humana son en si mismos eventos de registro requeridos.

---

Anexo IV: Documentacion Tecnica (Requisitos del Proveedor)

El Anexo IV especifica la documentacion tecnica que los proveedores deben preparar antes de colocar un sistema de IA de alto riesgo en el mercado o ponerlo en servicio. Aunque esta es una obligacion del proveedor y no un requisito de registro del Articulo 30, los implementadores que reciben sistemas de IA de proveedores deben verificar que esta documentacion exista.

Elementos de documentacion requeridos:

[ ] Descripcion general del sistema de IA incluyendo su proposito previsto y la version colocada en el mercado

[ ] Descripcion del proceso de desarrollo:

• Decisiones de diseno tomadas y su justificacion
• Caracteristicas de los datos de entrenamiento: fuentes, metodologia de etiquetado, procedimientos de preparacion de datos, volumen
• Procesos de entrenamiento y prueba utilizados
• Metricas de rendimiento y resultados de validacion

[ ] Documentacion de monitoreo, funcionamiento y control del sistema:

• Capacidades y limitaciones tecnicas
• Riesgos conocidos o previsibles, incluyendo riesgos derivados del mal uso
• Metricas de precision (desagregadas por subgrupos relevantes cuando sea aplicable)
• Medidas de robustez y ciberseguridad

[ ] Medidas de supervision humana requeridas para este sistema:

• Que supervision humana se requiere (HITL, HOTL u otra)
• Como se implementa la supervision humana tecnica y operativamente
• Quien es responsable de implementarla

[ ] Cambios realizados al sistema a lo largo de su ciclo de vida (historial de versiones)

[ ] Evaluacion de riesgos en el contexto de derechos fundamentales y no discriminacion

Para implementadores que reciben un sistema de un proveedor: Solicita el paquete de documentacion del Anexo IV a tu proveedor antes del despliegue. Un proveedor que no puede producir esta documentacion para un sistema de alto riesgo no ha completado sus obligaciones bajo la Ley. Esa brecha es tuya de gestionar — desplegar sin ella te expone a riesgo regulatorio junto con el proveedor.

---

Orientacion Practica de Implementacion

Que Cuenta como un "Evento" para Propositos de Registro

La Ley usa el termino "eventos" sin definicion exhaustiva. Basandose en el contexto regulatorio, lo siguiente debe registrarse como minimo:

Estructurando la Retencion de Registros para Diferentes Tipos de Datos

Los registros de decisiones de IA a menudo contienen datos personales — las entradas al modelo pueden incluir nombres, datos financieros, informacion de salud u otra PII. Esto crea una tension entre los requisitos de registro del EU AI Act y los principios de minimizacion de datos y limitacion de almacenamiento del GDPR.

Resolucion practica:

1. Separar registros operativos de registros de decisiones. Los registros operativos (metricas de rendimiento, tasas de error, latencia) pueden retenerse en cronogramas mas cortos. Los registros de decisiones (entradas, salidas, version del modelo, decisiones de revision humana) requieren retencion mas larga y deben gestionarse bajo una base legal especifica.

2. Aplicar pseudonimizacion a registros de decisiones cuando sea posible. Registra un identificador de caso pseudonimo en lugar de identificadores personales directos. Mantiene la tabla de mapeo por separado con controles de acceso apropiados. Esto reduce la sensibilidad GDPR de los registros mientras preserva la trazabilidad.

3. Documenta tu base legal para la retencion de registros. Bajo el GDPR, necesitas una base legal para procesar datos personales en registros. Para usos regulados (credito, empleo, beneficios), la base legal es tipicamente el cumplimiento de una obligacion legal (el propio EU AI Act). Documenta esto explicitamente en tu registro de actividades de tratamiento.

La Cuestion de la Soberania de Datos

Los registros del Articulo 30 pueden contener datos personales, activando obligaciones del GDPR sobre donde pueden almacenarse esos datos. Si tu sistema de IA procesa datos de residentes de la UE, tus registros de ese procesamiento generalmente deben almacenarse dentro de la UE — o en una jurisdiccion con una decision de adecuacion — a menos que tengas un mecanismo de transferencia valido implementado.

Esto tiene implicaciones practicas para organizaciones que usan infraestructura de registro basada en la nube: confirma que tu region de almacenamiento de registros coincida con tus compromisos de residencia de datos antes del despliegue, no despues de una consulta de una autoridad supervisora.

---

Conectando con la Implementacion

Implementar el cumplimiento del Articulo 30 desde cero requiere instrumentacion en la capa de integracion (donde tu aplicacion llama al sistema de IA), un sistema de almacenamiento de registros con controles de acceso y politicas de retencion apropiados, y un proceso de revision que capture las decisiones de supervision humana en registros estructurados y consultables.

Ertas Data Suite genera registros de auditoria compatibles con el Articulo 30 del EU AI Act directamente desde el pipeline de procesamiento de datos. Cada transformacion se registra con marca de tiempo e ID del operador. Los registros son a prueba de manipulacion y exportables en formato estructurado para presentacion regulatoria. Para organizaciones que operan on-premise (entornos aislados donde los datos no pueden salir del edificio), la arquitectura nativa de escritorio de Data Suite significa que los registros se generan y almacenan localmente — ningun dato sale de tu infraestructura.

Agenda una llamada de descubrimiento con Ertas →

Lista de Verificacion Resumen de Cumplimiento

Usa esto como tu evaluacion de preparacion antes de la fecha limite de agosto de 2026:

Infraestructura: [ ] Registro automatico activo en produccion (no manual, no basado en muestras) [ ] Almacenamiento de registros a prueba de manipulacion implementado [ ] Politicas de retencion establecidas (minimo 6 meses; mas largo para decisiones consecuentes) [ ] Controles de acceso implementados y auditados [ ] Procedimientos de respaldo y recuperacion para datos de registro

Contenido: [ ] Cada inferencia registrada con: marca de tiempo, version del modelo, entrada, salida [ ] Decisiones de supervision humana registradas por decision [ ] Cambios de configuracion registrados [ ] Errores y casos extremos registrados

Gobernanza: [ ] Documentacion tecnica del Anexo IV recibida de proveedores (o producida internamente para sistemas que desarrollas) [ ] Base legal de procesamiento de datos documentada para retencion de registros [ ] Residencia de datos de registro confirmada (UE o jurisdiccion adecuada) [ ] Acceso a registros puede proporcionarse a la autoridad competente dentro de un plazo aceptable

Especifico del implementador: [ ] Fechas de inicio/fin del despliegue y cambios de configuracion registrados [ ] Decisiones de revision humana registradas segun los requisitos de la hoja de trabajo HITL [ ] Desviaciones de las instrucciones del proveedor documentadas

Las organizaciones que han completado esta lista de verificacion estan en una posicion defendible para el Articulo 30. Las organizaciones que no lo han hecho deben priorizar los elementos de infraestructura primero — la infraestructura de registro toma tiempo para implementarse correctamente, y el registro retroactivo de decisiones pasadas no es posible.