Artículo 3 de la Ley de IA de la UE: definiciones clave y qué significan para sus obligaciones
El Artículo 3 de la Ley de IA de la UE define el sistema de IA, el proveedor, el responsable del despliegue y el modelo de GPAI. Comprenda su papel y sus obligaciones con arreglo al Reglamento (UE) 2024/1689.
El Artículo 3 del Reglamento (UE) 2024/1689 contiene 83 definiciones. Esa cifra no es una anécdota: refleja cuánta parte de la lógica de cumplimiento de la Ley reside en el nivel definitorio, antes incluso de llegar a las obligaciones sustantivas. Que una sanción de 35 millones de euros recaiga o no sobre su organización depende, en primera instancia, de si el sistema que opera tiene la consideración de «sistema de IA» con arreglo al Artículo 3, apartado 1, y de qué papel le asigna el Artículo 3. Si se yerra en las definiciones, todo paso de clasificación posterior se construye sobre un terreno defectuoso.
Esta guía recorre las definiciones de carga: qué dicen, cómo refinan la interpretación las orientaciones de la Comisión de febrero de 2025 sobre la definición de sistema de IA y —de forma crítica— cómo confundir «proveedor» con «responsable del despliegue» le expone a un conjunto enteramente distinto de deberes legales.
Qué entiende la Ley de IA de la UE por «sistema de IA»
El Artículo 3, apartado 1, define un sistema de IA como:
«un sistema basado en una máquina diseñado para funcionar con distintos niveles de autonomía, que puede mostrar capacidad de adaptación tras el despliegue y que, para objetivos explícitos o implícitos, infiere, a partir de la información de entrada que recibe, cómo generar información de salida como predicciones, contenidos, recomendaciones o decisiones que pueden influir en entornos físicos o virtuales».
Aquí importan cuatro elementos.
Basado en una máquina. El sistema debe ejecutar su lógica de forma automática. Un analista humano que se apoya en datos para redactar una recomendación no es un sistema de IA. Un algoritmo que genera esa recomendación a partir de los mismos datos sí lo es.
Distintos niveles de autonomía. La definición no exige una autonomía plena. Un sistema que siempre requiere la aprobación humana de su salida sigue teniendo la consideración de sistema de IA, siempre que su lógica opere con independencia de ese humano en el paso de inferencia.
Inferencia a partir de la información de entrada. Este es el umbral definitorio que separa los sistemas de IA del resto del software. Un motor de reglas estático —«si el campo X es igual a Y, devuélvase Z»— aplica una lógica predeterminada sin inferencia. Un sistema que aprende patrones de los datos de entrenamiento y los aplica a nuevas entradas infiere y, por tanto, tiene la consideración de sistema de IA. Los casos límite son reales: una herramienta de detección de fraude que utiliza reglas de umbral fijo queda fuera de la definición; la misma herramienta con una capa de aprendizaje automático que ajusta esos umbrales en función del historial de transacciones queda dentro.
Influencia en entornos físicos o virtuales. Las salidas deben tener alcance más allá del propio sistema. Un modelo que clasifica datos con fines de archivado interno y cuya salida nunca da lugar a actuación alguna se sitúa en el límite. Un motor de recomendación que conforma lo que ven los usuarios, una alerta de mantenimiento predictivo que desencadena la parada de un equipo o una herramienta de cribado de RR. HH. que determina quién avanza en un proceso de contratación cumplen claramente, todos ellos, el criterio.
Las directrices de la Comisión de febrero de 2025
En febrero de 2025, la Comisión Europea publicó orientaciones para ayudar a los operadores a aplicar en la práctica la definición del Artículo 3, apartado 1, señalando una dificultad particular con el criterio de inferencia. Las directrices aclaran que la atención se centra en si el sistema utiliza un enfoque de aprendizaje automático o estadístico que generaliza a partir de los datos de entrenamiento, no en si utiliza una arquitectura técnica concreta. Un sistema entrenado con conjuntos de datos etiquetados y utilizado para clasificar nuevas entradas es un sistema de IA aunque su arquitectura sea relativamente simple. Una tabla de consulta, en cambio, no lo es. Las directrices confirman asimismo que la capacidad de adaptación tras el despliegue —la capacidad de actualizar su comportamiento a partir de nuevos datos sin reprogramación explícita— es una condición suficiente pero no necesaria; un sistema puede ser un sistema de IA sin mostrar adaptación posterior al despliegue, siempre que se cumplan los demás elementos.
Para la clasificación práctica: si su sistema hace predicciones, genera contenidos, emite recomendaciones o produce decisiones procesando entradas a través de un modelo entrenado con datos, trátelo como un sistema de IA salvo que disponga de una base técnica documentada para sostener lo contrario.
Los papeles que determinan sus obligaciones
Proveedor — Artículo 3, apartado 3
Un proveedor es una persona física o jurídica que desarrolla un sistema de IA o un modelo de IA de uso general y lo introduce en el mercado o lo pone en servicio bajo su propio nombre o marca, ya sea a cambio de pago o gratuitamente.
Tres elementos desencadenan la condición de proveedor. Primero, debe haber desarrollado el sistema —o haber encargado su desarrollo y conservado un control significativo sobre el diseño, los datos de entrenamiento y los parámetros de rendimiento—. Segundo, debe introducirlo en el mercado o ponerlo en servicio (véanse esas definiciones más abajo). Tercero, lleva su nombre o marca, o usted lo presenta de otro modo como un producto propio.
Las obligaciones del proveedor para los sistemas de IA de alto riesgo se establecen en el Artículo 16. La lista es la más onerosa de la Ley: un sistema de gestión de riesgos con arreglo al Artículo 9; datos y gobernanza de datos con arreglo al Artículo 10; documentación técnica con arreglo al Anexo IV (Artículo 11); conservación de registros y archivos de registro con arreglo al Artículo 12; transparencia hacia los responsables del despliegue con arreglo al Artículo 13; capacidades de supervisión humana incorporadas en el sistema con arreglo al Artículo 14; normas de exactitud, robustez y ciberseguridad con arreglo al Artículo 15; un sistema de gestión de la calidad con arreglo al Artículo 17; y la evaluación de la conformidad antes de la introducción en el mercado con arreglo al Artículo 43, seguida del registro en la base de datos de la UE con arreglo al Artículo 49.
El techo sancionador por incumplimiento de las obligaciones del proveedor es de 15 millones de euros o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor (Artículo 99, apartado 4). Para las infracciones de las prohibiciones del Artículo 5 —la categoría de prácticas prohibidas—, el techo asciende a 35 millones de euros o el 7 % (Artículo 99, apartado 3). Para las empresas que sean pymes o empresas emergentes, el Artículo 99, apartado 6, limita la multa al menor de los dos importes, el porcentaje o la cantidad fija —una protección de proporcionalidad genuina que conviene conocer.
Responsable del despliegue — Artículo 3, apartado 4
Un responsable del despliegue es una persona física o jurídica que utiliza un sistema de IA bajo su propia autoridad en el ejercicio de su actividad profesional, salvo cuando el sistema se utilice en el ejercicio de una actividad personal de carácter no profesional.
La expresión clave es «bajo su propia autoridad». Usted es responsable del despliegue si controla el contexto en el que opera el sistema: fija los parámetros de entrada, determina para qué se utilizan las salidas del sistema y es responsable de lo que ocurra aguas abajo de las decisiones del sistema. Un bufete de abogados que se suscribe a una herramienta de IA de revisión de contratos y la utiliza para el trabajo de sus clientes es un responsable del despliegue. Una persona que utiliza la misma herramienta en casa para revisar un contrato de arrendamiento personal no está cubierta.
Las obligaciones del responsable del despliegue con arreglo al Artículo 26 son más ligeras que las del proveedor, pero no son leves. Para los sistemas de alto riesgo, los responsables del despliegue deben garantizar que las medidas de supervisión humana funcionen según lo previsto; asignar a una persona cualificada para supervisar el sistema; vigilar el sistema en busca de riesgos; y —cuando el responsable del despliegue sea un organismo público o cumpla las condiciones del Artículo 27, apartado 1— realizar una evaluación de impacto relativa a los derechos fundamentales (EIDF) con arreglo al Artículo 27 antes de desplegar el sistema.
Un punto práctico que sorprende a muchos operadores: la mayoría de las empresas que compran y utilizan herramientas de IA de terceros son responsables del despliegue, no proveedores. Ese es el lado de menores obligaciones de la línea divisoria. La parte que muerde es la instrucción del Artículo 26 de implementar las medidas de supervisión humana que el proveedor incorporó al sistema. Si el proveedor incorporó medidas que usted no está utilizando —porque nadie leyó las instrucciones de uso—, usted incumple como responsable del despliegue aunque no haya construido nada.
Cómo pueden acumularse las condiciones de proveedor y de responsable del despliegue
Una organización que desarrolla un sistema de IA para uso interno es simultáneamente proveedor (desarrollador) y responsable del despliegue (usuario). Una empresa de SaaS que integra un modelo de un tercero en su propio producto y lo comercializa bajo su propia marca es proveedor respecto de sus clientes, aunque también sea responsable del despliegue respecto del modelo subyacente. La acumulación de papeles es habitual; las organizaciones deben evaluar cada sistema por separado.
Definiciones de introducción en el mercado
Introducción en el mercado — Artículo 3, apartado 9: la primera comercialización de un sistema de IA en el mercado de la UE, ya sea a cambio de pago o gratuitamente, incluido el acceso remoto. En el momento en que un sistema llega al primer usuario de la cadena de distribución de la UE, ha sido «introducido en el mercado» y se desencadenan las obligaciones previas a la comercialización del proveedor.
Puesta en servicio — Artículo 3, apartado 11: la puesta a disposición de un sistema de IA para su primer uso a un responsable del despliegue dentro de la UE, directamente por el proveedor o a través de un tercero. Para el software empresarial vendido y desplegado internamente, la «puesta en servicio» es normalmente el momento de la puesta en marcha.
Comercialización — Artículo 3, apartado 10: todo suministro de un sistema de IA para su distribución o uso en el mercado de la UE en el transcurso de una actividad comercial, ya sea a cambio de pago o gratuitamente. Esta es la categoría más amplia; la «introducción en el mercado» es la primera instancia; la «comercialización» abarca el suministro continuado aguas abajo.
Estas distinciones importan para los importadores y distribuidores. Un importador (Artículo 3, apartado 14) introduce en el mercado de la UE un sistema que lleva la marca de un proveedor de fuera de la UE. Un distribuidor (Artículo 3, apartado 15) comercializa ese sistema más adelante en la cadena. Los importadores asumen obligaciones próximas a las de los proveedores cuando el desarrollador de fuera de la UE no ha cumplido sus requisitos; los distribuidores afrontan un deber más ligero, pero aun así real, de verificar el cumplimiento aguas arriba.
La modificación sustancial y el cambio de papel del Artículo 25
La modificación sustancial se define en el Artículo 3, apartado 23, como un cambio en un sistema de IA tras su introducción en el mercado o su puesta en servicio que afecta al cumplimiento del sistema con los requisitos de la Ley, o da lugar a una modificación de su finalidad prevista.
Esta definición es el desencadenante del Artículo 25 —la disposición que reasigna las obligaciones del proveedor a lo largo de la cadena de valor—. Si un agente aguas abajo (un responsable del despliegue, un distribuidor o un importador) realiza una modificación sustancial de un sistema de IA de alto riesgo, ese agente se convierte en el nuevo proveedor del sistema modificado. Hereda la pila completa de obligaciones del Artículo 16: gestión de riesgos, documentación técnica, evaluación de la conformidad, registro. La documentación del proveedor original no cubre la versión modificada.
En la práctica, la «modificación sustancial» es la definición que más subestiman la mayoría de las organizaciones. Ajustar un modelo (fine-tuning) con sus propios datos, integrar un modelo de un tercero en una nueva aplicación con una finalidad prevista materialmente distinta, o cambiar el diseño de entradas y salidas de maneras que afectan al perfil de riesgo del sistema —cada una de estas acciones puede desencadenar el Artículo 25—. Los cambios cosméticos (reskins de la interfaz, localización del texto mostrado) y los parches de seguridad puros que no alteran el comportamiento del sistema no lo hacen.
Ejemplo trabajado. Una empresa de tecnología de RR. HH. de 60 personas (Empresa A) licencia un sistema de IA de cribado de currículos de un proveedor especializado. El sistema puntúa los currículos de los candidatos en cuanto a competencia técnica y señala candidatos para su revisión por el seleccionador. La Empresa A es responsable del despliegue; el proveedor especializado es el proveedor. Seis meses después del despliegue, el equipo de desarrollo de la Empresa A integra el modelo en su propio ATS, lo ajusta con tres años de datos propios de resultados de contratación y amplía su alcance para puntuar el «encaje cultural» de los candidatos —una dimensión que el sistema original no evaluaba.
Resultado: la Empresa A ha realizado una modificación sustancial que cambia la finalidad prevista y altera materialmente el comportamiento del modelo. Con arreglo al Artículo 25, apartado 1, la Empresa A es ahora un proveedor. La documentación técnica del Anexo IV del proveedor original no cubre el sistema modificado. La Empresa A debe realizar su propia evaluación de la conformidad con arreglo al Artículo 43, elaborar documentación técnica nueva con arreglo al Artículo 11 y registrar el sistema modificado en la base de datos de la UE con arreglo al Artículo 49 antes de seguir utilizándolo.
El techo sancionador por incumplimiento, como proveedor de un sistema de alto riesgo utilizado en la contratación (Anexo III, punto 4), es de 15 millones de euros o el 3 % del volumen de negocios mundial.
Definiciones de GPAI: modelo frente a sistema
La Ley traza una distinción entre un modelo de IA de uso general y un sistema de IA de uso general que importa para determinar qué obligaciones se aplican.
Modelo de IA de uso general — Artículo 3, apartado 63: un modelo de IA, incluso cuando se haya entrenado con una gran cantidad de datos utilizando autosupervisión a gran escala, que muestra una generalidad significativa y es capaz de realizar de manera competente una amplia variedad de tareas distintas, y que puede integrarse en diversos sistemas o aplicaciones posteriores. Los ejemplos arquetípicos son los grandes modelos lingüísticos y los grandes modelos multimodales.
Sistema de IA de uso general — Artículo 3, apartado 66: un sistema de IA basado en un modelo de IA de uso general y que tiene la capacidad de servir a diversos fines, tanto para su uso directo como para su integración en otros sistemas de IA.
La división práctica es aguas arriba frente a aguas abajo. Un proveedor de un modelo de base —una organización que entrena y publica un modelo a gran escala— está sujeto a las obligaciones de los modelos de GPAI del capítulo V (Artículos 51 a 56), que incluyen documentación técnica para los proveedores posteriores, políticas de cumplimiento en materia de derechos de autor y, para los modelos con riesgo sistémico (los entrenados por encima de 10²⁵ FLOP con arreglo al Artículo 51), la evaluación del modelo y las pruebas adversas. Una empresa que construye una aplicación sobre ese modelo de base y la comercializa a usuarios finales tiene un sistema de IA de uso general; si además entra en el Anexo III, es también un sistema de IA de alto riesgo y el proveedor de ese sistema soporta la pila completa del Artículo 16.
Las obligaciones de los modelos de GPAI se aplican desde el 2 de agosto de 2025 (Artículo 113, apartado 3).
Definiciones biométricas y de datos sensibles
Varias definiciones del Artículo 3 fijan el alcance de las disposiciones biométricas del Anexo III (punto 1) y del Artículo 5.
Datos biométricos — Artículo 3, apartado 34: los datos personales obtenidos a partir de un tratamiento técnico específico, relativos a las características físicas, fisiológicas o conductuales de una persona física, que permitan o confirmen la identificación única de dicha persona física, como imágenes faciales o datos dactiloscópicos. El tratamiento de datos biométricos con el fin de identificar de manera única a personas físicas se clasifica como datos de categoría especial con arreglo al RGPD y, para los sistemas de IA, atrae el tratamiento más restrictivo de la Ley de IA de la UE.
Sistema de categorización biométrica — Artículo 3, apartado 40: un sistema de IA destinado a asignar a las personas físicas a categorías específicas en función de sus datos biométricos, incluidas sus características físicas, fisiológicas o conductuales, salvo que sea accesorio a otro servicio y estrictamente necesario por razones técnicas objetivas. Los sistemas de categorización biométrica destinados a utilizarse para la garantía del cumplimiento del Derecho o en espacios de acceso público afrontan las restricciones más estrictas con arreglo al Anexo III, punto 1, letra b).
Sistema de reconocimiento de emociones — Artículo 3, apartado 39: un sistema de IA destinado a detectar o inferir las emociones o las intenciones de personas físicas a partir de sus datos biométricos. Los sistemas de reconocimiento de emociones se tratan como de alto riesgo con arreglo al Anexo III y afrontan obligaciones de transparencia con arreglo al Artículo 50 (cuando una persona esté sometida a reconocimiento de emociones, debe ser informada). El uso prohibido de sistemas de reconocimiento de emociones en los lugares de trabajo y en los centros educativos está contemplado en el Artículo 5, apartado 1, letra f).
Incidente grave — Artículo 3, apartado 49
Un incidente grave es todo incidente o defecto de funcionamiento de un sistema de IA que, directa o indirectamente, provoque o pueda provocar: el fallecimiento de una persona o un perjuicio grave para su salud; una perturbación grave de infraestructuras críticas; el incumplimiento de obligaciones relativas a los derechos fundamentales; daños graves a la propiedad; o daños al medio ambiente.
Los proveedores de sistemas de IA de alto riesgo deben notificar los incidentes graves a las autoridades de vigilancia del mercado con arreglo al Artículo 73. La obligación de notificación es uno de los deberes poscomercialización continuos que soportan los proveedores una vez que un sistema se introduce en el mercado o se pone en servicio. Los responsables del despliegue también tienen la obligación de notificar al proveedor los incidentes graves o defectos de funcionamiento que planteen un riesgo.
El «incidente grave» figura junto al «cuasi accidente» en la documentación de gestión de riesgos que los proveedores deben mantener con arreglo al Artículo 9. Un sistema que produce salidas que evitaron por poco un resultado grave —pero no lo causaron— debe quedar igualmente recogido en el registro de gestión de riesgos, porque la vigilancia poscomercialización del Artículo 72 exige a los proveedores rastrear y evaluar los incidentes de forma sistemática, no solo aquellos que han causado un perjuicio.
Cómo ayuda Confir con el mapeo de papeles y definiciones
La mayoría de las organizaciones que abordan por primera vez el cumplimiento de la Ley de IA de la UE tienen dos preguntas inmediatas: ¿soy proveedor o responsable del despliegue? y ¿lo que opero tiene la consideración de sistema de IA? El proceso de admisión de Confir responde a ambas mediante preguntas de escenario en lenguaje sencillo —sin necesidad de redacción jurídica—. El motor de clasificación aplica las definiciones del Artículo 3 con lógica explícita basada en reglas: las mismas respuestas producen la misma determinación de papel, y la regla que se activó es visible en el registro de auditoría.
Una vez establecido el papel, Confir mapea sus obligaciones: deberes del Artículo 16 si es proveedor, deberes del Artículo 26 si es responsable del despliegue, con el desencadenante de modificación sustancial del Artículo 25 señalado si su admisión indica cambios poscomercialización en un sistema que recibió de un tercero. El resultado es un conjunto de obligaciones vinculado a artículos concretos, no una lista de comprobación genérica.
Fechas de cumplimiento que conviene retener tras el análisis del Artículo 3
Las definiciones del Artículo 3 se aplican de inmediato —la Ley entró en vigor el 1 de agosto de 2024—. No obstante, las obligaciones sustantivas vinculadas a esas definiciones se activan en fechas escalonadas:
- 2 de febrero de 2025 — Prohibiciones del Artículo 5 (prácticas de riesgo inaceptable). Ya en vigor. Si opera un sistema prohibido, la ventana sancionadora está abierta.
- 2 de agosto de 2025 — Obligaciones de los modelos de GPAI (capítulo V). Ya en vigor para los proveedores de GPAI.
- 2 de agosto de 2026 — Aplicación general de la Ley, incluidas las obligaciones de transparencia de riesgo limitado del Artículo 50.
- 2 de diciembre de 2027 — Sistemas de alto riesgo autónomos del Anexo III. En virtud del Ómnibus Digital, acordado en mayo de 2026, esta es la fecha revisada para las obligaciones de los Artículos 9 a 16, 26, 43, 47 a 49 y 72 a 73 que se aplican a los sistemas de IA de alto riesgo autónomos. La fecha original del 2 de agosto de 2026 se aplazó.
- 2 de agosto de 2028 — Sistemas de IA de alto riesgo integrados como componentes de seguridad en productos regulados por el Anexo I.
Realizar ahora su análisis del Artículo 3 —antes de que lleguen los plazos del responsable del despliegue del Artículo 26 y del proveedor del Artículo 16— le da tiempo para abordar cualquier problema de cambio de papel del Artículo 25 antes de que se convierta en exposición a la ejecución. Las prohibiciones biométricas del Artículo 5 y las obligaciones de GPAI de los Artículos 53 y 55 ya están vigentes.
Preguntas frecuentes
¿Cuál es la diferencia entre «introducción en el mercado» y «puesta en servicio» con arreglo al Artículo 3?
La «introducción en el mercado» (Artículo 3, apartado 9) es la primera comercialización de un sistema en la cadena de distribución de la UE —normalmente, el momento en que se vende o licencia al primer cliente de la UE—. La «puesta en servicio» (Artículo 3, apartado 11) se refiere al primer uso de un sistema directamente por un responsable del despliegue dentro de la UE, cuando no ha habido una introducción previa en el mercado. Para una empresa que desarrolla un sistema de IA exclusivamente para su propio uso interno, la «puesta en servicio» es el desencadenante pertinente —es simultáneamente proveedor y responsable del despliegue, y las obligaciones del Artículo 16 se aplican desde el primer uso.
¿La definición de sistema de IA de la Ley de IA de la UE cubre las herramientas de automatización basadas en reglas?
No automáticamente. Un sistema puramente basado en reglas —lógica condicional fija sin paso de inferencia a partir de datos de entrenamiento— no cumple la definición del Artículo 3, apartado 1, que exige que el sistema infiera cómo generar salidas a partir de la información de entrada que recibe. Los sistemas que combinan lógica basada en reglas con una capa de inferencia de aprendizaje automático sí tienen la consideración de sistema de IA. Las directrices de la Comisión de febrero de 2025 aclaran que el criterio de inferencia es el umbral crítico: aplíquelo al mecanismo técnico real, no a cómo se comercializa el sistema.
¿Cuándo se convierte un responsable del despliegue en proveedor con arreglo al Artículo 25?
Con arreglo al Artículo 25, apartado 1, un responsable del despliegue se convierte en proveedor cuando realiza una modificación sustancial (Artículo 3, apartado 23) de un sistema de IA de alto riesgo —una que cambia su estado de cumplimiento o altera su finalidad prevista—. Esto incluye ajustar un modelo con datos propios de maneras que cambian materialmente su comportamiento, integrarlo en una nueva aplicación con un caso de uso distinto o ampliar su alcance para abarcar una toma de decisiones para la que el sistema original no fue diseñado. El nuevo proveedor debe completar la evaluación de la conformidad, elaborar documentación técnica y registrar el sistema antes de seguir utilizando la versión modificada.
¿Qué se considera un «incidente grave» a efectos de la notificación del Artículo 73?
El Artículo 3, apartado 49, define el incidente grave como un incidente o defecto de funcionamiento de un sistema de IA que provoca o puede provocar el fallecimiento o un perjuicio grave para la salud, una perturbación de infraestructuras críticas, el incumplimiento de obligaciones relativas a los derechos fundamentales, daños graves a la propiedad o daños al medio ambiente. La palabra «puede» es significativa —un cuasi accidente cumple el umbral si planteó un riesgo creíble de perjuicio grave aunque no se produjera ningún perjuicio—. Los proveedores de sistemas de alto riesgo notifican a la autoridad nacional de vigilancia del mercado pertinente; los responsables del despliegue notifican al proveedor.
¿Qué es un modelo de IA de uso general y por qué importa la distinción?
Un modelo de IA de uso general (Artículo 3, apartado 63) es un modelo entrenado a gran escala con datos amplios que puede realizar una amplia variedad de tareas e integrarse en aplicaciones posteriores —normalmente un gran modelo lingüístico o multimodal—. La distinción importa porque las obligaciones de los modelos de GPAI (capítulo V, Artículos 51 a 56) se aplican a la organización que entrena y distribuye el modelo, no a las empresas que construyen aplicaciones sobre él. Si utiliza un modelo de base de un tercero para construir un producto, es probable que sea proveedor de un sistema de IA de uso general (Artículo 3, apartado 66), no proveedor de un modelo de GPAI. Las obligaciones de los modelos de GPAI —incluida la documentación técnica para los proveedores posteriores y, para los modelos con riesgo sistémico, las pruebas adversas— entraron en vigor el 2 de agosto de 2025.
¿Se tratan como de alto riesgo los sistemas de reconocimiento de emociones y de categorización biométrica?
Sí, en la mayoría de los contextos de despliegue. Los sistemas de categorización biométrica y los sistemas de reconocimiento de emociones figuran en el Anexo III, punto 1. Los sistemas de reconocimiento de emociones afrontan una prohibición adicional con arreglo al Artículo 5, apartado 1, letra f), cuando se utilizan en los lugares de trabajo y en los centros educativos. Ambas categorías desencadenan también obligaciones de transparencia del Artículo 50: toda persona sometida a reconocimiento de emociones debe ser informada. Que el filtro de reducción de riesgo del Artículo 6, apartado 3, pueda aplicarse a un sistema biométrico concreto depende del contexto de despliegue —pero ningún sistema que elabore perfiles de personas físicas puede acogerse a la exención del Artículo 6, apartado 3, con independencia de otros factores.
¿Cuáles son los techos sancionadores por una clasificación errónea del Artículo 3?
No existe un tramo de multa independiente para la clasificación errónea en sí. La sanción se vincula a la obligación sustantiva que queda incumplida como consecuencia de la clasificación errónea. Desplegar un sistema prohibido (Artículo 5): hasta 35 millones de euros o el 7 % del volumen de negocios anual mundial con arreglo al Artículo 99, apartado 3. No cumplir las obligaciones del proveedor o del responsable del despliegue para un sistema de alto riesgo (Artículos 16, 26): hasta 15 millones de euros o el 3 % con arreglo al Artículo 99, apartado 4. Facilitar información falsa a un organismo notificado o a una autoridad: hasta 7,5 millones de euros o el 1 % con arreglo al Artículo 99, apartado 5. Para las pymes y las empresas emergentes, el Artículo 99, apartado 6, limita las multas al menor de los dos importes, el porcentaje o la cantidad fija.
Guías relacionadas
- requisitos de clasificación de riesgos
- marco de cumplimiento de la Ley de IA de la UE
- soluciones de software de cumplimiento de la Ley de IA de la UE
- soluciones de software de gobernanza de la IA
- marco de cumplimiento de la gobernanza de la IA
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 →