La aplicación efectiva del bloque del Reglamento IA dedicado a sistemas de alto riesgo comienza en agosto. Una de las cuestiones técnicas de mayor relevancia para el sector regulado es la capacidad de reconstruir, con la precisión que la norma exige, la composición exacta del dataset que entrenó cada modelo en producción.
El Artículo 10 establece obligaciones documentales específicas sobre los datasets utilizados para entrenar, validar y probar sistemas clasificados como de alto riesgo. La distancia entre lo que se documenta habitualmente y lo que la norma exigirá demostrar a partir de agosto se resuelve fundamentalmente en la capa de arquitectura, más que en la capa de políticas.
Este análisis técnico aborda tres cuestiones concretas: qué exige reproducir el Artículo 10, qué configura una respuesta técnica suficiente ante una auditoría, y qué condiciones de arquitectura permiten alcanzarla sin reescribir los pipelines de entrenamiento.
Lo que dice el Artículo 10 del Reglamento europeo de Inteligencia Artificial
El Artículo 10 del Reglamento (UE) 2024/1689 obliga al proveedor del sistema de IA de alto riesgo a someter los datasets de entrenamiento, validación y prueba a prácticas de gobernanza y gestión de datos apropiadas. Las prácticas deben cubrir, como mínimo:
- La elección del diseño del dataset
- Los procesos de recopilación de datos
- Las operaciones de preparación (etiquetado, limpieza, enriquecimiento y agregación)
- La formulación de supuestos sobre lo que el dataset representa
- La evaluación previa de su disponibilidad, cantidad y adecuación
- El examen para detectar posibles sesgos que puedan afectar a la salud y la seguridad de las personas o producir discriminación
A esta exigencia técnica se añade una operativa: los datasets deben ser pertinentes, suficientemente representativos, libres de errores y completos en función de la finalidad prevista. Y deben tener en cuenta las características del entorno geográfico, contextual, conductual o funcional específico en el que se utilizará el sistema.
El cumplimiento del Artículo 10 se evaluará en auditoría con evidencia técnica reproducible. La descripción declarativa de las prácticas, incluso cuando está bien documentada, no opera por sí sola como demostración suficiente ante la autoridad supervisora.
El reto operativo: reconstruir la composición exacta del dataset
En la práctica habitual del ciclo de desarrollo de modelos de IA, los datasets de entrenamiento suelen construirse mediante:
- Extracciones de bases de datos productivas hacia entornos no productivos
- Transformaciones manuales o semi-automatizadas (anonimización, enmascaramiento, agregación)
- Consolidaciones en pipelines de entrenamiento, validación y prueba
- Versiones sucesivas del dataset que se acumulan a medida que el modelo evoluciona
La trazabilidad de la procedencia de cada campo, las transformaciones aplicadas y el momento en que se aplicaron es uno de los aspectos que el Reglamento europeo de IA prioriza explícitamente. En los marcos actuales, los datasets resultan funcionales para entrenar el modelo, pero su composición exacta no siempre queda registrada de forma reproducible.
Respuesta del sistema a una consulta de auditoría
La forma más útil de entender la exigencia del Artículo 10 es proyectarla sobre una pregunta concreta que la autoridad supervisora podría formular durante una auditoría documental:
"Para el modelo de detección de fraude desplegado en producción desde el 12 de marzo, indique cuántos registros con datos personales de ciudadanos no comunitarios entraron en el dataset de entrenamiento. Detalle qué transformaciones de anonimización se aplicaron a cada campo y bajo qué versión de la política de gobernanza vigente en el momento."
Sobre esta pregunta, dos arquitecturas producen respuestas radicalmente distintas:
Arquitectura A — Documentación paralela. La organización mantiene políticas escritas, registros operativos en hojas de cálculo y descripciones de pipelines en documentos de diseño. La respuesta requiere convocar al equipo de datos, recuperar el pipeline que generó la versión del dataset, intentar reconstruir las transformaciones aplicadas. Tiempo estimado de respuesta: 3 a 6 semanas. Resultado: parcial, con incertidumbre sobre la exactitud de la reconstrucción.
Arquitectura B — Evidencia reproducible. El sistema registra, para cada dato sensible incorporado al dataset, su origen (tap, tabla, columna), las transformaciones aplicadas (regla, parámetros, versión de política) y su destino (sink, modelo, entorno). La respuesta se obtiene mediante consulta directa al registro de linaje. Tiempo estimado de respuesta: minutos. Resultado: completo y verificable.
La diferencia entre ambas arquitecturas no es de calidad documental. Es estructural: depende de si la trazabilidad por campo está integrada en el comportamiento del sistema o si requiere reconstrucción puntual.
Las tres condiciones técnicas
Tres capacidades, en conjunto, permiten construir la evidencia reproducible que el Artículo 10 exigirá sin imponer sobrecarga operativa al ciclo de desarrollo de modelos. No son nuevas; lo nuevo es su exigibilidad ante una auditoría.
1. Linaje a nivel de campo
El sistema debe registrar, para cada dato sensible que entra en un dataset de entrenamiento, validación o prueba:
- Origen: tap, tabla, columna, identificador de registro
- Transformaciones aplicadas: anonimización, enmascaramiento, síntesis, agregación, con parámetros y versión de la regla
- Destino final: sink, dataset version, modelo, entorno
Esta trazabilidad debe persistir más allá del ciclo del pipeline que la generó. Si el pipeline se elimina o reescribe, el registro de linaje debe seguir disponible para responder a consultas retrospectivas. La forma habitual de lograrlo es separar la capa de registro de linaje de la capa de ejecución, con almacenamiento de eventos auditable e inmutable.
El detalle técnico de cómo se preserva el linaje sin perder integridad referencial entre tablas cuando se aplica anonimización está desarrollado en Integridad referencial al enmascarar datos: cómo preservarla y validarla.
2. Política versionada como código
Las reglas de gobernanza —qué campos se consideran sensibles, qué transformación aplica cada uno, qué excepciones existen— deben estar definidas en artefactos versionables (policy-as-code), no en documentos.
La razón es operacional. Cuando un auditor pregunta qué política regía la transformación de datos hace catorce meses, debe ser posible:
- Recuperar la versión exacta de esa política aplicable al momento en cuestión
- Demostrar quién la modificó, cuándo y bajo qué proceso de aprobación
- Reproducir el comportamiento de la política sobre un dato concreto de entonces
Esto se materializa con artefactos de política almacenados en repositorios Git, versionados con tags semánticos, integrados en pipelines CI/CD del sistema de gobernanza, y con un registro que asocia cada operación ejecutada con la versión de política aplicable en su momento.
3. Ejecución en origen
La transformación de datos sensibles se aplica antes de que el dataset abandone el perímetro controlado del entorno productivo, y no como tarea posterior aislada sobre copias ya extraídas.
Esta condición resulta especialmente relevante cuando el Reglamento IA se combina con NIS2 sobre la cadena de suministro TIC. Los entornos no productivos donde se construyen los datasets de entrenamiento entran en el perímetro regulatorio si contienen datos reales sin control equivalente al productivo. La ejecución en origen elimina la ventana de exposición entre la extracción y la anonimización.
Este principio arquitectural está expandido en Arquitectura de Seguridad por Diseño, donde se trata como motor de agilidad operativa además de cumplimiento.
Reglamento IA, NIS2 y DORA: una arquitectura, tres normas
Los tres marcos regulatorios europeos que más impacto operativo tienen sobre la gestión del dato no productivo —Reglamento IA, NIS2 y DORA— comparten un núcleo técnico común: la exigencia de evidencia auditable sobre el tratamiento de datos sensibles a lo largo de la cadena.