AI Act europeo en tu empresa: checklist de cumplimiento 2026

TL;DR

El AI Act europeo aplicado a tu empresa es el conjunto de obligaciones operativas, técnicas y de gobernanza que el Reglamento (UE) 2024/1689 impone a cualquier organización que desarrolle, distribuya o utilice sistemas de inteligencia artificial dentro del mercado europeo. Las prohibiciones entraron en vigor en febrero de 2025, las obligaciones para modelos de propósito general (GPAI) en agosto de 2025, los sistemas de alto riesgo se activan en agosto de 2026 y el resto del régimen aplica en agosto de 2027. Las sanciones llegan hasta 35 millones de euros o el 7% de la facturación global. Este artículo es el checklist práctico de 20 puntos que usamos en Datalvar AI para que el AI Act europeo aplicado a tu empresa deje de ser una abstracción legal y pase a ser una hoja de ruta operativa con responsables, fechas y entregables verificables.

!IMAGE_TODO[Mapa visual del cronograma de aplicación del AI Act europeo aplicado a tu empresa con hitos de febrero 2025, agosto 2025, agosto 2026 y agosto 2027 sobre línea temporal con iconos de cada tipo de obligación]

¿Por qué el AI Act europeo aplicado a tu empresa ya no es opcional en 2026?

En Datalvar AI llevamos desde 2023 acompañando a equipos de dirección que pasaron del “esto del AI Act lo miramos cuando toque” a descubrir, ya en 2026, que el “cuando toque” llegó hace dos veranos. La fotografía a junio de 2026 es la siguiente: el Reglamento (UE) 2024/1689 lleva en vigor desde el 1 de agosto de 2024, las prácticas prohibidas son ilegales desde el 2 de febrero de 2025, los modelos de propósito general (GPAI) llevan obligaciones específicas desde el 2 de agosto de 2025 y, lo más relevante para la mayoría de las empresas, los sistemas de alto riesgo entran en pleno régimen sancionador en agosto de 2026. Esto no es teoría: es el calendario que nos repiten en cada llamada con direcciones financieras nerviosas.

El cambio de tono de los reguladores también es palpable. La AEPD ya ha abierto su sandbox para sistemas de IA y la Comisión Europea ha publicado las guías oficiales sobre prácticas prohibidas y sobre obligaciones GPAI, lo que significa que ya no hay margen para alegar desconocimiento. El AI Act europeo aplicado a tu empresa no es solo una cuestión jurídica que el departamento legal pueda gestionar en paralelo: es una capa transversal que toca producto, ingeniería, datos, RR. HH., marketing y atención al cliente, porque cualquier herramienta de IA usada en cualquiera de esos ámbitos puede caer bajo el reglamento. Cuando hacemos auditorías iniciales, lo habitual es encontrar entre 12 y 30 sistemas de IA “en producción” que la dirección desconocía: chatbots, modelos de scoring de candidatos, asistentes de redacción para soporte, ranking de leads, OCR con clasificación automática, etc.

La consecuencia práctica es que el AI Act europeo aplicado a tu empresa cambia la forma en la que se contrata software. Hoy ya no se firma un SaaS de selección de personal sin cláusula AI Act, no se integra una API de IA generativa sin due diligence al proveedor GPAI y no se despliega un agente conversacional sin documentar quién es proveedor, quién es desplegador y quién asume qué obligaciones. Quien siga firmando contratos como si fuese 2023 está acumulando deuda regulatoria que pagará en 2026 o 2027, con multas que en su tope superan a las del GDPR. Por eso el primer paso en cualquier proyecto que abordamos es justamente este: convencer a la dirección de que el reloj ya está corriendo.

¿Qué dice exactamente el AI Act y a quién obliga?

El AI Act europeo aplicado a tu empresa parte de una idea muy concreta: regular los sistemas de IA por su riesgo y no por la tecnología subyacente. Da igual si usas un modelo de lenguaje grande, un random forest, un sistema de visión por computador o reglas heurísticas combinadas con aprendizaje supervisado: lo que importa es para qué se usa y qué consecuencias puede tener sobre los derechos fundamentales y la seguridad de las personas. Esto, en la práctica, obliga a hacer un inventario de casos de uso y a clasificarlos. Un mismo modelo puede ser de “riesgo mínimo” en una aplicación y de “alto riesgo” en otra; lo que cuenta es el contexto.

Los obligados son básicamente cuatro: proveedores (quienes desarrollan o ponen en el mercado un sistema de IA con su marca), desplegadores (quienes utilizan profesionalmente un sistema de IA bajo su autoridad), importadores y distribuidores. La mayoría de las pymes y empresas medianas son desplegadores: usan herramientas de IA de terceros para selección de personal, atención al cliente, decisiones crediticias, marketing predictivo o automatización interna. Pero ojo: si tu equipo personaliza, reentrena o reempaqueta un modelo bajo tu marca, te conviertes también en proveedor a efectos del reglamento, con un nivel de obligaciones bastante más exigente. Esta es una de las confusiones más caras que vemos: directores generales que asumen “yo solo uso ChatGPT” cuando en realidad han fine-tuneado un modelo para su sector y lo han embebido en su producto.

El ámbito territorial es muy amplio. El AI Act europeo aplicado a tu empresa se activa cuando el sistema se comercializa o se utiliza en la Unión Europea, o cuando el output del sistema se usa en la UE, aunque la empresa esté fuera. Esto significa que también afecta a proveedores estadounidenses, británicos o asiáticos cuyas APIs lleguen a usuarios europeos, y eso explica por qué OpenAI, Anthropic, Google y Mistral llevan meses ajustando documentación, tarjetas de modelo y términos contractuales: necesitan poder ser usados por empresas europeas sin que sus clientes les transmitan el riesgo. La trazabilidad contractual de la cadena GPAI es uno de los puntos donde más hemos visto romperse acuerdos de proveeduría en los últimos doce meses.

!IMAGE_TODO[Diagrama pirámide con los cuatro niveles de riesgo del AI Act europeo aplicado a tu empresa: prohibido (rojo), alto riesgo (naranja), riesgo limitado (amarillo) y riesgo mínimo (verde) con ejemplos por nivel]

¿Cuál es el cronograma exacto del AI Act europeo aplicado a tu empresa?

El cronograma de aplicación del Reglamento (UE) 2024/1689 es escalonado y conviene tenerlo muy presente porque define la prioridad de cualquier proyecto de adecuación. La entrada en vigor formal fue el 1 de agosto de 2024, pero las distintas obligaciones se activan en fechas diferentes para dar a las empresas un margen razonable de adaptación. La trampa es que ese margen ya está consumido para los dos primeros bloques, así que cualquier organización que aún no haya hecho su inventario está, técnicamente, en infracción potencial en al menos uno de esos frentes.

El 2 de febrero de 2025 se activaron dos cosas críticas: la prohibición de los sistemas listados en el artículo 5 (manipulación subliminal, explotación de vulnerabilidades, social scoring estatal, predicción policial individual basada solo en perfilado, reconocimiento de emociones en trabajo y educación con ciertas excepciones, scraping masivo no dirigido para bases de datos de reconocimiento facial, identificación biométrica remota en tiempo real en espacios públicos por autoridades fuera de excepciones tasadas y categorización biométrica para inferir raza, opinión política, religión, etc.) y, segundo, la obligación de alfabetización en IA (artículo 4) para todo el personal que interactúe con sistemas de IA, tanto en proveedores como en desplegadores. Esto último se ignora muchísimo y es una de las primeras cosas que la AEPD revisará en sus inspecciones.

El 2 de agosto de 2025 entraron las obligaciones para los modelos GPAI: documentación técnica, política de cumplimiento de derechos de autor, resumen del contenido usado para entrenamiento y, para los modelos con riesgo sistémico (los que superan ciertos umbrales de cómputo o de impacto), obligaciones reforzadas de evaluación, mitigación de riesgos sistémicos, ciberseguridad y notificación a la AI Office. El 2 de agosto de 2026 entra el grueso del régimen de alto riesgo del anexo III: empleo, educación, infraestructuras críticas, servicios esenciales privados (crédito, seguros de vida y salud), administración de justicia, procesos democráticos, migración y aplicación de la ley. Y el 2 de agosto de 2027 entran las obligaciones para los sistemas de alto riesgo del anexo I (los integrados como componentes de seguridad de productos ya regulados, como dispositivos médicos, juguetes, ascensores, automóviles o maquinaria), que ya estaban sujetos a sus propios marcos sectoriales. Para todo esto recomendamos contrastar siempre con la página oficial de la Comisión Europea sobre el AI Act y con el texto consolidado del Reglamento (UE) 2024/1689 en EUR-Lex.

El AI Act europeo aplicado a tu empresa no es una multa que llegará en 2027; es una arquitectura de gobernanza que necesitas levantar ahora, durante 18 meses, capa a capa, sin atajos.

¿Cómo clasificar tus sistemas de IA dentro del AI Act europeo aplicado a tu empresa?

La clasificación de riesgos es la columna vertebral de toda la regulación, y por tanto la pieza central del AI Act europeo aplicado a tu empresa. El reglamento define cuatro niveles: riesgo inaceptable (prohibido), alto riesgo, riesgo limitado (con obligaciones de transparencia) y riesgo mínimo (con códigos de conducta voluntarios). Cada uno tiene un régimen de obligaciones diferente, y un mismo sistema puede saltar entre categorías según el uso. Por eso el primer ejercicio que hacemos en cualquier auditoría es no clasificar tecnologías, sino casos de uso: “modelo X usado por el equipo Y para la finalidad Z”.

Los sistemas prohibidos son los menos numerosos pero los más sensibles. La Comisión publicó en febrero de 2025 directrices oficiales sobre las prácticas prohibidas (artículo 5) que conviene leer con detenimiento porque hay matices: por ejemplo, el reconocimiento de emociones está prohibido en el ámbito laboral y educativo, pero permitido para usos médicos o de seguridad. Lo mismo con la categorización biométrica: prohibida para inferir categorías sensibles, pero permitida para etiquetado técnico de imágenes ya adquiridas legalmente. Si hay un solo caso de uso prohibido en tu inventario, todo lo demás pasa a segundo plano: hay que pararlo de inmediato porque las sanciones por prohibiciones son las más altas, llegando al 7% de la facturación global.

Los sistemas de alto riesgo (anexo III) son la zona caliente para la mayoría de las empresas, porque ahí entran muchísimas herramientas SaaS de selección de personal, evaluación de empleados, scoring crediticio, detección de fraude en seguros, asignación de servicios públicos, control de fronteras o reconocimiento biométrico no prohibido. Cualquier herramienta que use IA para tomar o influir en decisiones que afecten a derechos fundamentales suele caer aquí. Para esos sistemas las obligaciones son densas: sistema de gestión de riesgos, gobernanza de datos, documentación técnica, registros automáticos, transparencia hacia el desplegador, supervisión humana, robustez, ciberseguridad y precisión, marcado CE, registro en la base de datos europea y, para desplegadores, evaluación de impacto en derechos fundamentales (FRIA). Es el grueso del trabajo del checklist.

¿Qué sistemas caen en “riesgo limitado” y qué obligaciones tienen?

El riesgo limitado afecta sobre todo a sistemas de IA que interactúan con personas físicas, generan contenido sintético o reconocen emociones o categorías biométricas (en los casos permitidos). Aquí entran los chatbots, los asistentes virtuales, los generadores de imágenes y vídeo, los sistemas de doblaje automático, los detectores de emociones en entornos no laborales ni educativos y similares. La obligación principal es de transparencia: dejar claro que el usuario está interactuando con una IA y, en el caso de contenido sintético, etiquetarlo como tal de forma legible por máquinas.

Esto es muy relevante para marketing, atención al cliente y comunicación interna, porque muchas empresas usan chatbots en su web, asistentes en LinkedIn o herramientas como ElevenLabs, Synthesia o Sora para producir vídeo. Todo eso necesita disclaimer claro, etiquetado correcto y, en el caso de deepfakes (incluso con fines artísticos o satíricos), una declaración explícita de que el contenido ha sido generado o manipulado artificialmente. No hablamos de sanciones del 7%, pero sí de hasta 15 millones de euros o el 3% del volumen de negocio. No es trivial.

En la práctica, cuando aplicamos el AI Act europeo aplicado a tu empresa en marcas que usan IA generativa para marketing, lo que recomendamos es centralizar una política interna que defina dónde y cómo se etiqueta el contenido sintético, cómo se documenta su trazabilidad y quién es responsable de revisarlo antes de publicarlo. Y, por supuesto, formación obligatoria al equipo de marketing y comunicación para que entienda qué pueden y qué no pueden publicar bajo el nuevo régimen. Estos son los proyectos más rápidos de implementar (4-6 semanas) pero los más visibles, porque tocan la imagen de marca.

¿Qué obligaciones reales tiene el riesgo mínimo?

El riesgo mínimo es la categoría residual: todo lo que no sea prohibido, alto riesgo ni limitado. Aquí entra la inmensa mayoría de los sistemas de IA empresariales: filtros antispam, recomendadores de productos en ecommerce no críticos, optimización de rutas, mantenimiento predictivo en activos no críticos, IA en videojuegos, etc. Para estos sistemas el AI Act no impone obligaciones obligatorias específicas, más allá de los códigos de conducta voluntarios y de las obligaciones generales de transparencia y alfabetización del artículo 4.

Esto no significa “ignorar”. Significa que la organización puede gestionarlos con políticas internas razonables, sin necesidad de la maquinaria pesada de alto riesgo. Pero conviene documentar por qué se han clasificado como mínimo, dejar evidencia del análisis y revisarlo periódicamente, porque un cambio de uso puede subir el riesgo. Por ejemplo, un recomendador de productos pasa a “limitado” si añade un chatbot conversacional, y puede acercarse a “alto riesgo” si se usa para decisiones que afectan a derechos (precios dinámicos discriminatorios, por ejemplo).

Nuestro consejo es muy concreto: incluso para riesgo mínimo, mantener una ficha técnica básica con propietario, finalidad, datos usados, proveedor, fecha de despliegue y revisión anual. Esto cuesta poco y te ahorra muchas explicaciones si un sistema sube de categoría o si la AEPD pregunta. Es el equivalente al inventario de tratamientos del GDPR pero aplicado a IA. De hecho, muchos clientes nuestros han optado por integrar ambos inventarios en una misma herramienta, porque las solapas son enormes.

¿Quién es proveedor y quién es desplegador? La confusión más cara

La distinción entre proveedor y desplegador es probablemente la pieza más malinterpretada del AI Act europeo aplicado a tu empresa, y la que más reescritura contractual nos genera en proyectos reales. Proveedor es quien desarrolla un sistema de IA o un modelo GPAI y lo pone en el mercado o en servicio bajo su nombre o marca, sea gratuito o de pago. Desplegador es quien usa un sistema de IA bajo su autoridad, en el ejercicio de su actividad profesional, sin ponerlo en el mercado bajo su marca. La diferencia parece sutil pero el régimen de obligaciones es radicalmente distinto.

El proveedor de alto riesgo carga con el grueso de la regulación: documentación técnica completa (anexo IV), sistema de gestión de riesgos, gobernanza de datos, supervisión humana, robustez, transparencia, registros, marcado CE, declaración UE de conformidad, registro en la base de datos europea, sistema de gestión de calidad, evaluación de conformidad, vigilancia post-comercialización y reporte de incidentes graves. El desplegador, por su parte, tiene obligaciones más acotadas: usar el sistema conforme a las instrucciones, garantizar supervisión humana adecuada, asegurar pertinencia de los datos de entrada (cuando los aporta), monitorear el funcionamiento, conservar registros, informar a los trabajadores afectados, hacer la evaluación de impacto en derechos fundamentales (FRIA) en los casos del artículo 27 y notificar incidentes graves al proveedor y a la autoridad.

El error caro que vemos repetidamente es este: una empresa toma un modelo de propósito general, lo fine-tunea con datos propios, lo embebe en su producto y lo vende a clientes bajo su marca. Esa empresa ha pasado de desplegador a proveedor a efectos del AI Act, con todas las consecuencias: documentación técnica completa, marcado CE si es alto riesgo, registro UE, etc. Otro error frecuente: integrar una API de un tercero (un OpenAI, un Anthropic) en un flujo crítico y asumir que toda la responsabilidad es del tercero. No: como desplegador sigues teniendo obligaciones propias, sobre todo si tu uso califica como alto riesgo. Las cláusulas de “AI Act compliance” en los contratos con proveedores GPAI son uno de los grandes campos de negociación legal de 2025-2026.

¿Cuándo te conviertes en proveedor sin saberlo?

Hay tres situaciones típicas en las que un desplegador se convierte en proveedor a efectos del AI Act y se lleva un disgusto regulatorio. La primera es poner tu marca sobre un sistema desarrollado por un tercero: si embebes un chatbot de un partner en tu web y lo presentas como “tu” asistente, asumes el rol de proveedor frente al usuario final. La segunda es modificar sustancialmente un sistema de alto riesgo ya puesto en el mercado: si reentrenas el modelo, cambias su finalidad principal o alteras su arquitectura de forma material, te conviertes en proveedor de un “nuevo” sistema. La tercera es cambiar el uso previsto: si coges un sistema diseñado para una finalidad y lo despliegas para otra distinta, especialmente si la nueva finalidad eleva el riesgo, también puedes pasar a ser proveedor.

Esto es crítico para empresas que están construyendo “agentes” o capas verticales sobre modelos generalistas. Si una agencia de marketing construye un agente de generación de contenido sobre la API de Anthropic y lo vende como producto “Brand-X AI”, esa agencia es proveedor a efectos del reglamento. Si la finalidad cae en alto riesgo (poco probable en marketing puro), la documentación exigida es enorme. Si cae en limitado o mínimo, las cargas son razonables pero sigue habiendo obligaciones (transparencia, alfabetización, contratos). En cualquier caso, la conversación con el departamento legal hay que tenerla antes de lanzar el producto, no después.

Otro caso particularmente delicado son los integradores y consultores. Una agencia que despliega un modelo de scoring de candidatos para un cliente puede acabar siendo proveedor en cadena, según cómo se haya configurado el contrato. Por eso en Datalvar AI hemos rediseñado nuestras propias condiciones contractuales: dejar siempre por escrito quién es proveedor y quién es desplegador en cada implementación, y separar claramente lo que es “consultoría” (sin asumir el rol de proveedor) de lo que es “producto” (asumiéndolo). Esto te lo recomendamos hacer ya, no esperar al primer cliente que pregunte por el AI Act.

¿Qué es el sandbox de la AEPD y cómo aprovecharlo?

España fue uno de los primeros países en activar la infraestructura institucional del AI Act. La AEAIA (Agencia Española de Supervisión de la Inteligencia Artificial), con sede en A Coruña, es la autoridad competente para muchos aspectos del reglamento, mientras que la AEPD se encarga de los aspectos vinculados a protección de datos y biometría. Una de las herramientas más útiles que se han creado en este marco es el sandbox regulatorio de IA, que permite probar sistemas innovadores en un entorno controlado, con supervisión y guía de la autoridad, sin asumir el riesgo completo de sanciones inmediatas.

El sandbox no es una “exención” de cumplir el AI Act europeo aplicado a tu empresa: es un espacio donde, durante un periodo limitado, puedes probar un sistema de alto riesgo (o un caso fronterizo) con la autoridad mirando por encima del hombro y dándote feedback. A cambio de aceptar mayor transparencia y reporte, recibes orientación regulatoria y, si surgen incidentes menores durante el periodo de prueba, la sanción se modula. Esto es especialmente útil para sectores como salud, edtech, fintech o RR. HH., donde la innovación y el riesgo regulatorio van de la mano.

Nuestro consejo: si estás desplegando un sistema fronterizo (por ejemplo, un asistente clínico que orienta diagnósticos, o una herramienta de cribado de currículums con IA generativa), valora seriamente entrar al sandbox antes que ir solo. La inversión de tiempo en preparar la candidatura es alta (entre 3 y 6 meses de trabajo previo) pero la red de seguridad regulatoria es considerable, y además te conviertes en interlocutor cualificado con la autoridad. Para los detalles operativos, consulta directamente la web institucional de la AEPD y de la AESIA, donde se publican las convocatorias y los criterios de admisión.

¿Qué sanciones reales tiene el AI Act europeo aplicado a tu empresa?

Las sanciones del AI Act están diseñadas para que duelan de verdad, especialmente a las grandes corporaciones, pero también para que las pymes no las puedan ignorar. Hay tres tramos. El primero, hasta 35 millones de euros o el 7% de la facturación anual mundial (lo que sea mayor), se aplica al incumplimiento de las prácticas prohibidas del artículo 5. Es decir, si tu organización utiliza social scoring privado masivo, reconocimiento de emociones en el trabajo o categorización biométrica para inferir datos sensibles, la multa puede alcanzar ese tope. Es el tramo más alto de todo el derecho regulatorio europeo, por encima del GDPR (4% de facturación) y del DMA (10% pero solo para gatekeepers).

El segundo tramo, hasta 15 millones de euros o el 3% de la facturación, se aplica al incumplimiento de obligaciones de alto riesgo, GPAI, transparencia y otras obligaciones sustantivas. Esto es lo que afectaría a la mayoría de las empresas con sistemas de scoring, selección, seguros o crédito que no cumplan la documentación técnica, la supervisión humana, la gobernanza de datos o el marcado CE. El tercer tramo, hasta 7,5 millones o el 1% de facturación, se aplica al suministro de información incorrecta, incompleta o engañosa a las autoridades. Para pymes y startups se establece que se aplicará el importe menor de los dos topes (el porcentaje o el absoluto), lo que da algo de proporcionalidad pero no elimina el riesgo.

Más allá de la multa monetaria, las consecuencias indirectas son igual o más graves. Una sanción pública por incumplimiento del AI Act erosiona la confianza de clientes y partners, complica la firma de contratos públicos (donde la diligencia debida en IA será cada vez más exigente), abre la puerta a litigios civiles por daños y, en sectores regulados, puede provocar la retirada de licencias o autorizaciones. Por eso el AI Act europeo aplicado a tu empresa no se gestiona como un riesgo financiero aislado: se integra en el mapa de riesgos corporativo, junto con ciberseguridad, GDPR y ESG, porque las tres disciplinas se solapan cada vez más.

!IMAGE_TODO[Tabla visual con los tres tramos de sanciones del AI Act europeo aplicado a tu empresa: 35M/7% por prácticas prohibidas, 15M/3% por alto riesgo y GPAI, 7,5M/1% por información incorrecta, con ejemplos de infracción en cada tramo]

El AI Act y el GDPR son dos reglamentos complementarios, no sustitutivos. El GDPR regula el tratamiento de datos personales (qué datos puedes usar, con qué base jurídica, con qué garantías), mientras que el AI Act regula los sistemas de IA y su ciclo de vida (cómo se diseñan, entrenan, despliegan y supervisan). En la práctica, cualquier sistema de IA que use datos personales (que es casi siempre) tiene que cumplir los dos a la vez. Y cuando los dos chocan, en general prevalece la protección más garantista, que suele ser la del GDPR para datos personales y la del AI Act para arquitectura del sistema.

Las solapas son enormes y bien gestionadas pueden ahorrar mucho trabajo. La gobernanza de datos del AI Act (artículo 10) bebe directamente de los principios del GDPR (minimización, exactitud, finalidad). La documentación técnica del AI Act (anexo IV) se solapa con el registro de actividades del GDPR (artículo 30). La evaluación de impacto en derechos fundamentales (FRIA) del AI Act se solapa con la evaluación de impacto en protección de datos (DPIA) del GDPR, hasta el punto de que ambas pueden hacerse en un solo documento integrado, como recomienda el European Data Protection Board. La supervisión humana del AI Act se relaciona con el artículo 22 del GDPR sobre decisiones automatizadas, etc.

Lo que recomendamos a nuestros clientes es unificar la función de gobernanza de IA y datos en una sola figura organizativa (o un comité mixto) en el que participen DPO, CISO, responsable de IA, legal y un sponsor de negocio. Crear procesos paralelos para AI Act y GDPR duplica costes y crea fricciones absurdas. Integrar inventarios, evaluaciones de impacto, documentación técnica y procesos de respuesta a incidentes en una sola arquitectura de gobernanza reduce un 30-40% el coste de cumplimiento (lo hemos medido en clientes con más de 50 sistemas de IA inventariados) y, sobre todo, hace que la organización tenga una sola fuente de verdad para auditores, clientes y autoridades.

El AI Act y el GDPR no son dos burocracias paralelas: son dos capas de la misma arquitectura de confianza. Quien los gestione por separado pagará dos veces.

¿Qué documentación técnica obligatoria exige el AI Act para alto riesgo?

La documentación técnica del anexo IV es el pilar operativo del cumplimiento de alto riesgo, y honestamente es donde más equipos se asustan. El reglamento exige que el proveedor mantenga, antes de poner el sistema en el mercado y durante toda su vida útil, un dossier técnico que permita a las autoridades evaluar la conformidad. La estructura tiene nueve secciones: descripción general del sistema, descripción detallada de los elementos, información sobre vigilancia, datos sobre el funcionamiento, sistema de gestión de riesgos, descripción de cambios, lista de normas armonizadas aplicadas, declaración UE de conformidad y descripción del sistema post-comercialización.

En la práctica, esto significa construir y mantener vivo un repositorio documental que incluya: arquitectura del sistema (datos de entrada, modelo, salidas, decisiones), datasets de entrenamiento y validación con su gobernanza (procedencia, anotación, limpieza, sesgos detectados y mitigados), métricas de precisión, robustez y ciberseguridad, plan de supervisión humana, registro automático de eventos (logging), procedimientos de cambio (versioning de modelos), evaluación de conformidad y plan de vigilancia post-mercado con criterios para retirar o actualizar el sistema. Todo ello en un formato accesible para auditores y, en su caso, traducible al idioma del Estado miembro donde se comercialice.

Para desplegadores, la documentación es menos exhaustiva pero igualmente formal. Hay que conservar los logs generados por el sistema, documentar la supervisión humana realizada, registrar los datos de entrada (cuando los aporte el desplegador), mantener actualizada la FRIA, comunicar a los trabajadores y representantes sindicales cuando aplique e informar a las personas afectadas de que un sistema de IA está siendo utilizado para tomar decisiones que les afectan. Aquí la herramienta práctica es montar plantillas estándar y workflows recurrentes (mensuales o trimestrales) para que el cumplimiento no dependa de la buena memoria de una persona. En proyectos reales solemos arrancar con una “carpeta tipo” en Notion o Confluence, con plantillas pre-rellenadas y owners asignados, y a partir de ahí el equipo la mantiene viva.

El checklist práctico de 20 puntos para aplicar el AI Act europeo aplicado a tu empresa

Este es el checklist que usamos en Datalvar AI cuando entramos en una organización a hacer la primera adecuación al AI Act europeo aplicado a tu empresa. No es exhaustivo, no sustituye al texto legal y no cubre todas las casuísticas sectoriales, pero cubre el 80% del camino para una empresa media española. Lo dividimos en cinco bloques: gobernanza, inventario y clasificación, sistemas prohibidos y de alto riesgo, transparencia y operación. Cada punto tiene un owner natural, un entregable y un plazo recomendado.

Bloque 1 — Gobernanza y responsabilidades (puntos 1 a 4)

Punto 1. Nombrar un responsable de cumplimiento del AI Act europeo aplicado a tu empresa. Puede ser el DPO ampliado, un compliance officer, un CTO con apoyo legal o un comité mixto, pero tiene que existir una figura formal con autoridad, presupuesto y línea directa con dirección. Sin owner, el proyecto se diluye. Documentar el nombramiento por escrito, con funciones, recursos y reporte trimestral al consejo o comité de dirección.

Punto 2. Crear un comité de gobernanza de IA. Incluye al responsable del punto 1, a legal/DPO, a CISO, a responsable de RR. HH. (clave para sistemas de empleo), a un representante de negocio y, si aplica, a un experto técnico externo. Reunión mensual los primeros 12 meses, trimestral después. Actas formales con decisiones y revisión de incidentes.

Punto 3. Cumplir el artículo 4 (alfabetización en IA). Diseñar y desplegar un programa de formación obligatoria para todo el personal que interactúe con sistemas de IA. Niveles diferenciados: básico (toda la plantilla), avanzado (equipos de producto, datos, RR. HH., marketing, legal) y especializado (responsables y owners de sistemas). Documentar asistencia y evaluaciones. La AEPD ya ha avisado de que la falta de alfabetización es uno de los primeros indicadores que mira.

Punto 4. Política interna de IA aprobada por dirección. Documento corto (10-15 páginas) que defina principios, roles, procesos de aprobación de nuevos sistemas, criterios de clasificación de riesgo, ciclo de vida documental, protocolo de incidentes y vínculo con el resto de políticas (GDPR, ciberseguridad, ética). Firmada por el primer ejecutivo y comunicada a toda la organización.

Bloque 2 — Inventario y clasificación (puntos 5 a 8)

Punto 5. Inventario completo de sistemas de IA en uso. Un Excel, una herramienta GRC o un módulo de Notion donde figuren todos los sistemas: nombre, finalidad, proveedor, equipo desplegador, datos usados, fecha de despliegue, contrato vinculado. Importante: incluir también las herramientas “informales” (extensiones de IA en navegadores, ChatGPT usado individualmente, copilots) porque también forman parte del perímetro. En proyectos reales el inventario inicial suele tener entre 12 y 50 sistemas que la dirección desconocía.

Punto 6. Clasificación por nivel de riesgo de cada sistema inventariado. Aplicar el algoritmo: ¿es prohibido por artículo 5? ¿es alto riesgo por anexo III o anexo I? ¿requiere obligaciones de transparencia? ¿es mínimo? Documentar la justificación de cada clasificación y revisarla anualmente o cuando cambie el uso. Aquí es donde más valor aporta tener criterio externo, porque las dudas son muchas y las equivocaciones se pagan caro.

Punto 7. Identificación del rol (proveedor / desplegador / importador / distribuidor) para cada sistema. No es trivial: un mismo sistema puede tener roles distintos en distintos contextos. Documentar y, si la organización es proveedor, activar el paquete completo de obligaciones (documentación técnica, marcado CE si aplica, registro UE). Si es desplegador, activar el paquete acotado (uso conforme, supervisión, FRIA si aplica).

Punto 8. Mapa de cadena de suministro. Para cada sistema, identificar al proveedor (y, en su caso, al proveedor del modelo GPAI subyacente). Revisar contratos, condiciones de uso, tarjetas de modelo, política de derechos de autor del proveedor, cumplimiento GPAI. Renegociar cláusulas si es necesario: hoy ya no se debe firmar un contrato SaaS de IA sin cláusulas específicas de AI Act, transmisión de obligaciones y régimen de incidentes.

Bloque 3 — Sistemas prohibidos y de alto riesgo (puntos 9 a 14)

Punto 9. Eliminación inmediata de cualquier sistema prohibido. Si tras el inventario y clasificación aparece algún caso de uso del artículo 5 (reconocimiento de emociones en trabajo, social scoring privado, categorización biométrica sensible, etc.), parar de inmediato y documentar la baja. Si hay duda razonable, suspender precautoriamente hasta dictamen legal. Las sanciones por este punto son las más altas del reglamento.

Punto 10. Sistema de gestión de riesgos para cada sistema de alto riesgo. Documento vivo que identifique riesgos previstos (precisión, sesgo, ciberseguridad, mal uso), mitigaciones implementadas, riesgos residuales aceptados y revisión periódica. Estructura tipo ISO 31000 adaptada. Owner técnico claro, revisión trimestral.

Punto 11. Gobernanza de datos de entrenamiento, validación y prueba. Para sistemas de alto riesgo, documentar procedencia de los datos, criterios de relevancia y representatividad, errores conocidos, sesgos detectados y medidas tomadas, así como categorías de personas afectadas. Especial atención a datos personales (vínculo con GDPR) y a posibles sesgos por género, edad, origen o discapacidad.

Punto 12. Supervisión humana documentada. Para cada sistema de alto riesgo definir: quién supervisa, con qué frecuencia, con qué autoridad para detener o revertir decisiones, qué métricas mira, cómo se forma esa persona y cómo se documenta su intervención. Sin supervisión humana real, el sistema no cumple. No vale poner “el responsable supervisa”: hay que demostrarlo con logs y procedimientos.

Punto 13. Documentación técnica del anexo IV (proveedores) o documentación de uso (desplegadores). Construir el dossier técnico siguiendo la estructura del anexo IV si eres proveedor, o un dossier simplificado si eres desplegador. Repositorio único, accesible, versionado. En desplegadores, exigir al proveedor que comparta su documentación técnica relevante: es derecho contractual del desplegador.

Punto 14. Evaluación de impacto en derechos fundamentales (FRIA). Obligatoria para desplegadores de sistemas de alto riesgo en los casos del artículo 27 (entidades de derecho público, prestadores de servicios públicos privatizados, scoring crediticio, seguros de vida y salud). Plantilla integrable con la DPIA del GDPR. Conservar copia y mantener actualizada.

Bloque 4 — Transparencia y derechos (puntos 15 a 17)

Punto 15. Etiquetado de contenido sintético y disclaimer en chatbots. Para sistemas de riesgo limitado (chatbots, generadores de imagen/vídeo, asistentes de voz), implementar etiquetado legible y, en el caso de contenido sintético, marca de agua o metadatos que permitan a sistemas automáticos identificar el contenido como generado por IA. Política interna que defina dónde y cómo se aplica.

Punto 16. Comunicación a personas afectadas y a trabajadores. Cuando un sistema de IA toma o influye en decisiones que afectan a personas (clientes, candidatos, empleados, ciudadanos), informarles de forma clara y comprensible. En el caso de trabajadores, además, informar a sus representantes sindicales antes del despliegue. Esto es derecho laboral, no solo AI Act.

Punto 17. Procedimiento para gestionar derechos individuales. Habilitar canal y proceso para que las personas afectadas puedan solicitar explicación de decisiones automatizadas (cruce con el artículo 22 GDPR), reclamar contra clasificaciones erróneas y, en su caso, pedir revisión humana. Plazos, owners y respuestas estandarizadas.

Bloque 5 — Operación, vigilancia y mejora continua (puntos 18 a 20)

Punto 18. Registro automático de eventos (logging) y trazabilidad. Para sistemas de alto riesgo, configurar el logging automático de decisiones, inputs, outputs y eventos relevantes durante toda la vida útil. Política de retención coherente con GDPR y con necesidades de auditoría. Acceso controlado y trazable.

Punto 19. Plan de vigilancia post-mercado e incidentes. Procedimiento para monitorizar el funcionamiento real del sistema, detectar desviaciones (drift, errores, sesgos emergentes), responder a incidentes graves (definidos en el artículo 3) y notificar a proveedor y autoridad cuando proceda. SLA internos claros: 72 horas para incidentes graves, igual que en GDPR.

Punto 20. Auditoría anual de cumplimiento. Revisión independiente (interna o externa) del estado de cumplimiento del AI Act europeo aplicado a tu empresa: vigencia del inventario, clasificaciones, documentación, formación, incidentes. Informe al comité de gobernanza y al consejo. Plan de acción para los hallazgos. Esta es la herramienta que mantiene viva la arquitectura: sin auditoría anual, la deuda se acumula sin que nadie la vea hasta que llega la inspección.

¿Cuánto cuesta de verdad implementar el AI Act europeo aplicado a tu empresa?

La pregunta que más nos hace la dirección financiera. La respuesta honesta: depende del tamaño, sector y número de sistemas de IA en uso, pero podemos dar rangos basados en proyectos reales. Para una pyme española (50-250 empleados) con 5-15 sistemas de IA en uso, sin sistemas prohibidos y con la mayoría en riesgo mínimo o limitado, el coste de adecuación inicial ronda los 25.000-60.000 euros (proyecto de 4-6 meses) y el coste recurrente anual de mantenimiento (formación, auditoría, actualizaciones documentales) ronda los 12.000-25.000 euros. Esto incluye consultoría externa, formación, herramientas y horas internas.

Para una empresa mediana (250-1.000 empleados) con sistemas de alto riesgo (por ejemplo, en RR. HH., crédito o seguros), el rango sube a 80.000-250.000 euros de adecuación inicial y 40.000-100.000 euros anuales de mantenimiento. Para grandes corporaciones con múltiples sistemas de alto riesgo, modelos propios y operación multinacional, los proyectos plurianuales pueden superar el millón de euros. Estos números asustan, pero hay que compararlos con el coste de no cumplir: una sanción mínima del 1% de facturación, en una empresa de 50 millones, son 500.000 euros, sin contar daños reputacionales y litigios.

Donde sí hay mucha oportunidad de optimizar es en integrar el AI Act europeo aplicado a tu empresa con el GDPR y la ciberseguridad. Si la organización ya tiene un buen sistema GDPR (DPO, registro de actividades, DPIAs, procedimientos de incidentes) y un ISO 27001 razonable, el coste marginal del AI Act baja entre un 30% y un 50%. Si parte de cero en gobernanza, hay que hacer la inversión completa, y el AI Act es solo una capa más. Por eso nuestra recomendación a clientes que vienen débiles en cumplimiento general es no ver el AI Act como un proyecto aislado, sino como la ocasión para construir una arquitectura de gobernanza moderna que les sirva también para futuras regulaciones (Data Act, Digital Services Act, NIS2, etc.).

¿Qué errores recurrentes vemos en empresas que abordan mal el AI Act europeo aplicado a tu empresa?

Después de docenas de proyectos, los errores son sorprendentemente repetitivos. El primero, y el más caro, es delegar el AI Act exclusivamente en legal. El reglamento es jurídico en su forma pero técnico-operativo en su fondo: si el departamento legal no tiene contraparte en ingeniería, datos y producto, los documentos que produce no se aterrizan, las clasificaciones son erróneas y los controles no se implementan. La gobernanza de IA es función transversal por naturaleza, y debe estructurarse así desde el día uno.

El segundo error es confundir cumplimiento con burocracia. He visto organizaciones generar cien páginas de políticas que nadie lee, mientras el equipo de RR. HH. sigue usando una herramienta de scoring de candidatos sin supervisión humana real. Cumplir el AI Act no es generar papel; es operar de forma que el papel refleje la realidad. Cada control documentado tiene que estar realmente implementado y, sobre todo, ser ejecutado en el día a día. Las inspecciones que vienen no se ganarán enseñando una carpeta llena de PDFs, sino mostrando logs reales de supervisión humana, decisiones registradas y formación efectivamente impartida.

El tercer error es no contar con el equipo de producto y datos en las decisiones de diseño. Muchas obligaciones del AI Act (gobernanza de datos, supervisión humana, robustez, ciberseguridad) son mucho más baratas si se incorporan en el diseño del sistema desde el principio. Añadirlas a posteriori cuesta entre 3 y 10 veces más, según nuestros datos internos. Por eso recomendamos integrar checkpoints de AI Act en el ciclo de desarrollo (mismo concepto que “privacy by design” del GDPR): revisión obligatoria en concepto, diseño, predespliegue y postlanzamiento. El equipo de producto se quejará al principio; lo agradecerá a los seis meses.

El cuarto error, contrarian respecto a lo que cuentan muchos consultores, es sobre-clasificar todo como “alto riesgo” por exceso de prudencia. La carga documental del alto riesgo es enorme y aplicarla a sistemas que no lo son drena recursos sin mejorar la postura de riesgo. Hay que clasificar bien, con criterio y con justificación documentada, y no caer en la tentación defensiva de tratar todo como crítico. Las autoridades valoran más una clasificación argumentada (aunque sea agresiva) que una sobrecarga improvisada para “curarse en salud”.

¿Cómo organizamos el calendario realista de adecuación al AI Act europeo aplicado a tu empresa?

Para una empresa que arranca hoy (junio de 2026) y que aún no ha hecho la adecuación, el calendario realista es de 12 a 18 meses para tener una postura razonable. Lo dividimos en cuatro fases. Fase 1 (mes 1 a 2): gobernanza, nombramientos, comité, política interna y arranque del inventario. Es la fase política: hay que conseguir el sponsorship del comité de dirección y el presupuesto. Sin esto, el resto no avanza.

Fase 2 (mes 2 a 5): inventario completo, clasificación, identificación de roles, mapa de cadena de suministro y eliminación de sistemas prohibidos. Es la fase de diagnóstico: salir con una foto clara de qué tiene la empresa, dónde está cada sistema, qué riesgo tiene cada uno y qué obligaciones aplican. Esta fase es la que más sorpresas trae: aparecen sistemas desconocidos, contratos sin cláusulas adecuadas y proveedores sin tarjetas de modelo.

Fase 3 (mes 5 a 10): construcción documental para alto riesgo (sistema de gestión de riesgos, gobernanza de datos, supervisión humana, documentación técnica, FRIA), implementación de transparencia para riesgo limitado (etiquetado, disclaimers, comunicación), formación a la plantilla y renegociación de contratos críticos con proveedores. Es la fase pesada: la mayor parte del esfuerzo y del presupuesto se consume aquí.

Fase 4 (mes 10 a 15): operación, logging, vigilancia post-mercado, auditoría interna y ajuste fino. Es la fase de madurez: la empresa pasa del “proyecto” al “operación continua”. Si la fase 4 no se diseña bien, la organización se relaja y la deuda regulatoria empieza a acumularse de nuevo. La auditoría anual del punto 20 del checklist es la herramienta que mantiene viva la arquitectura. Para los proyectos de cliente, en Datalvar AI insistimos en cerrar con un dashboard de KPIs de cumplimiento (sistemas inventariados, clasificados, documentados, formación impartida, incidentes detectados, FRIA actualizadas) que se reporta trimestralmente al comité de dirección. Sin métricas, no hay gestión.

En cumplimiento de IA no gana quien tiene más papel, sino quien tiene más realidad alineada con el papel que firmó.

Preguntas frecuentes

¿El AI Act europeo aplicado a tu empresa también afecta si soy una pyme de menos de 50 empleados?

Sí, plenamente. El AI Act no establece exenciones generales por tamaño de empresa: las obligaciones se aplican en función del riesgo del sistema, no del tamaño del desplegador o proveedor. Lo que sí incluye el reglamento son medidas específicas de apoyo a pymes y startups, como acceso preferente a los sandboxes regulatorios, plantillas simplificadas para algunos elementos documentales y, en cuanto a sanciones, la regla de que se aplica el importe menor entre el tope absoluto y el porcentaje sobre facturación. Esto da algo de aire económico pero no elimina la obligación.

En la práctica, lo que recomendamos a las pymes es priorizar agresivamente. No tiene sentido montar la arquitectura completa de una corporación. Se trata de hacer bien el inventario, clasificar con criterio, eliminar prohibidos, cumplir transparencia para chatbots y contenido sintético, formar al equipo y, si hay sistemas de alto riesgo, montar la documentación esencial sin barroquismos. Un proyecto pyme bien hecho puede salir adelante con 25.000-60.000 euros en 4-6 meses, y luego un mantenimiento ligero. Lo que no es aceptable es ignorar el reglamento por considerarse “demasiado pequeño”: las autoridades han avisado de que las inspecciones empezarán por sectores sensibles (RR. HH., crédito, salud, edtech) sin importar el tamaño.

¿Qué pasa si uso ChatGPT, Claude, Gemini o Copilot en mi empresa?

Usar modelos GPAI de proveedores como OpenAI, Anthropic, Google o Microsoft te convierte, casi siempre, en desplegador a efectos del AI Act europeo aplicado a tu empresa. El proveedor del modelo cumple sus propias obligaciones GPAI (documentación técnica, cumplimiento de derechos de autor, resumen de datos de entrenamiento, evaluación de riesgos sistémicos para los modelos más grandes), pero tú, como desplegador, tienes obligaciones propias: usar el sistema dentro de su finalidad prevista, supervisión humana adecuada, etiquetado de contenido sintético cuando aplique y, si tu uso califica como alto riesgo (por ejemplo, integrar GPT para evaluar candidatos en un proceso de selección), todas las obligaciones de desplegador de alto riesgo.

Lo que más vemos en la práctica es uso “informal” no controlado: empleados que usan ChatGPT individual, copilots en navegadores, extensiones, etc. Esto crea un perímetro de riesgo enorme, sobre todo en términos de fuga de información, ya que muchos planes gratuitos o personales no garantizan que los datos introducidos no se usen para entrenar futuros modelos. La política interna debería establecer qué herramientas están aprobadas, con qué planes (empresariales con cláusulas adecuadas), para qué tipo de datos y con qué procesos de revisión. Y, por supuesto, formar al equipo (artículo 4) para que sepa qué puede y qué no puede meter en estos sistemas.

La FRIA y la DPIA son evaluaciones distintas pero claramente complementarias. La DPIA se centra en los riesgos para los derechos y libertades de los interesados en relación con el tratamiento de datos personales (artículo 35 GDPR), mientras que la FRIA del AI Act (artículo 27) se centra en los riesgos para los derechos fundamentales que pueda generar el uso de un sistema de IA de alto riesgo por un desplegador, incluyendo aspectos que van más allá de la protección de datos: discriminación, libertad de expresión, dignidad, acceso a servicios esenciales, etc.

En la práctica, recomendamos integrar ambas evaluaciones en un único documento estructurado por capas: una primera capa común (descripción del sistema, finalidad, contexto, datos, decisiones), una capa específica de protección de datos (DPIA) y una capa específica de derechos fundamentales (FRIA). Esto evita duplicación, asegura coherencia y facilita la revisión por DPO y por el comité de gobernanza de IA. Las plantillas que estamos viendo emerger en el mercado europeo, especialmente las publicadas por la EDPB y por algunas autoridades nacionales, ya van en esta dirección integrada.

¿Qué obligaciones específicas tienen los modelos GPAI desde agosto de 2025?

Los proveedores de modelos GPAI (incluidos los modelos de lenguaje grandes como GPT, Claude, Gemini, Llama, Mistral, etc.) tienen desde el 2 de agosto de 2025 obligaciones específicas que recoge el capítulo V del AI Act. Las obligaciones generales incluyen: mantener documentación técnica actualizada del modelo (entrenamiento, evaluación, capacidades, limitaciones), facilitar información a proveedores que integren el modelo en sistemas downstream, establecer una política para cumplir con los derechos de autor y publicar un resumen suficientemente detallado del contenido usado para el entrenamiento del modelo.

Los modelos GPAI con riesgo sistémico (definidos por umbrales de cómputo, capacidades o impacto, y designados por la Comisión) tienen obligaciones adicionales: evaluación del modelo conforme a protocolos estandarizados, evaluación y mitigación de riesgos sistémicos a nivel UE, tracking y notificación a la AI Office de incidentes graves, garantía de un nivel adecuado de protección en ciberseguridad. Para desplegadores, lo importante es revisar las tarjetas de modelo, los términos contractuales y la documentación pública de los proveedores GPAI antes de integrarlos en sistemas críticos, y exigir que el proveedor declare conformidad con el AI Act como cláusula contractual estándar.

¿Es obligatorio el marcado CE para sistemas de IA de alto riesgo?

Sí. Los sistemas de IA de alto riesgo deben llevar marcado CE, igual que el resto de productos regulados que circulan en el mercado único europeo. El marcado CE indica que el sistema ha pasado por el procedimiento de evaluación de conformidad correspondiente y cumple con todas las obligaciones del AI Act europeo aplicado a tu empresa. La responsabilidad recae sobre el proveedor (no sobre el desplegador), pero el desplegador debe verificar que el sistema cuenta con el marcado antes de utilizarlo, especialmente en sistemas adquiridos a terceros.

Para sistemas de alto riesgo del anexo I (componentes de seguridad de productos ya regulados, como dispositivos médicos), el procedimiento de evaluación de conformidad se integra con el del marco sectorial existente. Para sistemas del anexo III, el procedimiento es el del propio AI Act, que en muchos casos permite la autoevaluación de conformidad por el proveedor (siempre con la documentación técnica del anexo IV), salvo en algunos casos específicos donde se exige intervención de organismo notificado. Además, los sistemas de alto riesgo del anexo III deben registrarse en la base de datos europea de sistemas de IA antes de su puesta en el mercado.

¿Qué pasa con los sistemas de IA que ya están en producción antes de las fechas de aplicación?

El AI Act incluye disposiciones transitorias específicas. Para los sistemas de IA que ya estaban en uso antes de las fechas correspondientes de aplicación, hay distintos regímenes según el tipo. Los sistemas de IA de alto riesgo puestos en el mercado o en servicio antes del 2 de agosto de 2026 solo deben adaptarse al reglamento si sufren cambios significativos en su diseño después de esa fecha. Para los sistemas utilizados por autoridades públicas, sin embargo, deben adaptarse a más tardar el 2 de agosto de 2030, incluso sin cambios.

Los modelos GPAI que ya estaban en el mercado antes del 2 de agosto de 2025 tienen plazo hasta el 2 de agosto de 2027 para alcanzar plena conformidad. Esto explica las actualizaciones que los grandes proveedores GPAI han ido publicando durante 2025 y 2026: están en plena fase de adecuación. Como desplegador, hay que tener en cuenta estas excepciones transitorias al hacer el inventario: un sistema en producción puede tener un régimen distinto al que tendría si se desplegara hoy desde cero. Pero ojo: la transitoriedad no es excusa para no inventariar, clasificar y supervisar. La obligación de saber qué tienes y cómo lo usas es desde ya.

¿Quién supervisa el cumplimiento en España y cómo serán las inspecciones?

En España, la supervisión del AI Act está distribuida principalmente entre la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial), con sede en A Coruña, como autoridad nacional competente para la mayoría de aspectos del reglamento, y la AEPD para los aspectos vinculados a protección de datos y biometría. Adicionalmente, las autoridades sectoriales (Banco de España, CNMV, CNMC, etc.) conservan competencias en sus respectivos ámbitos cuando los sistemas de IA caen dentro de su perímetro regulatorio.

Las inspecciones se espera que sigan un patrón mixto: por iniciativa de la autoridad (focalizadas en sectores prioritarios como RR. HH., crédito, seguros, salud y edtech), por denuncias de afectados (trabajadores, candidatos, clientes) y por reclamaciones cruzadas con otras autoridades (por ejemplo, AEPD detectando un caso de IA al investigar una brecha GDPR). El proceso será similar al ya conocido por GDPR: requerimiento de información, plazo de respuesta, inspección presencial si aplica, propuesta de resolución y eventual sanción. El proyecto de cumplimiento del AI Act debe diseñarse pensando en que cualquier día puede llegar un requerimiento, y todo lo que esté documentado y operativo se podrá demostrar; lo que no, no.