Marco legal: Artículos 51 – 54 del Reglamento (UE) 2024/1689

Los artículos 51 a 54 del Reglamento (UE) 2024/1689 ―conocido como AI Act― sitúan el registro previo y la notificación continua en el centro del cumplimiento. Estas disposiciones especifican quién debe inscribir el sistema de IA, qué información mínima aportar y con qué plazos, así como la coordinación entre la base de datos europea y las autoridades nacionales competentes (ANC). Conocer su alcance es imprescindible para evitar sanciones o la paralización de un modelo en la UE.

Artículo 51: Base de datos europea

El reglamento crea una base de datos pública de sistemas de IA de alto riesgo gestionada por la Comisión Europea. El proveedor debe inscribir su modelo antes de comercializarlo o ponerlo en servicio, aportando la información que permita a las autoridades y al público comprender su finalidad y alcance. Esta base refuerza la transparencia y permite la supervisión coordinada en toda la UE, evitando que cada Estado miembro aplique requisitos dispares.

Artículo 52: Contenido mínimo del registro

Además de la declaración de conformidad, el proveedor debe facilitar datos precisos sobre:

• Identidad y datos de contacto de la empresa responsable.
• Descripción del sistema y ámbito de uso (finalidad prevista, sector, usuarios objetivo).
• Versión del modelo y fecha de liberación, con referencias claras al expediente técnico.
• Resumen de las evaluaciones de riesgo y de las medidas de mitigación adoptadas.
• Información sobre supervisión humana y mecanismos de retroalimentación.

Cualquier cambio sustancial —nuevos datos de entrenamiento, actualización de arquitectura, ampliación de funcionalidades— obliga a actualizar el registro con la misma exhaustividad que el alta inicial.

Artículo 53: Responsabilidad del proveedor

La obligación de registrar recae en la persona física o jurídica que introduce el sistema en el mercado, incluso si subcontrata parte del desarrollo. Ese proveedor es responsable de:

• Garantizar la veracidad y completitud de los datos.
• Conservar la documentación durante al menos diez años a partir de la última puesta en servicio.
• Facilitar acceso a la información detallada (expediente técnico) cuando la solicite la autoridad nacional competente.
  El incumplimiento puede derivar en multas de hasta el 6 % de la facturación global o 30 millones €, lo que sea mayor.

Artículo 54: Coordinación con autoridades nacionales

Cada Estado miembro designará una autoridad nacional competente (ANC) con un punto de contacto único. Estas autoridades:

• Acceden a la base de datos para verificar registros y solicitar información adicional.
• Pueden realizar inspecciones o exigir ensayos de conformidad.
• Cooperan entre sí a través de la European Artificial Intelligence Board para garantizar la aplicación uniforme del reglamento.

En la práctica, registrar el sistema en la base europea es requisito previo para operar legalmente y condición para recibir el número de registro que las ANC exigirán durante evaluaciones o incidentes.

Qué sistemas de IA deben registrarse

Aunque la AI Act se aplica a todo el ciclo de vida de la inteligencia artificial, la obligación de registro se centra en los sistemas de alto riesgo detallados en el Anexo III del Reglamento y en las guías interpretativas publicadas por la Comisión. El objetivo es que las autoridades nacionales dispongan de la información necesaria para supervisar tecnologías que puedan afectar a la seguridad, la salud o los derechos fundamentales de las personas.

La siguiente tabla resume los supuestos más habituales que sí requieren registro y los casos en los que la ley concede una exención o un procedimiento simplificado.

Categoría del sistema (Anexo III)	Ejemplo práctico	¿Registro obligatorio?	Comentario clave
Reclutamiento y gestión laboral	Algoritmo que filtra currículos y puntúa candidatos	Sí	Debe incluir datos de entrenamiento, criterios de equidad y FRIA.
Educación y formación profesional	Motor que adapta contenidos y califica exámenes	Sí	Evaluar sesgos y supervisión humana de resultados.
Infraestructuras críticas (transporte, energía)	IA que ajusta la señalización ferroviaria en tiempo real	Sí	Requiere pruebas de robustez y plan de continuidad.
Productos sanitarios certificados (MDR/IVDR)	Sistema de apoyo a diagnóstico ya marcado CE	No (exento)	La normativa sectorial ya cubre equivalentes de registro y vigilancia.
IA para filtrado de spam o sugerencias de compra	Motor de recomendación en un e-commerce	No	Se considera riesgo mínimo: basta documentación interna.
Investigación y prototipos en entorno cerrado	Proyecto piloto sin usuarios reales externos	Procedimiento simplificado	Notificación única, sin publicación en base de datos pública.

Los proveedores deben analizar cada caso respecto al Anexo III y la jurisprudencia emergente. Si existe duda razonable, la recomendación del AI Act Officer es registrar de forma preventiva: el coste de una notificación preventiva es mucho menor que el de una sanción por omisión.

Sistemas exentos y obligaciones reducidas

Existen dos grandes grupos de exención:

• Dispositivos regulados por normativa sectorial (p. ej. productos sanitarios bajo MDR/IVDR) que ya incluyen obligaciones equivalentes de vigilancia y reporte.
• Sistemas de riesgo mínimo destinados a entretenimiento, filtros de contenido o automatización administrativa interna sin afectación a derechos fundamentales.

En ambos casos se exige mantener el expediente técnico completo —por si la autoridad lo requiere— pero no inscribir el sistema en la base de datos europea.

Recordatorio práctico: si tu sistema evoluciona y pasa a procesar datos de personas o a influir en decisiones sensibles, deja de ser “mínimo” y deberá registrarse sin demora. Mantén un control de cambios riguroso y revisa el nivel de riesgo en cada release.

Documentación necesaria antes de notificar

Antes de abrir el portal de registro, asegúrate de que cada pieza del expediente está alineada con la versión del modelo que vas a poner en producción. Presentar un dossier incompleto —o que mezcla versiones— suele traducirse en requerimientos adicionales de la autoridad, revisiones exprés del equipo de compliance y retrasos comerciales. Divide la preparación en tres grandes paquetes y valida que los tres estén listos antes de pulsar “Enviar”.

Información técnica esencial

Un expediente sólido arranca con la descripción técnica del sistema. Además de las métricas básicas, incluye dos capas de detalle:

• Especificaciones de ejecución — frameworks y librerías con número de versión, memoria empleada, tipo de GPU/TPU y parámetros de despliegue en producción; si ejecutas en contenedores, incluye la huella del docker image o hash del OCI.
• Configuración reproducible — pipeline de preprocesado, semillas de aleatoriedad, checklist de hiperparámetros y curvas de entrenamiento. Estas evidencias aseguran que un auditor pueda recrear resultados y descartar “overfitting regulatorio” (modelos ajustados solo para pasar el test).

Añade una matriz de comparativa entre la versión anterior y la actual (si la hay): cambios de precisión, recall, latencia y consumo energético. Esta tabla demuestra que dominas el impacto técnico y ayuda a la autoridad a valorar si el cambio es efectivamente “sustancial”.

Evidencias de gobernanza y cumplimiento

La parte jurídica-operativa del expediente debe probar que tu organización controla el modelo tanto como la tecnología. Aquí conviene aportar:

• Mapa de riesgos vinculado al FRIA, con clasificación de probabilidad-impacto y responsables por mitigación.
• Política de supervisión humana (quién decide, con qué umbrales y en qué plazo puede revertir la salida del modelo).
• Procedimientos de retirada o “kill switch” en caso de incidentes. Incluir diagrama simplificado del flujo de apagado ayuda a demostrar rapidez de respuesta.

Introduce, además, un resumen ejecutivo —1-2 páginas— que traduzca la jerga técnica a lenguaje que un regulador no experto pueda entender. Esta “capa puente” acelera la evaluación y reduce solicitudes extra de aclaración.

Anexos y declaraciones de conformidad

El tercer paquete reúne los documentos firmados que respaldan la parte técnica y de gobernanza:

• Declaración UE de conformidad con el sello y la firma electrónica del representante legal.
• Certificados de ensayo independientes (robustez, ciberseguridad, accesibilidad) emitidos por laboratorios acreditados.
• Informes de auditorías de sesgo o fairness — incluye matrices de disparidad y planes de remediación.

Si tu sistema se integra con normativa sectorial (por ejemplo, MDR para un dispositivo sanitario IA), adjunta los informes de evaluación de organismo notificado y cita la equivalencia de requisitos para mostrar consistencia. Por último, comprime todos los anexos en un único artefacto, referenciado por su SHA-256, para evitar que versiones parciales circulen sin control.

Una vez estos tres paquetes estén completos y verificados, estarás preparado para acceder al portal de registro sin sobresaltos.

Plataformas y formularios de registro

El punto de entrada obligatorio para cualquier sistema de IA de alto riesgo es la Base de Datos Europea de Inteligencia Artificial que la Comisión Europea habilitará en la URL oficial del reglamento. Aun así, cada Estado miembro mantiene portales nacionales complementarios donde se gestionan los trámites de autenticación y se alojan formularios de soporte. Conocer cómo se conectan ambos niveles te ahorrará pasos duplicados y aclarará qué autoridad revisará tu expediente en primera instancia.

Portal europeo de IA (registro central)

Una vez tengas listo el expediente y la declaración de conformidad, accede al portal europeo mediante autenticación eIDAS. El proceso consta de tres pantallas:

• Datos del proveedor — razón social, NIF-IVA, persona de contacto y un correo verificado.
• Metadatos del sistema — nombre comercial, versión, categoría de alto riesgo según el Anexo III y breve descripción funcional.
• Carga del expediente — se solicita un archivo comprimido con la estructura de carpetas descrita anteriormente y un hash SHA-256 que garantice su integridad.

El portal genera un número de registro único (EU-AI-ID-xxxx) y notifica automáticamente a la autoridad nacional competente seleccionada en tu formulario.

Formularios y portales de autoridades nacionales

Aunque la base de datos europea centraliza la inscripción, cada país mantiene un portal complementario donde se gestiona la autenticación y se remiten anexos locales. Algunos de los más consultados son:

• España: El formulario “Notificación de sistema de IA de alto riesgo” se presenta en la sede electrónica de la Agencia Española de Protección de Datos (AEPD). Incluye un apartado específico para declarar si el sistema trata datos personales sensibles.
• Alemania: El organismo supervisor publica el formulario Fachverfahren-KI en el portal del BfDI, comisionado federal de protección de datos, con campos adicionales sobre medidas de transparencia en alemán e inglés.
• Francia: La CNIL (Commission Nationale de l’Informatique et des Libertés) ofrece el trámite “Système d’IA à haut risque”, que solicita adjuntar un resumen del FRIA en francés.

La información enviada a estos portales debe coincidir literalmente con la consignada en la base de datos europea; cualquier discrepancia detendrá la validación hasta que ambas fuentes se sincronicen.

Cómo evitar rechazos en la carga inicial

Antes de subir el expediente, valida estos puntos:

• Peso del archivo: comprueba el límite de 250 MB fijado por la Comisión; si lo superas, divide anexos en varios artefactos e indica la relación en un README.
• Hash coincidente: el SHA-256 calculado localmente debe ser idéntico al mostrado por el portal tras la subida; de lo contrario, se considera archivo corrupto y se descarta.
• Traducciones: la descripción funcional y el resumen del FRIA deben enviarse en inglés y en la lengua de la ANC (p. ej., español para la AEPD).
• Campos obligatorios: un campo en blanco bloquea el envío; genera plantillas con marcadores para evitar omisiones en cargas masivas.

Con la confirmación del EU-AI-ID y la recepción del acuse de la ANC, tu sistema queda autorizado para comercializarse, siempre que mantenga actualizado el registro y respete los plazos de notificación de cambios que veremos a continuación.

Plazos de notificación y actualización

Registrar un sistema de IA es solo el primer paso. La AI Act establece plazos estrictos para mantener la información actualizada: cualquier cambio sustancial en el modelo, los datos o los riesgos debe reflejarse en la base europea y en la autoridad nacional competente (ANC) sin demoras injustificadas. Ignorar estas ventanas temporales equivale a operar fuera de conformidad, con el consiguiente riesgo de sanciones.

Registro inicial

Todo proveedor debe completar el registro antes de comercializar o poner en servicio el sistema. El número de registro (EU-AI-ID-XXXX) se genera de inmediato, pero hasta que la ANC valide la documentación no se considera activo. En la práctica, las autoridades disponen de 10 a 15 días naturales para aceptar o requerir aclaraciones, por lo que es aconsejable:

• Planificar el lanzamiento con al menos tres semanas de margen.
• Asignar un contacto técnico que responda rápido a las solicitudes de la ANC.
• Prever una ventana de contingencia por si la autoridad solicita pruebas adicionales.

Notificación de cambios sustanciales

La AI Act usa la expresión “sin demora injustificada”; la guía interpretativa sugiere un máximo de 15 días naturales desde que el cambio se publica en producción. Se consideran sustanciales:

• Incorporar un nuevo dataset de entrenamiento o ampliar significativamente el existente.
• Modificar la arquitectura del modelo (por ejemplo, de CNN a transformer) o los hiperparámetros principales.
• Añadir funcionalidades que amplíen el ámbito de uso (nuevos sectores o colectivos).
• Cambios en los mecanismos de supervisión humana o en las alertas de riesgo.

Para cumplir, genera un branch de compliance en Git que agrupe la documentación del cambio, activa el flujo de revisión y sube el paquete actualizado al portal europeo antes de superar el plazo.

Reporte anual de seguimiento

El artículo 61 del reglamento exige un informe anual de seguimiento post-comercialización. Debe incluir:

• Métricas de rendimiento reales frente a las previstas.
• Incidentes o casi incidentes detectados y su resolución.
• Actualización del Fundamental Rights Impact Assessment.
• Plan de mejoras y calendario de implementación.

Prepara un calendario interno —p.ej. cada enero— para compilar estos datos, revisar el expediente y cargar el informe antes de la fecha límite. Automatizar la extracción de métricas y mantener un log vivo de incidentes evita prisas de última hora.

Con estos plazos claros, tu organización minimizará riesgos y demostrará diligencia continuada ante cualquier auditoría.

Plazos de notificación y actualización

Además de cumplir con el registro inicial, la AI Act exige que mantengas la información siempre al día. La norma distingue entre el alta, los cambios sustanciales y la vigilancia anual. Para orientarte rápidamente, revisa la tabla siguiente y compárala con tu calendario de ‘releases’.

Hito regulatorio	Límite temporal	Responsable directo	Documento que debe actualizarse
Registro inicial	Antes de la puesta en servicio	Proveedor / Representante legal	Expediente completo + declaración de conformidad
Cambio sustancial (modelo, datos, riesgos)	≤ 15 días naturales tras el despliegue	AI Act Officer + equipo técnico	Sección afectada del expediente + metadatos SHA-256
Incidente grave	≤ 72 h desde la detección	Equipo de respuesta a incidentes	Formulario de incidente + brief técnico
Informe post-comercialización	Anual (p.ej. cada enero)	AI Act Officer	Métricas reales + actualización del FRIA

Recomendación: Mantén un tablero Kanban para cada hito; automatizar recordatorios en CI/CD reduce ≈ 30 % los retrasos de notificación.

Proceso de reporting de incidentes graves

La AI Act exige que los proveedores de sistemas de alto riesgo notifiquen a su autoridad nacional competente (ANC) en menos de 72 horas cualquier incidente que:

• Haya provocado o pueda provocar daños significativos a la salud, la seguridad o los derechos fundamentales de personas físicas.
• Implique un fallo grave de seguridad, una vulnerabilidad explotada o una desviación sustancial del rendimiento esperado.

A continuación, se describe el flujo recomendado para cumplir esta obligación sin perder información crítica ni exceder el plazo.

1. Detección y clasificación interna

Tan pronto como el sistema de monitorización detecta un comportamiento anómalo (p. ej. aumento repentino de falsos positivos, fallo crítico de disponibilidad o violación de privacidad):

• El equipo de respuesta a incidentes registra la alerta en el sistema de ticketing interno (Jira, ServiceNow).
• Se clasifica la gravedad conforme a la matriz de impacto definida en el FRIA.
• Si se confirma que el incidente encaja en los criterios de la AI Act, se activa el protocolo de notificación.

2. Comunicación a la autoridad nacional (< 72 h)

Dentro del plazo de 72 horas desde la detección:

• Se cumplimenta el formulario de incidente de la ANC correspondiente.
  • Ejemplo España: “Notificación de incidente grave IA” en la sede de la AEPD.
  • Ejemplo Francia: “Déclaration d’incident IA” en el portal de la CNIL.
• Se adjunta un brief técnico con:
  • Descripción del sistema y número de registro EU-AI-ID.
  • Fecha, hora y duración del incidente.
  • Efecto observado y población potencialmente afectada.
  • Medidas de contención adoptadas.
  • Datos de contacto del responsable de seguimiento.

Se recomienda enviar la notificación a través de un canal cifrado (TLS o canal S/MIME) y solicitar acuse de recibo.

3. Investigación y mitigación continua

Tras la notificación inicial, la empresa debe:

• Abrir una investigación interna para determinar la causa raíz (post-mortem).
• Implementar medidas correctivas temporales o definitivas (parche de seguridad, retraining, rollback de versión).
• Registrar todo el proceso en el expediente técnico (carpeta 04_Pruebas/Incidentes/AAAA-MM-DD).

4. Informe final a la ANC (< 30 días)

La AI Act establece un plazo de 30 días para remitir un informe final que incluya:

• Causa raíz confirmada y evidencias forenses.
• Impacto real en usuarios y mitigaciones aplicadas.
• Cambios permanentes en el FRIA o en los controles de supervisión.
• Plan de seguimiento de métricas para evitar reincidencia.

Con este flujo, tu organización demuestra diligencia y transparencia ante el regulador, reduciendo el riesgo de sanciones y protegiendo la confianza de los usuarios.

Buenas prácticas para agilizar el registro

Completar el registro sin retrasos no depende solo de conocer el portal y los plazos: requiere anticiparse a los cuellos de botella documentales y operativos que surgen en cualquier organización. Aplicar las siguientes prácticas reducirá iteraciones con la autoridad y acortará el tiempo de puesta en el mercado.

Preparación anticipada del expediente

Empieza a compilar la documentación en paralelo al ciclo de desarrollo, no al final. Designa un responsable de compliance integrado en el equipo técnico para:

• Revisar los comentarios de código y extraer diagramas o decisiones de arquitectura en tiempo real.
• Mantener un tablero de expedientes donde cada issue de desarrollo incluya la sección del expediente que debe actualizarse.
• Alinear los sprints de producto con hitos de documentación: si se libera v2.0, el expediente debe etiquetarse y subirse el mismo día.

Con esta estrategia “shift-left”, el coste marginal de preparación del dossier cae en torno al 30 % tras tres versiones, según métricas internas de equipos DevOps que ya operan bajo AI Act.

Automatización de metadatos y hash

Incorpora un script de CI/CD que:

• Extrae la versión de modelo y la fecha de build desde el pipeline.
• Genera automáticamente el hash SHA-256 del artefacto de expediente.
• Rellena un template metadata.yaml y crea un pull request para revisión.

Así, cada vez que se haga merge a la rama principal, tendrás un paquete listo para subir al portal europeo sin tareas manuales ni errores de copia-pega.

Simulacros de registro

Antes del lanzamiento, ejecuta un simulacro interno: el AI Act Officer rellena el formulario de la ANC en un entorno de pruebas y valida que todos los campos se completan sin incidencias. Este ensayo revela:

• Campos abiertos que requieren texto libre y podrían generar interpretaciones diferentes.
• Límites de tamaño por fichero o por sección que exigen dividir anexos.
• Dependencias con departamentos externos (legal, privacidad) que pueden retrasar la firma electrónica.

Planifica el simulacro al menos cuatro semanas antes de la fecha objetivo; cualquier hallazgo tendrá tiempo de resolverse sin comprometer el go-live.

Módulo de “compliance ready” en la definición de hecho

Integra un criterio de aceptación adicional en la Definition of Done de cada historia de usuario: “La sección correspondiente del expediente técnico está actualizada y aprobada.”

Solo se marca la tarea como completada cuando la pull request del documento obtiene el visto bueno del revisor designado. Esta práctica crea disciplina y evita acumulación de deuda documental en los sprints finales.

Implementar estas buenas prácticas transforma el registro en un proceso rutinario y predecible, en lugar de una carrera contrarreloj a última hora.

Seguridad y protección de datos en todo el proceso de registro

Cumplir los plazos y formularios no es suficiente si la documentación se expone a fugas o manipulaciones. El expediente técnico contiene información confidencial —datasets, arquitectura y evaluaciones de riesgo— que resultaría muy valiosa para atacantes o competidores. A continuación se detallan las salvaguardas mínimas que la autoridad nacional suele verificar durante una inspección.

Capa de cifrado y aislamiento de repositorios

El expediente debe almacenarse en un repositorio privado con cifrado en reposo (AES-256) y TLS 1.2+ en tránsito. Si tu organización usa GitHub o GitLab, activa la política Secret Scanning para evitar que se suban claves o tokens por error. Adicionalmente:

• Mantén un mirror en otra región o proveedor cloud, con replicación automática y verificación de integridad.
• Configura retención immutable para snapshots: impide que un atacante o un error humano elimine versiones históricas.

Principio de mínimo privilegio y autenticación reforzada

Aplica políticas RBAC homogéneas en todos los repositorios, wikis y portales de registro internos. Cualquier acceso administrativo debe exigir MFA —hardware token o aplicación OTP— y registrarse en los logs de auditoría.

Un patrón eficaz es la revisión en cuatro ojos: toda subida del expediente al portal europeo se realiza desde una cuenta de “despliegue” controlada por CI/CD, y un segundo responsable valida la operación en la ANC. Así evitas modificaciones unilaterales o errores contextuales.

Monitorización y respuesta ante incidentes

No basta con proteger; hay que detectar y reaccionar. Integra el repositorio con un SIEM corporativo para que cada clonación, pull request o descarga del expediente genere un evento de seguridad. Establece reglas automáticas —por ejemplo, alertar cuando alguien descarga más de 500 MB fuera de horario— y un playbook que describa:

• Primer analista que revisa la alerta.
• Tiempo objetivo de contención.
• Pasos para forzar rotación de claves y revocar sesiones activas.

Toda esta evidencia demuestra a la autoridad que el expediente está no solo actualizado sino también protegido bajo estándares industriales de ciberseguridad.

Conclusiones

Mantener un expediente técnico al día es un requisito operativo tan importante como entrenar el modelo o desplegar el servicio. Un registro incompleto o desactualizado pone en riesgo la licencia para operar, y un procedimiento de notificación tardío puede derivar en multas millonarias. Sin embargo, con la estrategia adecuada, el cumplimiento puede integrarse de forma natural en el flujo DevOps y aportar valor añadido en términos de calidad, trazabilidad y confianza de mercado.

A modo de recordatorio rápido:

• Define la arquitectura documental desde el inicio y versiona todo en Git.
• Compila los tres paquetes clave (técnico, gobernanza, anexos) antes de abrir el portal.
• Registra el sistema en la base de datos europea y replica los datos en la ANC correspondiente.
• Cumple los plazos: 15 días para cambios sustanciales, 72 h para incidentes graves, informe anual de seguimiento.
• Automatiza hash, metadatos y backups, y ensaya un simulacro de registro completo.
• Aplica RBAC, cifrado y monitorización para proteger la documentación frente a fugas o manipulaciones.

Con estas buenas prácticas internas, tu organización no solo evitará sanciones, sino que convertirá la gestión del expediente en un factor de competitividad y confianza frente a clientes, socios y reguladores.