AI Act en 2026: cómo decidir si un sistema de IA activa obligaciones, qué evidencias reunir y cuándo interviene una persona

Alcance de esta guía: una decisión trazable, no un dictamen jurídico

Esta guía está dirigida a equipos de producto, seguridad, cumplimiento, compras y tecnología que desarrollan, integran, distribuyen o utilizan sistemas de IA relacionados con el mercado de la Unión Europea. Su objetivo es convertir un caso de uso en una ficha auditable: qué hace el sistema, quién interviene en la cadena de suministro, dónde se usa, qué categoría podría resultar relevante, qué obligaciones están vigentes y qué evidencia existe.

No pretende resolver de forma concluyente la clasificación jurídica de un producto concreto. La aplicación del Reglamento de IA depende de los hechos, de la finalidad prevista, de la configuración real, de los actores que toman decisiones y, en ciertos sectores, de normas adicionales. Privacidad, empleo, crédito, productos sanitarios, aviación, biometría y prestación de servicios públicos pueden exigir evaluaciones bajo marcos distintos.

Las fechas importan, pero no hay una única fecha de aplicación para todo el Reglamento. La Comisión Europea presenta un calendario escalonado: algunas normas, incluidas las relativas a prácticas prohibidas y alfabetización en IA, comenzaron a aplicarse antes que el régimen general. Además, una modificación legislativa posterior cambia el calendario de determinadas obligaciones para sistemas de alto riesgo.

Use esta pieza como un procedimiento de gobernanza. Para explorar controles operativos, consulte la sección de Seguridad; para valorar alternativas técnicas y de proveedores, la sección Comparar; y para contextualizar capacidades y casos de uso, la sección Descubrir.

Paso 1: delimite el caso de uso antes de evaluar el riesgo

La unidad de análisis no debería ser únicamente el nombre comercial de una herramienta. Puede ser una funcionalidad concreta, una versión de modelo, un flujo automatizado o una integración. Un mismo producto puede tener funciones con niveles de exposición diferentes: resumir documentos internos no es equivalente a priorizar personas para una prestación, ni a ejecutar cambios en una cuenta externa.

Documente la finalidad prevista declarada por quien ofrece el sistema y la finalidad efectiva que su organización configura o permite. Incluya los territorios de puesta en el mercado, uso o disponibilidad de resultados; los grupos potencialmente afectados; el entorno de uso; la fase del ciclo de vida; las interfaces; y las acciones posteriores habilitadas. Conserve capturas de configuración, contratos, instrucciones, evaluaciones y versiones.

También identifique si se trata de un modelo de propósito general, de un sistema construido sobre dicho modelo o de ambos. Las directrices de la Comisión sobre modelos de propósito general son interpretativas y ayudan a separar obligaciones del proveedor del modelo de las del actor que ofrece o despliega un sistema aguas abajo. No sustituyen la norma ni una interpretación judicial.

Paso 2: identifique el rol por actividad, no por el nombre del contrato

Una organización puede desempeñar más de un rol en relación con productos o componentes distintos. El título de un contrato —por ejemplo, «cliente», «partner» o «revendedor»— no determina por sí solo el resultado. Lo relevante para el análisis es qué actor desarrolla, encarga desarrollar, comercializa, pone en servicio, importa, distribuye, modifica o utiliza el sistema bajo su autoridad.

Como marco operativo, trate como posible proveedor al actor que desarrolla un sistema o modelo, o encarga su desarrollo, y lo comercializa o pone en servicio con su nombre o marca. Trate como posible desplegador al actor que utiliza un sistema bajo su autoridad, salvo usos personales no profesionales. Importador y distribuidor son roles de cadena comercial que exigen revisar cómo se introduce o se pone a disposición el sistema en la Unión. La figura de representante autorizado requiere una designación y un mandato verificables.

Una modificación sustancial, un cambio de finalidad o la comercialización bajo marca propia son señales para detener el flujo automático y pedir revisión especializada. Las directrices disponibles sobre el alcance de obligaciones de proveedores de modelos de propósito general abordan, entre otros aspectos, la identificación del proveedor, la puesta en el mercado y las modificaciones; su condición de guía interpretativa debe quedar anotada en el expediente.

Paso 3: clasifique el uso y separe categorías que no son intercambiables

Empiece por descartar si el caso puede relacionarse con una práctica prohibida. Las prácticas prohibidas tienen un régimen de aplicación anterior al calendario general. La Comisión publicó directrices sobre estas prácticas; son útiles para estructurar preguntas y ejemplos, pero la interpretación autoritativa final corresponde a los tribunales competentes de la Unión.

Después evalúe, sin asumir el resultado, cuatro planos diferentes: si el sistema podría encajar en alto riesgo por ser un componente de seguridad de un producto regulado o por otro supuesto regulado; si su caso de uso podría entrar en categorías de alto riesgo; si activa deberes de transparencia; y si interviene un modelo de propósito general. Un sistema puede requerir transparencia sin ser de alto riesgo. Un modelo de propósito general no equivale automáticamente a un sistema de alto riesgo desplegado por un tercero.

No convierta una lista de sectores en un diagnóstico. La finalidad concreta, el efecto sobre personas, la autonomía operativa, el contexto de implementación y las excepciones aplicables pueden alterar la conclusión. Si el sistema afecta empleo, educación, acceso a servicios esenciales, crédito, salud, biometría, administración de justicia o servicios públicos, establezca una revisión jurídica y sectorial como condición de salida.

Paso 4: construya una línea temporal por obligación y condición

La planificación debe vincular cada obligación a una condición de activación, no limitarse a una fecha global. El marco de la Comisión indica que las prácticas prohibidas y las obligaciones de alfabetización en IA se aplican desde el 2 de febrero de 2025. Las obligaciones relativas a modelos de propósito general y determinadas disposiciones de gobernanza empezaron antes del régimen general, el 2 de agosto de 2025. El régimen general tiene como referencia el 2 de agosto de 2026, sujeto a las excepciones previstas.

Para alto riesgo, no reutilice automáticamente las fechas anteriores. La modificación legislativa publicada en 2026 aplaza la aplicación vinculada a los sistemas del anexo III y a los sistemas relacionados con el anexo I según un calendario diferenciado: el 2 de diciembre de 2027 para un grupo y el 2 de agosto de 2028 para el otro. La correspondencia concreta debe validarse contra el texto consolidado y la situación del sistema.

Las directrices de transparencia publicadas por la Comisión en 2026 se presentan como orientación sobre el alcance práctico de las obligaciones aplicables desde el 2 de agosto de 2026. Úselas para diseñar controles y evidencia, no para sustituir el análisis del texto legal o de actos posteriores.

Paso 5: traduzca requisitos en evidencias operativas

Una obligación solo es gestionable si se vincula a un propietario, una fuente, una fecha, una versión y una prueba de ejecución. El expediente no debe consistir en una declaración comercial genérica. Debe permitir reconstruir qué sistema se evaluó, con qué finalidad, qué configuración tenía, qué controles se aplicaron y qué decisión se tomó.

Para un caso que pueda ser de alto riesgo, las áreas habitualmente relevantes incluyen gestión de riesgos, gobernanza y calidad de datos cuando proceda, documentación técnica, registros, información para desplegadores, supervisión humana, exactitud, robustez y ciberseguridad. La aplicabilidad concreta depende de la clasificación y del rol. No declare que un control cumple un requisito si no se ha contrastado su alcance, prueba y evidencia.

La supervisión humana tampoco se demuestra con la frase «hay una persona en el circuito». Describa qué puede ver la persona, cuándo interviene, qué autoridad tiene para ignorar o detener una salida, qué formación recibe, cómo se gestionan alertas y qué ocurre ante automatización excesiva. Si no puede intervenir materialmente antes de una consecuencia relevante, documente esa limitación.

Paso 6: aplique el análisis a compras e integración de terceros

Comprar un sistema o una API no elimina las responsabilidades de quien lo configura y utiliza. La organización compradora debe distinguir documentación recibida del proveedor y evidencia generada sobre su propia implantación. Por ejemplo, el proveedor puede aportar instrucciones, características declaradas y documentación de conformidad cuando corresponda; el desplegador debe poder explicar la finalidad local, los usuarios autorizados, los datos conectados, los permisos y las decisiones tomadas tras una salida.

Incluya preguntas de cumplimiento en la selección, en el contrato, en la aceptación técnica y en la revisión periódica. Pida información con un nivel de detalle proporcional al uso previsto. Si el proveedor se niega a identificar versión, cambios relevantes, límites conocidos, condiciones de uso o mecanismo de incidentes, trate la falta de información como un riesgo de adquisición, no como una cuestión administrativa menor.

El Código de buenas prácticas para IA de propósito general, publicado en 2025 y considerado por la Comisión una herramienta voluntaria adecuada, puede ser una señal documental útil en algunos casos. No equivale por sí mismo a demostrar cumplimiento legal ni reemplaza la evidencia específica del sistema integrado.

Tres escenarios: qué hechos cambian el análisis

Escenario uno: un asistente interno redacta borradores a partir de documentos que el equipo carga manualmente. Si no decide sobre personas, no ejecuta acciones externas y se utiliza con revisión humana sustantiva, el expediente puede centrarse inicialmente en finalidad, datos, información a usuarios, permisos, proveedores y formación. Sin embargo, la clasificación cambia si los borradores se usan para decisiones de empleo, crédito, salud o acceso a servicios sin una revisión efectiva.

Escenario dos: un sistema prioriza solicitudes de clientes. El nombre «priorización» no resuelve nada. Importa si ordena solo una cola operativa o si determina, de hecho, quién recibe un servicio, con qué plazo, en qué condiciones y con qué posibilidad de corrección. Deben documentarse variables, reglas, métricas, sesgos conocidos, responsables de anulación y efectos de los falsos positivos y negativos.

Escenario tres: un agente puede enviar correos, modificar registros o activar acciones en herramientas externas. El hecho decisivo no es que use lenguaje natural, sino el alcance de sus permisos, la reversibilidad de las acciones, los umbrales de autorización, la identidad que ejecuta la acción y los controles previos y posteriores. Una capacidad de ejecución amplia puede exigir una evaluación de seguridad más intensa incluso cuando la clasificación regulatoria permanezca incierta.

Plantilla textual de ficha de aplicabilidad

Mantenga una ficha por caso de uso y actualícela cuando cambie la finalidad, el modelo, la integración, el proveedor, los datos o la población afectada. La ficha debe poder ser leída por producto, seguridad, compras y cumplimiento sin obligarles a reconstruir decisiones desde mensajes o reuniones aisladas.

Es preferible registrar incertidumbre explícita a cerrar una clasificación sin base suficiente. Marque qué conclusión es un hecho documentado, qué elemento es un análisis interno y qué asunto espera confirmación jurídica, técnica o contractual.

Errores frecuentes y cuándo detenerse para escalar

Un error habitual es asumir que el proveedor absorbe toda responsabilidad. Otro es aceptar una afirmación comercial de conformidad sin comprobar qué producto, versión, finalidad y actor cubre. También es frecuente usar una fecha única para todo el Reglamento, o convertir la evaluación de riesgos en una casilla que no se revisa tras un cambio técnico o de contexto.

Detenga el despliegue o la ampliación y escale a asesoramiento jurídico cuando haya una posible práctica prohibida; incertidumbre razonable sobre alto riesgo; tratamiento sensible o decisiones con efecto significativo sobre personas; biometría; empleo; crédito; salud; educación; servicios públicos; actividad policial o judicial; comercialización transfronteriza compleja; modificación sustancial; o conflicto entre la finalidad declarada y el uso real.

Escalar no equivale a bloquear permanentemente el producto. Significa formular una pregunta concreta, adjuntar hechos y evidencia, identificar la decisión pendiente y preservar una versión del sistema evaluado. Esta disciplina permite que la revisión legal, de privacidad, de seguridad o de derechos fundamentales sea más rápida y verificable.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.