La IA en la admisión de estudiantes: clasificación de alto riesgo en virtud del Anexo III de la Ley de IA de la UE
La IA de admisión es de alto riesgo en virtud del Anexo III, punto 3. Obligaciones de proveedor y responsable del despliegue, EIDF, riesgo de discriminación y el plazo del 2 de diciembre de 2027.
Una universidad que despliega un sistema de IA para clasificar a los solicitantes y determinar quién obtiene una plaza no está utilizando una herramienta de conveniencia — está operando un sistema de IA de alto riesgo en virtud del Reglamento (UE) 2024/1689. Esa designación no es una cuestión de opinión. El Anexo III, punto 3, de la Ley de IA de la UE enumera los sistemas de IA utilizados para determinar el acceso o la admisión a instituciones educativas y de formación profesional de todos los niveles como categóricamente de alto riesgo. La pila de obligaciones que se deriva — gestión de riesgos, documentación técnica, supervisión humana, evaluación de la conformidad, registro — se aplica a todo sistema que responda a esa descripción, con independencia del tamaño de la institución o de la exactitud que el sistema afirme tener.
El plazo de cumplimiento para los sistemas de IA de alto riesgo autónomos del Anexo III es el 2 de diciembre de 2027. En virtud del Ómnibus Digital acordado en mayo de 2026, esa fecha sustituyó a la fecha original del 2 de agosto de 2026. No es un objetivo flexible. Solo la documentación lleva meses ensamblarla; las instituciones que empiecen a finales de 2027 no terminarán a tiempo.
Qué hace de alto riesgo a un sistema de admisión
El desencadenante del Anexo III, punto 3, es la función que desempeña el sistema: determinar el acceso o la admisión, o asignar personas físicas a una institución educativa o de formación profesional. Un sistema que criba a los solicitantes antes de que los vea un humano, clasifica a los candidatos y alimenta esa clasificación en una decisión final, o automatiza la generación de ofertas, está dentro del ámbito de aplicación. El Anexo también cubre la IA utilizada para evaluar los resultados del aprendizaje y para supervisar a los estudiantes en busca de trampas en los exámenes — pero esas son funciones independientes. Esta página aborda el ángulo de la admisión y la asignación.
El Artículo 6, apartado 3, ofrece una salida estrecha: un sistema no es de alto riesgo si no plantea un riesgo significativo de perjuicio para la salud, la seguridad o los derechos fundamentales. La Ley enumera cuatro situaciones en las que esto puede aplicarse — desempeñar una tarea procedimental limitada, mejorar el resultado de una actividad humana previamente realizada, detectar patrones de toma de decisiones sin sustituir ni influir en la evaluación humana, o realizar un trabajo preparatorio. Todo sistema que elabore perfiles de personas físicas es automáticamente de alto riesgo, con independencia de cualquier otro factor. Para la mayoría del software de admisión, la salida del Artículo 6, apartado 3, no está disponible. El sistema está decidiendo quién entra. Eso afecta al derecho a la educación en virtud del artículo 14 de la Carta de los Derechos Fundamentales de la UE y conlleva un alto potencial de perjuicio para cualquier persona excluida.
Los proveedores que crean que pueden apoyarse en el Artículo 6, apartado 3, deben documentar el razonamiento por escrito y registrar el sistema en la base de datos de la UE en virtud del Artículo 49 de todos modos. La exención no es de aplicación automática.
Proveedor frente a responsable del despliegue: quién soporta qué
El proveedor del software de admisión y la institución que lo despliega ocupan posiciones jurídicas diferentes en virtud de la Ley, con obligaciones diferentes.
El proveedor (Artículo 16)
El proveedor es la empresa que desarrolla e introduce el sistema de IA de admisión en el mercado — el proveedor de tecnología educativa (EdTech), la empresa SaaS, quienquiera que haya construido y comercialice el sistema. Las obligaciones del proveedor son el nivel más pesado:
- Artículo 9 — establecer y mantener un sistema de gestión de riesgos a lo largo del ciclo de vida del sistema, identificando y mitigando los riesgos previsibles, incluidos los resultados discriminatorios.
- Artículo 10 — implementar procedimientos de gobernanza de datos que cubran la composición, el etiquetado, las lagunas, los sesgos y las propiedades estadísticas de los datos de entrenamiento. Los datos históricos de matriculación son una fuente de sesgo bien documentada (véase más abajo); el Artículo 10 exige al proveedor abordarlo directamente.
- Artículo 11 — preparar y mantener la documentación técnica conforme al Anexo IV, que cubra el diseño del sistema, la finalidad prevista, la metodología de entrenamiento, las métricas de rendimiento desglosadas por subgrupos pertinentes y el registro de gestión de riesgos.
- Artículo 13 — garantizar que el sistema sea transparente para los responsables del despliegue, incluidas sus capacidades, limitaciones y las circunstancias que requieren supervisión humana.
- Artículo 14 — diseñar el sistema de modo que los responsables del despliegue puedan implementar eficazmente la supervisión humana, incluida la capacidad de anular, interrumpir y supervisar.
- Artículo 15 — garantizar una exactitud, robustez y ciberseguridad apropiadas a lo largo del ciclo de vida del sistema. Para los sistemas de admisión, el rendimiento debería validarse en los distintos grupos demográficos, no solo en el conjunto de datos agregado.
- Artículo 43 — completar una evaluación de la conformidad antes de introducir el sistema en el mercado. Para la mayoría de los sistemas del Anexo III, punto 3, esto es una autoevaluación en virtud del Anexo VI (control interno), salvo que el sistema utilice datos biométricos, en cuyo caso puede requerirse la intervención de un organismo notificado. La evaluación de la conformidad debe documentarse y mantenerse disponible.
- Artículo 47 — redactar una declaración UE de conformidad una vez completada la evaluación de la conformidad.
- Artículo 49 — registrar el sistema en la base de datos de la UE antes de comercializarlo.
- Artículo 73 — notificar los incidentes graves a la autoridad nacional competente.
El responsable del despliegue (Artículo 26)
El responsable del despliegue es el colegio, la universidad, el centro de formación o la autoridad pública que pone el sistema en funcionamiento. Los responsables del despliegue no quedan exentos simplemente porque otro haya construido el sistema. El Artículo 26 exige a los responsables del despliegue:
- Utilizar el sistema únicamente de conformidad con las instrucciones del proveedor y para su finalidad prevista.
- Garantizar que las personas físicas asignadas a la supervisión humana sean competentes para la tarea — deben comprender los resultados y las limitaciones del sistema, y deben tener autoridad genuina para anularlo o pausarlo.
- Supervisar el funcionamiento de forma continua y notificar los incidentes graves al proveedor en virtud del Artículo 73.
- Conservar los registros del funcionamiento del sistema durante al menos seis meses en virtud del Artículo 26.
- Informar a los solicitantes o a sus representantes de que se está utilizando un sistema de IA en el proceso de admisión, cuando esto no sea obvio (Artículo 26).
Si el responsable del despliegue modifica sustancialmente el sistema, cambia su finalidad prevista o pone su propio nombre en él, el Artículo 25 desencadena un cambio de función: el responsable del despliegue se convierte en proveedor y hereda todas las obligaciones del proveedor.
El requisito de la EIDF para los responsables del despliegue que son organismos públicos (Artículo 27)
El Artículo 27 exige a los responsables del despliegue que sean autoridades públicas — y a los responsables del despliegue que operan bajo mandato público — llevar a cabo una evaluación de impacto relativa a los derechos fundamentales antes de desplegar un sistema de IA de alto riesgo. La mayoría de las universidades de los Estados miembros de la UE son organismos públicos o están financiadas con fondos públicos. Una institución privada queda comprendida si presta un servicio de interés público o si está sujeta a una obligación equivalente a la de una autoridad pública en virtud del Derecho nacional.
La EIDF no es lo mismo que una evaluación de la conformidad. Es una obligación adicional que el responsable del despliegue soporta con independencia del trabajo del Artículo 43 del proveedor. Debe evaluar:
- La naturaleza y el contexto del despliegue (admisión en qué nivel, para qué programas, con qué criterios de selección).
- El posible impacto sobre el derecho a la educación y la no discriminación, incluidos los efectos sobre grupos históricamente infrarrepresentados.
- Si el sistema trata datos personales de categorías especiales en virtud del Artículo 9 del RGPD (información sobre discapacidad, origen étnico, religión) y si existe una base jurídica para ese tratamiento.
- Qué vías de recurso tienen los solicitantes si creen que el sistema se aplicó de forma injusta.
Los responsables del despliegue del sector público deben registrar la EIDF completada en la base de datos de la UE (Artículo 49) y ponerla a disposición del público. La EIDF es un documento vivo — debe revisarse siempre que el sistema o el contexto de despliegue cambien materialmente.
El problema de la discriminación en los datos de admisión
Entrenar una IA de admisión con datos históricos de matriculación no produce un sistema neutral. Produce un sistema que refleja cualquiera que sea la lógica de selección que dio forma a ese conjunto de datos histórico — incluidos, con frecuencia, patrones que favorecieron a los solicitantes de determinados orígenes socioeconómicos, tipos de centro o códigos postales, no porque esos factores sean criterios de selección legítimos, sino porque se correlacionaban con las preferencias institucionales del pasado.
Tres mecanismos impulsan este riesgo:
Variables indirectas (proxy). Aun cuando las características protegidas (etnia, condición de discapacidad, origen socioeconómico) se eliminan del conjunto de características, el modelo puede reconstruir su señal a través de variables correlacionadas: el nombre del centro de secundaria al que se asistió, el municipio del solicitante, la elección de actividades extracurriculares, la estructura de la carta de motivación. Un modelo que puntúa sistemáticamente más bajo a los solicitantes de un código postal concreto está discriminando sobre un indicador indirecto del estatus socioeconómico, aunque nunca vea datos de ingresos.
Infrarrepresentación en los datos de entrenamiento. Si los grupos históricamente desfavorecidos fueron admitidos a tasas más bajas, los datos de entrenamiento contienen menos ejemplos exitosos de esos grupos. El modelo aprende que esos perfiles predicen un menor éxito — y luego perpetúa la exclusión de los mismos perfiles para los que tiene la señal menos fiable.
Bucles de retroalimentación. Si el proceso automatizado admite a menos estudiantes de grupos infrarrepresentados, esos grupos siguen infrarrepresentados en los futuros datos de entrenamiento, y la siguiente iteración del modelo reproduce o empeora el mismo patrón. Sin una intervención deliberada, el sistema se autorrefuerza.
El Artículo 10, apartado 2, letra f), exige a los proveedores examinar los datos de entrenamiento en busca de posibles sesgos y adoptar las medidas de mitigación apropiadas. El Artículo 9, apartado 2, exige que el sistema de gestión de riesgos aborde la discriminación como un riesgo previsible. Ninguno de los dos artículos indica al proveedor exactamente qué métrica de equidad utilizar — paridad demográfica, igualdad de probabilidades, probabilidad calibrada — porque ninguna métrica única es la adecuada para todos los contextos. Lo que la Ley exige es que el proveedor tome una decisión documentada y razonada, la explique a los responsables del despliegue y haga un seguimiento de la divergencia demográfica tras el despliegue.
Para los responsables del despliegue, la obligación de EIDF del Artículo 27 es el mecanismo para examinar si el sistema, tal como se despliega en su contexto específico, produce resultados equitativos. Un análisis general de equidad a nivel del proveedor no puede sustituir a una evaluación específica del contexto a nivel del responsable del despliegue.
El Artículo 22 del RGPD y la prohibición de las decisiones exclusivamente automatizadas
Cuando una decisión de admisión se adopta exclusivamente por medios automatizados y produce un efecto jurídico o un efecto significativo similar sobre el solicitante, el Artículo 22 del RGPD se aplica con independencia de la Ley de IA de la UE. El Artículo 22 otorga a los interesados el derecho a no ser objeto de tales decisiones, salvo que se cumpla una de tres condiciones: que la decisión sea necesaria para un contrato, esté autorizada por el Derecho de la Unión o de los Estados miembros, o se base en el consentimiento explícito.
Para la mayoría de las decisiones de admisión educativa, la base contractual solo se aplica cuando la institución es privada y el solicitante entra en una relación comercial. Para las instituciones públicas, la base de tratamiento lícito suele ser la potestad oficial en virtud del Artículo 6, apartado 1, letra e), del RGPD, que permite la toma de decisiones automatizada solo si la decisión también está autorizada por el Derecho de los Estados miembros y se establecen salvaguardias adecuadas.
La consecuencia práctica: las instituciones no deberían diseñar su proceso de admisión de modo que el sistema de IA tome la decisión final sin un humano en el bucle. Eso no es meramente una buena práctica — es un requisito legal en virtud del Artículo 22 cuando el solicitante no tiene ninguna otra interacción con un responsable humano de la toma de decisiones antes de que se emita una oferta o un rechazo. El requisito de supervisión humana del Artículo 14 de la Ley de IA de la UE y el Artículo 22 del RGPD se refuerzan mutuamente aquí. Documente ambas bases jurídicas.
Ejemplo práctico: una universidad alemana de tamaño medio
Una universidad estatal de Alemania utiliza una herramienta de admisión construida por una empresa de tecnología educativa con sede en Berlín. El software ingiere las solicitudes, las puntúa frente a un modelo entrenado con cinco años de datos históricos de admisión y produce una lista ordenada. La oficina de admisiones utiliza esa lista ordenada para enviar ofertas condicionales.
Las obligaciones del proveedor. El proveedor berlinés es el proveedor. Antes de introducir el software en el mercado alemán debe completar una evaluación del sistema de gestión de riesgos del Artículo 9 — documentando cómo probó el sesgo demográfico, qué medidas de mitigación implementó y qué riesgos residuales subsisten. Debe preparar la documentación técnica del Anexo IV que cubra la arquitectura del modelo, la composición de los datos de entrenamiento (incluido si se detectó un sesgo histórico y cómo se abordó) y las métricas de rendimiento desglosadas por género, condición de estudiante de primera generación y Bundesland de origen. Debe completar una evaluación de la conformidad del Artículo 43, emitir una declaración UE de conformidad del Artículo 47 y registrarse en la base de datos de la UE en virtud del Artículo 49 antes de que el software salga al mercado.
Las obligaciones de la universidad. Como organismo público, la universidad es un responsable del despliegue sujeto al Artículo 26 y al requisito de EIDF del Artículo 27. Antes de entrar en producción, debe completar una EIDF — evaluando cómo el resultado de la lista ordenada afecta al acceso de los estudiantes con formación de escuela profesional, los estudiantes con discapacidad y los estudiantes de los estados del este de Alemania históricamente infrarrepresentados en la matriculación de la institución. La EIDF debe registrarse en la base de datos de la UE. La universidad debe designar a personal formado para revisar la lista ordenada, con autoridad documentada para anular o reordenar el resultado de la IA. Debe conservar los registros de funcionamiento durante al menos seis meses e informar a los solicitantes de que se utiliza IA en el proceso. También debe verificar que los datos que introduce en el sistema — sus expedientes históricos de solicitantes — sean exactos y suficientemente representativos.
La superposición del Artículo 22 del RGPD. La lista ordenada no es la decisión final; el personal humano emite las ofertas. Ese diseño mantiene a la universidad fuera de la prohibición pura de las decisiones automatizadas. Pero la institución debería documentar que la revisión humana es genuina y no meramente ceremonial — que los revisores ejercen realmente su juicio sobre los casos cercanos al umbral, que el resultado de la IA no determina de hecho el resultado para el 70 % inferior de la lista sin ninguna consideración humana.
Plazo. Tanto el proveedor como la universidad deben cumplir antes del 2 de diciembre de 2027.
Cómo ayuda Confir
El cumplimiento de la IA de admisión implica obligaciones en dos frentes: el lado del proveedor (gestión de riesgos, documentación técnica, evaluación de la conformidad) y el lado del responsable del despliegue (EIDF, supervisión humana, registro). Confir cubre ambos.
La admisión de clasificación de Confir formula preguntas en lenguaje sencillo sobre qué hace el sistema, quién lo construyó y cómo se despliega. Las mismas respuestas de admisión producen un mapa de obligaciones estructurado — identificando si usted es un proveedor, un responsable del despliegue o ambos, y qué artículos se aplican. La lógica de clasificación es basada en reglas y determinista: las mismas respuestas producen siempre el mismo hallazgo, con la regla que se activó visible y auditable.
Para los responsables del despliegue que son organismos públicos, Confir ejecuta el flujo de trabajo de la EIDF del Artículo 27 — una evaluación estructurada en siete secciones que cubre la exposición a los derechos fundamentales, la licitud con arreglo al RGPD, el riesgo de resultados discriminatorios, las obligaciones de transparencia y las vías de recurso. El resultado es un documento de EIDF con formato listo para el registro.
Para los proveedores, Confir genera el paquete de documentación técnica del Anexo IV y la declaración UE de conformidad del Artículo 47. La puntuación de salud del cumplimiento hace un seguimiento del progreso en las obligaciones de los Artículos 9, 10, 11, 13, 14 y 15, señalando lo que está hecho, lo que está en curso y lo que falta.
Sin consultores, sin una implementación de seis meses.
Preguntas frecuentes
¿Cubre el Anexo III, punto 3, toda la IA educativa, o solo las admisiones universitarias? El punto 3 cubre la admisión y la asignación a instituciones educativas «de todos los niveles» — primaria, secundaria, formación profesional, educación superior y formación continua. Un sistema de sorteo de escuela primaria que utiliza IA para asignar a los niños a los colegios, un programa de formación profesional que utiliza IA para clasificar a los solicitantes según la preparación laboral prevista y una herramienta de admisión de grado universitario están todos dentro del ámbito de aplicación. La exención de tarea limitada del Artículo 6, apartado 3, puede aplicarse a herramientas puramente procedimentales (comprobadores de completitud de documentos, sistemas de recordatorio de plazos) que no desempeñan ningún papel en la determinación de quién es admitido.
¿Es una empresa que vende software de admisiones a las universidades un proveedor en virtud de la Ley? Sí. Si la empresa introduce el software en el mercado de la UE o lo pone en servicio bajo su propio nombre o marca, es un proveedor en virtud del Artículo 3, apartado 3, y debe cumplir todas las obligaciones del Artículo 16, incluidos el Artículo 9 (gestión de riesgos), el Artículo 11 (documentación técnica) y el Artículo 43 (evaluación de la conformidad). El tamaño no es un umbral — una startup de tecnología educativa de cinco personas que vende a una sola universidad soporta las mismas obligaciones formales que un gran proveedor. El tope sancionador para pymes del Artículo 99, apartado 6, ofrece cierta protección de proporcionalidad en la ejecución, pero no renuncia a las obligaciones subyacentes.
¿Qué ocurre si la institución modifica el sistema de IA que suministró el proveedor? Si la modificación es sustancial — cambiando la finalidad prevista, la arquitectura del modelo o el alcance del sistema de un modo que crea nuevos riesgos —, se aplica el Artículo 25. La institución pasa de responsable del despliegue a proveedor y asume todas las obligaciones del proveedor para el sistema modificado. Las instituciones que integran la IA de admisión de un proveedor en un sistema interno más amplio de apoyo a la decisión, o reentrenan el modelo con sus propios datos, deberían asesorarse jurídicamente sobre si eso constituye una modificación sustancial antes de proceder.
¿Cuáles son las sanciones por el incumplimiento? El incumplimiento de las obligaciones de alto riesgo atrae multas de hasta 15.000.000 € o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor, en virtud del Artículo 99, apartado 4. Para las pymes y las empresas emergentes, la multa se limita al menor de los dos importes — el nivel del porcentaje, no la cantidad fija, si esta es menor. Las autoridades competentes también pueden ordenar la suspensión de los sistemas o su retirada del mercado.
¿Sigue aplicándose el RGPD por separado? Sí. La Ley de IA de la UE no desplaza al RGPD. Los sistemas de IA de admisión que tratan datos personales — que es lo que hacen todos — deben tener una base lícita en virtud del Artículo 6 del RGPD, y si tratan datos de categorías especiales (discapacidad, etnia) también en virtud del Artículo 9. Cuando las decisiones de admisión se adoptan exclusivamente por medios automatizados, se aplica el Artículo 22 del RGPD y restringe esa práctica salvo que exista una base jurídica específica. Los interesados tienen derechos de acceso, rectificación y explicación que operan con independencia de las obligaciones de la Ley de IA de la UE.
¿Cuándo debe estar establecido el cumplimiento? El plazo de alto riesgo para los sistemas autónomos del Anexo III es el 2 de diciembre de 2027, tras el aplazamiento del Ómnibus Digital acordado en mayo de 2026. La fecha original del 2 de agosto de 2026 ya no se aplica. Sin embargo, las evaluaciones de la conformidad, la documentación técnica y las EIDF llevan un tiempo sustancial de preparación — es improbable que las instituciones y los proveedores que comiencen el trabajo serio de cumplimiento a mediados de 2027 terminen antes del plazo.
Guías relacionadas
- clasificación de alto riesgo del Artículo 6
- determine si su sistema cumple los requisitos
- requisitos de gestión de riesgos del Artículo 9
- obligaciones de cumplimiento del Artículo 8
- requisitos de los sistemas de IA de alto riesgo
- realice una evaluación de riesgos
- guía de clasificación de riesgo de la Ley de IA de la UE
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →