El Supervisor Europeo de Protección de Datos ha llevado el AI Act al terreno operativo de las propias instituciones de la Unión Europea. En una sesión de Government Innovation celebrada el 16 de septiembre, Wojciech Wiewiórowski, Supervisor Europeo de Protección de Datos, y Sonia Perez Romero, responsable de la unidad de inteligencia artificial del EDPS, presentaron el enfoque Compass para ordenar supervisión, responsabilidad y protección de datos en los usos institucionales de IA.
La sesión se centró en cómo convertir un reglamento complejo en decisiones prácticas para organismos públicos: identificar casos de alto riesgo, coordinar gobernanza de IA con protección de datos y establecer responsabilidades cuando sistemas automatizados entran en procesos internos.
El interés para otras Administraciones está en observar cómo una institución supervisora aborda el mismo problema que tendrán miles de organismos europeos: pasar del texto legal a inventarios, procedimientos, responsables y controles.
Operacionalizar el AI Act dentro del sector público
La aplicación de una norma de IA no se resuelve con una política general. Cada organismo necesita localizar sistemas, clasificarlos y decidir qué obligaciones corresponden.
El EDPS Compass se presenta como una aproximación para estructurar ese trabajo dentro de las instituciones europeas.
La sesión se dirige a responsables de políticas, delegados de protección de datos, corresponsales de IA y líderes tecnológicos, lo que refleja su carácter multidisciplinar.
La protección de datos y la gobernanza de IA se solapan
Muchos sistemas de IA utilizan datos personales, por lo que AI Act y RGPD pueden aplicarse simultáneamente.
Una evaluación de riesgo algorítmico no sustituye un análisis de protección de datos. Tampoco un cumplimiento correcto del RGPD resuelve automáticamente obligaciones específicas del AI Act.
Los organismos necesitan coordinar ambos procesos para evitar controles duplicados o vacíos.
Casos de alto riesgo como prioridad
La sesión del EDPS pone el foco en sistemas de alto riesgo. Estos casos requieren una gobernanza más intensa porque pueden afectar derechos o decisiones relevantes.
La clasificación debe realizarse a partir de la función real del sistema y no solo de la tecnología utilizada.
Un mismo modelo puede ser de bajo impacto en una tarea de resumen y mucho más sensible si interviene en recursos humanos o identificación.
Biometría: una categoría especialmente sensible
Los usos biométricos aparecen entre los ejemplos tratados por el EDPS. Identificación y categorización pueden tener consecuencias significativas sobre privacidad y derechos.
Los organismos deben analizar necesidad, proporcionalidad, precisión y alternativas antes de incorporar estos sistemas.
También deben considerar falsos positivos, sesgos y consecuencias de una identificación incorrecta.
IA en recursos humanos
Los sistemas utilizados en selección, evaluación o gestión de personas requieren especial cautela. Un modelo puede influir sobre oportunidades laborales y carrera profesional.
La supervisión humana debe permitir revisar criterios y resultados, no limitarse a confirmar una recomendación.
La gobernanza debe incluir transparencia para las personas afectadas y mecanismos de reclamación.
Inventario: el primer problema práctico
Una institución no puede gobernar sistemas que desconoce. Por eso el inventario es una pieza esencial.
Además de proyectos formalmente identificados como IA, pueden existir funciones integradas en software adquirido: clasificación automática, recomendadores o análisis de comportamiento.
El inventario debe actualizarse cuando proveedores añaden nuevas capacidades.
Shadow AI dentro de las organizaciones
El uso informal de asistentes comerciales por empleados puede quedar fuera de los procesos de aprobación.
Esto crea riesgos de datos y dificulta saber qué decisiones han recibido apoyo automatizado.
La solución no es solo prohibir. Los organismos necesitan alternativas autorizadas y reglas comprensibles.
Responsabilidad y accountability
La sesión destaca la responsabilidad como eje de la gobernanza. Debe quedar claro quién aprueba un sistema, quién lo mantiene y quién responde ante incidencias.
Un proveedor puede desarrollar la tecnología, pero la institución conserva responsabilidad sobre su uso.
Los contratos deben facilitar documentación y auditoría suficiente.
El papel de los delegados de protección de datos
Los DPO ya cuentan con experiencia en evaluación de tratamientos y riesgos. La IA amplía su ámbito de colaboración.
No deberían convertirse en únicos responsables de la gobernanza algorítmica, pero sí participar en usos que impliquen datos personales.
El modelo más sólido combina jurídico, tecnología, seguridad, negocio y protección de datos.
Corresponsales o puntos de contacto de IA
Muchas organizaciones están creando figuras internas para coordinar inventario y cumplimiento.
Estos perfiles pueden ayudar a traducir normativa, mantener documentación y escalar dudas.
La dirección sigue siendo necesaria para resolver decisiones con impacto estratégico.
Pruebas antes de producción
Los sistemas de alto impacto necesitan evaluaciones sobre datos representativos y casos extremos.
En modelos generativos, la precisión no siempre se expresa mediante una métrica única. Es necesario evaluar alucinaciones, estabilidad y comportamiento ante instrucciones maliciosas.
Las pruebas deberían repetirse cuando cambie una versión.
Documentar el propósito limita usos secundarios
Un sistema aprobado para una finalidad no debería reutilizarse automáticamente para otra.
La documentación del propósito permite evaluar si un cambio requiere nueva revisión.
Esto resulta especialmente importante cuando el modelo utiliza datos personales o produce perfiles.
Gobernanza proporcional al riesgo
No todos los usos necesitan el mismo procedimiento. Un marco excesivamente pesado puede bloquear aplicaciones de bajo riesgo.
Clasificar por impacto permite concentrar recursos de supervisión donde son más necesarios.
El enfoque basado en riesgo es también la lógica central del AI Act.
Relación con Plan IA360 y otras estrategias públicas
España está desarrollando su propia hoja de ruta con Plan IA360.
El caso del EDPS aporta una perspectiva complementaria: cómo una organización pública transforma principios de gobernanza en mecanismos internos.
Las Administraciones nacionales pueden aprender de estructuras, aunque sus marcos competenciales sean diferentes.
Transparencia hacia empleados y ciudadanos
Cuando un sistema interviene en una interacción o decisión, las personas necesitan información adecuada.
La transparencia debe explicar función, no abrumar con detalles técnicos.
Las nuevas pautas europeas sobre etiquetado y contenido generado por IA muestran la evolución del principio hacia requisitos prácticos.
Supervisión humana no puede ser simbólica
Una persona debe disponer de capacidad real para apartarse de la recomendación del sistema.
También necesita información suficiente para detectar errores.
Si la interfaz solo muestra un resultado sin contexto, la supervisión puede convertirse en una formalidad.
Logs y trazabilidad
La institución debe poder reconstruir qué versión del sistema se utilizó, qué entrada recibió y qué salida produjo.
Los registros son esenciales para investigar reclamaciones y comprobar rendimiento.
El nivel de detalle debe equilibrarse con minimización y seguridad.
Autorizaciones y agentes
A medida que los sistemas puedan ejecutar acciones, la gestión de permisos ganará importancia.
Modelos como PICEE-PA proponen separar capacidad del modelo y autorización de cada acción.
La gobernanza del AI Act tendrá que convivir con estos controles técnicos.
Interoperabilidad entre registros de IA
Si cada organismo documenta sistemas de forma distinta, la supervisión agregada se complica.
Modelos comunes de inventario pueden facilitar intercambio con autoridades y comparación.
Europa está impulsando precisamente componentes interoperables mediante herramientas como GovStack.
Contratación pública y documentación
Los proveedores deben aportar información suficiente para que la institución pueda cumplir sus obligaciones.
Esto incluye versiones, datos de entrenamiento cuando proceda, métricas, limitaciones y mecanismos de actualización.
Un contrato que impide auditar un sistema puede crear un problema de cumplimiento aunque el producto funcione correctamente.
Qué ocurre cuando cambia el modelo
Los proveedores actualizan sistemas con frecuencia. Una modificación puede alterar rendimiento o riesgo.
La gobernanza necesita criterios para decidir qué cambios requieren nueva evaluación.
Los organismos deberían evitar depender de actualizaciones invisibles en procesos sensibles.
Formación específica para responsables
La regulación de IA no puede quedar en manos de un pequeño equipo. Directivos, compradores y responsables de servicio deben comprender sus obligaciones.
Iniciativas como el ciclo directivo de la EAPC muestran que esta formación ya se está extendiendo en Administraciones.
La cultura de gobernanza reduce decisiones improvisadas.
Qué no debe interpretarse del Compass
La sesión explica cómo el EDPS está operacionalizando el marco, pero no debe utilizarse para inventar obligaciones adicionales no publicadas.
Las instituciones deben acudir a los textos legales y a la documentación oficial aplicable.
Compass funciona como modelo de implementación y supervisión dentro del contexto institucional europeo.
Fuente institucional
La sesión «AI under watch: Inside the EDPS Compass» se celebró el 16 de septiembre dentro de los iTalks on Government Innovation de la Comisión Europea.
La principal lección es que el AI Act no termina cuando una organización identifica una categoría jurídica. La implementación exige inventario, responsables, documentación, pruebas, control de proveedores y supervisión. El EDPS está convirtiendo esos elementos en práctica institucional, ofreciendo una referencia útil para otras Administraciones que ahora deben construir sus propios modelos de gobernanza.
Un registro vivo de sistemas y casos de uso
Para aplicar un marco basado en riesgo, el inventario debe contener más que el nombre del producto. Conviene registrar finalidad, unidad responsable, proveedor, datos utilizados, usuarios afectados, versión y estado del despliegue.
La información debe actualizarse cuando el sistema cambia. Un asistente inicialmente limitado a documentación interna puede adquirir nuevas funciones y pasar a interactuar con ciudadanos.
Un registro vivo permite detectar estos cambios y activar revisiones antes de que se consoliden en producción.
DPIA y evaluación del AI Act: coordinar sin duplicar
Cuando existe tratamiento de datos personales de alto riesgo, puede ser necesaria una evaluación de impacto en protección de datos. El análisis del AI Act puede exigir además controles específicos sobre el sistema.
Los equipos deberían reutilizar evidencias comunes —finalidad, datos, actores, riesgos, medidas— y mantener claras las conclusiones de cada marco.
Esta coordinación reduce carga documental y evita que dos evaluaciones independientes lleguen a descripciones contradictorias del mismo sistema.
Cláusulas de cambio de modelo
Los contratos deberían obligar al proveedor a informar de modificaciones relevantes en modelo, datos, ubicación del servicio o funciones. Una actualización silenciosa puede alterar una evaluación previa.
La institución necesita decidir qué cambios son menores y cuáles exigen nuevas pruebas. También debe conservar capacidad de aplazar una versión cuando el impacto no esté suficientemente evaluado.
Esta gobernanza es especialmente importante en servicios SaaS que evolucionan de forma continua.
Evidencias de supervisión humana
La supervisión no debería quedar descrita solo en una política. Los registros pueden mostrar cuándo una persona revisó, corrigió o rechazó una salida automática.
Analizar estas correcciones ayuda a detectar áreas donde el sistema falla con frecuencia. También demuestra que el control humano tiene efecto real.
Si casi nunca se modifica una recomendación, conviene comprobar si el sistema es realmente muy preciso o si el diseño induce aceptación automática.
Canales de reclamación y revisión
Las personas afectadas necesitan saber cómo solicitar una revisión cuando un uso de IA influye en una decisión o servicio. El procedimiento debe ser comprensible y no depender de conocimientos técnicos.
La unidad que atiende la reclamación necesita acceso a evidencias suficientes para reconstruir el caso. Esto conecta trazabilidad técnica con garantías administrativas.
Los datos de reclamaciones pueden incorporarse a la evaluación periódica del sistema.
Experimentación separada de producción
Los sandboxes y pilotos permiten probar sistemas con controles específicos, pero el paso a producción requiere una decisión explícita. Las condiciones de un entorno experimental no deben trasladarse automáticamente al servicio ordinario.
Antes del despliegue deben verificarse soporte, continuidad, permisos, documentación y responsable operativo.
Esta separación protege la innovación: permite experimentar con mayor libertad sin rebajar los requisitos del servicio estable.
Revisión independiente en usos sensibles
Para determinados casos de alto riesgo puede ser útil una revisión distinta del equipo que desarrolló o compró la solución. Esa segunda mirada reduce sesgos de confirmación y puede detectar supuestos no probados.
La independencia no necesita implicar siempre una auditoría externa. Puede organizarse mediante unidades internas con funciones separadas.
Lo importante es que la evaluación no dependa únicamente de quienes tienen interés directo en que el proyecto avance.
Gobernanza de datos de prueba
Los entornos de evaluación necesitan conjuntos representativos, pero no deberían utilizar datos personales reales sin necesidad. La anonimización, generación sintética y controles de acceso forman parte de la gobernanza.
También conviene documentar qué grupos o escenarios están representados para detectar sesgos antes de producción.
La calidad de las pruebas condiciona la calidad de cualquier conclusión sobre seguridad y rendimiento.
Retirada segura de un sistema de IA
La gobernanza también debe contemplar el final del ciclo de vida. Si un sistema deja de utilizarse, deben cerrarse accesos, conservarse las evidencias necesarias y definir qué ocurre con los datos o configuraciones asociados.
Una retirada mal gestionada puede mantener cuentas, integraciones o dependencias activas durante años. Documentar el cierre es tan importante como aprobar el inicio.
El registro institucional debería reflejar cuándo se desactiva un caso y qué obligaciones de conservación siguen vigentes.
Fotografía: Kampus Production / Pexels.