Reglamento de IA de la UE: clasifique sus casos de uso y planifique las evidencias

La gobernanza de la IA empieza por saber qué sistemas proporciona, despliega o pone a disposición de otro modo la organización. Una lista de nombres de modelos no basta: la finalidad prevista, el contexto de despliegue y su rol determinan las obligaciones que hay que examinar.

Para la dirección, la clasificación es una decisión de asignación de recursos además de una evaluación jurídica. Determina qué proyectos necesitan una revisión especializada, qué deben demostrar los proveedores y qué evidencias deben existir antes de la puesta en producción. Una herramienta de selección de personal y un asistente interno de redacción pueden usar el mismo modelo y, aun así, requerir evaluaciones muy distintas.

El resultado útil es un registro revisado de casos de uso vinculado a responsables, requisitos, evidencias y decisiones de cambio, no una etiqueta para toda la empresa que diga «IA de bajo riesgo».

Establezca el ámbito y las responsabilidades antes de asignar el riesgo

El Reglamento de Inteligencia Artificial de la UE (EU AI Act) es un reglamento cuyas obligaciones dependen de la actividad, del sistema y del operador. Su ámbito territorial incluye a los proveedores que introducen sistemas en el mercado de la UE o los ponen en servicio, a los responsables del despliegue establecidos o ubicados en la UE y a determinados proveedores y responsables del despliegue de fuera de la UE cuando la información de salida de los sistemas se utiliza en la UE. La nacionalidad por sí sola no es el criterio.

Pida a revisores jurídicos y técnicos que determinen si la aplicación cumple la definición de sistema de IA del Reglamento y si se aplica alguna exclusión pertinente de su ámbito. No suponga que todo script de automatización es IA ni que un servicio alojado externamente queda fuera de sus responsabilidades.

A continuación, registre su rol:

• Proveedor: desarrolla un sistema, o encarga su desarrollo, y lo introduce en el mercado o lo pone en servicio con su propio nombre o marca.
• Responsable del despliegue: utiliza un sistema bajo su propia autoridad en un contexto profesional.
• Importador o distribuidor: introduce sistemas pertinentes en el mercado de la UE o los comercializa a través de la cadena de suministro, con las obligaciones de verificación correspondientes.
• Fabricante del producto o representante autorizado: tiene responsabilidades derivadas del acuerdo concreto sobre el producto o del mandato escrito.

Una organización puede ocupar roles distintos en su cartera. Comprar una API no resuelve el rol de la aplicación final. Cambiar la marca, introducir una modificación sustancial o cambiar la finalidad prevista puede desencadenar responsabilidades de proveedor en las condiciones aplicables. Por tanto, el ajuste fino es un desencadenante de revisión, no una conclusión jurídica automática.

Distinga el modelo de IA de uso general del sistema construido en torno a él. Las obligaciones del proveedor del modelo y las obligaciones relativas al sistema posterior están relacionadas, pero no son intercambiables.

Elabore un inventario de casos de uso que sirva para decidir

Haga inventario de las funciones de negocio, no solo de los proveedores. Entreviste a compras, RR. HH., producto, operaciones y TI: la IA puede llegar a través de una nueva funcionalidad de un proveedor existente en lugar de mediante una compra específica.

Para cada caso de uso, recoja:

Registre los flujos de trabajo reales junto a la finalidad prevista. Una herramienta descrita como «asistencia al reclutador» puede excluir de hecho a candidatos si el personal solo examina su lista preseleccionada. Una política escrita que exige revisión humana no demuestra que esa revisión se produzca.

El entregable es un registro versionado por caso de uso. Las clasificaciones sin resolver deben seguir figurando de forma visible como no resueltas, con un responsable y una fecha límite de decisión, en lugar de asignarse por defecto a la categoría menos exigente.

Evalúe por separado las prohibiciones, las vías del alto riesgo y la transparencia

La conocida descripción en cuatro niveles (prohibido, alto riesgo, obligaciones de transparencia y menor riesgo) es una introducción útil. No es un árbol de decisión completo. Las obligaciones de transparencia pueden solaparse con las de alto riesgo, y las obligaciones de alfabetización en materia de IA no se limitan a los sistemas de alto riesgo.

Descarte primero las prácticas prohibidas

El artículo 5 prohíbe determinadas prácticas, con sujeción a las condiciones y excepciones detalladas de la disposición. Entre las preguntas de cribado pertinentes figuran si un sistema utiliza manipulación perjudicial o explota vulnerabilidades, realiza una puntuación ciudadana prohibida, crea bases de datos de reconocimiento facial mediante extracción no selectiva de imágenes o lleva a cabo una categorización biométrica prohibida.

También está prohibido inferir emociones mediante IA a partir de datos biométricos en los lugares de trabajo y en los centros educativos, salvo por motivos médicos o de seguridad especificados. El análisis de sentimiento basado solo en texto no entra en esta prohibición por el mero hecho de evaluar el tono emocional. Determinados usos biométricos con fines de garantía del cumplimiento del Derecho tienen reglas estrictamente acotadas; «todo el reconocimiento facial está prohibido» no es un sustituto preciso de la evaluación.

Escale una posible práctica prohibida antes de la compra o el despliegue. Las evidencias deben describir la funcionalidad y el razonamiento jurídico, no limitarse a repetir la declaración de «IA ética» de un proveedor.

Pruebe las dos vías hacia la clasificación de alto riesgo

La vía del producto regulado, artículo 6, apartado 1: examine si la IA es en sí misma un producto, o un componente de seguridad de un producto, regulado por la legislación pertinente del anexo I, y si ese producto debe someterse a una evaluación de la conformidad de terceros. Ambas condiciones importan. Utilice el texto jurídico modificado del régimen de producto concreto; incorporar IA no establece por sí solo la condición de alto riesgo.

La vía del anexo III, artículo 6, apartado 2: examine si la función prevista coincide con un caso de uso enumerado. Los ocho ámbitos son epígrafes amplios, no reglas que conviertan en alto riesgo cualquier aplicación de un sector.

Lea las entradas detalladas y sus exclusiones. Por ejemplo, la detección del fraude financiero se distingue del uso enumerado de evaluación de la solvencia, y la verificación de documentos de viaje queda excluida de la entrada pertinente sobre identificación en materia de migración. La organización administrativa de campañas no equivale a influir en los votantes.

Evalúe la transparencia aunque no se apliquen las normas de alto riesgo

El artículo 50 aborda determinadas interacciones e informaciones de salida. Según el rol y las circunstancias, las obligaciones consisten en informar a las personas de que están interactuando con una IA, marcar en formato legible por máquina las informaciones de salida sintéticas, revelar las ultrasuplantaciones (deepfakes) y determinados textos de interés público generados por IA. Los usos de reconocimiento de emociones y de categorización biométrica también tienen disposiciones de información cuando están permitidos.

No lo reduzca a «etiquetar todos los documentos elaborados con ayuda de IA». Determine qué disposición se aplica, quién debe actuar y si es pertinente alguna excepción. Conserve como evidencia la redacción y la ubicación de los avisos, los mecanismos de marcado de la información de salida y los resultados de las pruebas.

Trate la excepción del artículo 6, apartado 3, como una evaluación documentada

Algunos sistemas del anexo III pueden quedar fuera de la clasificación de alto riesgo en virtud del artículo 6, apartado 3. No es una exención general para las herramientas en cuyo proceso interviene una persona en algún punto.

La evaluación debe determinar si el sistema plantea un riesgo importante de causar un perjuicio a la salud, la seguridad o los derechos fundamentales, incluido si influye sustancialmente en el resultado de la toma de decisiones. La disposición identifica circunstancias relativas a tareas de procedimiento limitadas, a la mejora del resultado de una actividad humana previamente realizada, a la detección de patrones o desviaciones en condiciones de revisión especificadas y a tareas preparatorias. Acogerse a la excepción exige cumplir al menos una de estas condiciones y establecer que el sistema no plantea el riesgo importante especificado.

Un proveedor que se acoja a esta excepción debe documentar la evaluación antes de introducir el sistema en el mercado o ponerlo en servicio, y cumplir la obligación de registro aplicable. Es fundamental que un sistema del anexo III que elabora perfiles de personas físicas sigue siendo de alto riesgo; esto no significa que todo sistema de elaboración de perfiles pase a ser automáticamente de alto riesgo en cualquier contexto.

Las evidencias deben explicar qué información utiliza el sistema, cómo afectan sus informaciones de salida a los revisores y si la tarea supuestamente preparatoria determina quién recibe una consideración sustantiva. Incluya observaciones del flujo de trabajo e informaciones de salida representativas. Una frase del tipo «la decisión final la toma una persona» es insuficiente si la clasificación, el filtrado o las recomendaciones determinan de hecho esa decisión.

Planifique en función de las fechas de aplicación vigentes

A fecha de 7 de octubre de 2026, el resumen y calendario actuales de la Comisión Europea sobre el Reglamento de IA identifican los siguientes hitos:

Compruebe el texto jurídico modificado y sus disposiciones transitorias concretas. Los sistemas existentes, las fechas de introducción de los modelos, los cambios y los acuerdos particulares de los operadores pueden requerir un análisis adicional. Las guías más antiguas pueden seguir mostrando fechas anteriores para el alto riesgo.

No interprete el calendario actualizado del alto riesgo como un aplazamiento de todo el Reglamento. Presupueste por separado las obligaciones que ya son aplicables y la preparación para el régimen de alto riesgo pertinente. Su registro debe identificar el hito aplicable y la fuente utilizada para establecerlo.

Convierta la clasificación en un plan de evidencias

Las responsabilidades del proveedor y las del responsable del despliegue son distintas. La dirección debe exigir un plan específico para cada rol en lugar de asignar todas las obligaciones a todos los equipos.

Si proporciona un sistema de alto riesgo

Los requisitos de alto riesgo y las obligaciones del proveedor abarcan la gestión de riesgos, la gobernanza de datos, la documentación técnica, la conservación de registros, la información para los responsables del despliegue, la supervisión humana, la precisión, la solidez, la ciberseguridad y la gestión de la calidad. También hay que planificar los procesos aplicables de evaluación de la conformidad, declaración, marcado, registro, vigilancia poscomercialización e incidentes.

Tradúzcalos en entregables:

• Una evaluación de riesgos a lo largo del ciclo de vida con medidas de mitigación, riesgos residuales y decisiones de aprobación.
• Registros sobre la procedencia, la idoneidad y la calidad de los datos cuando sean pertinentes para el sistema.
• Documentación técnica que identifique la finalidad, el diseño, las dependencias, las limitaciones y los métodos de evaluación.
• Resultados de pruebas vinculados a criterios de aceptación y al contexto de despliegue.
• Instrucciones de supervisión que expliquen la intervención, la anulación y el escalado.
• Especificaciones de registro de eventos, mecanismos de monitorización y procedimientos de incidentes.
• Un plan de trabajo de conformidad que identifique la vía aplicable y los registros exigidos.

No todos los sistemas de alto riesgo siguen la misma vía de evaluación. No presupueste una auditoría universal de terceros ni trate una certificación de seguridad como prueba de conformidad con el Reglamento de IA.

Si despliega un sistema de alto riesgo

Céntrese en utilizar el sistema conforme a las instrucciones, asignar una supervisión competente, vigilar su uso y conservar los registros exigidos. Ocúpese de la idoneidad de los datos de entrada cuando usted controle esos datos y de los requisitos aplicables de información a los trabajadores o a las personas afectadas.

Pida a los proveedores las instrucciones, limitaciones, requisitos de supervisión e información de conformidad pertinentes. Identifique lo que no pueden facilitar y quién resolverá esa carencia. Una declaración de garantía de un proveedor no establece que su configuración local sea adecuada.

Evalúe si se requiere una evaluación de impacto relativa a los derechos fundamentales para su categoría de responsable del despliegue y su caso de uso. No es universal para todos los despliegues. Cuando haya datos personales implicados, evalúe por separado los requisitos del RGPD; una evaluación de impacto relativa a la protección de datos y una evaluación conforme al Reglamento de IA tienen finalidades jurídicas distintas, aunque las evidencias se solapen.

Para cada entregable, especifique un responsable, un revisor, una fecha límite, la ubicación de la fuente y un criterio de aceptación. «Política subida» no equivale a «control demostrado».

Ejemplo práctico: un modelo, dos decisiones de negocio

Supuestos ilustrativos: un empleador de la UE utiliza un modelo de lenguaje de un tercero para un asistente interno de redacción y para una aplicación de selección de personal independiente. La aplicación de selección puntúa a los candidatos frente a los criterios del puesto y presenta una lista preseleccionada ordenada. El empleador utiliza ambas internamente; sus roles exactos como operador requieren revisión.

Para el asistente de redacción, registre las tareas de redacción permitidas, las restricciones sobre los datos, la revisión de la información de salida y cualquier requisito de transparencia aplicable. La redacción interna ordinaria no pasa a ser de alto riesgo por el mero hecho de utilizar IA. Ampliar su uso a la evaluación laboral desencadenaría una nueva evaluación.

En la selección de personal, la entrada del anexo III relativa al empleo es directamente pertinente. Revise la puntuación y la elaboración de perfiles de los candidatos, no solo la descripción de la interfaz. Si los reclutadores solo consideran a los candidatos preseleccionados, el sistema condiciona sustancialmente el acceso al empleo. La aprobación humana de la contratación final no elimina esa influencia.

Por tanto, la decisión de la dirección es distinta para cada aplicación. El asistente de redacción puede seguir adelante con controles proporcionados tras la revisión. El proyecto de selección de personal necesita un plan de preparación para el alto riesgo, evidencias del proveedor, una supervisión formada, una evaluación del uso local y una decisión de puesta en producción documentada.

Si el equipo propone cambiar la función de selección a la programación del calendario de entrevistas, evalúe de nuevo esa nueva finalidad y ese flujo de trabajo. La programación puede ser una tarea de procedimiento limitada, pero mantener la puntuación de candidatos en segundo plano socavaría la nueva justificación. Versione la decisión en lugar de sobrescribir el registro original.

Haga visible la responsabilidad en las decisiones operativas

Asigne un responsable de negocio que pueda explicar la finalidad y aprobar recursos, un responsable técnico que pueda fundamentar el comportamiento y un revisor jurídico o de cumplimiento que pueda cuestionar la clasificación. La aprobación de la dirección debe resolver la financiación, las restricciones de puesta en producción y el riesgo no resuelto, no sustituir el análisis especializado.

Como recomendación práctica, revise la clasificación cuando cambien la finalidad, los usuarios, los datos, las integraciones, la autonomía o la influencia en decisiones con consecuencias. Vincule esa revisión a las renovaciones de compras y a las versiones de producto. Una actualización del modelo por sí sola puede no cambiar la clasificación, pero puede invalidar las evidencias de evaluación o los supuestos operativos.

Entre los errores habituales están aceptar las clasificaciones generales de los proveedores, suponer que la revisión humana crea automáticamente una exención, pasar por alto las obligaciones de alfabetización y transparencia que ya son aplicables y recopilar documentos sin probar el funcionamiento local. Un sistema de gestión conforme a ISO/IEC 42001 puede respaldar la gobernanza, pero la certificación no acredita automáticamente el cumplimiento del Reglamento de IA.

Secani puede respaldar el flujo de evidencias vinculando requisitos, controles, material de origen, responsables, tareas y decisiones revisadas. Empiece con un proceso, vincule las evidencias a lo que demuestran y mantenga los comentarios, las aprobaciones y las marcas de tiempo junto a las conclusiones significativas. Trate las sugerencias asistidas por IA como borradores para revisión humana, no como determinaciones jurídicas. Nuestra guía de gobernanza de agentes de IA ofrece controles prácticos para los permisos y la revisión.

El siguiente paso útil es un taller de clasificación centrado: seleccione los casos de uso en producción con más consecuencias, reúna a sus responsables de negocio y técnicos y elabore registros revisados con las preguntas sin resolver y las tareas de evidencias. Así la dirección dispone de una base defendible para decidir qué puede seguir adelante, qué necesita condiciones y qué requiere una evaluación adicional.