Skip to content
Glosario

Finalidad prevista: el ancla de clasificación de la Ley de IA de la UE

Definition15 January 2026· 13 min de lectura

La finalidad prevista (Artículo 3, apartado 12) impulsa la clasificación de la Ley de IA de la UE en virtud del Artículo 6, la modificación sustancial y el cambio de papel del Artículo 25.

En virtud del Reglamento (UE) 2024/1689, la «finalidad prevista» es el uso para el que un proveedor ha diseñado y documentado un sistema de IA —que abarca el contexto y las condiciones de uso específicos, tal como se establecen en las instrucciones de uso, en los materiales promocionales o de venta y en la documentación técnica—. Se define en el Artículo 3, apartado 12. El concepto importa porque la clasificación, las obligaciones de conformidad y la asignación de papeles dependen todas de lo que un sistema está documentado para hacer, no meramente de lo que es técnicamente capaz de hacer.

La definición de la Ley de IA de la UE

El Artículo 3, apartado 12, del Reglamento (UE) 2024/1689 define la finalidad prevista como «el uso para el que un proveedor concibe un sistema de IA, incluidos el contexto y las condiciones de uso específicos, según la información facilitada por el proveedor en las instrucciones de uso, los materiales y declaraciones promocionales o de venta y la documentación técnica».

En esa definición se nombran tres fuentes de documentación, y las tres tienen peso:

Las instrucciones de uso son la guía operativa que un proveedor proporciona a los responsables del despliegue y a los usuarios: el quién, el qué y bajo qué condiciones. Los materiales y declaraciones promocionales o de venta recogen lo que el proveedor ha comunicado al mercado sobre la función del sistema, aunque sea de manera informal en presentaciones comerciales o en el texto del sitio web. La documentación técnica (regida por el Artículo 11 y detallada en el Anexo IV) expone la justificación del diseño del sistema, el enfoque de entrenamiento, las capacidades y las limitaciones.

El alcance de esa tercera fuente es significativo. Un proveedor no puede reclamar una finalidad prevista estrecha en las instrucciones mientras comercializa el sistema para una aplicación más amplia. Las tres fuentes se leen conjuntamente; las incoherencias juegan en contra del proveedor. Los reguladores y las autoridades de vigilancia del mercado pueden basarse en cualquiera de ellas.

Por eso la documentación que produce un proveedor no es una mera formalidad de cumplimiento: define el perímetro jurídico de las obligaciones del sistema. Lo que un proveedor escribe determina qué nivel se aplica.

Finalidad prevista frente a uso indebido razonablemente previsible

La Ley empareja la finalidad prevista con un concepto estrechamente relacionado: el «uso indebido razonablemente previsible», definido en el Artículo 3, apartado 13, como la utilización «de un modo que no corresponde a su finalidad prevista, pero que puede derivarse de un comportamiento humano o una interacción con otros sistemas razonablemente previsibles».

La distinción importa porque las obligaciones no se detienen en el uso previsto. El Artículo 9, que exige a los proveedores de sistemas de IA de alto riesgo establecer un sistema de gestión de riesgos, cubre explícitamente ambos. Los proveedores deben identificar y analizar los riesgos asociados a la finalidad prevista del sistema y considerar también cómo podría utilizarse indebidamente el sistema de formas previsibles —incluidos los responsables del despliegue que llevan el sistema más allá de su alcance declarado, o los usuarios finales que lo adaptan de formas que el proveedor no anticipó—.

En la práctica, esto significa que un proveedor no puede documentar una finalidad prevista estrecha y luego ignorar las formas obvias en que un responsable del despliegue podría estirarla. Si una herramienta de contratación está documentada para filtrar las solicitudes entrantes pero podría plausiblemente reutilizarse para evaluar a los empleados existentes con vistas a una promoción o un despido, esa extensión previsible del uso debe abordarse en el sistema de gestión de riesgos. Las mitigaciones pueden incluir restricciones contractuales en las condiciones del servicio, salvaguardas técnicas o advertencias explícitas en las instrucciones de uso.

El sistema de gestión de riesgos del Artículo 9 es un proceso vivo, no una evaluación puntual. Debe actualizarse a lo largo de todo el ciclo de vida del sistema, y la finalidad prevista, junto con los escenarios de uso indebido previsible, se sitúa en su centro.

Por qué importa para la clasificación y los papeles

El uso más trascendente de la finalidad prevista en la Ley es la clasificación. El Artículo 6 determina si un sistema de IA es de alto riesgo comprobando si entra dentro del Anexo III —la lista de ocho ámbitos de uso de alto riesgo— en conjunción con el filtro del Artículo 6, apartado 3, que puede excluir un sistema del nivel de alto riesgo si no plantea un riesgo significativo de perjuicio a pesar de entrar en un ámbito del Anexo III.

Esa prueba de clasificación se aplica a la finalidad prevista del sistema. Una herramienta de programación de uso general se clasifica por lo que está documentada para hacer: programar tareas. Un modelo con una arquitectura subyacente idéntica, documentado y comercializado como herramienta para clasificar el rendimiento de los empleados o asignar tareas en función de la vigilancia de la productividad, entra de lleno en el Anexo III, punto 4 (empleo y gestión de los trabajadores). Misma tecnología, finalidad prevista distinta, nivel de riesgo distinto, pila de cumplimiento completamente distinta.

Esto significa que los proveedores no pueden escapar de la clasificación subestimando la finalidad del sistema. Si los materiales promocionales describen una clasificación del rendimiento y las instrucciones de uso describen una programación, se examina el conjunto completo de la documentación. Redactar una finalidad prevista conservadora que no refleje el uso comercializado real del sistema es a la vez jurídicamente frágil y —si el sistema sí causa un perjuicio— potencialmente material para la responsabilidad.

Cambiar la finalidad prevista activa la modificación sustancial. El Artículo 3, apartado 23, define la modificación sustancial como un cambio en un sistema de IA de alto riesgo que afecta al cumplimiento de los requisitos de la Ley o que altera la finalidad prevista para la que se evaluó el sistema. Si un proveedor estrecha, amplía o redirige la finalidad documentada de un sistema de IA tras la evaluación de la conformidad inicial, eso puede constituir una modificación sustancial, lo que exige una nueva evaluación en virtud del Artículo 43 antes de que el sistema modificado se reintroduzca en el mercado. El marcado CE y la declaración de conformidad originales se refieren a la finalidad prevista original; no se trasladan automáticamente a una nueva.

Los responsables del despliegue afrontan su propia exposición. El Artículo 25 dispone que cuando un responsable del despliegue modifica la finalidad prevista de un sistema de IA de alto riesgo —o utiliza un sistema de uso general para un fin de alto riesgo—, el responsable del despliegue se convierte en el proveedor del sistema modificado o reutilizado y hereda el conjunto completo de obligaciones del proveedor en virtud del Artículo 16. Este es el mecanismo de cambio de papel: un responsable del despliegue que lleva un sistema fuera de su alcance documentado no incumple simplemente una obligación del responsable del despliegue, sino que se convierte en proveedor. Ese cambio conlleva toda la pila del Artículo 16 —documentación técnica, gestión de la calidad en virtud del Artículo 17, evaluación de la conformidad en virtud del Artículo 43, registro en virtud del Artículo 49, marcado CE en virtud del Artículo 48 y nombramiento de un representante autorizado si tiene su sede fuera de la UE—.

Incluso sin llegar a un cambio formal de papel, un responsable del despliegue que utiliza un sistema de IA fuera de su finalidad prevista —sin modificarlo formalmente— sigue incumpliendo el Artículo 26, que exige que los responsables del despliegue utilicen el sistema de acuerdo con su finalidad prevista y las instrucciones del proveedor.

Ejemplos

Considere una empresa de software que desarrolla un modelo de aprendizaje automático capaz de analizar texto escrito e inferir atributos estructurados a partir de él. Si la empresa documenta y comercializa el sistema como una herramienta para clasificar los tiques de atención al cliente entrantes por tema, la finalidad prevista es la categorización de texto no estructurado en un contexto de atención al cliente, una función de riesgo mínimo. No se activa ningún ámbito del Anexo III; no surge ninguna obligación de alto riesgo.

Ahora la misma empresa lanza una segunda línea de productos utilizando el mismo modelo. Se comercializa a los departamentos de RR. HH. como una herramienta de cribado de candidatos que clasifica a los solicitantes de empleo según su idoneidad prevista. Las instrucciones de uso describen cómo el sistema puntúa los currículos y las cartas de presentación, y los materiales de venta incluyen casos de estudio de equipos de adquisición de talento. La finalidad prevista es ahora la evaluación de personas en el contexto de la contratación: Anexo III, punto 4, letra a). El modelo no cambia; sí lo hace la finalidad documentada. El segundo producto requiere un programa completo de cumplimiento de alto riesgo: un sistema de gestión de riesgos del Artículo 9, gobernanza de datos del Artículo 10, documentación técnica del Artículo 11 / Anexo IV, disposiciones de supervisión humana del Artículo 14, una evaluación de la conformidad en virtud del Artículo 43 (el control interno del Anexo VI se aplica al Anexo III, punto 4), registro en la base de datos de la UE en virtud del Artículo 49 y una declaración UE de conformidad en virtud del Artículo 47. El primer producto no requiere ninguna de ellas.

Un escenario de despliegue más nítido ilustra el ángulo del responsable del despliegue. Una empresa de logística compra una herramienta de programación de la plantilla cuya finalidad prevista —documentada por el proveedor— es la planificación de turnos en función de la demanda operativa. El equipo de operaciones de la empresa, sin involucrar al proveedor, empieza a utilizarla para puntuar el rendimiento de los trabajadores individuales y señalar a los empleados para revisiones de gestión del rendimiento. Ese uso está fuera de la finalidad prevista documentada. La empresa de logística, en los términos del Artículo 25, ha modificado la finalidad prevista del sistema. Según la importancia del cambio, puede haberse convertido en el proveedor de un sistema de IA de alto riesgo que cubre la gestión de los trabajadores (Anexo III, punto 4), con las obligaciones asociadas recayendo sobre ella, no sobre el proveedor original. Como mínimo, incumple el Artículo 26.

Preguntas frecuentes

¿Debe la finalidad prevista coincidir en todas las fuentes de documentación, o pueden distintas fuentes describir usos diferentes?

Todas las fuentes de documentación se leen conjuntamente en virtud del Artículo 3, apartado 12. Una finalidad prevista estrecha en las instrucciones de uso no prevalece sobre afirmaciones más amplias en los materiales de marketing o la documentación técnica. La incoherencia entre fuentes crea exposición jurídica: los reguladores pueden basarse en cualquiera de las tres, y un sistema se clasificará normalmente por su uso documentado más amplio. Los proveedores deben auditar las tres fuentes en busca de alineación antes de introducir un sistema en el mercado.

Si añadimos una nueva función a un sistema de IA desplegado, ¿cambia automáticamente la finalidad prevista?

No automáticamente: depende de lo que haga la función. Si la nueva función entra dentro del alcance de la finalidad prevista original tal como está documentada, y no altera el perfil de riesgo del sistema de formas que afecten al cumplimiento, es más probable que el cambio se considere mantenimiento rutinario o una actualización menor. Si la función extiende el uso del sistema a un nuevo contexto, un nuevo grupo de usuarios o un nuevo tipo de toma de decisiones —en particular uno que entre en un ámbito del Anexo III—, eso puede constituir un cambio en la finalidad prevista y activar la evaluación de modificación sustancial del Artículo 3, apartado 23.

¿Puede un responsable del despliegue especificar su propia finalidad prevista con independencia de la documentación del proveedor?

Un responsable del despliegue solo puede utilizar un sistema dentro de la finalidad prevista definida por el proveedor. Si un responsable del despliegue necesita que el sistema sirva a una finalidad distinta, debe o bien negociar con el proveedor para ampliar el alcance documentado —lo que puede activar las propias obligaciones de conformidad del proveedor—, o bien aceptar que está asumiendo la condición de proveedor en virtud del Artículo 25. Lo que un responsable del despliegue no puede hacer es documentar su propia finalidad prevista más amplia para un sistema y luego basarse en la evaluación de la conformidad y el marcado CE del proveedor para cubrir ese uso.

¿Afecta la finalidad prevista al sistema de gestión de riesgos?

Directamente. El sistema de gestión de riesgos del Artículo 9 se construye en torno a la finalidad prevista y los escenarios de uso indebido razonablemente previsible derivados de ella. La identificación y el análisis de riesgos, las medidas de mitigación y la evaluación del riesgo residual parten todos de la finalidad prevista documentada. Una finalidad prevista precisa y realista hace tratable el análisis del Artículo 9; una finalidad prevista vaga o demasiado amplia hace imposible delimitarlo, y crea responsabilidad si el sistema causa un perjuicio que una finalidad más estrecha habría excluido.

¿Qué ocurre si la finalidad prevista se cambia tras el marcado CE y la introducción en el mercado?

Si el cambio constituye una modificación sustancial —tal como se define en el Artículo 3, apartado 23—, el proveedor debe volver a ejecutar la evaluación de la conformidad en virtud del Artículo 43, emitir una declaración UE de conformidad nueva o actualizada en virtud del Artículo 47, actualizar la documentación técnica y volver a registrar el sistema si es necesario. El marcado CE emitido para la finalidad prevista original no se extiende al sistema modificado. Para los proveedores que ya están en el mercado, este es un ejercicio nada trivial: la documentación técnica del Anexo IV es extensa, y la evaluación de la conformidad para el Anexo III, punto 4 (empleo), requiere el procedimiento de control interno del Anexo VI en su totalidad.

¿Cómo interactúa la finalidad prevista con la exención del Artículo 6, apartado 3?

El Artículo 6, apartado 3, permite a un proveedor argumentar que un sistema que entra en un ámbito del Anexo III no es de alto riesgo porque no plantea un riesgo significativo de perjuicio —por ejemplo, porque desempeña una tarea procedimental limitada, mejora el resultado de una actividad humana previamente realizada o realiza un trabajo preparatorio sin sustituir la evaluación humana—. Ese argumento debe fundamentarse en la finalidad prevista real tal como está documentada. Un proveedor no puede reclamar una exención del Artículo 6, apartado 3, basándose en una finalidad prevista restringida mientras comercializa el sistema para un uso que expondría claramente a las personas físicas a un riesgo significativo. La evaluación de la exención debe documentarse y el sistema debe registrarse igualmente en virtud del Artículo 49, aunque el proveedor concluya que no es de alto riesgo.

Términos relacionados

Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar

Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.

Empieza la prueba gratuita →