Ingeniería de cumplimiento del Reglamento de Inteligencia Artificial: documentación técnica, registros, supervisión y gobernanza de datos

Casi todo lo que se ha escrito sobre el AI Act trata del ámbito de aplicación: en qué nivel de riesgo cae usted, si es proveedor o responsable del despliegue, si su sistema queda atrapado por el anexo III. Eso lo responden sus asesores jurídicos.

Lo que casi nadie aborda es qué pasa después de esa respuesta. Si su sistema es de alto riesgo, el reglamento exige un sistema de gestión de riesgos que recorra todo el ciclo de vida, una gobernanza de datos que se pueda evidenciar, registros automáticos con conservación definida, documentación técnica con una estructura prescrita, supervisión humana diseñada y no simplemente afirmada, y una vigilancia poscomercialización que recoja algo de verdad. Todo eso son entregables de ingeniería. Esa es la parte que construimos nosotros.

Cómo está hoy el calendario

El Reglamento de Inteligencia Artificial (Reglamento (UE) 2024/1689) entró en vigor en agosto de 2024 y se aplica por fases. El escalonamiento cambió en 2026, y conviene ser preciso, porque ese cambio movió dinero y atención.

• 2 de febrero de 2025: se aplican las prácticas prohibidas y las obligaciones de alfabetización en materia de IA.
• 2 de agosto de 2025: se aplican las obligaciones para los modelos de IA de uso general.
• 2 de agosto de 2026: se aplican las obligaciones de transparencia del artículo 50: informar de que el usuario está interactuando con un sistema de IA, marcado del contenido sintético, información sobre reconocimiento de emociones y categorización biométrica, y etiquetado de las ultrafalsificaciones.
• 2 de diciembre de 2027: obligaciones de alto riesgo para los sistemas independientes, tras el Digital Omnibus. El Consejo y el Parlamento acordaron el aplazamiento en mayo de 2026 y recibió la aprobación definitiva en junio de 2026.
• 2 de agosto de 2028: obligaciones de alto riesgo para los sistemas de IA integrados en productos regulados.

Si usted es proveedor de un sistema de alto riesgo, el aplazamiento le ha comprado unos dieciséis meses. No ha reducido el trabajo, y no ha movido las dos obligaciones que ya están en vigor: la transparencia del artículo 50 y la alfabetización en IA del personal que opera estos sistemas.

Qué construimos

Documentación técnica como artefacto generado

El anexo IV especifica lo que debe contener la documentación técnica: descripción del sistema, decisiones de diseño, arquitectura, requisitos de datos, metodología de entrenamiento cuando proceda, procedimientos de validación y prueba, métricas, medidas de gestión de riesgos y los cambios realizados a lo largo del ciclo de vida.

Escrito a mano, ese documento queda desactualizado la semana siguiente a firmarlo. Nosotros lo construimos como algo que produce su propia canalización: fichas de modelo y de conjunto de datos generadas a partir de las ejecuciones de entrenamiento y evaluación, descripciones de arquitectura y de flujo de datos mantenidas junto al código, resultados de evaluación asociados a la versión que describen, y un historial de cambios que sale de su control de versiones y no de la memoria de alguien. El documento pasa a ser una salida del build.

Registros automáticos conformes al artículo 12

Los sistemas de alto riesgo deben registrar automáticamente durante toda su vida útil, con un nivel que permita la trazabilidad del funcionamiento y la vigilancia poscomercialización, con una conservación adecuada a la finalidad y, en algunos casos, de al menos seis meses.

En la práctica, esto significa decidir qué es un "evento" en su sistema, capturar entradas, salidas, versión del modelo, camino de decisión e identidad de la persona implicada, guardarlo de forma consultable años después, y hacerlo sin acumular datos personales que no tenga base para conservar. Esa tensión (registrar lo suficiente para el AI Act, conservar lo bastante poco para el RGPD) es el verdadero problema de diseño, y lo trabajamos de forma explícita con sus responsables de protección de datos.

Gobernanza de datos según el artículo 10

Los conjuntos de datos de entrenamiento, validación y prueba tienen que ser pertinentes, suficientemente representativos y, en la medida de lo posible, completos y sin errores, con examen de posibles sesgos. Cumplir eso exige un linaje de datos demostrable, procedencia documentada, una metodología de evaluación de sesgos con resultados, y la capacidad de reproducir qué datos produjeron qué versión del modelo.

Construimos la canalización que hace verificables esas afirmaciones en lugar de aspiracionales: conjuntos de datos versionados, particiones reproducibles, controles automáticos de calidad de datos y evaluación de sesgos sobre las características protegidas relevantes para su caso de uso.

Supervisión humana, construida y no declarada

El artículo 14 exige que los sistemas de alto riesgo se diseñen de manera que una persona pueda entender la salida, mantenerse consciente del sesgo de automatización, interpretar correctamente el resultado, decidir no utilizarlo e intervenir o detener el sistema.

Eso es una especificación de interfaz. Nosotros construimos la supervisión dentro del producto: confianza e incertidumbre expuestas con honestidad, factores que hay detrás de una salida hechos visibles, una anulación tan fácil de usar como la aceptación, un control de parada que funciona, y registro de cada anulación para que la vigilancia poscomercialización tenga de qué aprender.

Vigilancia poscomercialización y notificación de incidentes

Se exige un plan de vigilancia, y también la notificación de incidentes graves a la autoridad correspondiente. Construimos la telemetría que lo alimenta: rendimiento medido contra las métricas de su documentación, detección de deriva en entradas y salidas, un canal para los problemas reportados por usuarios que llegue hasta ingeniería, y un flujo de incidentes con los plazos de notificación incorporados de antemano y no descubiertos durante uno.

Obligaciones de transparencia del artículo 50

Ya en vigor. Informar de que el usuario trata con un sistema de IA, marcado legible por máquina del audio, la imagen, el vídeo y el texto sintéticos, etiquetado de ultrafalsificaciones e información sobre reconocimiento de emociones. Implementamos las superficies de información y el marcado de procedencia del contenido (credenciales C2PA donde ese sea el mecanismo adecuado), y hacemos que sobrevivan a las rutas de exportación y recodificación que normalmente los borran.

Apoyo al registro y a la conformidad

Los sistemas de alto riesgo de los ámbitos del anexo III deben inscribirse en la base de datos de la UE antes de su introducción en el mercado, y los proveedores deben someterse a una evaluación de la conformidad. Preparamos las entradas técnicas (la documentación, el expediente de evidencias, los artefactos del sistema de gestión de la calidad del lado de ingeniería), y trabajamos junto a su organismo notificado o a su proceso interno de evaluación.

Lo que no hacemos

No damos asesoramiento jurídico y no le decimos en qué nivel de riesgo cae su sistema. Esa determinación es jurídica, tiene consecuencias reales y corresponde a su abogado o a un asesor de cumplimiento cualificado.

Tampoco vendemos una plataforma de gobernanza de IA. Hay un campo amplio de esas, y si lo que necesita es un registro de sistemas de IA y un flujo de aprobación de políticas, una de ellas le servirá mejor que nosotros. Lo nuestro es la ingeniería dentro de los propios sistemas.

Para quién es esto

Proveedores de sistemas de IA de alto riesgo del anexo III (selección de personal y gestión de trabajadores, scoring crediticio, tarificación de seguros, evaluación educativa, acceso a servicios esenciales, sistemas biométricos), que ahora tienen hasta diciembre de 2027 y mucho que construir.

Fabricantes que incorporan IA a productos regulados (productos sanitarios, maquinaria, vehículos), donde el AI Act se superpone a un régimen de conformidad existente y los dos conjuntos de documentación tienen que ser coherentes.

Empresas que despliegan sistemas de alto riesgo comprados a terceros, que tienen obligaciones propias: supervisión humana, pertinencia de los datos de entrada, seguimiento y conservación de registros.

Cualquiera que lance funcionalidades generativas a usuarios de la UE, donde la transparencia del artículo 50 ya se aplica hoy con independencia del nivel de riesgo.

Cómo trabajamos

Evaluación técnica de brechas, de dos a cuatro semanas. Tomamos la clasificación a la que ha llegado su equipo jurídico y evaluamos sus sistemas frente a las obligaciones de ingeniería que se derivan de ella. El entregable es un registro de brechas (obligación, situación actual, qué hay que construir, esfuerzo), con el que pueden trabajar tanto su responsable de cumplimiento como su responsable de ingeniería.

Construcción, por fases, normalmente empezando por los registros y la generación de documentación, porque todo lo demás produce evidencias que tienen que aterrizar en algún sitio.

Revisión de preparación antes de la evaluación de la conformidad, con el expediente de evidencias montado y las brechas que queden nombradas con honestidad.

Normas y marcos de referencia

Reglamento (UE) 2024/1689 y sus anexos III y IV; las normas armonizadas que están saliendo del CEN/CENELEC JTC 21; ISO/IEC 42001 para sistemas de gestión de la IA e ISO/IEC 23894 para gestión del riesgo de la IA; el NIST AI Risk Management Framework cuando una matriz estadounidense necesita alineamiento; y el RGPD, que no desaparece y que condiciona la mayoría de las decisiones sobre registros.

Preguntas frecuentes

¿Se ha retrasado el Reglamento de Inteligencia Artificial?

En parte. El Digital Omnibus aplazó las obligaciones de alto riesgo al 2 de diciembre de 2027 para los sistemas independientes y al 2 de agosto de 2028 para la IA integrada en productos regulados. Las prácticas prohibidas, la alfabetización en IA, las obligaciones para los modelos de IA de uso general y las reglas de transparencia del artículo 50 no se aplazaron y están en vigor ahora.

Solo usamos sistemas de IA construidos por terceros. ¿Tenemos obligaciones?

Sí, como responsables del despliegue. Entre ellas: operar el sistema conforme a sus instrucciones, encomendar la supervisión humana a personas con la competencia y la autoridad para ejercerla, asegurar que los datos de entrada son pertinentes para la finalidad prevista, vigilar el funcionamiento y conservar los registros. Son más ligeras que las del proveedor, pero son reales, y conviene saber que modificar sustancialmente un sistema o ponerle su nombre puede convertirle en proveedor.

Nuestro sistema no es de alto riesgo. ¿Hay algo que hacer?

Probablemente dos cosas. La transparencia del artículo 50 se aplica a determinados sistemas con independencia del nivel de riesgo, incluidos los chatbots y la generación de contenido sintético. Y la alfabetización en IA del artículo 4 se aplica a proveedores y responsables del despliegue en general. Más allá de eso, poder evidenciar la decisión de clasificación es algo que merece la pena tener si algún día lo pregunta un regulador.

¿De verdad se puede generar la documentación técnica?

La mayor parte, sí. La arquitectura, las descripciones de conjuntos de datos, los resultados de evaluación, las métricas, las versiones de modelo y el historial de cambios ya existen en sus sistemas; el trabajo consiste en capturarlos en una estructura estable en tiempo de compilación. Las secciones genuinamente narrativas (finalidad prevista, análisis de riesgos, justificación del diseño) las escriben personas, y después se guardan en el mismo repositorio para que versionen con todo lo demás.

¿Cómo interactúa el Reglamento de Inteligencia Artificial con el RGPD?

Se solapan y a veces tiran en direcciones opuestas, sobre todo en materia de registros. El AI Act quiere trazabilidad; el RGPD quiere minimización y supresión. La solución suele pasar por la seudonimización, por acotar con cuidado qué se registra y por una conservación definida y ligada a una finalidad documentada. Es una decisión de diseño, tomada una vez y con intención.

¿Usar un modelo de un tercero nos convierte en proveedores de ese modelo?

No, pero construir un sistema de IA encima de él sí puede convertirle en proveedor de ese sistema, con las obligaciones que ello conlleva. Dónde cae exactamente la línea depende de qué construya y de cómo lo presente, lo que es una cuestión jurídica, pero la consecuencia de ingeniería es que debe asumir que va a necesitar documentación de su propio sistema en cualquier caso.

Primeros pasos

Cuéntenos qué hacen sus sistemas y a qué conclusión han llegado sus asesores jurídicos sobre la clasificación. Evaluaremos qué significan las obligaciones en código y le entregaremos un registro de brechas con el esfuerzo asociado a cada línea.

Contáctenos para reservar una evaluación técnica de brechas del AI Act.

Servicios relacionados

• Agentes de IA e integración MCP: construir los sistemas que este régimen regula
• Desarrollo Entrada Mercado UE: el stack más amplio de cumplimiento digital en la UE
• Remediación de accesibilidad web: la otra obligación europea que acaba siendo un proyecto de ingeniería