El reglamento europeo de IA, explicado para las empresas que lo tienen que aplicar

Todo lo que viene después desarrolla estas seis frases. Si solo te quedas con seis cosas, que sean estas.

El reglamento no regula la inteligencia artificial como si fuera una sustancia. Regula usos, ordenados por el daño que un fallo podría hacerle a los derechos, la seguridad o el sustento de una persona.

Una lista corta de prácticas está prohibida sin más, con la puntuación social y las técnicas manipuladoras dentro. Un conjunto definido de usos es de alto riesgo y carga con la maquinaria pesada de la norma. Una banda intermedia lleva deberes de transparencia, que consiste en avisar a la persona de que está interactuando con una máquina. Todo lo demás es riesgo mínimo y casi no lleva nada.

¿Y dónde cae un asistente normal de empresa? Un asistente interno que responde sobre documentación, un chatbot que reserva citas o un agente que lee facturas caen, en la mayoría de configuraciones, en la banda limitada o en la mínima.

El alto riesgo depende sobre todo del uso que se haga de la IA, no de lo sofisticado que sea el modelo. En cuanto la IA toca contratación, crédito, educación, servicios esenciales, biometría o cualquiera de los demás dominios del anexo III, la misma tecnología de debajo pasa a ser de alto riesgo y se activan las obligaciones específicas que establece el reglamento para esos sistemas.

En qué banda cae tu uso concreto es la primera pregunta para tus abogados. Las secciones siguientes te dan el vocabulario para esa conversación.

Los modelos de propósito general que utilizan sistemas como los nuestros tienen obligaciones específicas en el reglamento, en vigor desde agosto de 2025 para las empresas que los proveen. Quien provee un modelo de propósito general debe documentación técnica, información a las empresas que construyen encima, una política de derechos de autor y un resumen del contenido usado para entrenar.

La mayoría de esas obligaciones corresponden al proveedor del modelo, pero su documentación afecta directamente a tu expediente de cumplimiento. Eso pasa porque la descripción de tu sistema se apoya en la del modelo de debajo.

Cuando montamos ese expediente para un cliente, las condiciones y la documentación del proveedor de modelo entran dentro. Es una razón más de que la elección de proveedor la apruebes tú en vez de heredarla de nosotros.

Lo que hay que pedir es corto. Quien te venda algo construido sobre un modelo grande debería poder nombrar el modelo, señalar la documentación que su proveedor publica para este reglamento y enseñar qué datos tuyos llegan hasta él. Si falta cualquiera de esos datos, tendrás un vacío en la documentación que necesitas para evaluar tu sistema.

El reglamento entró en vigor en agosto de 2024 y sus obligaciones se aplican desde fechas distintas. Todas las fechas de abajo están en el pasado o ya tienen día fijado. Aun así, muchas empresas siguen tratando el cumplimiento de la IA como algo que pueden revisar más adelante.

La estructura de sanciones va por tramos, como la del RGPD. Las prácticas prohibidas llegan a 35 millones de euros o al 7 % de la facturación mundial, lo que sea más alto. Casi todo lo demás, con los deberes de quien despliega dentro, llega a 15 millones o al 3 %. Dar información engañosa a las autoridades tiene su propio tramo, más bajo.

¿Y qué probabilidad real hay de que te inspeccionen? Nadie que te venda certeza sobre eso merece que le creas. Lo que sí se puede decir con pruebas es quién está mirando.

Cada país nombra a su autoridad de vigilancia del mercado y la nuestra llegó antes que ninguna. La AESIA fue la primera agencia nacional de Europa dedicada solo a la IA, creada por el Real Decreto 729/2023, con potestad sancionadora plena desde agosto de 2025 y dieciséis guías publicadas.

Su línea declarada durante 2026 ha sido avisar antes que sancionar. Ya ha abierto investigaciones preliminares sobre sistemas desplegados por organizaciones españolas. La supervisión ya está en marcha y las empresas tendrán que poder demostrar cómo cumplen.

La consecuencia práctica para quien compra es de calendario. Construir un sistema que pueda demostrar lo que hace mientras se está construyendo cuesta poco. Lo sabemos porque es como trabajamos de todas formas. Intentar añadir estas garantías cuando ya existe una inspección o un problema suele ser mucho más caro que diseñarlas desde el principio.

Esta es una de las primeras preguntas que conviene resolver, porque de ella dependen las obligaciones que pueden aplicarte. La Comisión desglosa la definición de sistema de IA en siete elementos y el elemento clave es la capacidad del sistema para inferir resultados a partir de los datos que recibe: un sistema basado en una máquina, con cierta autonomía, que deduce de lo que recibe cómo generar resultados como predicciones, recomendaciones o decisiones.

La Comisión Europea publicó unas directrices sobre esta definición exacta en febrero de 2025, precisamente porque todas las empresas hacían la misma pregunta.

En la práctica, muchos sistemas habituales quedan fuera de esa definición. Una calculadora, una fórmula fija de hoja de cálculo o un motor de reglas que aplica siempre la misma lógica escrita no infiere y por lo general queda fuera. Un sistema que aprende patrones, ordena candidatos, puntúa riesgo o genera texto sí infiere y está dentro.

Los casos de frontera requieren una valoración jurídica de tus abogados y el razonamiento hay que dejarlo por escrito caiga del lado que caiga. En un sistema construido sobre un modelo de lenguaje, esta parte suele estar clara: el modelo genera resultados a partir de la información que recibe.

Dos figuras concentran la mayoría de las obligaciones: el proveedor y el responsable del despliegue. Un proveedor desarrolla un sistema de IA o encarga que se desarrolle, para ponerlo en el mercado bajo su propio nombre. Un responsable del despliegue usa un sistema de IA de forma profesional, bajo su propia autoridad y para sus propios fines.

El proveedor responde del diseño y quien despliega responde del uso. Los deberes de diseño son la conformidad, la documentación y el registro donde toque. Los deberes de uso son el asunto de esta guía.

Un banco que compra un sistema de puntuación crediticia a un fabricante es responsable del despliegue, con deberes de supervisión, vigilancia y registros. El fabricante es el proveedor, con deberes sobre cómo se construyó y documentó el sistema.

La misma distinción se aplica a otros usos empresariales: la clínica que usa un asistente de citas, el hospital que usa una ayuda al diagnóstico y la asesoría que extrae datos de documentos son responsables del despliegue de esos sistemas, los haya construido quien los haya construido.

Cuando construimos un agente a medida, el contrato debe dejar claro quién asume el papel de proveedor y quién el de responsable del despliegue.

Lo definimos desde el principio. Tus abogados y los nuestros cierran la redacción. La parte técnica de la respuesta, quién documenta qué y quién guarda qué registros, se diseña desde dentro en lugar de discutirse después.

El papel de una empresa puede cambiar según lo que haga con el sistema. El reglamento sienta a quien despliega en la silla del proveedor cuando le pone su nombre o su marca a un sistema de alto riesgo, cuando lo modifica de forma sustancial o cuando cambia la finalidad prevista del sistema hacia terreno de alto riesgo.

El tercer caso es especialmente fácil de pasar por alto, porque «finalidad prevista» suena a lenguaje de marketing y es en realidad el concepto sobre el que descansa el reglamento entero.

Concretando. Una empresa que licencia un asistente documental general y lo convierte en una herramienta que criba candidaturas de empleo ha cambiado la finalidad hacia un dominio del anexo III y con ella, quizá, su propio papel. Una empresa que vende con su nombre el sistema de un fabricante pasa a asumir obligaciones de proveedor al comercializarlo bajo su propia marca.

Nada de esto impide personalizar un sistema, pero puede hacer que aparezcan nuevas obligaciones. Esas obligaciones son documentación y deberes que alguien tiene que aceptar a conciencia. Si una modificación concreta es «sustancial» es un juicio jurídico.

Nuestra aportación es técnica y empieza antes de esa valoración jurídica. Un sistema construido con una finalidad prevista escrita, un registro de qué cambió y unos registros de lo que el sistema hace de verdad dan a tus abogados la información necesaria para valorar esa situación sin tener que reconstruir cómo funciona el sistema. Un sistema montado de manera informal no les da nada. Un abogado prudente sin nada con lo que trabajar siempre te dará la respuesta cara.

Alto riesgo por dominio significa que el reglamento enumera dónde están las cosas lo bastante en juego como para el régimen pesado. El anexo III nombra ocho áreas. Si tu uso de la IA toca una de ellas, debes tratarlo como potencialmente de alto riesgo hasta que tus abogados determinen lo contrario.

El artículo 6.3 abre una salida estrecha. Un sistema que cae en un dominio del anexo III puede evitar la condición de alto riesgo cuando solo hace una tarea procedimental estrecha, cuando mejora el resultado de una actividad humana ya terminada o cuando detecta patrones sin sustituir el juicio humano.

Una herramienta que da formato a las notas de una entrevista toca empleo y a las claras no está decidiendo la carrera de nadie.

Esa excepción tiene varias condiciones que limitan su aplicación. La excepción tiene que estar documentada, con una evaluación escrita de por qué el sistema encaja, hecha antes de apoyarse en ella y no después de que alguien pregunte. Hay que registrarse además en la base de datos de la UE, que es el paso que más se olvida.

El perfilado elimina esa excepción. Un sistema en un dominio del anexo III que perfile a personas, en el sentido que le da el RGPD de evaluar aspectos de su vida como el rendimiento, la fiabilidad o la situación económica, es siempre de alto riesgo, haga lo que haga además.

Nuestra recomendación desde el punto de vista técnico es sencilla. Decide de qué lado de esa línea va a vivir un sistema antes de construirlo, escribe esa intención y diseña los flujos de datos para que el sistema no pueda cruzarla en silencio. El riesgo está en que el sistema vaya incorporando funciones hasta entrar en un uso distinto del que se evaluó inicialmente. Por ejemplo, una herramienta útil que gana una función por trimestre acaba haciendo algo que nadie clasificó.

Si un sistema que despliegas es de alto riesgo, el artículo 26 es tu lista. Estas son las obligaciones, explicadas una por una.

El artículo 27 añade un deber más que no es para todos. Solo obliga a un grupo definido. Son los organismos públicos, las empresas privadas que prestan servicios públicos y quienes usan sistemas de alto riesgo para puntuación crediticia o para riesgo y precio en seguros de vida y salud.

Esos tienen que hacer una evaluación de impacto sobre los derechos fundamentales antes del primer uso. Consiste en analizar qué derechos puede afectar el sistema, qué personas pueden verse afectadas y qué medidas existen si algo sale mal.

El reglamento permite apoyarse en trabajo ya hecho. Quien despliega puede basarse en una evaluación que hiciera el proveedor o en una evaluación de impacto existente que cubra el terreno, lo que en la práctica significa que el ejercicio se solapa mucho con la evaluación de impacto que tu delegado de protección de datos ya sabe hacer. Es una evaluación similar a la de protección de datos, pero centrada en un conjunto más amplio de derechos.

Nuestro papel ahí sigue siendo el mismo que en el resto de la página. La evaluación es tuya, la haces y la firmas tú. La descripción del sistema que necesita, qué hace, qué entra en él, quién lo supervisa y qué queda registrado, es el expediente que nuestros sistemas producen como efecto secundario de estar construidos así.

El artículo 4 es una obligación que muchas empresas pasan por alto porque no exige una medida técnica concreta. Desde febrero de 2025, proveedores y responsables del despliegue tienen que garantizar un nivel suficiente de alfabetización en materia de IA en las personas que operan y usan estos sistemas por su cuenta, proporcional a su puesto y al contexto.

Aplica a todo sistema de IA, sea de alto riesgo o no, por lo que es una obligación que ya puede afectar a cualquier empresa que utilice sistemas de IA.

¿Y cuánta formación es suficiente? «Suficiente» no está definido como un certificado. No significa que toda la plantilla necesite el mismo curso. Quien aprueba resultados de un modelo debe saber qué tareas puede delegar en él y cuáles debe revisar. Quien utiliza un asistente debe saber qué información no debe introducir en él. Quien supervisa un sistema de alto riesgo debe tener conocimientos suficientes para detectar problemas y decidir cuándo intervenir o detenerlo.

Una formación adaptada a cada puesto, documentada y con fechas, es una de las formas más sencillas de demostrar que cumples esta obligación y reducir errores de uso.

También debería formar parte de la evaluación de cualquier proveedor. Pregúntale qué material le entrega a tu equipo para esto, porque si no aporta materiales de formación, toda esa obligación queda en tu empresa.

Los deberes de transparencia del artículo 50 se aplican desde agosto de 2026 y son bastante concretos. A la persona que interactúa con un sistema de IA hay que informarle de que lo está haciendo, salvo que resulte obvio por el contexto.

El audio, la imagen y el vídeo sintéticos tienen que ir marcados como generados artificialmente y ese marcado lo debe quien construye el sistema. A quien despliega le toca avisar cuando publique una ultrasuplantación o un texto generado sobre asuntos de interés público. Quien despliega reconocimiento de emociones o categorización biométrica debe informar a las personas expuestas.

Para muchos sistemas empresariales, esto implica diseñar la interfaz para informar claramente de que se está utilizando IA. El asistente se presenta como asistente, el informe generado dice que se ha generado y debe existir una forma real de contactar con una persona cuando sea necesario.

Contamos cómo se presentan nuestros sistemas conversacionales y cómo entregan los casos urgentes al equipo en la página del servicio. Ese mismo diseño sirve para este artículo sin modificarlo.

La conclusión práctica es clara. Estas obligaciones son mucho más fáciles de cumplir cuando forman parte del diseño desde el principio que cuando se añaden después.

Desde el punto de vista técnico, muchas de esas obligaciones se pueden traducir en tres propiedades del sistema. El sistema debe generar registros, permitir que una persona lo inspeccione, intervenga o lo detenga, y mantener controladas su finalidad y sus entradas.

Ninguna de las tres se puede añadir de forma convincente después. Las tres salen baratas cuando son decisiones de diseño.

Estas medidas técnicas encajan con la forma en que construimos nuestros sistemas. No las añadimos por el reglamento: las adoptamos porque son necesarias para operar sistemas en producción con control. Nuestros sistemas escriben cada decisión según ocurre, en un registro al que se puede añadir pero que nunca se edita. El propio sistema nunca vuelve a leerlo, así que documenta el comportamiento sin influir en él.

La supervisión no es un nombre en un archivo. Las personas que hay detrás de nuestros asistentes reciben bandejas de casos reales con su rastro. Cada acción que un sistema hace por alguien corre con los permisos de esa persona, así que la pregunta de quién pudo hacer esto siempre tiene una respuesta que tu sistema de identidad ya conoce.

La vigilancia puede parecer una obligación abierta, pero es una de las que podemos demostrar con más facilidad. Antes de publicar un cambio tiene que pasar una batería de casos anotados y anonimizados. Después de publicar, cada semana una tanda de conversaciones de prueba anonimizadas recorre de principio a fin el sistema vivo.

Hacemos estas dos comprobaciones por separado para cubrir momentos distintos del ciclo de vida. Juntas permiten demostrar que el sistema se comprueba antes de cada cambio y también mientras está en producción.

Cuando un sistema que hemos construido entra en tu revisión de cumplimiento, estos materiales se generan durante la construcción y operación del sistema, no se preparan a posteriori para una revisión.

Nada de esto exige un consultor para empezar. Una persona competente de dentro, con una hoja de cálculo, permite pasar en pocos días de no tener un inventario a tener los sistemas identificados y una lista concreta de preguntas para los abogados. Y esas preguntas estarán basadas en sistemas y usos concretos, no en dudas generales.

El reglamento de IA y el RGPD hacen preguntas distintas sobre el mismo sistema. Uno regula el uso por su riesgo y el otro los datos personales de dentro.

Un mismo sistema puede cumplir las exigencias de ambos reglamentos si incorpora desde el diseño los registros, la supervisión y los controles necesarios. Esa arquitectura es la que nuestra página de RGPD describe mecanismo a mecanismo. Ese nivel de control forma parte de todos los sistemas que construimos, independientemente de que el uso concreto entre o no en el anexo III.

Si estás decidiendo si construir algo bajo estas reglas, la misma claridad vale para los presupuestos. Los nuestros están publicados.