Artículo 2 de la Ley de IA de la UE: ámbito de aplicación y a quién se aplica

El Artículo 2 del Reglamento (UE) 2024/1689 plantea la primera pregunta real del Reglamento: ¿le afecta algo de todo esto? Antes de examinar los niveles de riesgo, evaluar los requisitos de documentación o determinar si es necesaria una evaluación de la conformidad, hay que responder al umbral jurisdiccional. Si se yerra en cualquiera de los dos sentidos —reclamando una exención que no se tiene o suponiendo que se está fuera de ámbito cuando no es así—, toda decisión de cumplimiento posterior se construye sobre arena.

Este artículo recorre quién queda comprendido, quién está excluido y por qué la respuesta rara vez resulta evidente en la práctica.

Por qué el ámbito de aplicación precede a todo lo demás

La Ley de IA de la UE impone obligaciones vinculándolas a roles —proveedor, responsable del despliegue, importador, distribuidor— y a los territorios donde un sistema se introduce en el mercado, se pone en servicio o cuyos resultados se utilizan. El Artículo 2 define ambas cosas. Hasta que no se sabe qué rol se ocupa y si se activa el desencadenante territorial, no hay nada útil que se pueda hacer con los Artículos 9 a 49.

La cuestión del ámbito tiene además una asimetría tajante. Si se está dentro de ámbito, sigue una cascada de obligaciones: clasificación de riesgo con arreglo al Artículo 6, documentación técnica con arreglo al Artículo 11, requisitos de supervisión humana del Artículo 14 para los sistemas de alto riesgo, registro con arreglo al Artículo 49, etcétera. Si se está genuinamente fuera de ámbito —porque el sistema es un prototipo de investigación o sirve únicamente para un uso personal no profesional—, ninguna de esas obligaciones se aplica. Por tanto, lo que está en juego en la cuestión del umbral es elevado.

Una razón más por la que el análisis del ámbito va primero: el alcance territorial de la Ley de IA de la UE se extiende mucho más allá de las fronteras de la UE. Muchas organizaciones se sorprenden al descubrir que están dentro de ámbito.

Quién queda comprendido: las seis categorías de agentes

El Artículo 2, apartado 1, identifica seis categorías de agentes que entran en el ámbito del Reglamento. Cada una conlleva obligaciones posteriores diferentes.

Proveedores que introducen en el mercado o ponen en servicio en la UE

Un proveedor, según se define en el Artículo 3, apartado 3, es toda persona física o jurídica que desarrolla un sistema de IA —o que encarga su desarrollo— y lo introduce en el mercado o lo pone en servicio con su propio nombre o marca. El rasgo definitorio del rol de proveedor es que el proveedor es la entidad que pone el sistema a disposición de terceros o lo despliega bajo su propia autoridad.

La geografía del establecimiento es irrelevante. Una empresa con sede en San Francisco que cede bajo licencia un modelo de calificación crediticia basado en IA a bancos de Alemania, Austria y los Países Bajos es un proveedor con arreglo al Artículo 2, apartado 1, letra a). El Reglamento la alcanza igual que alcanza a un proveedor constituido en Múnich. Los proveedores de SaaS estadounidenses, británicos, israelíes o de cualquier otro país no perteneciente a la UE que venden herramientas con IA en el mercado de la UE son proveedores dentro de ámbito.

El rol de proveedor conlleva la pila de obligaciones más pesada: el sistema de gestión de riesgos (Artículo 9), la gobernanza de datos (Artículo 10), la documentación técnica (Artículo 11), la conservación de registros (Artículo 12), la transparencia hacia los responsables del despliegue (Artículo 13), las medidas de supervisión humana (Artículo 14), los requisitos de exactitud y robustez (Artículo 15), la gestión de la calidad (Artículo 17), la evaluación de la conformidad (Artículo 43) y el registro (Artículo 49), para los sistemas de alto riesgo. Los proveedores de modelos de IA de uso general (GPAI) tienen un conjunto separado de obligaciones de referencia con arreglo al Artículo 53, que se aplican desde el 2 de agosto de 2025.

Responsables del despliegue establecidos o situados en la UE

Un responsable del despliegue es toda persona física o jurídica, autoridad pública, agencia u otro organismo que utiliza un sistema de IA bajo su autoridad en un contexto profesional, salvo cuando el sistema se utiliza en el marco de una actividad personal de carácter no profesional. Si una empresa de logística de Varsovia utiliza una IA de optimización de rutas de un tercero, es un responsable del despliegue. Si un hospital de Lyon utiliza una herramienta de IA de apoyo al diagnóstico desarrollada por una empresa estadounidense de tecnología médica, el hospital es el responsable del despliegue.

Las obligaciones del responsable del despliegue con arreglo al Artículo 26 son más ligeras que las del proveedor, pero no son triviales. Los responsables del despliegue deben seguir las instrucciones de uso del proveedor, garantizar la supervisión humana cuando el sistema lo requiera, vigilar el sistema en funcionamiento y, para determinados usos de alto riesgo, realizar una evaluación de impacto relativa a los derechos fundamentales (EIDF, FRIA) con arreglo al Artículo 27. Los responsables del despliegue que sean organismos públicos o que desplieguen sistemas de alto riesgo en contextos específicos tienen deberes adicionales de transparencia y registro.

La mayoría de las empresas que compran e integran herramientas de IA de terceros son responsables del despliegue, no proveedores. Ese es el punto de partida práctico para la mayoría de las empresas.

Proveedores y responsables del despliegue establecidos en terceros países cuyos resultados se utilizan en la UE

Este es el anclaje extraterritorial. El Artículo 2, apartado 1, letra c), comprende a los proveedores y responsables del despliegue establecidos fuera de la UE cuando el resultado del sistema de IA se utiliza dentro de la UE. No exige que el sistema se despliegue en suelo de la UE; exige que los resultados —las decisiones, recomendaciones, clasificaciones, contenidos o puntuaciones que el sistema produce— sean consumidos por personas o procesos dentro de la UE.

Un ejemplo práctico: una empresa estadounidense de análisis de RR. HH., con sede en Austin, opera una IA de cribado de candidatos para un cliente multinacional. El sistema está alojado en Virginia. Pero los candidatos que se criban optan a puestos en Fráncfort, Ámsterdam y Madrid, lo que significa que el resultado del cribado se utiliza dentro de la UE. La empresa de Austin es un proveedor dentro de ámbito con arreglo al Artículo 2, apartado 1, letra c).

Esta disposición cierra una laguna que, de lo contrario, permitiría a los agentes de fuera de la UE atender a usuarios de la UE desde fuera de la jurisdicción de la UE sin responsabilidad regulatoria.

Importadores y distribuidores

El Artículo 2, apartado 1, letra d), comprende a los importadores —entidades que introducen en el mercado de la UE el sistema de IA de un proveedor de fuera de la UE— y a los distribuidores, que ponen a disposición un sistema de IA en la UE sin introducirlo ellos mismos en el mercado. Sus obligaciones, recogidas en los Artículos 23 y 24, se centran en el cumplimiento de la cadena de suministro: comprobar que el proveedor ha completado la evaluación de la conformidad, garantizar que el marcado CE está colocado y notificar a las autoridades competentes y al proveedor si un sistema presenta un riesgo.

Los importadores y distribuidores pueden convertirse en proveedores en el sentido pleno con arreglo al Artículo 25, apartado 1, si introducen un sistema en el mercado con su propio nombre o marca, lo modifican sustancialmente o cambian su finalidad prevista de un modo que lo sitúe en la categoría de alto riesgo.

Fabricantes de productos que introducen un sistema de IA junto con su producto bajo su nombre

Cuando un sistema de IA se incorpora a un producto físico sujeto a la legislación de armonización de la Unión —el Reglamento sobre máquinas, el Reglamento sobre los productos sanitarios, el Reglamento general de seguridad de los productos y otros enumerados en el Anexo I— y el fabricante introduce el producto combinado en el mercado con su propio nombre, el fabricante es tratado como el proveedor del componente de IA. Esto importa porque tales sistemas se clasifican como de alto riesgo con arreglo al Artículo 6, apartado 1: son componentes de seguridad de productos cubiertos por el Anexo I, y el procedimiento de evaluación de la conformidad aplicable rige desde el 2 de agosto de 2028 (en virtud del Ómnibus Digital acordado en mayo de 2026).

Un fabricante de robots industriales que incorpora detección de colisiones basada en IA es el caso paradigmático. El fabricante del robot, y no el proveedor del software de IA, carga con las obligaciones de proveedor para el sistema tal como se despliega en ese producto.

Representantes autorizados de proveedores de fuera de la UE

Cuando un proveedor no está establecido en la UE, debe designar un representante autorizado con arreglo al Artículo 22: una persona física o jurídica establecida en la UE mandatada por escrito para actuar en nombre del proveedor. El representante autorizado pasa a ser un punto de contacto designado para las autoridades competentes de la UE y asume responsabilidades de cumplimiento definidas. Los proveedores de fuera de la UE que introducen sistemas de IA de alto riesgo en el mercado de la UE sin designar un representante autorizado incumplen el Reglamento desde el momento en que comienza la aplicación general de dichas disposiciones.

Personas afectadas situadas en la UE

El Artículo 2, apartado 1, letra g), extiende la protección a las personas físicas que se encuentren físicamente en la UE y que estén sujetas a los resultados de un sistema de IA, con independencia de su nacionalidad o residencia. Esta disposición sustenta la ejecución en casos en los que, por ejemplo, un sistema de IA utilizado por un gobierno de fuera de la UE toma decisiones sobre personas que se encuentran en territorio de la UE.

Exclusiones clave: qué queda fuera del Artículo 2

El Reglamento excluye expresamente varias categorías. Cada exclusión tiene su propio ámbito y sus propios límites; ninguna es tan amplia como podría parecer a primera vista.

Seguridad nacional, fines militares y de defensa

El Artículo 2, apartado 3, excluye los sistemas de IA utilizados exclusivamente con fines militares y de defensa, y los sistemas de IA utilizados exclusivamente con fines de seguridad nacional, con independencia del tipo de entidad que lleve a cabo dichas actividades. Un sistema construido y operado únicamente con fines de seguridad nacional queda por completo fuera del Reglamento.

La palabra «exclusivamente» es determinante. Un sistema que sirve tanto a una función clasificada de seguridad nacional como a una función comercial civil —un proveedor que vende el mismo modelo subyacente a servicios de inteligencia y a clientes de servicios financieros— no puede reclamar la exención para sus usos civiles. La exención es específica del uso, no de la entidad.

Investigación y desarrollo científicos

El Artículo 2, apartado 6, excluye los sistemas de IA desarrollados y puestos en servicio con el único fin de la investigación y el desarrollo científicos. Un grupo universitario que desarrolla un modelo experimental de procesamiento del lenguaje natural para un estudio de lingüística está fuera de ámbito durante la fase de investigación. En el momento en que la institución despliega ese modelo para un uso operativo —en un entorno clínico, como producto comercial o en cualquier otro contexto no de investigación—, se aplica el Artículo 2.

La actividad de investigación y prueba previa a la introducción de un sistema en el mercado también queda fuera de ámbito, con una salvedad crítica: la prueba en condiciones reales de sistemas de IA de alto riesgo en la UE puede constituir una «puesta en servicio» y, por tanto, puede activar el ámbito. El Artículo 2, apartado 8, contempla una excepción estrecha para las pruebas en condiciones específicas, pero no es una exención general para la investigación.

La exclusión por investigación no está al alcance de una empresa que está pilotando un sistema con clientes de pago mientras lo denomina «beta». Eso es despliegue en el mercado, no investigación científica.

IA libre y de código abierto

El Artículo 2, apartado 12, exime a los sistemas de IA publicados con licencias libres y de código abierto de la mayoría de los requisitos del Reglamento, con tres excepciones que eliminan la mayor parte del aparente alivio:

1. Los sistemas comprendidos en el Artículo 5 (prácticas prohibidas) no están exentos, con independencia de su licencia.
2. Los sistemas de alto riesgo con arreglo al Artículo 6 no están exentos. Un desarrollador de código abierto que publica un modelo diseñado para la calificación crediticia o el cribado de candidatos hereda la pila completa de obligaciones de alto riesgo.
3. Los sistemas sujetos a las obligaciones de transparencia del Artículo 50 (chatbots, etiquetado de contenido sintético, reconocimiento de emociones, ultrasuplantaciones) no están exentos.

En la práctica, la exención de código abierto cubre sistemas de riesgo genuinamente mínimo. Todo modelo fundacional que pudiera adaptarse de forma plausible a usos prohibidos o de alto riesgo, y cuyo proveedor no haya restringido o documentado contra tal uso, debe evaluarse cuidadosamente antes de apoyarse en esta exclusión.

Los proveedores de modelos GPAI que publican con licencias de código abierto conservan las obligaciones de referencia del Artículo 53 (política de cumplimiento de los derechos de autor, resumen de los datos de entrenamiento), salvo que cumplan los requisitos de una excepción limitada específica con arreglo al Artículo 53, apartado 2.

Uso personal y no profesional

Los sistemas de IA utilizados por personas físicas para actividades puramente personales y no profesionales quedan fuera de ámbito. Utilizar un asistente de redacción para escribir correos personales, o una IA de fitness para planificar entrenamientos, no es una conducta regulada. En el momento en que el mismo sistema se utiliza en un contexto profesional o empresarial —para tratar datos de clientes, gestionar empleados o prestar un servicio—, la exención decae.

Esta exclusión importa principalmente para las personas físicas. No ayuda a las empresas.

Otra normativa de la Unión e interacciones sectoriales

El Artículo 2 también aborda los sistemas ya regulados por normativa sectorial específica de la Unión. Cuando ya se aplica un acto legislativo de la Unión específico para una aplicación de IA, los requisitos de la Ley de IA ceden ante ese marco sectorial de formas limitadas, principalmente para evitar duplicar los procedimientos de evaluación de la conformidad. El Reglamento sobre los productos sanitarios, por ejemplo, tiene su propio proceso de evaluación por organismo notificado; el Artículo 2 lo acomoda en lugar de superponer una evaluación de la conformidad de la Ley de IA enteramente separada. Pero esta coordinación es procedimental, no sustantiva: no exime a la IA de los productos sanitarios de los requisitos sustantivos del Reglamento, sino únicamente de la duplicación de determinados pasos procedimentales.

Interacción con el RGPD

El Artículo 2 de la Ley de IA de la UE y el Reglamento General de Protección de Datos (RGPD) operan en paralelo, no en secuencia. Un sistema de IA que trata datos personales debe cumplir ambos. Abordan riesgos diferentes: el RGPD se ocupa de los derechos de los interesados, la licitud del tratamiento y la minimización de datos; la Ley de IA se ocupa de los riesgos que los sistemas de IA plantean para la salud, la seguridad y los derechos fundamentales. Un sistema de IA puede infringir el RGPD sin infringir la Ley de IA, y viceversa.

Donde más muerde el solapamiento es en los sistemas de alto riesgo que también tratan datos personales a gran escala: un sistema de identificación biométrica, una herramienta de calificación de solvencia basada en IA, un modelo de cribado de selección de personal. En esos casos, la evaluación de impacto relativa a la protección de datos (EIPD) del RGPD con arreglo al Artículo 35 del RGPD y la EIDF del Artículo 27 de la Ley de IA abordan un terreno solapado desde ángulos distintos. Ambas deben realizarse; ninguna sustituye a la otra. Las autoridades de control con arreglo al RGPD y las autoridades competentes de vigilancia del mercado con arreglo a la Ley de IA son organismos distintos con competencias de ejecución distintas.

Para las organizaciones ya integradas en programas de cumplimiento del RGPD, las obligaciones de documentación, conservación de registros y transparencia de la Ley de IA resultarán estructuralmente familiares. Pero las bases jurídicas y las pruebas exigidas no son las mismas.

Dos ejemplos prácticos

Ejemplo 1: un proveedor de SaaS estadounidense que vende en la UE

Una empresa de software de 60 personas con sede en Chicago vende una herramienta de evaluación de candidatos que utiliza un modelo de puntuación para clasificar a los solicitantes de empleo. La empresa no tiene oficina ni empleados en la UE. Entre sus clientes figuran departamentos de RR. HH. de Alemania, España y Suecia.

Esta empresa es un proveedor con arreglo al Artículo 2, apartado 1, letra a) —introduce un sistema de IA en el mercado de la Unión— y también queda comprendida por el Artículo 2, apartado 1, letra c) —los resultados se utilizan dentro de la UE—. El sistema entra casi con certeza en el ámbito 4 del Anexo III (empleo, gestión de los trabajadores y acceso al autoempleo) y, por tanto, es presuntamente de alto riesgo con arreglo al Artículo 6, apartado 1. La empresa debe cumplir la pila completa de obligaciones de alto riesgo, designar un representante autorizado con arreglo al Artículo 22 y registrar el sistema con arreglo al Artículo 49. No puede ampararse en su establecimiento fuera de la UE.

El plazo revisado para los sistemas 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: ese es el objetivo de cumplimiento para los requisitos básicos de alto riesgo.

Ejemplo 2: un prototipo interno de I+D

Una fintech de 200 personas en Ámsterdam tiene un equipo de ciencia de datos que desarrolla un modelo de prueba de concepto para la detección de fraude. El modelo se ejecuta sobre datos de prueba internos, nunca ha procesado transacciones reales de clientes y no está desplegado en producción. Ningún tercero lo utiliza.

Durante esta fase, el sistema queda probablemente fuera de ámbito con arreglo al Artículo 2, apartado 6 (único fin de investigación y desarrollo). Pero la exclusión es condicional. En el momento en que el equipo lo despliega sobre datos reales de transacciones de clientes, aun bajo el marco de un «piloto», la exclusión del Artículo 2, apartado 6, decae. En ese punto, la empresa debe evaluar si se trata de un sistema de alto riesgo (la detección de fraude está expresamente excluida de la categoría de solvencia del ámbito 5 del Anexo III, por lo que el resultado de la clasificación puede ser de riesgo mínimo, pero el análisis debe documentarse igualmente), determinar su rol y proceder en consecuencia.

Las sanciones en contexto

El incumplimiento de las obligaciones desencadenadas por estar dentro de ámbito —no realizar una evaluación de la conformidad, no mantener la documentación técnica, no designar un representante autorizado— entra en el Artículo 99, apartado 4: hasta 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Facilitar información incorrecta, incompleta o engañosa a las autoridades o a los organismos notificados conlleva el nivel inferior del Artículo 99, apartado 5: hasta 7 500 000 EUR o el 1 % del volumen de negocios.

Con arreglo al Artículo 99, apartado 6, las multas para las pymes y las empresas emergentes se limitan al menor de los dos importes, el porcentaje o la cantidad fija. Para una empresa con 4 millones de euros de volumen de negocios anual, el techo de un incumplimiento general es de 120 000 EUR (el 3 % de 4 millones), no de 15 millones. Conviene tener presente esa protección de proporcionalidad, aunque no es una licencia para despriorizar el cumplimiento.

Las sanciones que pueden derivarse de una determinación errónea del ámbito no son directas: no se puede multar por «equivocarse con el Artículo 2» de forma aislada. La multa se vincula a la obligación que se dejó de cumplir por haber concluido erróneamente que se estaba fuera de ámbito. Eso eleva lo que está en juego y hace valiosa la documentación del análisis de ámbito: un registro razonado y contemporáneo de que se consideró la cuestión y se alcanzó una conclusión defendible constituye una prueba significativa en cualquier investigación de ejecución.

Cómo ayuda Confir

Lo primero que Confir pregunta cuando se registra un sistema de IA es un conjunto de preguntas en lenguaje sencillo sobre cómo se despliega el sistema, dónde se utilizan sus resultados y quién lo controla. Las respuestas impulsan una clasificación determinista y basada en reglas de su rol con arreglo al Artículo 2 —proveedor, responsable del despliegue, importador, distribuidor o ninguno— y vinculan ese rol a los artículos concretos que se aplican. La misma admisión señala si se aplica alguna exención y documenta el fundamento de esa determinación.

Ese resultado de delimitación del ámbito alimenta directamente el flujo de trabajo de cumplimiento: si usted es proveedor de un sistema de alto riesgo, Confir abre la evaluación de gestión de riesgos del Artículo 9, el generador de documentación del Artículo 11 y la vía de la EIDF del Artículo 27 si procede. Si el sistema se clasifica como de riesgo mínimo, esas vías permanecen cerradas y el registro muestra por qué. La lógica es transparente y legible por humanos: mismo dato de entrada, mismo resultado, siempre.

Del ámbito a la sustancia

El Artículo 2 no es en sí mismo una carga. No impone requisitos de documentación, ni evaluaciones, ni plazos propios. Lo que hace es determinar si todas las demás disposiciones del Reglamento se le aplican. Eso lo convierte en el punto de partida adecuado, y en el lugar idóneo donde invertir esmero analítico antes de pasar a los artículos cargados de obligaciones que vienen después.

El análisis del ámbito tampoco es un ejercicio puntual. Si lanza un nuevo sistema de IA, cambia materialmente la finalidad prevista de un sistema existente, adquiere una empresa que desarrolla IA o empieza a vender una herramienta de IA a clientes de la UE por primera vez, hay que reevaluar el Artículo 2. La cuestión del ámbito permanece viva mientras lo esté su cartera de IA.

Guías relacionadas

• ámbito jurisdiccional del Artículo 2
• requisitos de cumplimiento para pymes
• hoja de ruta de cumplimiento para empresas emergentes
• definiciones del Artículo 3
• resumen de la Ley de IA de la UE
• plazos de cumplimiento
• fundamentos de la Ley de IA de la UE
• roles de proveedor frente a responsable del despliegue