UISH

Sección 5 – Comprueba si el software producido puede calificarse como inteligencia artificial

a cargo del CNR-IFAC

Valentina Colcelli, Nicola Zoppetti, Andrea Barucci, Andrea Manzi

La calificación del software como sistema de IA es el paso que determina la aplicación del Reglamento de IA y de las obligaciones consiguientes (en particular, la clasificación del riesgo y las obligaciones de transparencia, que se tratan más adelante en esta sección). Para orientar al desarrollador en esta comprobación se proponen a continuación: la definición normativa, una lista de comprobación secuencial sobre los siete elementos que la componen, un vocabulario técnico mínimo derivado de ISO/IEC 22989:2022, una profundización sobre el algoritmo determinista (caso en el que no procede la calificación como IA) y una serie de ejemplos de aplicación de la lista de comprobación.

5.1 Definición de sistema de IA: lista de comprobación, vocabulario y ejemplos

5.1.1 Algoritmo, modelo y sistema: de lo general a la IA

Antes de aplicar la lista de comprobación conviene fijar tres nociones anidadas —algoritmo, modelo y sistema—, primero en su significado general y después en el significado específico que adquieren para la inteligencia artificial con arreglo al Reglamento de IA y a la norma ISO/IEC 22989:2022.

En general

• Algoritmo: una secuencia finita y ordenada de instrucciones bien definidas para resolver un problema o tratar datos. La jurisprudencia administrativa lo ha definido como «una secuencia finita y ordenada de operaciones de cálculo elementales y claras que permiten resolver, de manera determinada, un problema» (Consejo de Estado, Secc. VI, sentencia n.º 2270/2019; cfr. TAR Campania, Nápoles, Secc. VII, 14 de noviembre de 2022, n.º 7003). En sí mismo es un procedimiento abstracto: no es ni «IA» ni «no IA».
• Modelo: según la ISO/IEC 22989:2022 (punto 3.1.23), es la «representación física, matemática o, de otro modo, lógica de un sistema, una entidad, un fenómeno, un proceso o unos datos». Es la representación sobre la que opera un sistema; en los sistemas de aprendizaje, es el constructo que, tras el entrenamiento, produce inferencias o predicciones.
• Sistema: un conjunto de componentes que interactúan, organizados para alcanzar uno o varios fines (definición general de «sistema», ISO/IEC/IEEE 24765:2017). Es el artefacto de ingeniería que pone en funcionamiento uno o varios algoritmos y modelos, con interfaces de entrada/salida hacia el entorno.

Para la inteligencia artificial

• Sistema de IA: con arreglo al artículo 3, punto 1, del Reglamento (UE) 2024/1689, es «un sistema basado en una máquina que está diseñado para funcionar con distintos niveles de autonomía […] y que, para objetivos explícitos o implícitos, infiere de la información de entrada que recibe la manera de generar resultados de salida» (texto íntegro en el § 5.1.2); en términos técnicos, la ISO/IEC 22989:2022 (punto 3.1.4) lo describe como «sistema de ingeniería que genera resultados de salida […] para un conjunto dado de objetivos definidos por el ser humano». El elemento que lo distingue del software tradicional es la inferencia, unida a la autonomía y a la capacidad de adaptación (considerando 12 del Reglamento de IA).
• Modelo de IA: es el modelo (en el sentido ISO antes indicado) entrenado con datos, núcleo que genera las inferencias del sistema. El Reglamento de IA no regula los modelos en cuanto tales, pero dedica una regulación específica a los modelos de uso general (GPAI), que presentan «un grado considerable de generalidad» y son capaces «de realizar de manera competente una gran variedad de tareas distintas» (artículo 3, punto 63). Por tanto, un modelo no es necesariamente un GPAI: el GPAI es solo el caso que activa obligaciones propias.
• Algoritmo en el contexto de la IA: también los sistemas de IA se basan en algoritmos (p. ej., algoritmos de aprendizaje), pero a efectos de la calificación lo relevante es cómo opera el algoritmo: si el sistema se limita a aplicar reglas fijadas manualmente, es un algoritmo determinista y queda fuera de la noción de IA; si, en cambio, un motor infiere conclusiones no especificadas puntualmente —incluso con reglas codificadas—, se entra en el ámbito de la IA (considerando 12 del Reglamento de IA; Consejo de Estado, Secc. III, sentencia n.º 7891/2021). La profundización se encuentra en el § 5.1.7.

Tabla sinóptica — las tres nociones en su significado general y en el específico para la IA.

5.1.2 Definición normativa

Con arreglo al artículo 3, punto 1, del Reglamento (UE) 2024/1689 (Reglamento de Inteligencia Artificial), se entiende por «sistema de IA»:

«un sistema basado en una máquina que está diseñado para funcionar con distintos niveles de autonomía y que puede mostrar capacidad de adaptación tras el despliegue, y que, para objetivos explícitos o implícitos, infiere de la información de entrada que recibe la manera de generar resultados de salida, como predicciones, contenidos, recomendaciones o decisiones, que pueden influir en entornos físicos o virtuales».

Nota terminológica. La versión italiana del Reglamento de IA traduce la expresión inglesa machine-based system por «sistema automatizzato». Las Directrices de la Comisión (apdos. 11–12) aclaran que el término indica únicamente que el sistema funciona por medio de máquinas, es decir, de componentes de hardware y software que proporcionan capacidad de cálculo: «todos los sistemas de IA son automatizados, ya que requieren máquinas para su funcionamiento». Por tanto, el adjetivo no debe leerse como sinónimo de automatización: el elemento 1 es un presupuesto común a cualquier software y no es, por sí solo, indicio de IA. Lo que distingue un sistema de IA del software tradicional, por automatizado que sea, es la capacidad de inferencia (elemento 5).

Cuando el software desarrollado es, en cambio, un modelo (y no un sistema), es relevante la definición de «modelo de IA de uso general» del artículo 3, punto 63, del Reglamento de IA; en tal caso, se remite al § 5.3 (Cuestionario de definición de modelo de IA).

5.1.3 Nociones relacionadas

Las nociones que siguen no son objeto de la lista de comprobación del § 5.1.4, pero constituyen referencias útiles para el lector que, una vez calificado su software, quiera situarlo correctamente en el marco normativo del Reglamento de IA y del ordenamiento nacional.

Sistema de IA de uso general (GPAI) — artículo 3, punto 66, del Reglamento de IA. Sistema de IA basado en un modelo de IA de uso general y que puede servir para diversos fines, tanto para su uso directo como para su integración en otros sistemas de IA. La clasificación de los modelos GPAI con riesgo sistémico la establece el artículo 51 del Reglamento de IA (umbrales de capacidad de cálculo y criterios del anexo XIII).

Proveedor posterior — artículo 3, punto 68, del Reglamento de IA. Proveedor de un sistema de IA —también de uso general— que integra un modelo de IA, con independencia de que el modelo lo proporcione él mismo y esté integrado verticalmente o lo proporcione otra entidad en virtud de relaciones contractuales. La noción es relevante para determinar las obligaciones a lo largo de la cadena de valor.

Proveedor y responsable del despliegue — artículo 3, puntos 3 y 4, del Reglamento de IA. El proveedor desarrolla un sistema de IA, o encarga su desarrollo, y lo introduce en el mercado o lo pone en servicio con su propio nombre o marca; el responsable del despliegue utiliza un sistema de IA bajo su propia autoridad, salvo el uso personal no profesional. La distinción es decisiva porque las obligaciones del Reglamento de IA se reparten entre los dos papeles: la entidad que desarrolla y entrega a la administración pública un módulo de IA del GDU puede asumir la posición de proveedor, mientras que la administración pública que lo emplea en sus propios procedimientos es, por regla general, responsable del despliegue; la administración pública es, en cambio, proveedor si desarrolla o encarga el desarrollo de un sistema y lo pone en servicio con su propio nombre o marca (artículo 3, punto 3), y pasa a serlo en los casos del artículo 25, apartado 1 (véanse los recuadros más adelante en esta sección).

Normativa nacional sobre IA. La Ley n.º 132, de 23 de septiembre de 2025 (G.U. de 25 de septiembre de 2025, código de redacción 25G00143), establece los principios y las delegaciones legislativas para la adaptación del ordenamiento interno al Reglamento (UE) 2024/1689 y debe consultarse para los aspectos de competencia nacional (autoridades competentes, sanciones, investigación, tratamiento de datos). A efectos de la ley se aplica la misma definición de sistema de IA del reglamento (artículo 2, apartado 1, letra a)).

Directrices de AGID para la adopción de la IA en la administración pública. El Borrador de Directrices de AGID (Resolución n.º 17/2025) recoge la definición de sistema de IA del artículo 3, punto 1, del Reglamento de IA y desarrolla en una tabla sus cuatro características distintivas (capacidad inferencial, objetivos, niveles de autonomía variables, capacidad de adaptación). Es la referencia operativa para las administraciones públicas en fase de adopción.

5.1.4 Lista de comprobación secuencial — los siete elementos de la definición

La definición se compone de siete elementos. Para cada uno de ellos, el desarrollador valora si concurre en su software respondiendo a la pregunta guía y contrastando el criterio con la realidad del sistema; los ejemplos proporcionados —articulados en dos grupos, respectivamente para los sistemas comprendidos en el elemento y para los que no lo están— tienen una función orientativa. Las Directrices de la Comisión (apdo. 9) precisan que no es necesario que los siete elementos estén presentes de forma continua: algunos pueden aparecer solo en la fase de construcción (entrenamiento) y no en la de uso, y viceversa.

Elemento 1 — Sistema automatizado (basado en una máquina)

Pregunta guía. ¿El software se implementa y ejecuta en una máquina, entendida como combinación de componentes de hardware (unidades de procesamiento, memoria, almacenamiento, red) y de software (código, programas, sistema operativo), que se encarga de su funcionamiento sin necesidad de ejecutar manualmente cada uno de los pasos?

Criterio de concurrencia. El elemento concurre cuando la ejecución del software depende enteramente de una plataforma computacional capaz de procesar los datos y producir los resultados: la noción es deliberadamente amplia y comprende sistemas tradicionales, computación distribuida, computación cuántica e incluso sistemas biológicos u orgánicos, siempre que proporcionen capacidad computacional (Directrices de la Comisión, apdos. 11–13). En cambio, no concurre en presencia de procedimientos enteramente manuales, aunque estén documentados.

Ejemplos de sistemas comprendidos en el elemento:

• Servicio en la nube que aloja un clasificador de imágenes para reconocer vehículos, peatones y ciclistas a partir de las cámaras de tráfico del GDU.
• Microservicio de backend que recibe los datos de una red de sensores IoT urbanos, los pasa a un modelo y devuelve un resultado.
• Módulo embebido ejecutado en un dispositivo edge (p. ej., un controlador de semáforos) que realiza la inferencia en el propio dispositivo.
• Sistema híbrido que combina procesamiento clásico y módulos de computación cuántica para problemas de optimización del transporte público.
• Pipeline de simulación molecular ejecutado en un clúster HPC para el estudio de sistemas biofísicos.
• Pipeline de análisis de imágenes de microscopía confocal ejecutado en una estación de trabajo con GPU dedicadas.

Ejemplos de sistemas no comprendidos:

• Procedimiento de evaluación de expedientes realizado íntegramente por el operador con herramientas en papel o formularios que se rellenan a mano.
• Hoja de cálculo actualizada constantemente por el operador, sin componente de procesamiento automático.
• Directriz organizativa recogida en un documento pero no traducida en ninguna aplicación.
• Experimento de laboratorio con instrumentación manual y anotación de los resultados en un cuaderno, sin implementación del procedimiento en software.

Elemento 2 — Autonomía variable

Pregunta guía. ¿El software está diseñado para producir resultados de salida con un grado, aunque sea mínimo, de independencia respecto de la intervención humana directa y continua?

Criterio de concurrencia. El elemento concurre cuando el sistema puede generar al menos un resultado de salida no especificado puntualmente por el operador: la relación entre autonomía e implicación humana es un continuo (Directrices de la Comisión, apdos. 15–17), por lo que también es relevante el caso del sistema que recibe entradas manuales pero produce de forma autónoma el resultado de salida. No concurre cuando cada resultado de salida del software está enteramente determinado por una acción humana puntual y paso a paso, sin ningún margen de iniciativa del sistema.

Ejemplos de sistemas comprendidos en el elemento:

• Sistema de detección de anomalías en los flujos de tráfico del GDU que, una vez recibidos los datos en tiempo real de los sensores, emite una alerta sin necesidad de confirmación humana en cada caso.
• Módulo de transcripción automática del habla a texto, que produce la transcripción sin que el usuario intervenga en cada palabra.
• Planificador de rutas que, una vez recibidas las restricciones de origen, destino y disponibilidad de la red, devuelve de forma autónoma un plan completo.
• Filtro antispam que etiqueta los mensajes sin requerir una decisión humana sobre cada uno.
• Pipeline de observación astronómica que identifica automáticamente candidatos a fenómenos transitorios en los flujos de datos del telescopio, sin intervención para cada imagen.
• Sistema de adquisición automática en física de altas energías que aplica un trigger de primer nivel a los datos de los detectores sin intervención humana puntual.

Ejemplos de sistemas no comprendidos:

• Editor de texto que ejecuta exclusivamente los comandos de formato activados uno a uno por el usuario.
• Calculadora científica.
• Macro o script que ejecuta una secuencia de operaciones rigurosamente idéntica en cada invocación.
• Flujo de trabajo de aprobación en el que cada avance requiere la acción manual puntual del operador y el resultado de salida de cada nodo es solo el registro de la elección humana.
• Sesión de análisis estadístico en un entorno interactivo (R, notebook de Python) en la que el investigador configura y supervisa cada uno de los pasos.

Elemento 3 — Capacidad de adaptación tras el despliegue

Pregunta guía. ¿El software, una vez puesto en servicio, puede modificar su comportamiento sobre la base de la experiencia adquirida, hasta el punto de generar resultados de salida distintos ante una misma entrada?

Criterio de concurrencia. El elemento concurre cuando el sistema dispone de mecanismos de autoaprendizaje o de actualización de sus parámetros durante el uso, aunque se limiten a fases de reentrenamiento automático cuando se alcanzan determinados umbrales. No concurre cuando el modelo queda congelado en el momento de su publicación y cualquier modificación del comportamiento requiere una nueva versión. La capacidad de adaptación no es un requisito obligatorio para la calificación como IA (Reglamento de IA, artículo 3, y Directrices de la Comisión, apdos. 22–23): su ausencia no excluye por sí misma la calificación, pero su presencia la refuerza.

Ejemplos de sistemas comprendidos en el elemento:

• Motor de recomendación de servicios públicos que reajusta los pesos del modelo en producción sobre la base de las interacciones de los usuarios (aprendizaje en línea).
• Sistema de detección de fraudes que realiza un ajuste fino periódico automático con datos recogidos durante el funcionamiento.
• Agente de aprendizaje por refuerzo que actualiza su política de decisión a raíz de la retroalimentación recibida del entorno.
• Pipeline con reentrenamiento automático desencadenado por la superación de un umbral de deriva de los datos.
• Clasificador de imágenes histopatológicas reentrenado de forma continua a medida que llegan nuevos casos etiquetados por los patólogos.
• Modelo de análisis de la señal fisiológica que adapta sus parámetros a cada paciente durante el uso clínico.

Ejemplos de sistemas no comprendidos:

• Modelo de clasificación cuyos parámetros permanecen invariables tras su publicación; las posibles actualizaciones se realizan solo fuera de línea y mediante la distribución de una nueva versión del servicio.
• Componente con lógica codificada manualmente que no cambia salvo con un nuevo despliegue.
• Calculador de indicadores sintéticos cuyos pesos se fijan de antemano y nunca se revisan sin intervención humana.
• Modelo de simulación climática cuyos parámetros (físicos y calibrados) quedan congelados en el momento de lanzar la ejecución de producción y no se modifican durante el funcionamiento.

Elemento 4 — Objetivos (explícitos o implícitos)

Pregunta guía. ¿El software persigue, durante su funcionamiento, uno o varios objetivos —aunque no se declaren explícitamente— que puedan deducirse de su comportamiento o de sus hipótesis de diseño?

Criterio de concurrencia. El elemento concurre tanto cuando los objetivos están codificados de forma declarada (por ejemplo, una función de coste o de recompensa) como cuando surgen implícitamente de los parámetros elegidos, de los datos de entrenamiento o de las métricas de evaluación. Debe distinguirse de la finalidad prevista, que es externa al sistema y describe el contexto de uso (Directrices de la Comisión, apdos. 24–25). No concurre cuando el software se limita a operaciones mecánicas carentes de objetivo interno: transformaciones de formato, copias, conversiones de codificación.

Ejemplos de sistemas comprendidos en el elemento:

• Clasificador entrenado para minimizar el error sobre un conjunto etiquetado (función de pérdida explícita).
• Sistema de recomendación que, incluso sin una declaración formal, optimiza implícitamente métricas de interacción (engagement) de los usuarios.
• Asistente conversacional para la ciudadanía cuyo objetivo interno es maximizar la exactitud de las respuestas respecto de las preguntas frecuentes oficiales de la administración pública.
• Sistema de detección de anomalías en el alumbrado público cuyo objetivo es minimizar los falsos negativos sobre un conjunto reducido de patrones de avería conocidos.
• Modelo para la predicción de la estructura terciaria de proteínas, entrenado para minimizar el error respecto de estructuras resueltas experimentalmente.
• Modelo de triaje clínico cuyo objetivo interno es maximizar la sensibilidad en la detección de casos de riesgo.

Ejemplos de sistemas no comprendidos:

• Conversor de archivos CSV a JSON sin ninguna evaluación interna.
• Función hash criptográfica.
• Compresor sin pérdida que aplica una transformación determinista carente de objetivo propio en el sentido del Reglamento de IA.
• Tarea programada de copia de seguridad que copia los datos en otra unidad.
• Integrador numérico de ecuaciones diferenciales ordinarias (p. ej., método de Runge–Kutta) que aplica una fórmula de cuadratura sin objetivo propio.
• Código de cálculo que resuelve un sistema lineal con un método directo (p. ej., factorización LU): ejecuta un procedimiento matemático sin objetivo interno autónomo.

Elemento 5 — Inferencia a partir de la información de entrada

Pregunta guía. ¿El software obtiene sus resultados de salida a partir de las entradas mediante un proceso inferencial, es decir, un razonamiento que lleva a conclusiones a partir de premisas conocidas (hechos, reglas, modelos, características, datos brutos), yendo más allá de la mera ejecución de reglas codificadas explícitamente?

Criterio de concurrencia. El elemento concurre cuando el resultado de salida lo producen técnicas de aprendizaje automático (supervisado, no supervisado, autosupervisado, por refuerzo) o enfoques lógico-simbólicos dotados de un motor de inferencia que derive conclusiones no especificadas puntualmente (Directrices de la Comisión, apdos. 26–28; ISO/IEC 22989, 3.1.17). No concurre cuando las reglas están enteramente codificadas por personas físicas y se aplican de forma determinista, ni en los casos de mera optimización matemática que mejora la eficiencia de métodos consolidados sin aprendizaje. El elemento es central: su ausencia excluye por regla general la calificación como IA. Tampoco constituyen inferencia las consultas a bases de datos, los filtros o las macros de hojas de cálculo, por complejos que sean, cuyos resultados vienen determinados por criterios enteramente establecidos por el operador.

Ejemplos de sistemas comprendidos en el elemento:

• Red neuronal convolucional que, a partir de las imágenes de las cámaras del GDU, clasifica los vehículos por categoría.
• Sistema experto con motor de inferencia que aplica reglas lógicas para apoyar un diagnóstico de infraestructuras.
• Árbol de decisión entrenado con datos históricos de consumo eléctrico para estimar la demanda energética de un barrio.
• Modelo transformer (LLM) que genera respuestas textuales en lenguaje natural a partir de la pregunta del usuario.
• Modelo bayesiano que infiere la probabilidad de avería de un componente a partir de los datos telemétricos.
• Red profunda para la identificación de partículas en experimentos de física de altas energías a partir de los datos de los detectores.
• Modelo transformer para la predicción de propiedades químicas o biológicas de nuevas moléculas en el descubrimiento de fármacos.
• Modelo generativo que propone candidatos de síntesis retrosintética en química orgánica.

Ejemplos de sistemas no comprendidos:

• Flujo de trabajo if-then-else escrito íntegramente a mano por el diseñador, en el que cada condición y cada acción se especifican puntualmente.
• Algoritmo de ordenación (p. ej., quicksort) o de búsqueda en grafos (p. ej., Dijkstra) utilizado de forma determinista, sin componente de aprendizaje.
• Solucionador de programación lineal que mejora la eficiencia computacional de un problema de optimización consolidado.
• Modelo de previsión simple (p. ej., media móvil de las temperaturas) utilizado como referencia estadística (benchmark).
• Sistema de gestión de bases de datos que aplica filtros o agregaciones según criterios establecidos explícitamente.
• Transformada rápida de Fourier (FFT) aplicada a una señal experimental para pasar al dominio de la frecuencia.
• Filtro de Kalman lineal para el seguimiento de trayectorias a partir de un modelo dinámico especificado a priori por el diseñador.

Elemento 6 — Resultados de salida: predicciones, contenidos, recomendaciones o decisiones

Pregunta guía. ¿El software produce al menos una de las cuatro categorías de resultados de salida indicadas por el Reglamento de IA: predicciones (estimaciones de valores desconocidos), contenidos (materiales generados desde cero), recomendaciones (sugerencias) o decisiones (elecciones adoptadas de forma autónoma)?

Criterio de concurrencia. El elemento concurre cuando el resultado de salida pertenece al menos a una de las cuatro categorías, con independencia del grado de acción que se derive de él (Directrices de la Comisión, apdos. 54–57). La noción de predicción comprende también resultados no referidos al futuro: clasificaciones, traducciones, diagnósticos de hechos pasados (cfr. ISO/IEC 22989, 3.1.27). No concurre cuando el resultado de salida es una mera representación descriptiva o una visualización de datos sin ninguna valoración por parte del sistema.

Ejemplos de sistemas comprendidos en el elemento:

• Previsión de la congestión de una zona urbana para las próximas seis horas a partir de series históricas y datos en tiempo real.
• Generación automática de descripciones textuales que acompañan a imágenes de satélite para la documentación de actuaciones de la administración pública.
• Lista ordenada de intervenciones prioritarias de mantenimiento viario, producida como recomendación para la oficina competente.
• Decisión automática de prolongar la fase verde del semáforo en función del flujo de vehículos detectado en tiempo real.
• Predicción de la toxicidad de un compuesto químico a partir de su estructura molecular (predicción).
• Recomendación de candidatos farmacológicos prioritarios que deben sintetizarse y probarse en laboratorio.

Ejemplos de sistemas no comprendidos:

• Cuadro de mando que visualiza las series históricas de consumo de agua sin derivar valoraciones ni sugerencias.
• Exportación de un informe PDF que contiene exclusivamente tablas y gráficos de datos brutos.
• Tabla devuelta por una consulta SQL, presentada al operador sin ningún tratamiento valorativo.
• Función de anonimización que se limita a seudonimizar los campos de un conjunto de datos.
• Visualización de un diagrama de Hertzsprung–Russell calculado a partir de un catálogo estelar, sin valoraciones asociadas.
• Tabla de los parámetros obtenidos de un ajuste no lineal (p. ej., coeficientes de un modelo cinético) presentada al investigador sin derivar ninguna recomendación o decisión.

Elemento 7 — Influencia en entornos físicos o virtuales

Pregunta guía. ¿Los resultados de salida del software inciden concretamente en entidades físicas (objetos, personas, infraestructuras) o virtuales (sistemas de información, procesos, decisiones)?

Criterio de concurrencia. El elemento concurre cuando los resultados de salida del sistema están destinados a ser consumidos, expuestos o ejecutados en un entorno, produciendo efectos tangibles o digitales (Directrices de la Comisión, apdo. 9, y considerando 12 del Reglamento de IA). No concurre cuando el resultado de salida permanece puramente interno al sistema, no se expone ni se consume y no produce ninguna repercusión. La noción de influencia es amplia e incluye tanto la acción sobre objetos físicos (actuadores, vehículos, infraestructuras) como la acción sobre entornos digitales (modificación de información, alimentación de otros procesos, condicionamiento de las elecciones de usuarios u operadores).

Ejemplos de sistemas comprendidos en el elemento:

• Orden automática a un actuador vial (apertura o cierre de una barrera, activación de un semáforo).
• Actualización de una base de datos operativa que rige la prestación de servicios públicos (p. ej., cola de reservas).
• Modificación de la priorización de las llamadas a un centro de atención telefónica municipal sobre la base de una estimación del riesgo.
• Notificación al ciudadano de una clasificación de su expediente (aunque la decisión final la adopte después un funcionario).
• Alimentación de un sistema posterior (p. ej., un cuadro de mando de seguimiento) que desencadena acciones de otras oficinas.
• Triaje automático de pruebas radiológicas que reordena la cola de lectura del radiólogo sobre la base de la probabilidad de hallazgo.
• Orden a un microscopio robótico para adquirir fotogramas adicionales de una región de interés identificada por el sistema.

Ejemplos de sistemas no comprendidos:

• Resultado calculado en un entorno de pruebas interno y nunca expuesto, almacenado ni consumido.
• Resultado de salida escrito en un archivo de registro temporal que no lee ningún proceso ni ningún operador.
• Resultado de un benchmark ejecutado sobre el modelo en la fase de evaluación previa a su publicación.
• Resultado de una simulación exploratoria archivado, nunca publicado ni utilizado para tratamientos o decisiones posteriores.

Regla de lectura de la lista de comprobación

La comprobación de la concurrencia de los siete elementos debe realizarse a lo largo de ambas fases del ciclo de vida del sistema, que las Directrices de la Comisión (apdo. 9) identifican en la fase anterior al despliegue, o «de construcción» del sistema, y en la posterior al despliegue, o «de uso». Las mismas Directrices aclaran que «no es necesario que los siete elementos indicados en dicha definición estén presentes de forma continua en ambas fases de dicho ciclo de vida»: la definición reconoce «la posibilidad de que algunos elementos específicos aparezcan en una fase, pero no persistan en ambas fases». En particular, la capacidad de adaptación (elemento 3) es propia solo de la fase de uso, mientras que la inferencia (elemento 5) puede manifestarse tanto en la obtención de modelos o algoritmos a partir de los datos durante la construcción como en la generación de resultados de salida a partir de las entradas durante el uso (Directrices, apdo. 28).

Entre los siete elementos, tienen carácter necesario el sistema automatizado (elemento 1), un grado, aunque sea mínimo, de autonomía (elemento 2), los objetivos, explícitos o implícitos (elemento 4), y la capacidad de inferir (elemento 5): en su ausencia no se está ante un sistema de IA con arreglo al Reglamento de IA. La capacidad de inferencia no debe entenderse en sentido restrictivo: el considerando 12 del Reglamento (UE) 2024/1689 especifica que «las técnicas que permiten la inferencia al construir un sistema de IA incluyen estrategias de aprendizaje automático que aprenden de los datos cómo alcanzar determinados objetivos y estrategias basadas en la lógica y el conocimiento que infieren a partir de conocimientos codificados o de una representación simbólica». La noción es coherente con la ISO/IEC 22989:2022, 3.1.17, que define la inferencia como «razonamiento mediante el cual se extraen conclusiones a partir de premisas conocidas», precisando que, en el ámbito de la IA, una premisa es «un hecho, una regla, un modelo, una característica o datos brutos» (Directrices de la Comisión, apdo. 27).

Las Directrices califican también la autonomía (2) como condición necesaria: «el nivel de autonomía es una condición necesaria para determinar si un sistema puede considerarse un sistema de IA» (apdo. 20). Sin embargo, el umbral es bajo y está estrechamente ligado a la inferencia, con la que «va de la mano» (apdo. 15), ya que basta «cierto grado de independencia con respecto a la actuación humana» (considerando 12 del Reglamento de IA): en la práctica, un sistema que infiere ya dispone del mínimo de autonomía exigido. En particular, la autonomía no queda excluida por la presencia de intervención humana: la implicación humana puede ser «directa […] o indirecta, por ejemplo a través de controles […] que permiten a los seres humanos delegar o supervisar» (apdo. 17), y «un sistema que requiere entradas manuales para generar un resultado de salida […] es un sistema con cierto grado de autonomía», al igual que el sistema que, a partir de entradas humanas, «produce por sí solo una recomendación» (apdo. 18). Solo queda excluida la ejecución enteramente manual; la supervisión o la confirmación humana del resultado de salida no degradan la calificación, ya que corresponden a la supervisión humana (artículo 14 del Reglamento de IA), que presupone un sistema de IA. La capacidad de adaptación (3) es, en cambio, facultativa (apdos. 22–23); los objetivos (4), explícitos o implícitos (apdos. 24–25), son necesarios, porque la definición los exige sin alternativas. Los elementos 6 (resultados de salida del tipo predicciones, contenidos, recomendaciones, decisiones) y 7 (influencia en entornos físicos o virtuales) califican el efecto del sistema y delimitan la categoría de los resultados de salida relevantes.

En síntesis, el software entra en la definición de sistema de IA cuando concurren conjuntamente, al menos en una de las dos fases del ciclo de vida, los elementos necesarios 1 (sistema automatizado), 2 (autonomía, con un umbral mínimo), 4 (objetivos explícitos o implícitos) y 5 (inferencia), con un resultado de salida atribuible a las categorías indicadas por el elemento 6 e idóneo para incidir en el entorno físico o virtual (elemento 7); la capacidad de adaptación (3) es facultativa. A la inversa, la mera ejecución automática de reglas enteramente fijadas por el diseñador, sin un proceso inferencial efectivo, excluye la calificación como IA. En tal caso, el software entra en la noción de algoritmo determinista: el Consejo de Estado (Secc. III, sentencia n.º 7891/2021) ha aclarado expresamente que la inteligencia artificial concurre cuando «el algoritmo contempla mecanismos de machine learning y crea un sistema que no se limita solo a aplicar las reglas de software y los parámetros preestablecidos (como hace, en cambio, el algoritmo tradicional) sino que, por el contrario, elabora constantemente nuevos criterios de inferencia entre datos y adopta decisiones eficientes sobre la base de dichas elaboraciones, según un proceso de aprendizaje automático». Para la profundización se remite al § 5.1.7. Una vez calificado el software como sistema de IA, los pasos siguientes —identificación del propio papel (proveedor o responsable del despliegue), comprobación de las exclusiones del artículo 2 (en particular, investigación y desarrollo, apartados 6 y 8), clasificación del riesgo (artículos 5 y 6) y obligaciones de transparencia (artículo 50)— se tratan más adelante en esta sección.

5.1.5 Casos no comprendidos en la definición

El considerando 12 del Reglamento de IA precisa que la definición debe distinguir los sistemas de IA de los «sistemas de software o los planteamientos de programación tradicionales y más sencillos» y no abarca los sistemas basados en reglas definidas únicamente por personas físicas. Las Directrices de la Comisión (sección 5.2, apdos. 40–51) enumeran las categorías que, aunque en algunos casos puedan inferir de forma limitada, quedan fuera de la noción por su limitada capacidad de analizar patrones y de ajustar de forma autónoma el resultado de salida. La exclusión no es automática: debe comprobarse caso por caso aplicando la lista de comprobación del § 5.1.4.

• Sistemas basados en reglas definidas únicamente por personas físicas: ejecutan operaciones de forma automática aplicando reglas fijadas por el ser humano, sin aprendizaje, razonamiento o modelización autónomos (considerando 12 del Reglamento de IA; Directrices, apdo. 40). Es el caso del algoritmo determinista que se analiza en profundidad en el § 5.1.7.
• Sistemas para mejorar la optimización matemática: aceleran o aproximan métodos de optimización consolidados (p. ej., regresión lineal o logística): aunque tengan capacidad inferencial, no trascienden «el tratamiento básico de datos» y persiguen la eficiencia computacional, no decisiones que se adapten de forma inteligente (Directrices, apdos. 42–45).
• Sistemas de tratamiento básico de datos: siguen instrucciones predefinidas y explícitas, sin técnicas de IA (p. ej., gestión de bases de datos para filtrar registros, hojas de cálculo sin funcionalidades de IA) (Directrices, apdo. 46).
• Sistemas de análisis descriptivo, contraste de hipótesis y visualización: sintetizan y representan los datos con métodos estadísticos (p. ej., cuadros de mando de ventas, pruebas de significación), pero no «aprenden, razonan ni modelizan» ni recomiendan acciones (Directrices, apdo. 47).
• Sistemas basados en la heurística clásica: aplican reglas o algoritmos predefinidos para obtener soluciones aproximadas (p. ej., minimax con evaluación heurística en el ajedrez), sin aprender de los datos (Directrices, apdo. 48).
• Sistemas de predicción simples: aquellos cuyo rendimiento se obtiene con una regla estadística elemental de base (p. ej., predicción igual a la media histórica), aunque técnicamente se basen en ML, quedan excluidos por su rendimiento limitado; sirven típicamente como referencia (benchmark) (Directrices, apdos. 49–51).

Varios de estos casos se retoman, con la cumplimentación explícita de la lista de comprobación, entre los ejemplos del § 5.1.8 (en particular, los casos límite de ML); la profundización sobre el algoritmo determinista se encuentra en el § 5.1.7.

5.1.6 Vocabulario técnico — entradas esenciales de la ISO/IEC 22989:2022

Las entradas que siguen, tomadas de la cláusula 3 de la norma ISO/IEC 22989:2022 (Information technology — Artificial intelligence — Artificial intelligence concepts and terminology), constituyen el puente entre la definición normativa y el plano de implementación del sistema. Se recomienda el uso coherente de estos términos en la documentación técnica.

La tabla siguiente relaciona los siete elementos de la definición (artículo 3, punto 1, del Reglamento de IA) con las entradas de la ISO/IEC 22989:2022. Cuando la norma ISO no ofrece una entrada específica, el elemento lo precisan las Directrices de la Comisión (los números remiten a los apartados de las Directrices). Las definiciones ISO completas se recogen justo después.

Tabla de correspondencias — para cada elemento de la definición, la entrada ISO/IEC 22989 correspondiente; cuando la ISO no ofrece una entrada específica, la referencia son las Directrices de la Comisión.

Sistema de IA (AI system) — 3.1.4. Sistema de ingeniería que genera resultados de salida como contenidos, previsiones, recomendaciones o decisiones para un conjunto dado de objetivos definidos por el ser humano. Para lograrlos puede utilizar técnicas y enfoques diversos con el fin de construir un modelo que represente datos, conocimiento y procesos.

Inferencia (inference) — 3.1.17. Razonamiento mediante el cual se extraen conclusiones a partir de premisas conocidas; en el ámbito de la IA, la premisa es un hecho, una regla, un modelo, una característica o un dato bruto. El término designa tanto el proceso como su resultado.

Modelo (model) — 3.1.23. Representación física, matemática o, de otro modo, lógica de un sistema, una entidad, un fenómeno, un proceso o unos datos. En los sistemas de aprendizaje, es el constructo que, tras el entrenamiento, produce inferencias o predicciones a partir de los datos de entrada.

Autonomía (autonomy) — 3.1.5. Característica de un sistema capaz de modificar su propio ámbito de uso o su propio objetivo sin intervención, control o supervisión externos. Se distingue de la mera automatización (3.1.7), que indica el funcionamiento sin intervención humana en condiciones especificadas.

Aprendizaje automático (machine learning, ML) — 3.3.5. Proceso de optimización de los parámetros de un modelo mediante técnicas computacionales, de modo que el comportamiento del modelo refleje datos o experiencia. Se divide en supervisado (3.3.13), no supervisado (3.3.18), semisupervisado (3.3.12) y por refuerzo (3.3.10).

Datos de entrenamiento (training data) — 3.3.17. Datos utilizados para entrenar un modelo de aprendizaje automático. Su calidad, cobertura y corrección inciden directamente en la representatividad y en la fiabilidad del modelo resultante.

IA simbólica y subsimbólica (symbolic / subsymbolic AI) — 3.1.33, 3.1.34. La IA simbólica se basa en la manipulación de símbolos según reglas explícitas (resultados de salida declarativos); la IA subsimbólica utiliza una codificación implícita derivada de datos o de la experiencia (resultados de salida con probabilidad de error). La distinción es útil para argumentar la presencia del elemento 5 de la definición (inferencia).

Predicción (prediction) — 3.1.27. Resultado de salida primario de un sistema de IA a partir de datos de entrada. No implica necesariamente una referencia al futuro: comprende clasificación, traducción, generación, diagnóstico de hechos pasados.

5.1.7 Profundización: el algoritmo determinista (cuando no se está ante una IA)

Si la comprobación del § 5.1.4 excluye la calificación del software como sistema de IA, el software entra normalmente en la categoría del algoritmo determinista. La jurisprudencia administrativa lo ha definido (Consejo de Estado, Secc. VI, sentencia n.º 2270/2019; cfr. también TAR Campania, Nápoles, Secc. VII, 14 de noviembre de 2022, n.º 7003) como «una secuencia finita y ordenada de operaciones de cálculo elementales y claras que permiten resolver, de manera determinada, un problema».

El algoritmo determinista se caracteriza por las siguientes propiedades:

• Finitud: conduce a la solución en un número finito de pasos;
• Generalidad: resuelve una clase de problemas y no un único problema aislado;
• No ambigüedad: las instrucciones se especifican de forma unívoca: la ejecución se produce siempre del mismo modo, con independencia de quién la realice;
• Repetibilidad (determinismo): ante una misma entrada, el algoritmo proporciona siempre el mismo resultado.

Diferencia con el sistema de IA

El Consejo de Estado (Secc. III, sentencia n.º 7891/2021) ha aclarado que el algoritmo, incluso cuando se aplica a sistemas tecnológicos, sigue siendo una «secuencia finita de instrucciones, bien definidas y no ambiguas»; la inteligencia artificial concurre, en cambio, cuando «el algoritmo contempla mecanismos de machine learning y crea un sistema que no se limita solo a aplicar las reglas de software y los parámetros preestablecidos (como hace, en cambio, el algoritmo tradicional) sino que, por el contrario, elabora constantemente nuevos criterios de inferencia entre datos y adopta decisiones eficientes sobre la base de dichas elaboraciones, según un proceso de aprendizaje automático».

En términos operativos, la diferencia se traduce en el elemento 5 de la lista de comprobación: el algoritmo determinista no infiere, sino que aplica reglas fijadas manualmente; el sistema de IA infiere, incluso cuando las reglas están codificadas (siempre que exista un motor de inferencia que derive conclusiones no especificadas puntualmente).

Mismo algoritmo, dos usos. La distinción no se refiere al instrumento matemático en sí, sino al uso que se hace de él. Una regresión o una red neuronal, incluso de pocas neuronas, pueden servir para describir un conjunto de datos ya conocido —estimar parámetros, interpolar, verificar una hipótesis— o bien para aprender de los datos una función destinada a producir resultados de salida correctos con entradas nunca observadas, según la práctica del aprendizaje automático (separación entre datos de entrenamiento, validación y prueba; medición del error con datos no vistos). Solo en el segundo caso el sistema «infiere de la información de entrada la manera de generar resultados de salida» en el sentido del elemento 5: las Directrices describen el aprendizaje como la adquisición de una correspondencia entre entradas y salidas «generalizándola posteriormente a datos nuevos y no vistos» (apartado 33). El primer uso, en cambio, se encuadra entre los casos excluidos del § 5.1.5 (optimización matemática, análisis descriptivo y comprobación de hipótesis). Los ejemplos 5 y 11 del § 5.1.8 ilustran el primer uso; los ejemplos 2 y 12, el segundo. El criterio es una ayuda práctica y no sustituye a las exclusiones de las Directrices: un modelo que generaliza puede quedar igualmente fuera de la definición si solo sirve para acelerar métodos consolidados (ejemplo 4; apartados 42–45).

Implicaciones para la administración pública

La calificación como algoritmo determinista excluye la aplicación del Reglamento de IA, pero no la de los principios que la jurisprudencia administrativa aplica al uso de procedimientos automatizados por parte de la administración pública (véanse Consejo de Estado, Sección VI, sentencias n.º 2270/2019 y n.os 8472–8474/2019; Sección III, n.º 7891/2021): cognoscibilidad de la regla técnica, transparencia reforzada (la «fórmula técnica» debe ir acompañada de explicaciones que la traduzcan en la regla jurídica subyacente), identificación del responsable del procedimiento, obligación de motivación, garantías de participación, no exclusividad de la decisión algorítmica (presencia de un control humano significativo en el circuito decisorio). Se remite a la sección 7 (apartados 7.3, 7.4.1.2 y 7.4.2).

5.1.8 Ejemplos generales de aplicación de la lista de comprobación

A continuación se ilustra la cumplimentación de la lista de comprobación en doce casos de estudio, elegidos para cubrir las cuatro situaciones relevantes para la calificación: sistemas de IA plenamente sujetos al Reglamento de IA, sistemas de IA exentos con arreglo al artículo 2, apartado 6 (investigación científica), algoritmos deterministas en el sentido del § 5.1.7 y software que, aun empleando técnicas de aprendizaje automático indicadas por la norma ISO/IEC 22989:2022, apartados 3.3 y 3.4, se encuadra entre los casos límite expresamente excluidos por las Directrices de la Comisión (sección 5.2). Para cada ejemplo se recoge la respuesta a los elementos 1–7 de la lista de comprobación y la consiguiente motivación del resultado con arreglo a la Regla de lectura.

Ejemplo 1 — Clasificador de imágenes histopatológicas con ajuste fino continuo

Descripción. Sistema empleado en un centro hospitalario: una red neuronal convolucional, ejecutada en una estación de trabajo con GPU, clasifica las imágenes de biopsias histológicas en categorías diagnósticas (p. ej., tejido normal, lesión benigna, lesión sospechosa) y proporciona al patólogo una probabilidad asociada a cada clase. Los pesos del modelo se someten periódicamente a un ajuste fino automático con los nuevos casos etiquetados.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El software lo ejecuta una máquina (estación de trabajo con GPU) sobre entradas digitales procedentes del escáner histológico.
• Elemento 2 (autonomía variable) — SÍ. Para cada imagen, el sistema produce la clasificación sin intervención del operador en el caso concreto.
• Elemento 3 (capacidad de adaptación tras el despliegue) — SÍ. Los parámetros del modelo se actualizan durante el funcionamiento mediante ajuste fino con los nuevos casos etiquetados.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivo explícito: minimizar el error de clasificación respecto al patrón de referencia elaborado por el patólogo.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. El resultado de salida se obtiene por inferencia mediante una red neuronal (ISO/IEC 22989, apdo. 3.4) entrenada de forma supervisada (3.3.13).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Genera una predicción (clase) y una recomendación implícita de prioridad en la emisión del informe.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. El resultado de salida alimenta la historia clínica del paciente e incide en el itinerario diagnóstico-terapéutico.

Resultado: sistema de IA. Concurren conjuntamente los elementos necesarios (1, 2, 4 y 5), así como los elementos 3, 6 y 7. Al tratarse de un uso en el ámbito sanitario, para la evaluación del riesgo (artículo 6, apartado 1, y anexo I del Reglamento de IA – productos sanitarios) se remite además al recuadro «Evalúa si tu sistema es inteligencia artificial de alto riesgo» de esta sección. A los desarrollos confinados al ámbito de la investigación puede aplicarse la exclusión del artículo 2, apartados 6 y 8, del Reglamento de IA (recuadro «¿Eres un organismo público de investigación o una universidad que desarrolla software para el GDU…»).

Ejemplo 2 — Predictor de la congestión viaria del Gemelo Digital Urbano

Descripción. Módulo del GDU que, a partir de los datos de sensores de espira y cámaras, predice la congestión de una zona urbana para las seis horas siguientes mediante un modelo secuencial (red recurrente o transformer) y envía el resultado al sistema de gestión semafórica. Los parámetros del modelo quedan congelados en el momento del lanzamiento y solo se actualizan fuera de línea mediante el lanzamiento de una nueva versión.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El módulo funciona en una infraestructura de servidores del GDU y consume flujos de datos de sensores y cámaras.
• Elemento 2 (autonomía variable) — SÍ. Produce las predicciones periódicas sin ninguna intervención humana puntual.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Los pesos del modelo quedan congelados en el lanzamiento; la actualización se produce únicamente con una nueva versión. El elemento no es obligatorio para la calificación.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivo explícito: minimizar el error de predicción sobre la serie histórica de entrenamiento.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. El resultado de salida deriva de un proceso inferencial de aprendizaje automático (ISO/IEC 22989, 3.3.5; red neuronal, apdo. 3.4).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultados de salida del tipo predicción y recomendación (prioridad de intervención en los semáforos).
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. El resultado de salida condiciona la gestión semafórica real de la zona y, por tanto, la movilidad urbana.

Resultado: sistema de IA. Concurren los elementos necesarios (1, 2, 4 y 5) y los elementos 6 y 7; la ausencia del elemento 3 (facultativo) no es óbice (Directrices de la Comisión, apartados 9 y 22–23; véase la Regla de lectura).

Ejemplo 3 — Flujo de trabajo para la evaluación automática de un expediente administrativo

Descripción. Software de la administración pública que evalúa la admisibilidad de un expediente (p. ej., la concesión de una ayuda) sobre la base de un árbol de decisión íntegramente codificado por el diseñador: cada condición, umbral y resultado se especifica de forma explícita en reglas if-then-else y en los parámetros de configuración. El sistema no utiliza modelos entrenados con datos.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El software lo ejecuta una infraestructura de aplicaciones de la administración pública.
• Elemento 2 (autonomía variable) — SÍ. Para cada expediente produce automáticamente el resultado, sin intervención humana en el caso concreto.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Las reglas y los umbrales están congelados y solo pueden modificarse con una nueva versión del software.
• Elemento 4 (objetivos explícitos o implícitos) — NO. El sistema aplica reglas explícitas, sin un objetivo interno propio en el sentido del Reglamento de IA.
• Elemento 5 (inferencia a partir de la información de entrada) — NO. Falta un proceso inferencial efectivo: las reglas las ha codificado íntegramente la persona física del diseñador (Directrices de la Comisión, apartado 40).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Produce una decisión (admisión o denegación).
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. La decisión incide directamente en la situación administrativa del ciudadano.

Resultado: software no calificable como IA. Faltan los elementos 4 y 5, necesarios junto con los elementos 1 y 2 para la calificación con arreglo al Reglamento de IA. El software se encuadra en la noción de algoritmo determinista (§ 5.1.7); siguen siendo aplicables los principios de la jurisprudencia administrativa (transparencia reforzada, cognoscibilidad, no exclusividad de la decisión: Consejo de Estado n.º 2270/2019 y n.º 8472/2019).

Ejemplo 4 — Modelo sustituto de red neuronal para simulaciones de dinámica de fluidos computacional

Descripción. Un grupo de investigación entrena una red neuronal feed-forward (ISO/IEC 22989, apdo. 3.4) para reproducir el resultado de salida de un solucionador tradicional de las ecuaciones de Navier–Stokes en un dominio aerodinámico, con el fin de reducir en dos órdenes de magnitud el tiempo de cálculo. Después, el modelo se utiliza como componente acelerado dentro de la misma cadena de simulación física.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El modelo se ejecuta en un clúster HPC.
• Elemento 2 (autonomía variable) — SÍ. Produce los valores predichos sin intervención en cada evaluación.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Los pesos quedan congelados tras el entrenamiento.
• Elemento 4 (objetivos explícitos o implícitos) — PARCIAL. El objetivo interno es minimizar una función de pérdida respecto al solucionador de referencia; sin embargo, la finalidad del sistema es exclusivamente la eficiencia computacional del cálculo físico.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ (formalmente). Se trata, a todos los efectos, de aprendizaje automático (ISO/IEC 22989, 3.3.5) llevado a cabo mediante una red neuronal (apdo. 3.4).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultado de salida numérico asimilable a una predicción.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ (indirecto). El resultado de salida lo consume el solucionador físico situado aguas abajo.

Resultado: software no calificable como IA (caso límite de ML). Aunque concurre formalmente el elemento 5 (inferencia mediante ML), el sistema se encuadra entre las exclusiones expresas de las Directrices de la Comisión (apartados 42–43): «los sistemas basados en la física [que] pueden utilizar técnicas de aprendizaje automático para mejorar el rendimiento computacional, acelerando las simulaciones tradicionales basadas en la física o estimando parámetros, que después se introducen en modelos físicos consolidados». El modelo «no trasciende el tratamiento básico de datos»: la exclusión debe documentarse en el expediente técnico.

Ejemplo 5 — Regresión lineal para la estimación de una asociación en un estudio epidemiológico

Descripción. En un estudio observacional se estima, mediante regresión lineal múltiple (machine learning algorithm, ISO/IEC 22989, 3.3.6), la asociación entre la exposición a un factor de riesgo y un indicador biomédico, controlando por factores de confusión. El resultado de salida es el vector de los coeficientes de regresión con sus intervalos de confianza, que se presenta al investigador.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El análisis se ejecuta en un entorno de software estadístico (R, Stata, Python).
• Elemento 2 (autonomía variable) — NO. El investigador dirige y supervisa el análisis en cada paso.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. No hay ningún mecanismo de actualización de los coeficientes tras la estimación.
• Elemento 4 (objetivos explícitos o implícitos) — NO. El objetivo es puramente estadístico-descriptivo (criterio de mínimos cuadrados), no un objetivo del sistema en el sentido del Reglamento de IA.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ (formalmente). La regresión lineal se clasifica como machine learning algorithm (ISO/IEC 22989, 3.3.6).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — NO. El resultado de salida no es una predicción, recomendación o decisión operativa, sino una estadística descriptiva.
• Elemento 7 (influencia en entornos físicos o virtuales) — NO. El resultado de salida está destinado al análisis del investigador, no a incidir en un entorno físico o virtual.

Resultado: software no calificable como IA (caso límite de ML). Aunque emplea una técnica formalmente de aprendizaje automático, el caso se encuadra en una doble exclusión de las Directrices: apartado 42 («los sistemas utilizados para mejorar la optimización matemática o para acelerar y aproximar métodos de optimización tradicionales y consolidados, como los métodos de regresión lineal o logística» no están incluidos en la definición) y apartado 47 (análisis descriptivo, comprobación de hipótesis y visualización). Falta además el elemento 4 (objetivos), necesario para la calificación.

Ejemplo 6 — Análisis de componentes principales (PCA) sobre datos genómicos para visualización exploratoria

Descripción. A un conjunto de perfiles de expresión génica se le aplica el análisis de componentes principales (unsupervised machine learning, ISO/IEC 22989, 3.3.18) para obtener una representación bidimensional de las muestras, útil para identificar visualmente clústeres de pacientes. El resultado de salida es un diagrama de dispersión que se entrega al investigador.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El procesamiento se ejecuta en un entorno de software bioinformático.
• Elemento 2 (autonomía variable) — NO. El investigador fija los parámetros (número de componentes, preprocesamiento) e interpreta la representación.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. No hay ninguna actualización de los parámetros de la transformación tras la ejecución.
• Elemento 4 (objetivos explícitos o implícitos) — NO. Ningún objetivo del sistema en el sentido del Reglamento de IA: el PCA minimiza una función objetivo estadística orientada a la varianza explicada, con fines exclusivamente exploratorios.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ (formalmente). El PCA se encuadra en el aprendizaje no supervisado (ISO/IEC 22989, 3.3.18).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — NO. El resultado de salida es una representación gráfica exploratoria, no una predicción, recomendación o decisión.
• Elemento 7 (influencia en entornos físicos o virtuales) — NO. Ninguna repercusión operativa directa en un entorno: la visualización sirve de apoyo a la interpretación.

Resultado: software no calificable como IA (caso límite de ML). Aunque emplea una técnica de aprendizaje automático no supervisado, el sistema se encuadra en la exclusión expresa de la sección 5.2 de las Directrices de la Comisión y, en particular, de su apartado 47: «los sistemas destinados exclusivamente al análisis descriptivo, la comprobación de hipótesis y la visualización no están incluidos en la definición de sistema de IA». Faltan además los elementos 4, 6 y 7 de la lista de comprobación.

Ejemplo 7 — Sistema experto simbólico para el apoyo al diagnóstico de daños estructurales

Descripción. Sistema empleado en la oficina técnica de una entidad local: una base de conocimiento codificada por ingenieros de estructuras (reglas, hechos, ontología de lesiones y cuadros de fisuración) es consultada por un motor de inferencia que, a partir de un levantamiento del edificio introducido por el operador, devuelve un abanico ordenado de hipótesis diagnósticas con la correspondiente cadena deductiva. Se trata de IA simbólica (ISO/IEC 22989, 3.1.33; expert system, 3.1.13), sin ningún componente de aprendizaje automático.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. El sistema experto se ejecuta en un servidor de aplicaciones de la entidad.
• Elemento 2 (autonomía variable) — SÍ. El resultado de salida lo deriva automáticamente el motor de inferencia, sin supervisión puntual del resultado.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. La base de conocimiento es estática y solo se actualiza mediante intervenciones manuales de los curadores del dominio.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivo interno: identificar el conjunto de hipótesis más coherentes con los hechos observados según las reglas de la base de conocimiento.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. El considerando 12 del Reglamento de IA y el apartado 30 de las Directrices incluyen expresamente entre las técnicas de inferencia las «estrategias basadas en la lógica y el conocimiento que infieren a partir de conocimientos codificados o de una representación simbólica».
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultado de salida del tipo recomendación (hipótesis diagnósticas ordenadas por plausibilidad).
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. El resultado de salida orienta las inspecciones posteriores y las intervenciones de consolidación.

Resultado: sistema de IA. Concurren los elementos necesarios (1, 2, 4 y 5) y los elementos 6 y 7 (solo falta la capacidad de adaptación, que es facultativa). El caso pone de manifiesto que la calificación como IA no requiere el uso de aprendizaje automático: también la IA simbólica entra en el ámbito del Reglamento de IA, en coherencia con el considerando 12 del Reglamento de IA y con la definición de inferencia de la ISO/IEC 22989 (3.1.17).

Ejemplo 8 — Asistente conversacional para el ciudadano basado en un modelo de lenguaje de gran tamaño

Descripción. Servicio del ayuntamiento que pone a disposición del ciudadano, a través de una interfaz web, un modelo de lenguaje de gran tamaño (transformer, ISO/IEC 22989, apdo. 3.4; sub-symbolic AI, 3.1.34) con una arquitectura de generación aumentada por recuperación sobre acuerdos, reglamentos y formularios municipales. El sistema produce respuestas en lenguaje natural e indica las referencias a los actos pertinentes.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Servicio en la nube que ejecuta el modelo en GPU dedicadas.
• Elemento 2 (autonomía variable) — SÍ. Para cada solicitud produce la respuesta de forma autónoma.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. El modelo de base está congelado; las actualizaciones (p. ej., un ajuste fino periódico) se realizan fuera de línea con nuevas versiones.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivo del sistema: maximizar la adecuación de la respuesta a las fuentes normativas recuperadas, minimizando las invenciones.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. El modelo es una red neuronal profunda entrenada de forma autosupervisada con grandes corpus de texto.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultados de salida del tipo contenido (texto generado) y recomendación (sugerencia de procedimientos u oficinas).
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. El resultado de salida orienta las decisiones del ciudadano en relación con los servicios de la administración pública.

Resultado: sistema de IA. Concurren los elementos necesarios (1, 2, 4 y 5) y los elementos 6 y 7. Al tratarse de un sistema que interactúa directamente con personas físicas y que genera contenido sintético, se aplican las obligaciones de transparencia del artículo 50 del Reglamento de IA (información al usuario de que está interactuando con un sistema de IA; marcado de los contenidos generados). Para la evaluación del riesgo se remite al recuadro «Evalúa si tu sistema es inteligencia artificial de alto riesgo».

Ejemplo 9 — Calculadora automática del Indicador de la Situación Económica Equivalente (ISEE)

Descripción. Módulo de la plataforma del INPS que, sobre la base de los datos de identificación y patrimoniales declarados por el ciudadano y de los datos fiscales obtenidos de la Agenzia delle Entrate, calcula el indicador ISEE aplicando las fórmulas y las escalas de equivalencia establecidas por el DPCM 159/2013 y sus modificaciones posteriores. El resultado se devuelve al ciudadano y lo utilizan otras ventanillas digitales para evaluar la admisibilidad a medidas de ayuda.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Ejecución en una infraestructura de aplicaciones del INPS.
• Elemento 2 (autonomía variable) — SÍ. Cálculo producido automáticamente, sin supervisión puntual de cada expediente.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Las fórmulas las fija la normativa y solo se actualizan con nuevos actos normativos o nuevas versiones del software.
• Elemento 4 (objetivos explícitos o implícitos) — NO. El sistema aplica íntegramente reglas normativas, sin ningún objetivo interno propio.
• Elemento 5 (inferencia a partir de la información de entrada) — NO. Ningún proceso inferencial: el resultado de salida es el resultado determinista de las fórmulas normativas.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultado de salida del tipo decisión (valor del ISEE que condiciona los umbrales de acceso).
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. El resultado incide en el acceso del ciudadano a prestaciones sociales y a beneficios fiscales.

Resultado: software no calificable como IA. Faltan los elementos 4 y 5: se trata de la aplicación automática de reglas normativas íntegramente codificadas y, por tanto, de un algoritmo determinista (§ 5.1.7). Siguen siendo plenamente aplicables los principios de la jurisprudencia administrativa (Consejo de Estado n.º 2270/2019 y n.º 8472/2019) en materia de transparencia reforzada, cognoscibilidad de la regla técnica (que aquí coincide con la regla jurídica), motivación y no exclusividad de la decisión.

Ejemplo 10 — Predictor meteorológico básico como referencia de comparación (media semanal)

Descripción. En el marco de una evaluación comparativa de sistemas de predicción meteorológica, se utiliza un predictor elemental que estima la temperatura del día siguiente como la media de la semana anterior. El procedimiento puede clasificarse técnicamente como machine learning algorithm (ISO/IEC 22989, 3.3.6) con una hipótesis estadística trivial, y se emplea exclusivamente como término de comparación.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Ejecución en un entorno de cálculo científico.
• Elemento 2 (autonomía variable) — SÍ. Produce la predicción sin intervención puntual.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Ninguna actualización de los parámetros fuera de la estimación estática.
• Elemento 4 (objetivos explícitos o implícitos) — PARCIAL. Objetivo estadístico reducido: replicar la hipótesis de la media; falta un objetivo del sistema en el sentido pleno del Reglamento de IA.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ (formalmente). Inferencia mínima a partir de una regla básica de aprendizaje estadístico.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ (formalmente). Resultado de salida del tipo predicción.
• Elemento 7 (influencia en entornos físicos o virtuales) — NO. El resultado de salida está destinado a servir de término de comparación en una evaluación técnica, no a incidir en un entorno.

Resultado: software no calificable como IA (caso límite de ML). El caso está expresamente excluido por las Directrices, apartados 49–50: «todos los sistemas automatizados cuyo rendimiento pueda alcanzarse mediante una regla básica de aprendizaje estadístico, aunque técnicamente puedan clasificarse como basados en estrategias de aprendizaje automático, quedan fuera del ámbito de aplicación de la definición de sistema de IA debido a su rendimiento», con la referencia específica a la predicción de la temperatura mediante la media semanal.

Ejemplo 11 — Red neuronal feed-forward para la aproximación de funciones especiales en una biblioteca científica

Descripción. Dentro de una biblioteca de cálculo científico, una red neuronal feed-forward (ISO/IEC 22989, apdo. 3.4) se entrena de forma supervisada (3.3.13) para reproducir con buena precisión una función analítica conocida —por ejemplo, una función de Bessel, una integral elíptica o un núcleo de integración gaussiana— con el fin de invocarla en lugar de la implementación clásica para reducir el coste computacional. El resultado de salida de la red lo consumen otros módulos numéricos como valor de la función.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. La red se ejecuta dentro de un entorno de cálculo numérico (estación de trabajo, clúster).
• Elemento 2 (autonomía variable) — SÍ. Devuelve automáticamente el valor aproximado en cada llamada, sin supervisión puntual.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Los pesos quedan congelados al terminar el entrenamiento.
• Elemento 4 (objetivos explícitos o implícitos) — PARCIAL. El objetivo interno es puramente estadístico (minimizar el error de aproximación respecto a la función analítica de referencia); la finalidad de uso es exclusivamente la eficiencia del cálculo.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ (formalmente). Se trata de una red neuronal (ISO/IEC 22989, apdo. 3.4) entrenada con datos: técnicamente, aprendizaje automático en el sentido de la ISO/IEC 22989, 3.3.5.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ (formalmente). Devuelve un valor numérico, formalmente asimilable a una predicción, pero que corresponde al valor de una función analítica conocida.
• Elemento 7 (influencia en entornos físicos o virtuales) — NO. No orienta decisiones ni incide en un entorno: el valor devuelto es funcionalmente intercambiable con la implementación clásica de la misma función, de la que constituye un mero acelerador.

Resultado: software no calificable como IA (caso límite de ML). Aunque concurre formalmente el elemento 5, faltan el elemento 7 y, en términos sustanciales, el elemento 4: el uso de la red es exclusivamente instrumental a la velocidad del cálculo, sin un proceso decisorio o predictivo propio. El caso se encuadra entre las exclusiones del apartado 42 de las Directrices de la Comisión («los sistemas utilizados para mejorar la optimización matemática o para acelerar y aproximar métodos de optimización tradicionales y consolidados»), en la medida en que el modelo «no trasciende el tratamiento básico de datos»: la exclusión debe documentarse en el expediente técnico.

Ejemplo 12 — Red neuronal profunda para la identificación de partículas en experimentos de física de altas energías

Descripción. En el marco de un experimento en el CERN, una red neuronal profunda (deep learning, ISO/IEC 22989, apdo. 3.4; supervised machine learning, 3.3.13) se entrena para clasificar los sucesos registrados por los detectores (p. ej., discriminación señal-fondo) a efectos del análisis científico. El modelo se emplea con los datos del experimento y los resultados se destinan a las publicaciones de la colaboración científica.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Ejecución en la Worldwide LHC Computing Grid (clústeres distribuidos, GPU).
• Elemento 2 (autonomía variable) — SÍ. Clasifica de forma autónoma miles de millones de sucesos sin supervisión puntual de cada dato.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. Modelo congelado al inicio de la campaña de análisis.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivo explícito: maximizar la precisión de la clasificación señal/fondo.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. Inferencia plenamente en el sentido del Reglamento de IA mediante una red neuronal profunda.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultados de salida del tipo predicción (clase del suceso) y datos derivados para el análisis estadístico.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. El resultado de salida alimenta el análisis estadístico y, por tanto, las publicaciones de la colaboración científica.

Resultado: sistema de IA, pero exento del Reglamento de IA por tratarse de una actividad de investigación científica. Concurren los elementos necesarios (1, 2, 4 y 5) y los elementos 6 y 7: la calificación formal como sistema de IA es, por tanto, positiva. Sin embargo, el artículo 2, apartado 6, del Reglamento de IA excluye del ámbito de aplicación del Reglamento «los sistemas o modelos de IA, incluidos sus resultados de salida, desarrollados y puestos en servicio específicamente con la investigación y el desarrollo científicos como única finalidad», como se ilustra en el recuadro «¿Eres un organismo público de investigación o una universidad que desarrolla software para el GDU…» de esta sección. Siguen siendo aplicables, en todo caso, los principios éticos y los derechos fundamentales de los participantes en la investigación.

5.1.9 Ejemplos específicos para los Gemelos Digitales Urbanos

Un Gemelo Digital Urbano es típicamente un «sistema de sistemas»: integra módulos heterogéneos (sensores, modelado 3D, simulación, análisis de datos, modelos predictivos, apoyo a las decisiones). Por ello no se califica «en bloque»: la lista de comprobación del § 5.1.4 debe aplicarse componente por componente, porque algunos módulos son sistemas de IA y otros no. Los ejemplos que siguen —extraídos de casos reales documentados en el informe «Italia città intelligenti» y en el documento «COMTem — Casi d'uso di Digital Twin»— ilustran este abanico en el contexto del apoyo a la administración pública municipal. Dado que dichas fuentes son divulgativas, los ejemplos deben leerse como casos tipo: la calificación definitiva depende del «cómo» se haya realizado efectivamente cada módulo.

Ejemplo GDU-1 — Núcleo decisorio del GDU (modelos predictivos, sistema experto, optimización)

Descripción. En el modelo de GDU como «sistema de sistemas» (Urban Intelligence, CNR-DIITET; casos de Matera y Catania), el núcleo de apoyo a las decisiones integra modelos de aprendizaje automático para la predicción (p. ej., demanda de movilidad, calidad del aire), un sistema experto que razona con reglas «if-then» (Urban Sensing Engine) y algoritmos de optimización multiobjetivo, y produce para la administración pública escenarios y recomendaciones operativas y estratégicas; el sistema aprende de forma continua de los datos de la ciudad.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software ejecutado en una infraestructura de cálculo y un data lake.
• Elemento 2 (autonomía variable) — SÍ. Genera de forma autónoma escenarios y recomendaciones que la administración evalúa.
• Elemento 3 (capacidad de adaptación tras el despliegue) — SÍ. El «bucle continuo de aprendizaje y optimización» adapta los modelos a los nuevos datos tras el lanzamiento.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivos explícitos de gobernanza (reducir la congestión, las emisiones y los consumos).
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. Inferencia tanto subsimbólica (ML) como simbólica: el motor «if-then» deriva conclusiones no especificadas puntualmente (considerando 12 del Reglamento de IA; Directrices, apartado 30).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Predicciones, escenarios y recomendaciones para la toma de decisiones.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. Incide en el entorno urbano orientando las decisiones de gobernanza.

Resultado: sistema de IA. Concurren los elementos necesarios (1, 2, 4 y 5) y todos los demás. Obsérvese que también el sistema experto basado en reglas es IA, porque cuenta con un motor de inferencia (a diferencia del algoritmo determinista, § 5.1.7). Sin embargo, este es solo el núcleo inferencial del GDU: los módulos de mera simulación (GDU-2), de representación 3D (GDU-3) o de cuadro de mando (GDU-6) deben calificarse por separado.

Ejemplo GDU-2 — Módulo de simulación físico-numérica (escenarios «what-if»)

Descripción. Módulo del gemelo digital que simula escenarios «what-if» resolviendo modelos físicos conocidos —propagación del ruido del tráfico (caso Pilsen/DUET), flujos energéticos de una comunidad energética (caso +PADOVAxCHANGE), impactos climáticos (caso Amiens)— para evaluar el efecto de una intervención antes de realizarla.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software de cálculo.
• Elemento 2 (autonomía variable) — NO. Ejecuta el cálculo según los parámetros fijados por el operador, sin autonomía operativa.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. No aprende tras el lanzamiento: con la misma entrada devuelve el mismo resultado (repetibilidad).
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Tiene el objetivo de estimar el impacto de un escenario.
• Elemento 5 (inferencia a partir de la información de entrada) — NO. No infiere: aplica leyes físicas y reglas definidas por el ser humano. Las Directrices (apartados 42-43) excluyen los sistemas basados en modelos físicos consolidados, incluso cuando se aceleran o aproximan con ML.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Produce predicciones y escenarios.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. Los escenarios influyen en las decisiones de planificación.

Resultado: no es un sistema de IA (simulación). Falta el elemento 5 (inferencia): aunque es «predictivo», el módulo calcula con reglas físicas fijadas, es repetible y no aprende. Es un algoritmo determinista (§ 5.1.7). Se contrapone a GDU-5, donde, en cambio, la predicción se aprende de los datos.

Ejemplo GDU-3 — Modelo digital 3D del territorio o de un bien cultural

Descripción. Réplica digital tridimensional de alta precisión del territorio o de un bien cultural, navegable y consultable (p. ej., el gemelo del Oratorio de San Giorgio en Padua; el modelo geométrico-topográfico de Rennes), utilizada para la consulta, la valorización y como base para la planificación.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software de representación geoespacial.
• Elemento 2 (autonomía variable) — NO. Devuelve lo que se ha levantado y modelado, a petición del usuario.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. No aprende ni se adapta.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ (formalmente). Tiene la finalidad de representar fielmente el objeto.
• Elemento 5 (inferencia a partir de la información de entrada) — NO. No infiere: muestra datos geométricos medidos y almacenados.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — PARCIAL. Produce visualizaciones, no predicciones, recomendaciones ni decisiones.
• Elemento 7 (influencia en entornos físicos o virtuales) — NO. Es una herramienta de consulta.

Resultado: no es un sistema de IA (representación). Es un «Digital Model» sin inferencia ni capacidad de adaptación: un sistema de información geoespacial, no un sistema de IA. Faltan los elementos necesarios 2 y 5, así como los elementos 3 y 7.

Ejemplo GDU-4 — Videovigilancia urbana con visión artificial

Descripción. Sistema que analiza en tiempo real los flujos de vídeo de la red de cámaras de la ciudad con modelos de aprendizaje profundo para detectar eventos (accidentes, aglomeraciones, objetos abandonados), clasificar y seguir vehículos y leer las matrículas (OCR), y que alerta a los operadores de la seguridad urbana (véase la sala de control de Venecia).

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software en una infraestructura de videoanálisis.
• Elemento 2 (autonomía variable) — SÍ. Señala los eventos relevantes sin una supervisión humana constante y puede desencadenar acciones.
• Elemento 3 (capacidad de adaptación tras el despliegue) — PARCIAL. Los modelos pueden volver a entrenarse, no necesariamente de forma continua.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivos de seguridad y control del territorio.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. Inferencia mediante aprendizaje profundo (clasificación, detección, reconocimiento).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Alertas, identificaciones, decisiones operativas.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. Incide en la seguridad y en el espacio físico urbano.

Resultado: sistema de IA. Concurren los elementos necesarios (1, 2, 4 y 5) y todos los demás. Es típicamente de alto riesgo (anexo III del Reglamento de IA) y, en caso de que tenga funciones de identificación biométrica, está sujeto a las prohibiciones y límites del artículo 5 y a la normativa sobre datos personales (EIPD): se remite al recuadro «Evalúa si tu sistema es inteligencia artificial de alto riesgo» y a la sección 4 sobre datos personales.

Ejemplo GDU-5 — Mantenimiento predictivo de las infraestructuras (aprendizaje automático)

Descripción. Modelo de aprendizaje automático que, a partir de los datos históricos y en tiempo real de los sensores instalados en puentes, edificios o redes (de agua, eléctrica), aprende los patrones de deterioro y predice las averías para programar intervenciones preventivas (casos de Espoo, Chorus Life Bergamo, GDU de Matera).

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software en una infraestructura de análisis de datos.
• Elemento 2 (autonomía variable) — SÍ. Produce alertas y prioridades de intervención sin intervención puntual.
• Elemento 3 (capacidad de adaptación tras el despliegue) — SÍ. Puede volver a entrenarse y actualizarse con los nuevos datos.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivo de prevenir averías y optimizar el mantenimiento.
• Elemento 5 (inferencia a partir de la información de entrada) — SÍ. Inferencia aprendida de los datos (ML): deriva predicciones no especificadas puntualmente.
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Predicciones de averías y recomendaciones de intervención.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. Incide en el mantenimiento de las infraestructuras.

Resultado: sistema de IA. Concurren los elementos necesarios (1, 2, 4 y 5) y todos los demás. A diferencia de GDU-2, el resultado de salida se infiere de patrones aprendidos de los datos y no se calcula a partir de leyes físicas fijadas: la diferencia está en el «cómo» (considerando 12; § 5.1.7). Si, en cambio, la «predicción» se redujera a una regla estadística elemental (p. ej., la media histórica), se encuadraría entre los casos excluidos (§ 5.1.5; Directrices, apartados 49-51).

Ejemplo GDU-6 — Plataforma de integración de datos / sala de control urbana

Descripción. Cuadro de mando que recoge, integra y visualiza en tiempo real los datos de la ciudad (afluencia de personas, tráfico, aparcamientos, meteorología, transporte público) sobre una base geolocalizada, con un posible telecontrol de las instalaciones basado en reglas (p. ej., Roma Data Platform; sala de control de Florencia; Nottingham), en apoyo de las decisiones de los operadores.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software de integración y visualización de datos.
• Elemento 2 (autonomía variable) — NO. Ejecuta la recogida, la visualización y órdenes predefinidas.
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. No aprende ni se adapta.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ (formalmente). Tiene la finalidad de representar el estado de la ciudad.
• Elemento 5 (inferencia a partir de la información de entrada) — NO. No infiere: agrega y presenta datos (análisis descriptivo y visualización; Directrices, apartado 47).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — PARCIAL. Resultados de salida informativos (cuadro de mando), no recomendaciones inferidas.
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ (indirecto). Apoya las decisiones de los operadores humanos.

Resultado: no es un sistema de IA (sistema de información). Falta el elemento 5: es un sistema de información/de supervisión asimilable al análisis descriptivo y a la visualización excluidos por las Directrices (§ 5.1.5, apartado 47). Solo se convierte en IA si se le incorporan módulos inferenciales (p. ej., predicción, GDU-5).

Ejemplo GDU-7 — Servicios IoT urbanos basados en reglas (aparcamientos, alumbrado adaptativo)

Descripción. Servicios del GDU basados en sensores y reglas: aparcamiento inteligente que indica las plazas libres y calcula el recorrido y la tarifa; alumbrado público adaptativo (TAI/FAI) que regula la intensidad en función del movimiento, el tráfico y la luminosidad; recogida de residuos con optimización de las rutas.

Cumplimentación de la lista de comprobación:

• Elemento 1 (sistema automatizado) — SÍ. Software sobre sensores IoT.
• Elemento 2 (autonomía variable) — PARCIAL. Regulación automática dentro de condiciones especificadas: es automatización, no autonomía (ISO/IEC 22989, 3.1.7).
• Elemento 3 (capacidad de adaptación tras el despliegue) — NO. La «adaptatividad» es una reacción a umbrales, no aprendizaje tras el lanzamiento.
• Elemento 4 (objetivos explícitos o implícitos) — SÍ. Objetivos de eficiencia del servicio.
• Elemento 5 (inferencia a partir de la información de entrada) — NO. Aplica reglas fijas a entradas procedentes de sensores; la eventual optimización de las rutas es optimización matemática excluida (Directrices, apartados 42-45).
• Elemento 6 (resultados de salida: predicciones, contenidos, recomendaciones, decisiones) — SÍ. Resultados de salida operativos (indicaciones, regulaciones).
• Elemento 7 (influencia en entornos físicos o virtuales) — SÍ. Incide en el entorno físico (estacionamiento, alumbrado, recogida).

Resultado: no es un sistema de IA (automatización basada en reglas). Falta el elemento 5: aplica reglas fijas y, como mucho, optimización matemática excluida. Caso útil para distinguir la adaptatividad técnica (por umbrales) de la capacidad de adaptación del Reglamento de IA (aprendizaje) y la optimización matemática de la inferencia (§ 5.1.5).

5.2 Cuestionario de definición de sistema de IA

La definición de sistema de IA adopta una perspectiva basada en el ciclo de vida que abarca dos fases principales: la fase previa al despliegue o de «construcción» del sistema y la fase posterior al despliegue o de «uso» del sistema⁴⁸.

No es necesario que los siete elementos indicados en la definición estén presentes de forma continuada en ambas fases de dicho ciclo de vida. La definición reconoce, en cambio, la posibilidad de que algunos elementos específicos aparezcan en una fase, pero no persistan en ambas fases».⁴⁹

Aunque no es posible determinar automáticamente qué sistemas entran o no en la definición de sistema de IA ni elaborar listas exhaustivas, se invita a recurrir a una evaluación meramente preliminar que pueda ayudar a calificar el sistema que se entrega a la administración pública.

ANOTACIÓN

La evaluación no es mecánica

Debe hacerse caso por caso

La capacidad inferencial es fundamental para lograr la autonomía50.

INICIA LA HERRAMIENTA

Cuestionario de definición de sistema de IA

⚠️ Atención: la calificación como sistema de IA no implica automáticamente la aplicación de obligaciones normativas específicas. Las obligaciones dependen de la clasificación del riesgo (alto riesgo, riesgo limitado, etc.) con arreglo a los artículos 5, 6 y 50 del Reglamento. Queda a salvo, para los proveedores y los responsables del despliegue de cualquier sistema de IA, la obligación de alfabetización en materia de IA (artículo 4, en la redacción dada por el Reglamento (UE) 2026/1744).

5.3 Cuestionario de definición de modelo de IA

Aunque no es posible determinar automáticamente qué sistemas entran o no en la definición de modelo de IA de uso general (artículo 3, punto 63) ni elaborar listas exhaustivas, se invita a recurrir a una evaluación meramente preliminar que pueda ayudar a calificar el modelo que se entrega a la administración pública.

ANOTACIÓN

La evaluación no es mecánica

Debe hacerse caso por caso

Evalúa si un sistema entra en la definición de modelo de IA de uso general y si presenta riesgo sistémico, según la Comunicación de la Comisión Europea C(2025) 5045 final, Bruselas, 18 de julio de 2025, que contiene las Directrices sobre el ámbito de aplicación de las obligaciones para los modelos de IA de uso general establecidas en el Reglamento (UE) 2024/1689 (Reglamento de Inteligencia Artificial).

INICIA LA HERRAMIENTA

Test de clasificación de modelos GPAI

FOCUS BOX

¿Eres una empresa que desarrolla el GDU?

Las empresas que desarrollan GDU para la administración pública (véanse el § 5.1.3 y la sección 9 del Vademécum) están obligadas a respetar lo establecido por el Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo (el denominado AI Act) y las obligaciones que de él se derivan.

Las fechas de aplicación del Reglamento, modificado por el Reglamento (UE) 2026/1744 («Ómnibus Digital sobre la IA», DO L de 24 de julio de 2026, en vigor desde el 27 de julio de 2026), se resumen en el cuadro siguiente, al que remiten las demás secciones del Vademécum (artículos 111 y 113 del Reglamento de IA, modificados por el Reglamento (UE) 2026/1744, artículo 1, puntos 39 y 40): 2 de febrero de 2025: capítulos I y II (disposiciones generales, incluida la obligación de alfabetización en materia de IA del artículo 4, reformulada por el Reglamento (UE) 2026/1744 con efecto desde el 27 de julio de 2026; prácticas prohibidas del artículo 5 en su versión original); 2 de agosto de 2025: obligaciones de los proveedores de modelos de IA de uso general (capítulo V); los modelos ya introducidos en el mercado antes de esa fecha deben adaptarse a ellas a más tardar el 2 de agosto de 2027 (artículo 111, apartado 3); 2 de agosto de 2026: aplicación general del Reglamento, incluidas las obligaciones de transparencia del artículo 50 y las sanciones del artículo 101 para los proveedores de modelos de uso general; 2 de diciembre de 2026: nuevas prohibiciones del artículo 5 introducidas por el Reglamento (UE) 2026/1744 (apartado 1, letras b bis) y b ter): contenidos íntimos no consentidos y material de abuso sexual de menores generados con IA); 2 de diciembre de 2027: capítulo III, secciones 1–3 (clasificación, requisitos y obligaciones para el alto riesgo, incluidos los artículos 26 y 27 y la FRIA), para los sistemas del anexo III; 2 de agosto de 2028: capítulo III, secciones 1–3, para los sistemas del anexo I; 2 de agosto de 2030: plazo de adaptación para los sistemas de alto riesgo destinados a ser utilizados por autoridades públicas e introducidos en el mercado o puestos en servicio antes de la fecha de aplicación del capítulo III (artículo 111, apartado 2). Fuentes: Reglamento (UE) 2024/1689, texto consolidado en EUR-Lex (incluye las modificaciones del Reglamento (UE) 2026/1744); AI Act Service Desk de la Comisión Europea. https://artificialintelligenceact.eu/implementation-timeline/ Con arreglo al artículo 2, apartado 1, del Reglamento 2024/1689, el Reglamento se aplica a:

a)los proveedores que introduzcan en el mercado o pongan en servicio sistemas de IA o que introduzcan en el mercado modelos de IA de uso general en la Unión, con independencia de si dichos proveedores están establecidos o ubicados en la Unión o en un tercer país; b)los responsables del despliegue de sistemas de IA que estén establecidos o ubicados en la Unión; c)los proveedores y responsables del despliegue de sistemas de IA que estén establecidos o ubicados en un tercer país, cuando los resultados de salida generados por el sistema de IA se utilicen en la Unión; d)los importadores y distribuidores de sistemas de IA; e) los fabricantes de productos que introduzcan en el mercado o pongan en servicio un sistema de IA junto con su producto y con su propio nombre o marca; f)los representantes autorizados de los proveedores que no estén establecidos en la Unión; g)las personas afectadas que estén ubicadas en la Unión. Con arreglo al considerando 13 del Reglamento de IA, el concepto de «responsable del despliegue» debe interpretarse como cualquier persona física o jurídica, incluida cualquier autoridad pública, agencia u otro organismo, que utilice un sistema de IA bajo su propia autoridad, salvo cuando el sistema de IA se utilice en el transcurso de una actividad personal de carácter no profesional.

Comprueba a qué obligaciones está sujeto tu sistema de IA con arreglo al Reglamento de IA

Puedes utilizar esta herramienta interactiva para determinar si tu sistema de IA estará sujeto o no a estas obligaciones siguiendo el test desarrollado por el equipo del Future of Life Institute. https://artificialintelligenceact.eu/

Sigue: https://artificialintelligenceact.eu/it/assessment/controllo-della-conformita-dell-ue-alla-legge-ai/ https://artificialintelligenceact.eu/wp-content/uploads/2025/07/AI-Act-Compliance-Checker-Flowchart-v1.0_compressed.pdf O bien utiliza la herramienta siguiente, que resume el anterior control de conformidad con la ley de IA: Utiliza el Compliance Checker AI Act, una herramienta que adapta el sistema antes citado para determinar las obligaciones aplicables

ATENCIÓN:

¿Eres un organismo público de investigación o una universidad que desarrolla software para el GDU, calificable como inteligencia artificial (IA)?

Esta parte del documento está dedicada a los organismos de investigación y a las universidades que apoyan el desarrollo de un GDU, para que se proporcione a la administración pública toda la información necesaria y esta pueda utilizarla en apoyo de su propia actividad.

Como se ha recordado anteriormente, el ámbito subjetivo de aplicación del Reglamento comprende, entre otros, a los proveedores y a los responsables del despliegue de los sistemas de IA, incluidas también las administraciones públicas, cuando utilicen dichos sistemas en el ejercicio de sus funciones institucionales.

El Reglamento (UE) 2024/1689 (Reglamento de IA) se aplica a los desarrolladores y a quienes implementan los sistemas durante todo el ciclo de vida de la IA, pero prevé excepciones distintas para la exploración académica y científica

En el contexto de las colaboraciones entre organismos de investigación y administraciones públicas surge una cuestión central: ¿cuándo un sistema algorítmico, desarrollado originalmente con fines científicos, entra en el ámbito de aplicación del Reglamento de IA y pasa a estar sujeto a las obligaciones previstas en él?

Desde el punto de vista objetivo, el Reglamento «no se aplicará a los sistemas o modelos de IA, incluidos sus resultados de salida, desarrollados y puestos en servicio específicamente con la investigación y el desarrollo científicos como única finalidad» (artículo 2, apartado 6)

En concreto, el Reglamento «no se aplicará a ninguna actividad de investigación, prueba o desarrollo relativa a sistemas de IA o modelos de IA antes de su introducción en el mercado o puesta en servicio. Dichas actividades se llevarán a cabo de conformidad con el Derecho de la Unión aplicable. Las pruebas en condiciones reales no estarán cubiertas por esa exclusión (artículo 2, apartado 8)».

Por «introducción en el mercado» se entiende: la primera comercialización en el mercado de la Unión de un sistema de IA o de un modelo de IA de uso general (artículo 3, punto 9)

Por «puesta en servicio» se entiende: el suministro de un sistema de IA para su primer uso directamente al responsable del despliegue o para uso propio en la Unión para su finalidad prevista (artículo 3, punto 11)

Por «prueba en condiciones reales» se entiende: la prueba temporal de un sistema de IA para su finalidad prevista en condiciones reales, fuera de un laboratorio u otro entorno de simulación, con el fin de recabar datos fiables y sólidos y de evaluar y comprobar la conformidad del sistema de IA con los requisitos del presente Reglamento, y que no se considerará una introducción en el mercado o una puesta en servicio del sistema de IA en el sentido del presente Reglamento, siempre que se cumplan todas las condiciones establecidas en el artículo 57 o en el artículo 60 (artículo 3, punto 57).

Por tanto, el Reglamento (UE) 2024/1689 (Reglamento de IA) establece dos exclusiones principales centradas en la investigación. Esto incluye la investigación realizada no solo por organizaciones sin ánimo de lucro, sino también por empresas privadas:

• Exención para la investigación científica (artículo 2, apartado 6): Excluye los sistemas de IA (incluidos sus resultados de salida) desarrollados y puestos en servicio específicamente con la investigación y el desarrollo científicos como única finalidad.
• Exención para el desarrollo previo a la comercialización (artículo 2, apartado 8): Exime a cualquier sistema o modelo de IA sometido a investigación, prueba o desarrollo antes de su introducción en el mercado o puesta en servicio⁵¹.

Las dos exclusiones tienen presupuestos distintos:

• en el caso del artículo 2, apartado 6, el sistema o el modelo debe haberse desarrollado y puesto en servicio específicamente con la investigación y el desarrollo científicos como única finalidad;
• en el caso del artículo 2, apartado 8, debe tratarse de actividades de investigación, prueba o desarrollo realizadas antes de la introducción en el mercado o de la puesta en servicio, excluidas las pruebas en condiciones reales;
• la exclusión cubre también la investigación y el desarrollo orientados a productos (considerando 25), pero no el uso, con fines de investigación, de un sistema ya introducido en el mercado o puesto en servicio.

No obstante, el alcance de la exclusión es limitado. Se pierde la exención y habrá que cumplir las normas ordinarias del Reglamento de IA si:

• Comercialización: el modelo o el sistema se vende, se cede bajo licencia o se introduce en el mercado interior.
• Implantación en el mundo real: La IA se pone en servicio en condiciones reales con usuarios finales efectivos (por ejemplo, implantando una herramienta experimental de diagnóstico médico en un hospital en lugar de en un laboratorio).
• Publicación en código abierto: Aunque el Reglamento de IA prevé condiciones favorables para la IA de uso general publicada con licencias libres y de código abierto, la mera publicación de un modelo o de un código puede conllevar obligaciones si se considera «comercialización» (artículo 3, punto 10, del Reglamento de IA). La exclusión para los sistemas publicados con licencia libre y de código abierto está prevista en el artículo 2, apartado 12, y no se aplica a los sistemas de alto riesgo ni a los de los artículos 5 y 50.

En el caso de que un organismo de investigación desarrolle un algoritmo y lo transfiera a una administración pública, se dan dos configuraciones jurídicas posibles.

Uso en el ámbito de la investigación

Si el sistema es utilizado por la administración pública:

• exclusivamente en el marco de un proyecto de investigación;
• sin incidencia en procedimientos administrativos;
• sin efectos directos en las situaciones jurídicas de los ciudadanos,
• puede seguir quedando comprendido en la exclusión para la investigación científica.

Uso operativo en la actividad administrativa

Por el contrario, si el sistema:

• se emplea para apoyar o automatizar decisiones administrativas;
• incide en derechos, intereses o expectativas legítimas de los ciudadanos;
• se integra de forma estable en los procesos organizativos de la administración pública,
• se produce una puesta en servicio efectiva, con la consiguiente aplicación del Reglamento de IA.

En tal caso, el sistema sale de la esfera de la investigación y entra en el circuito regulado, lo que determina:

• la calificación del organismo de investigación como proveedor;
• la calificación de la administración pública como responsable del despliegue.

Requisitos que deben respetarse en todo caso: incluso cuando se opera estrictamente en el ámbito de la exención para la investigación, las actividades deben llevarse a cabo de conformidad con el Derecho de la Unión aplicable (artículo 2, apartado 8) y con las normas éticas y profesionales reconocidas (considerando 25); en particular, conviene que los investigadores y los centros de investigación:

• Garanticen que el desarrollo y el uso del sistema de IA respeten los derechos fundamentales y los valores de la Unión.
• Garanticen que cualquier prueba fuera de condiciones puramente de laboratorio conlleve una gobernanza responsable

ANOTACIÓN

La dimensión ética de la IA no es una característica añadida o exótica: debe formar parte integrante del desarrollo de la IA, se aplique o no la exención

Incluso en caso de excepción, es esencial respetar los derechos fundamentales de los participantes en la investigación antes de que dichos sistemas o modelos se introduzcan en el mercado o se pongan en servicio. Esto significa que, según las fuentes jurídicas europeas antes citadas, para evitar los riesgos de la IA y aumentar sus beneficios, la IA debe ser lícita, es decir, debe respetar las leyes y los reglamentos aplicables, y debe ser también «ética», en el sentido de que no debe comprometer los intereses y los valores protegidos por el ordenamiento jurídico y, por tanto, debe respetar un «marco ético», tal como lo define el documento Directrices éticas para una IA fiable de 2019 (High-Level Expert Group on AI – HLEGAI) Ethics Guidelines for Trustworthy AI (DG CONNECT).

La Assessment List for Trustworthy AI (ALTAI) es la lista de autoevaluación publicada en julio de 2020 por el grupo de expertos de alto nivel sobre IA (AI HLEG) creado por la Comisión Europea para verificar la adecuación a los 7 requisitos de la IA fiable definidos en las Directrices éticas de 2019. La herramienta del Vademécum propone una selección adaptada: 28 preguntas reformuladas, frente a las 126 del original, distribuidas en 7 secciones. Responde y obtén una visión de conjunto del grado de cumplimiento autoevaluado de los siete requisitos; la puntuación y los umbrales son propios de esta herramienta: la ALTAI no asigna puntuaciones. La autoevaluación es voluntaria y no mide la conformidad jurídica: en particular, no es un instrumento de conformidad con el Reglamento (UE) 2024/1689, que menciona los siete requisitos como principios éticos no vinculantes (considerando 27). La ALTAI recomienda cumplimentarla en un grupo multidisciplinar y después de una evaluación de impacto relativa a los derechos fundamentales, que en la ALTAI es una evaluación general, distinta de la FRIA del artículo 27 del Reglamento de IA. Fuente: AI HLEG, The Assessment List for Trustworthy Artificial Intelligence (ALTAI) for self assessment, 2020, doi:10.2759/002360. Consulta: https://altai.insight-centre.org/Home/HowToComplete

INICIA LA HERRAMIENTA Assessment List for Trustworthy AI (ALTAI): ALTAI — Assessment List for Trustworthy AI

FOCUS BOX

Si un proyecto de investigación se amplía y pasa al uso comercial o a una implantación «de alto riesgo» (como la IA en la contratación de personal, en las infraestructuras críticas o en los dispositivos médicos autónomos), los desarrolladores y los implementadores deben cumplir, antes de la introducción en el mercado o de la puesta en servicio, los requisitos del Reglamento de IA. Esto implica el registro de la IA, el establecimiento de sistemas de gestión de riesgos, la conservación de la documentación y el sometimiento a evaluaciones de la conformidad52.

Verificación de la conformidad con la Ley de IA de la UE Como en el caso del GDU desarrollado por empresas, puedes utilizar esta herramienta interactiva para determinar si tu sistema de IA estará sujeto o no a estas obligaciones

Para las fechas de aplicación del Reglamento, véase el cuadro recogido en el focus box «¿Eres una empresa que desarrolla el GDU?» (§ 5.3). https://artificialintelligenceact.eu/implementation-timeline/ Con arreglo al artículo 2, apartado 1, del Reglamento 2024/1689, el Reglamento se aplica a:

a)los proveedores que introduzcan en el mercado o pongan en servicio sistemas de IA o que introduzcan en el mercado modelos de IA de uso general en la Unión, con independencia de si dichos proveedores están establecidos o ubicados en la Unión o en un tercer país; b)los responsables del despliegue de sistemas de IA que estén establecidos o ubicados en la Unión; c)los proveedores y responsables del despliegue de sistemas de IA que estén establecidos o ubicados en un tercer país, cuando los resultados de salida generados por el sistema de IA se utilicen en la Unión; d)los importadores y distribuidores de sistemas de IA; e) los fabricantes de productos que introduzcan en el mercado o pongan en servicio un sistema de IA junto con su producto y con su propio nombre o marca; f)los representantes autorizados de los proveedores que no estén establecidos en la Unión; g)las personas afectadas que estén ubicadas en la Unión. Con arreglo al considerando 13 del Reglamento de IA, el concepto de «responsable del despliegue» debe interpretarse como cualquier persona física o jurídica, incluida cualquier autoridad pública, agencia u otro organismo, que utilice un sistema de IA bajo su propia autoridad, salvo cuando el sistema de IA se utilice en el transcurso de una actividad personal de carácter no profesional.

Comprueba a qué obligaciones está sujeto tu sistema de IA con arreglo al Reglamento de IA

Puedes utilizar esta herramienta interactiva para determinar si tu sistema de IA estará sujeto o no a estas obligaciones siguiendo el test desarrollado por el equipo del Future of Life Institute. https://artificialintelligenceact.eu/

Sigue: https://artificialintelligenceact.eu/it/assessment/controllo-della-conformita-dell-ue-alla-legge-ai/ https://artificialintelligenceact.eu/wp-content/uploads/2025/07/AI-Act-Compliance-Checker-Flowchart-v1.0_compressed.pdf O bien utiliza la herramienta siguiente, que resume el anterior control de conformidad con la ley de IA: Utiliza el Compliance Checker AI Act, una herramienta que adapta el sistema antes citado para determinar las obligaciones aplicables

Evalúa si tu sistema es inteligencia artificial de alto riesgo

El Reglamento (UE) 2024/1689 (Reglamento de IA) introduce un enfoque basado en el riesgo para garantizar el respeto de los derechos fundamentales consagrados en la Carta de la UE. Se presta especial atención a los sistemas de IA de alto riesgo.

El Reglamento (UE) 2024/1689 (Reglamento de IA) define un sistema de inteligencia artificial de alto riesgo como un sistema que, por su impacto potencial en los derechos fundamentales, la seguridad o los intereses públicos, está sujeto a obligaciones más estrictas de conformidad y control.

Características principales

• Elevado potencial de daño para las personas o para la sociedad (p. ej., discriminación, violación de la privacidad, riesgos para la salud).
• Uso en sectores sensibles o en procesos de toma de decisiones que afectan a los derechos fundamentales.

Un sistema de IA se considera de alto riesgo (artículo 6 del Reglamento de IA) si, con independencia de si se ha introducido en el mercado o se ha puesto en servicio sin estar integrado en los productos a que se refieren las letras a) y b) siguientes, se cumplen las dos condiciones que se indican a continuación:

a)el sistema de IA está destinado a ser utilizado como componente de seguridad de un producto, o el propio sistema de IA es un producto, que entra en el ámbito de aplicación de los actos legislativos de armonización de la Unión enumerados en el anexo I del Reglamento de IA⁵³;

b)el producto del que el sistema de IA es componente de seguridad con arreglo a la letra a), o el propio sistema de IA como producto, debe someterse a una evaluación de la conformidad de terceros para su introducción en el mercado o puesta en servicio con arreglo a los actos legislativos de armonización de la Unión enumerados en el anexo I.

Además de los sistemas de IA de alto riesgo mencionados (artículo 6, apartado 1, y anexo I: sistemas que son productos regulados por los actos legislativos de armonización de la Unión, o componentes de seguridad de estos, como productos sanitarios y productos sanitarios para diagnóstico in vitro, máquinas, juguetes, equipos de seguridad), también se consideran de alto riesgo los sistemas de IA contemplados en el anexo III del Reglamento de IA (artículo 6, apartado 2).

Se consideran de alto riesgo, en particular, los sistemas de IA que:

• Realizan acciones que pueden calificarse como biométricas:
  • • Identificación remota de personas.
    • Categorización basada en características sensibles (salvo los casos prohibidos por el artículo 5, apartado 1, letra g)).
• Se utilizan como componentes de seguridad en la gestión y el funcionamiento de las infraestructuras digitales críticas, del tráfico rodado o del suministro de agua, gas, calefacción o electricidad (punto 2).
• Se refieren a la educación y la formación profesional y están destinados a ser utilizados:
  • • para determinar el acceso, la admisión o la asignación de personas físicas a los centros educativos y de formación profesional de todos los niveles;
    • para evaluar los resultados del aprendizaje;
    • para evaluar el nivel de educación adecuado que recibirá una persona o al que podrá acceder, en el contexto de los centros educativos o de formación profesional, o dentro de estos, de todos los niveles;
    • para el seguimiento y la detección de comportamientos prohibidos por parte de los estudiantes durante los exámenes en el contexto de los centros educativos y de formación profesional, o dentro de estos, de todos los niveles.
• Se utilizan en el ámbito del empleo:
  • • Contratación, selección, evaluación del rendimiento.
• Se aplican al acceso a servicios esenciales:
  • • Sanidad, crédito, seguros.
• Los utilizan las fuerzas y cuerpos de seguridad:
  • • Prevención de delitos, evaluación de pruebas.
• Se utilizan en las actividades de migración y de control de fronteras.
• Apoyan los procesos de administración de justicia y los procesos democráticos:
  • • Asistencia a una autoridad judicial en la investigación y la interpretación de los hechos y del Derecho y en la aplicación de la ley, o destinados a ser utilizados en la resolución alternativa de litigios;
    • Utilizados para influir en el resultado de una elección o de un referéndum o en el comportamiento electoral de las personas en el ejercicio de su derecho de voto en elecciones o referendos.

Un sistema del anexo III que elabore perfiles de personas físicas se considera siempre de alto riesgo (artículo 6, apartado 3, último párrafo). Para los demás sistemas del anexo III, el artículo 6, apartado 3, permite una excepción cuando el sistema no plantea un riesgo importante de causar un perjuicio a la salud, la seguridad o los derechos fundamentales, en las condiciones del párrafo segundo; el proveedor que se acoge a ella documenta la evaluación (artículo 6, apartado 4) y registra el sistema (artículo 49, apartado 2).

FOCUS BOX

Te invitamos a evaluar si tu sistema es de alto riesgo siguiendo la Evaluación de impacto de la inteligencia artificial (AIIA) desarrollada por el Ministerio de Infraestructuras y Gestión del Agua de los Países Bajos, a la que remitimos para una lectura completa; aquí se reproduce la parte operativa con una traducción no oficial: https://www.government.nl/documents/2023/03/02/ai-impact-assessment

Hemos creado una herramienta operativa a partir del contenido de los apéndices 1 y 2 y de las preguntas para los operadores contenidas en el texto antes citado:

INICIA LA HERRAMIENTA

Evaluación del nivel de riesgo

Focus box

Realiza la FRIA

Utilizando la plantilla Excel para la evaluación de impacto relativa a los derechos fundamentales (artículo 27 del Reglamento de IA), que acompaña a la guía «A Guide to Fundamental Rights Impact Assessments (FRIA)» del European Center for Not-for-Profit Law (ECNL) y del Danish Institute for Human Rights (DIHR), de 12 de diciembre de 2025 (https://ecnl.org/publications/guide-fundamental-rights-impact-assessments-fria). La plantilla está en inglés y debe entenderse como plantilla de trabajo: el modelo de cuestionario que la Oficina de IA debe poner a disposición (artículo 27, apartado 5, en la redacción dada por el Reglamento (UE) 2026/1744) no consta como publicado a 16 de octubre de 2026, y la Comisión lo menciona entre las directrices en preparación (https://digital-strategy.ec.europa.eu/en/news/supporting-implementation-ai-act-clear-guidelines).

5.4 Obligaciones de transparencia de los sistemas de IA

El Reglamento de IA europeo impone requisitos de transparencia a determinados sistemas de IA, con independencia de su clasificación de riesgo (para los de alto riesgo, además de los requisitos del capítulo III). Estas obligaciones se definen específicamente en el artículo 50. Desde el 2 de agosto de 2026, tanto los proveedores (provider) como los responsables del despliegue (deployer) están sujetos a obligaciones precisas de notificación y marcado

A la luz del marco normativo, convendría iniciar un proceso de adaptación estructurado.

Toda organización que utilice sistemas de IA incluidos en las categorías del artículo 50 debería:

• Comunicar la naturaleza artificial de la interacción (artículo 50, apartado 1)
• Garantizar el marcado técnico de los contenidos sintéticos (artículo 50, apartado 2)
• Información sobre el reconocimiento de emociones y la categorización biométrica (artículo 50, apartado 3)
• La divulgación de las ultrasuplantaciones y de los textos de interés público (artículo 50, apartado 4)

A continuación, algunas indicaciones prácticas sobre aspectos relevantes que deben tenerse en cuenta.

1. 1.En primer lugar, es necesario mapear los sistemas de IA en uso e identificar el propio papel (proveedor o responsable del despliegue)
2. 2.Un segundo elemento que debería tenerse en cuenta es el mapeo de las modalidades de comunicación existentes de los sistemas ya en uso en contacto con los usuarios, para verificar el nivel de madurez respecto a las obligaciones que pasarán a ser aplicables.
3. 3.Además, en lo que respecta a los proveedores de sistemas de IA que generan contenido, conviene también iniciar la evaluación de las soluciones técnicas de marcado para la señalización de los contenidos 
4. 4.el personal de la organización que utiliza herramientas de IA de entre las descritas anteriormente debe recibir formación sobre las obligaciones de divulgación. En particular, es importante que también las personas de la organización que utilizan esas soluciones de IA conozcan los casos vistos anteriormente y las obligaciones correspondientes⁵⁴.

Regla de transparencia si tu sistema interactúa con las personas y para los contenidos generados por IA

El artículo 50 del Reglamento (UE) 2024/1689 (Reglamento de IA) establece un sistema articulado de obligaciones de transparencia aplicables tanto a los proveedores (provider) como a los usuarios profesionales (deployer) de sistemas de inteligencia artificial, con independencia de su clasificación de riesgo. El artículo 50 del Reglamento de IA impone obligaciones de transparencia a los sistemas de inteligencia artificial que interactúan con las personas, aunque no sean de alto riesgo

Cuándo se aplica:

• El sistema de IA interactúa con un ser humano (p. ej., chatbots, asistentes de voz, avatares).
• El sistema genera contenidos (p. ej., texto, imágenes, audio) aparentemente humanos.
• El sistema se utiliza para detectar emociones o inferir características personales (p. ej., edad, sexo, estado emocional).

En su conjunto, las obligaciones de transparencia del Reglamento de IA persiguen un objetivo fundamental: garantizar que las personas sean siempre conscientes del origen artificial de la interacción o del contenido cuando dicho origen pueda influir en su capacidad de decisión.

La transparencia se configura, por tanto, no solo como un requisito técnico o informativo, sino como un presupuesto esencial para la protección de la autonomía individual, de la confianza y de la corrección del ecosistema informativo.

Código de buenas prácticas sobre la transparencia de los contenidos generados por IA

La Comisión Europea publicó el 10 de junio de 2026 la versión definitiva del Código de buenas prácticas en materia de marcado y etiquetado de los contenidos generados por IA (comunicado IP/26/1328), un instrumento voluntario que define medidas prácticas para ayudar a los proveedores y a los responsables del despliegue de sistemas de IA generativa a cumplir las obligaciones de transparencia previstas en el artículo 50 del Reglamento de IA, aplicables desde el 2 de agosto de 2026. El 8 de julio de 2026 la Comisión concluyó que el código cubre adecuadamente las obligaciones del artículo 50, apartados 2, 4 y 5, y al día siguiente el Consejo Europeo de Inteligencia Artificial adoptó su propia evaluación de adecuación. El código es distinto del Código de buenas prácticas para los modelos de IA de uso general, publicado el 10 de julio de 2025, citado en el § 5.5.

El código de buenas prácticas respalda el cumplimiento de las obligaciones de transparencia previstas en el Reglamento (UE) 2024/1689 (Reglamento de IA) relativas al marcado y el etiquetado de los contenidos generados por IA. Ayuda a los proveedores y a los operadores de sistemas de IA generativa a cumplir las obligaciones de la Ley de IA en materia de etiquetado y marcado de los contenidos generados por IA (artículo 50, apartados 2, 4 y 5, de la Ley de IA). Aunque la adhesión al código es voluntaria, los requisitos de transparencia previstos en el artículo 50 de la Ley de IA constituyen obligaciones jurídicas.

Consulta el Código de buenas prácticas sobre la transparencia de los contenidos generados por IA , del que reproducimos un extracto

https://ec.europa.eu/newsroom/dae/redirection/document/129555

5.4.1 Lista de comprobación práctica

Todas las organizaciones

• Realizar un inventario de todos los sistemas de IA en uso dentro de la organización e identificar los que entran en el ámbito de aplicación del artículo 50.
• Verificar si se aplican posibles exenciones o excepciones.
• Seguir la aplicación del Código de buenas prácticas sobre los contenidos generados por IA y las Directrices de la Comisión.
• Exigir contractualmente la conformidad a los proveedores de IA.
• Tener en cuenta la obligación de alfabetización en materia de IA (artículo 4 del Reglamento de IA, en la redacción dada por el Reglamento (UE) 2026/1744): se aplica a los proveedores y a los responsables del despliegue de cualquier sistema de IA, con independencia del nivel de riesgo, y es aplicable desde el 2 de febrero de 2025.

Proveedores

• Para los sistemas que interactúan directamente con las personas, garantizar una información clara sobre la IA en el momento de la primera interacción, de modo que se cumplan los requisitos de accesibilidad.
• Para los sistemas de IA generativa (incluida la GPAI), aplicar un marcado legible por máquina de los resultados de salida sintéticos en todas las modalidades (audio, imagen, vídeo, texto).

Responsables del despliegue

• Para el reconocimiento de emociones o la categorización biométrica, examinar cada caso de uso a la luz de la prohibición del artículo 5 antes de plantearse la divulgación con arreglo al artículo 50, apartado 3.
• Para los usos permitidos, diseñar mecanismos de notificación que informen a las personas afectadas de forma clara y distinguible.
• Para los sistemas capaces de generar ultrasuplantaciones, mapear todos los casos de uso que producen contenidos de imagen, audio o vídeo que podrían entrar en la definición de «ultrasuplantación» y diseñar una información adecuada.
• Inventariar los resultados de salida textuales publicados e identificar los publicados con el fin de informar al público sobre asuntos de interés público. Para los textos incluidos en el ámbito de aplicación, aplicar la información o establecer el proceso de revisión humana y de responsabilidad editorial para acogerse a la exclusión.

Transparencia técnica para los sistemas de alto riesgo (artículo 13)

Para los sistemas de IA de alto riesgo (p. ej., los utilizados en la selección de personal, en los productos sanitarios o en la evaluación de la solvencia), la transparencia sirve para garantizar la trazabilidad y el control:

• Documentación técnica: Debe elaborarse antes de la introducción en el mercado y mantenerse actualizada. Incluye la arquitectura del modelo, la lógica de funcionamiento y los sistemas de cálculo. (Artículo 11; véase https://ai-act-service-desk.ec.europa.eu/it/ai-act/article-11; anexo IV, «Documentación técnica a que se refiere el artículo 11»)
• Instrucciones de uso: Los proveedores deben facilitar a los usuarios (empresas y profesionales) un manual claro, detallado y comprensible sobre las capacidades y los límites del sistema.
• Registro: Algunas categorías de IA de alto riesgo deben registrarse en una base de datos pública de la UE gestionada por la Comisión Europea.

5.5 Obligaciones de transparencia de los modelos de IA

Transparencia para los modelos de IA de uso general

(General Purpose AI)

Los modelos de IA de uso general (GPAI) son la base de muchos sistemas de IA diferentes. Para garantizar una IA segura y transparente, el Reglamento (UE) 2024/1689 (Reglamento de IA) establece obligaciones para todos los proveedores de modelos GPAI y obligaciones adicionales para los proveedores de los modelos más avanzados o de gran impacto (es decir, modelos GPAI con riesgo sistémico). Estas obligaciones se aplican desde el 2 de agosto de 2025 (para los modelos introducidos en el mercado antes de esa fecha, a más tardar el 2 de agosto de 2027); las sanciones del artículo 101 se aplican desde el 2 de agosto de 2026.

Sigue las «Obligaciones en materia de IA de uso general con arreglo al Reglamento (UE) 2024/1689 (Reglamento de IA)» consultando el sitio web de la CE:

https://digital-strategy.ec.europa.eu/it/factpages/general-purpose-ai-obligations-under-ai-act

Para cumplir tus obligaciones de transparencia, cumplimenta este documento. El texto compartido procede del GPAI Code of Practice (versión final, 10 de julio de 2025), capítulo de Transparencia, Measure 1.1. Se trata del modelo que los proveedores de modelos de IA de uso general (GPAI) adheridos al Código pueden utilizar para demostrar la conformidad con las obligaciones de documentación previstas en el artículo 53, apartado 1, letras a) y b), del Reglamento de IA.

La página oficial con todos los PDF descargables (Code of Practice completo + Model Documentation Form) es: https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai

Notas importantes

• El formulario no se aplica a los proveedores de modelos publicados con licencia libre y de código abierto cuyos parámetros se ponen a disposición del público, salvo que el modelo presente riesgo sistémico (artículo 53, apartado 2, del Reglamento de IA).
• La información debe actualizarse y conservarse durante 10 años tras la introducción en el mercado.
• El capítulo de Transparencia comprende 3 medidas: 1.1 (documentación), 1.2 (comunicación de la información a los proveedores posteriores y a la Oficina de IA), 1.3 (calidad e integridad).

Esta página es una traducción del original italiano; en caso de discrepancia, prevalece el texto italiano.