El cumplimiento empieza con la clasificación
El Reglamento Europeo de IA no se aplica de la misma forma a todos los sistemas. Antes de crear documentación, controles o procesos de QA, el equipo debe determinar en qué categoría cae el sistema: riesgo mínimo, riesgo limitado, alto riesgo o prácticas prohibidas. Esta clasificación determina las obligaciones, el nivel de evidencia y la ruta de evaluación de conformidad.
Para equipos de producto y machine learning, el error más común es tratar el cumplimiento como una tarea legal al final del proyecto. En realidad, las obligaciones relevantes afectan a datos, entrenamiento, evaluación, logging, supervisión humana, ciberseguridad, documentación y procesos de calidad. Si se dejan para el final, se vuelven mucho más costosas.
Esta checklist traduce las principales exigencias operativas en un marco de trabajo práctico para equipos que desarrollan o despliegan sistemas de IA en el mercado europeo.
1. Sistema de gestión de riesgos
Todo sistema de alto riesgo necesita un proceso continuo para identificar, evaluar, mitigar y supervisar riesgos. No basta con una matriz estática. El equipo debe documentar riesgos previsibles, escenarios de mal uso, límites del sistema, impacto potencial, controles implementados y criterios de aceptación antes y después del despliegue.
En la práctica, esto implica vincular requisitos de producto, pruebas, métricas de evaluación, revisión humana y procedimientos de escalado. Un riesgo identificado debe tener dueño, evidencia y seguimiento.
2. Gobernanza de datos
Los datasets de entrenamiento, validación y prueba deben ser adecuados para el uso previsto. Eso incluye calidad, representatividad, cobertura de casos relevantes, gestión de sesgos, procedencia, limpieza, etiquetado y documentación de limitaciones. Para sistemas basados en modelos generativos, también conviene documentar prompts de prueba, datasets dorados, métricas humanas y criterios de evaluación.
La gobernanza de datos no es solo una cuestión de volumen. Un dataset pequeño pero bien diseñado puede aportar más evidencia que millones de muestras mal documentadas. La trazabilidad de la anotación y del QA es especialmente importante para sistemas sensibles.
3. Documentación técnica
La documentación debe permitir entender cómo funciona el sistema, para qué se diseñó, cómo se entrenó o configuró, qué datos se utilizaron, qué métricas se midieron, qué limitaciones existen y cómo se gestiona el ciclo de vida. Debe ser lo bastante clara para soportar revisión interna, procurement, auditoría o evaluación de conformidad.
Un buen expediente técnico incluye descripción del sistema, arquitectura, datos, criterios de rendimiento, análisis de riesgos, controles humanos, logs, cambios de versión y resultados de evaluación. En IA generativa, también debe cubrir comportamiento esperado, pruebas de seguridad, alucinaciones, robustez y escenarios de uso no previsto.
4. Registro y logging automático
Los sistemas deben generar registros suficientes para reconstruir eventos relevantes. En un modelo de lenguaje o sistema RAG, esto puede incluir versión del modelo, configuración, prompt, contexto recuperado, respuesta, puntuaciones de confianza, decisiones humanas, flags de seguridad y resultados de evaluación. La granularidad depende del riesgo, pero la ausencia de logs impide investigar errores y demostrar control.
5. Transparencia e información al usuario
Los usuarios, clientes o deployers deben recibir información clara sobre capacidades, límites, condiciones de uso, interpretación de outputs y medidas de supervisión. En sistemas generativos, es fundamental explicar cuándo una respuesta puede ser incierta, cuándo requiere validación humana y qué decisiones no deben automatizarse únicamente con el modelo.
6. Supervisión humana
La supervisión humana no significa poner una persona simbólica al final del proceso. Debe estar diseñada para que el revisor pueda entender el output, detectar errores, intervenir, anular decisiones y escalar casos. Eso requiere interfaz, formación, criterios de revisión y métricas de calidad.
En proyectos de evaluación de LLM, la supervisión humana también incluye calibrar rúbricas, medir acuerdo entre revisores, revisar casos límite y mantener un histórico de decisiones. La supervisión solo es efectiva si está integrada en el flujo operativo.
7. Exactitud, robustez y ciberseguridad
El sistema debe evaluarse frente a métricas relevantes para su uso real. No basta con un benchmark genérico. Los equipos deben probar rendimiento por segmento, idioma, dominio, tipo de usuario, caso límite y escenario adversarial. También deben evaluar degradación, prompt injection, manipulación de inputs, fallos de recuperación y dependencia de datos externos.
8. Sistema de gestión de calidad
El cumplimiento exige procesos repetibles. Un sistema de gestión de calidad define roles, responsabilidades, revisión de cambios, control de proveedores, gestión de incidentes, documentación, QA y mejora continua. Para un equipo de IA, esto conecta MLOps, governance, seguridad, legal y producto.
Provider vs deployer: quién hace qué
Una de las fuentes de confusión más frecuentes es la diferencia entre proveedor y deployer. El proveedor desarrolla o pone el sistema en el mercado. El deployer lo utiliza en un contexto concreto. En muchos proyectos B2B, las obligaciones se reparten: el proveedor debe entregar documentación y capacidades de control, mientras que el deployer debe evaluar impacto, configurar el uso, formar usuarios y supervisar resultados.
FRIA, registro y marcado CE
Para ciertos sistemas, el deployer puede necesitar una evaluación de impacto sobre derechos fundamentales. Además, los sistemas de alto riesgo pueden requerir registro en bases de datos europeas y marcado CE según la ruta aplicable. Estos pasos no deben tratarse como trámites aislados: dependen de la evidencia técnica acumulada durante el desarrollo.
Secuencia operativa recomendada
Un enfoque realista empieza con inventario y clasificación. Después vienen gestión de riesgos, gobernanza de datos y diseño de métricas. A continuación se construye la documentación técnica, los logs, los procesos de QA y las pruebas de robustez. Finalmente se prepara la evaluación de conformidad, la documentación para deployers y el ciclo de supervisión post-despliegue.
La clave es no esperar a que el producto esté terminado. La evidencia se construye durante el desarrollo, no después.
Qué significa para los vendedores de IA
Los compradores europeos pedirán cada vez más evidencias: datasets de evaluación, trazabilidad, métricas, registros, políticas de supervisión, pruebas de robustez y documentación. Los proveedores que puedan demostrar estos elementos tendrán una ventaja comercial. Los que solo presenten demos o benchmarks públicos tendrán más dificultad en sectores regulados.
Cómo puede ayudar DataVLab
DataVLab ayuda a equipos de IA a construir evidencias humanas y datasets de evaluación para sistemas de alto impacto: soporte de cumplimiento del Reglamento Europeo de IA, evaluación de LLM, red teaming, revisión RAG, anotación de datos y QA documentado. Si necesita preparar un sistema para revisión interna, procurement o cumplimiento, contáctenos.
