Antes del checklist: qué determina tus obligaciones en la AI Act

Antes de revisar controles, documentos o procedimientos, hay que resolver una cuestión previa: qué posición ocupa realmente la empresa frente a cada sistema de IA. La AI Act no impone un paquete único de obligaciones a cualquier organización que utilice inteligencia artificial. El alcance cambia según el sistema, su finalidad, el contexto de uso y el papel que desempeña cada actor.

Por eso, un inventario que solo enumere herramientas resulta insuficiente. Debe permitir saber dónde se utilizan, para qué decisiones o tareas, quién las proporciona, quién las opera y qué personas pueden verse afectadas. Esa información convierte una lista tecnológica en un mapa de exposición sobre el que sí puede hacerse un triaje de cumplimiento.

Qué sistema utilizas, para qué y con qué nivel de riesgo

El nombre comercial de una herramienta no determina por sí solo su tratamiento. Una empresa puede utilizar un chatbot para responder preguntas generales de clientes y, al mismo tiempo, emplear otro sistema para filtrar candidaturas. Ambos incorporan IA, pero el segundo uso puede entrar en ámbitos que la AI Act considera de alto riesgo cuando se cumplen las condiciones previstas para empleo y gestión de trabajadores.

Esto obliga a documentar la finalidad y el uso real, no solo la funcionalidad anunciada por el proveedor. También conviene detectar usos que hayan aparecido fuera de los procesos previstos. Una misma solución puede introducir riesgos y obligaciones diferentes cuando cambia el contexto en el que se aplica o la función que desempeña dentro de una decisión.

Qué rol ocupa tu empresa y cuándo aplica cada requisito

La siguiente distinción es organizativa. La AI Act diferencia, entre otros, entre provider o proveedor, deployer o responsable del despliegue, importer y distributor. Una empresa que desarrolla y comercializa un sistema bajo su propia marca no ocupa la misma posición que otra que utiliza una solución contratada a un tercero. Comprar IA no elimina responsabilidades, pero tampoco convierte automáticamente al cliente en proveedor.

El rol tampoco es necesariamente permanente. En determinados sistemas de alto riesgo, poner la propia marca sobre el sistema, realizar una modificación sustancial o cambiar su finalidad prevista de forma que pase a considerarse de alto riesgo puede hacer que otro actor asuma obligaciones propias del provider. Por eso, el contrato con un proveedor no sustituye la revisión de lo que la empresa hace realmente con el sistema.

Una vez determinado el rol, todavía falta comprobar el calendario. Hay requisitos que dependen de la clasificación y del supuesto concreto, y disposiciones de alto riesgo sujetas a transición. El triaje debe registrar qué requisito existe, a quién aplica y desde qué momento.

Qué aplica en 2026 y qué debe preparar tu empresa

El calendario forma parte del triaje. En agosto de 2026, gran parte de la AI Act ya es aplicable, pero las obligaciones de alto riesgo no han entrado todas en vigor. Por eso, identificar un requisito en el Reglamento no basta: también hay que comprobar desde cuándo resulta exigible.

Fecha	Qué revisar
2 de febrero de 2025	Medidas de AI literacy y la mayoría de prácticas prohibidas
2 de agosto de 2025	Gobernanza y obligaciones sobre modelos de IA de propósito general
2 de agosto de 2026	Aplicación general de la AI Act y requisitos sin transición posterior
2 de diciembre de 2026	Determinadas prácticas prohibidas introducidas por el AI Omnibus
2 de diciembre de 2027	Reglas para sistemas de alto riesgo incluidos en el Anexo III
2 de agosto de 2028	Reglas para sistemas de alto riesgo integrados en productos regulados del Anexo I

La cronología oficial de aplicación de la AI Act permite comprobar estas fechas, pero cada empresa debe relacionarlas con su sistema, uso y rol antes de convertirlas en una obligación concreta.

Obligaciones ya aplicables y requisitos todavía en transición

Que un sistema pueda clasificarse como de alto riesgo no implica que todo su régimen específico sea exigible en agosto de 2026. Sin embargo, todavía no exigible no significa irrelevante: adaptar contratos, documentación, supervisión o procesos puede requerir meses y depender de proveedores o de varias áreas internas.

Una herramienta de selección de personal ilustra bien esta diferencia. La empresa debe determinar ahora su clasificación y responsabilidades, aunque algunos requisitos específicos de alto riesgo tengan una fecha de aplicación posterior.

Cómo priorizar una brecha y asignar la siguiente acción

Cuando aparezca una brecha, la prioridad debe depender del riesgo jurídico, el impacto y el tiempo necesario para corregirla:

• Escalar primero los usos que puedan afectar a prácticas prohibidas o requisitos ya aplicables.
• Validar el supuesto si existen dudas sobre clasificación, rol o aplicabilidad.
• Pedir información cuando el cumplimiento dependa de un proveedor.
• Preparar la transición si una obligación futura exige cambios técnicos, contractuales u organizativos.
• Documentar la decisión cuando se concluya que un requisito no aplica.

El triaje termina cuando cada brecha tiene un responsable y una siguiente acción. Sin esa asignación, el checklist detecta problemas, pero no ayuda a gobernarlos.

Checklist de cumplimiento de la AI Act para empresas

Una vez identificado el sistema, su uso y el papel de la organización, el checklist puede empezar a funcionar. Su objetivo no es acumular casillas marcadas, sino distinguir qué exige la norma, qué depende del supuesto concreto y qué conviene adoptar como buena práctica. Para el marco general, puedes consultar qué es la AI Act y cómo afecta a las empresas.

La tabla funciona como triaje inicial. Cada respuesta debe conducir a una comprobación o acción posterior, no interpretarse por sí sola como prueba de cumplimiento.

Pregunta	Si respondes sí	Si respondes no	Tipo de requisito	A quién aplica	Fuente oficial
¿Has identificado tus sistemas y usos de IA?	Clasifica cada uso y asigna responsable	Completa el inventario	Buena práctica	Cualquier organización	Comisión Europea
¿Sabes si eres provider, deployer, importer o distributor?	Revisa las obligaciones de ese rol	Determina primero tu posición	Obligación condicionada	Según función	AI Act, arts. 3 y 16-26
¿El uso puede ser una práctica prohibida?	Detén y valida el supuesto	Continúa con la clasificación	Obligación	Operadores afectados	AI Act, art. 5
¿El sistema puede ser de alto riesgo?	Comprueba requisitos y calendario	Revisa otras obligaciones posibles	Obligación condicionada	Según sistema y rol	AI Act, art. 6
¿Le afectan requisitos específicos de transparencia?	Verifica qué información debes proporcionar	Documenta el criterio	Obligación condicionada	Según sistema y rol	AI Act, art. 50
Si es de alto riesgo, ¿has revisado documentación, datos, logs, supervisión y seguridad?	Asigna los controles que correspondan	Identifica las brechas	Obligación condicionada	Según rol	AI Act, arts. 9-15 y 26
¿Te corresponde realizar una FRIA?	Realízala antes del despliegue cuando proceda	No la trates como requisito universal	Obligación condicionada	Deployers del art. 27	AI Act, art. 27
¿Eres provider o deployer?	Revisa las medidas de AI literacy	Confirma que quedas fuera de esos roles	Obligación	Providers y deployers	AI Act, art. 4
¿Se ha producido un incidente grave?	Activa el procedimiento que corresponda	Mantén la monitorización aplicable	Obligación condicionada	Según sistema y rol	AI Act, arts. 26 y 73

El resultado no debería ser un porcentaje de cumplimiento, sino un mapa de cuestiones pendientes. La referencia final para validar cada supuesto debe ser el texto vigente del Reglamento (UE) 2024/1689, especialmente cuando el triaje detecte una obligación condicionada.

Inventario, clasificación y obligaciones según el rol

El inventario debe permitir reconstruir qué sistema se utiliza, para qué y bajo qué responsabilidad. Una relación de herramientas no basta para determinar obligaciones. Una solución empleada para responder consultas comerciales no plantea las mismas preguntas que otra utilizada para filtrar candidaturas, aunque ambas procedan del mismo proveedor.

Como mínimo, para cada sistema conviene registrar:

• Finalidad y uso real, incluida cualquier utilización distinta de la prevista inicialmente.
• Área responsable y personas que operan o supervisan el sistema.
• Proveedor u origen, diferenciando solución externa, desarrollo interno o adaptación propia.
• Rol de la empresa como provider, deployer, importer o distributor cuando corresponda.
• Clasificación preliminar y requisitos que pueden activarse según el uso.

Este inventario también ayuda a evitar una conclusión frecuente: que contratar IA a un tercero traslada toda la responsabilidad al proveedor. La empresa debe comprobar qué obligaciones conserva en su propio papel y qué información necesita del tercero para cumplirlas. En un desarrollo interno, además, determinadas decisiones sobre cómo se introduce o pone en servicio el sistema pueden hacer que la organización asuma responsabilidades propias del provider.

Documentación, datos, trazabilidad y supervisión humana

La documentación, los registros, la calidad de los datos y la supervisión humana no recaen del mismo modo sobre todos los actores. En sistemas de alto riesgo, el provider asume requisitos específicos sobre diseño, documentación y funcionamiento, mientras que el deployer debe revisar las obligaciones que le correspondan sobre uso, datos de entrada, conservación de logs, monitorización y supervisión.

Cuando corresponda al deployer asignar la supervisión humana, debe hacerlo a personas con competencia, formación, autoridad y apoyo suficientes. Además, la supervisión debe permitir comprender las capacidades y límites del sistema, detectar anomalías e intervenir sobre sus resultados. En una herramienta de selección, por ejemplo, una validación formal aporta poco si la persona responsable no puede ignorar, revertir o detener el uso cuando existan motivos para hacerlo.

Seguridad, monitorización, registro, FRIA, incidentes y AI literacy

Estos controles no forman un único paquete ni afectan automáticamente a cualquier empresa. Seguridad, monitorización, registro, FRIA e incidentes tienen sujetos, condiciones y procedimientos distintos, por lo que el triaje debe determinar primero cuál entra realmente en juego.

Si existe un supuesto de registro, el procedimiento puede ampliarse en la guía sobre registro de sistemas en la AI Act. La FRIA tampoco debe incorporarse como requisito estándar para todo sistema de alto riesgo: el artículo 27 de la AI Act delimita qué deployers y supuestos están obligados a realizarla.

También conviene separar monitorizar de reportar un incidente. Detectar desviaciones, conservar determinados registros o comunicar un incidente grave responden a obligaciones diferentes y dependen del sistema y del rol de la organización. Un problema detectado durante el uso debe llevar primero a identificar qué procedimiento corresponde y quién debe activarlo.

La AI literacy tiene otra función. Providers y deployers deben adoptar medidas adecuadas para que las personas que utilizan sistemas de IA en su nombre dispongan de conocimientos suficientes según su experiencia y contexto. Formar es una parte de la gobernanza, no una prueba automática de cumplimiento: las personas también necesitan saber qué pueden decidir, qué deben supervisar y cuándo escalar un problema.

Conclusiones

La AI Act obliga a abandonar una idea cómoda pero poco útil: que el cumplimiento pueda resolverse con una lista idéntica para cualquier empresa. El punto de partida es determinar la exposición concreta de cada sistema, su finalidad, el papel de la organización y el momento en que cada requisito resulta exigible.

Ese análisis permite distinguir entre lo que debe corregirse ahora, lo que depende de una clasificación o responsabilidad concreta y lo que conviene preparar antes de que termine un periodo transitorio. También evita convertir recomendaciones internas en supuestas exigencias legales o confiar en que el proveedor asumirá responsabilidades que corresponden a la propia organización.

El resultado útil del checklist no es una puntuación, sino un mapa de decisiones: qué brecha existe, quién debe resolverla, qué evidencia falta y cuándo es necesario recurrir a una revisión jurídica, técnica u operativa más profunda.