Ir al contenido
Volver al Blog
Guía

La EU AI Act para pymes: lo que realmente tiene que hacer antes de agosto de 2026

La fecha límite del sistema de alto riesgo de la EU AI Act es el 2 de agosto de 2026. La mayoría de pymes han oído el término y no tienen idea de qué les aplica realmente. Esta guía corta a través del pánico y la complacencia.

12 min de lectura

Las cuatro categorías de riesgo y cuáles realmente tocan su automatización de procesos

La EU AI Act clasifica cada sistema de IA en una de cuatro cubetas de riesgo, y la carga de compliance es estrictamente proporcional a la cubeta. La mayoría de pymes se preocupan por la cubeta equivocada, lo que desperdicia presupuesto legal en riesgos que no tienen y deja exposición real sin tratar. Antes de gastar un euro en compliance, sepa en qué cubeta está.

Las cuatro categorías son riesgo inaceptable, alto riesgo, riesgo limitado y riesgo mínimo. Los sistemas de riesgo inaceptable están prohibidos directamente: social scoring por autoridades públicas, ciertas aplicaciones de predictive policing, reconocimiento de emociones en el trabajo o la escuela, scraping sin targeting de imágenes faciales para bases de datos biométricas. Si está leyendo esto porque dirige una firma de logística de 150 personas o una consulta legal de 40 personas, no está construyendo nada de esto. Puede saltarse esta categoría.

El alto riesgo es donde los operadores pyme quedan atrapados

Los sistemas de alto riesgo llevan las obligaciones más pesadas: documentación, gestión de riesgos, supervisión humana, transparencia, gobernanza de datos, pruebas de precisión y robustez, registro en la base de datos de la UE. La categoría incluye IA usada en decisiones de empleo (contratación, despido, scoring de desempeño), acceso a servicios esenciales (crédito, seguro, beneficios públicos), evaluación educativa, aplicación de la ley e infraestructura crítica. También incluye cualquier sistema de IA que funcione como un componente de seguridad de un producto regulado: dispositivos médicos, juguetes, maquinaria, vehículos.

La mayoría de la automatización de procesos se sitúa en la categoría de riesgo limitado o mínimo, pero los casos límite importan. Una herramienta de IA que filtra CVs es de alto riesgo. Una herramienta de IA que redacta respuestas a quejas de clientes es de riesgo limitado. Una herramienta de IA que resume notas internas de reuniones es de riesgo mínimo. El mismo proveedor puede producir sistemas en tres cubetas distintas.

  • El riesgo limitado cubre sistemas que interactúan con humanos, generan contenido sintético, o usan reconocimiento de emociones en contextos no regulados. Obligación: transparencia (decirle al usuario que está interactuando con IA).
  • El riesgo mínimo cubre todo lo demás: filtros de spam, motores de recomendación, forecast de inventario, la mayoría de la automatización de back-office. Obligación: ninguna, más allá de códigos de conducta voluntarios.

Qué dispara la clasificación de alto riesgo, y qué no a pesar del rumor

La lista de disparadores de alto riesgo en el Annex III del Act es específica y limitada. No es una sensación general. Proveedores y consultores han estado vendiendo pánico dando a entender que cualquier uso serio de IA es de alto riesgo. No lo es. La categoría está enumerada, y si su caso de uso no está en la lista o no funciona como componente de seguridad de un producto regulado, no es de alto riesgo.

El Annex III cubre ocho áreas enumeradas: identificación biométrica, infraestructura crítica, educación y formación, empleo y gestión de trabajadores, acceso a servicios esenciales, aplicación de la ley, migración y control de fronteras, y administración de justicia. Los sectores son específicos y los casos de uso dentro de cada sector están aún más delimitados. La IA que recomienda un curso de formación a un empleado está dentro del alcance. La IA que proyecta la necesidad de contratación del próximo trimestre a nivel de departamento no lo está.

El rumor que hace tropezar a las pymes

Una mala lectura común: «usamos IA en RR. HH., así que somos de alto riesgo». No automáticamente. Los casos de uso de RR. HH. que son de alto riesgo bajo el Act son los que afectan directamente contratación, despido, promoción, asignación de tareas o monitoreo de desempeño de individuos. Un chatbot que responde preguntas de empleados sobre la política de vacaciones no está dentro del alcance. Una herramienta que resume entrevistas a candidatos para el reclutador no está automáticamente dentro del alcance, dependiendo de si el resumen funciona como input de decisión. Una herramienta que puntúa y ranquea candidatos sí está dentro del alcance.

El segundo rumor: «si procesamos datos personales con IA, somos de alto riesgo bajo el AI Act». No. Eso es GDPR. El AI Act se superpone al GDPR, no lo reemplaza. Un sistema puede ser relevante para GDPR y de riesgo mínimo bajo el AI Act, o al revés. Trátelos como dos regímenes paralelos.

Los seis documentos que debe producir si despliega un sistema de alto riesgo

Si concluyó que el sistema es de alto riesgo, el conjunto de obligaciones es concreto y documentable. Seis artefactos cubren la mayoría de lo que un regulador o auditor pedirá. Ninguno de ellos requiere un consultor especialista si el sistema se entiende bien internamente.

1. Documentación del sistema de gestión de riesgos

Una descripción escrita de los riesgos que el sistema plantea a la salud, seguridad y derechos fundamentales. Las mitigaciones en vigor. El riesgo residual después de la mitigación. La cadencia de revisión. Para una empresa de 200 personas, esto es un documento de cinco a diez páginas, no un tratado de noventa.

2. Gobernanza de datos y documentación de datos de entrenamiento

Con qué datos se entrenó el sistema (si lo construyó), o sobre qué datos opera (si lo despliega). Verificaciones de calidad de datos. Resultados de pruebas de sesgo. Manejo de categorías especiales de datos. Si es deployer de un sistema de tercero, esto es principalmente trabajo del proveedor, pero usted documenta lo que el proveedor le dijo.

3. Documentación técnica

Cómo funciona el sistema a un nivel suficiente para que un regulador pueda evaluar el compliance. Arquitectura, propósito previsto, métricas de precisión, limitaciones. De nuevo, si es deployer, el provider suministra la mayor parte de esto y usted conserva una copia.

4. Logs

Logging automático de la operación del sistema, retenido durante al menos seis meses (o más en algunos sectores). Esto es una capacidad de plataforma, no un documento que escriba. Confirme que su proveedor lo provee o constrúyalo internamente si despliega in-house.

5. Transparencia e instrucciones de uso

Si es provider, suministra instrucciones a los deployers. Si usted es deployer, debe documentar cómo se usa realmente el sistema en su contexto y asegurarse de que los individuos afectados estén informados donde se requiera.

6. Arreglos de supervisión humana

Quién supervisa el sistema. Qué están entrenados para hacer. Cuándo intervienen. Cómo pueden anular outputs. Para la mayoría de despliegues pymes, esto es un humano nombrado con un proceso escrito, no un equipo de revisores.

Transparencia y supervisión humana en usos de riesgo limitado

La mayoría de despliegues de IA en pymes aterrizan en riesgo limitado, y las obligaciones ahí son modestas pero reales. Ignorarlas crea una exposición que es fácilmente demostrable en una auditoría. El deber núcleo es transparencia: el usuario debe saber que está interactuando con IA, y el contenido generado por IA debe etiquetarse donde el usuario sería engañado de lo contrario.

En la práctica, esto significa tomar medidas concretas. Si su operación de atención al cliente utiliza un chatbot de IA, el chatbot debe indicar claramente que es una IA. Si usted utiliza IA para generar descripciones de productos y estas se presentan al consumidor final, debe etiquetarlas como generadas por IA. Si emplea IA para editar imágenes de personas reales (usos adyacentes a deepfake), también debe etiquetarlas. Las obligaciones recaen sobre el deployer, que en la mayoría de los casos es usted, no el proveedor.

Supervisión humana donde no es estrictamente requerida

Incluso cuando el Act no requiere supervisión humana, el default sensato para cualquier output generado por IA que alcance a un cliente, un regulador o un empleado es un checkpoint humano. Esto no es un requisito legal para riesgo limitado, es un requisito de calidad. Las empresas que se saltan el checkpoint son las que descubren seis meses después que su generador de contratos con IA ha estado insertando el mismo error de cláusula en cada acuerdo.

  • Los chatbots de IA deben revelar que son IA antes o durante la interacción.
  • Las imágenes, vídeo y audio generados por IA que podrían confundirse con reales deben etiquetarse.
  • El texto sintético que podría engañar (una reseña falsa, un testimonio falso) está cubierto por la ley de protección al consumidor independientemente del estatus bajo el AI Act.
  • Los usos internos (redactar, resumir, analizar) no tienen obligación de divulgación, pero la mayoría de empresas adoptan una política interna de todos modos.

Penalizaciones, cronograma y qué obtienen realmente las pymes de las exenciones SME

La estructura de penalizaciones del Act se ve compleja en papel y está estructurada para escalar con el tamaño de la empresa. Los números titulares asumen infractores a escala empresarial. La exposición de las pymes es menor en términos absolutos pero no cero, y el daño reputacional de un hallazgo público escala independientemente de la multa.

Multas máximas: 35 millones de euros o 7 por ciento de la facturación global anual (lo que sea mayor) por violaciones de IA prohibida. 15 millones o 3 por ciento para la mayoría de otras violaciones. 7,5 millones o 1 por ciento por proporcionar información falsa a reguladores. Para pymes, el Act instruye a las autoridades a tener en cuenta el tamaño de la empresa y las circunstancias, y para microempresas los topes aplican sobre el menor de los dos valores en lugar del mayor. El efecto práctico para una empresa de 50 personas es que las penalizaciones escalan a algo asumible, no a nivel de quiebra. Según las directrices del Parlamento Europeo 2026, las sanciones deben ser proporcionadas y disuasorias, pero sin ahogar la innovación de las pequeñas empresas.

Cronograma en lenguaje claro

  1. 2 de febrero de 2025: prácticas de IA prohibidas vetadas. Ya en vigor.
  2. 2 de agosto de 2025: obligaciones de modelos de IA de propósito general en vigor. Del lado del provider.
  3. 2 de agosto de 2026: aplican obligaciones para sistemas de IA de alto riesgo bajo el Annex III. Esta es la fecha límite que importa para la mayoría de deployers pymes.
  4. 2 de agosto de 2027: aplican obligaciones para sistemas de alto riesgo que son componentes de seguridad de productos regulados (dispositivos médicos, maquinaria, etc.).

Qué le conceden realmente las provisiones SME

El Act especifica mecanismos de apoyo para pymes y startups: acceso prioritario a sandboxes regulatorios, opciones simplificadas de documentación, asistencia de evaluación de conformidad gratuita o de bajo coste en algunos estados miembros, campañas de concientización y programas de formación de autoridades nacionales. Ninguno de estos le exime del compliance sustantivo. Reducen el coste y complejidad de llegar al compliance.

Un starter pack pragmático de compliance: los próximos 90 días

Con cuatro meses hasta la fecha límite de agosto de 2026, el trabajo del starter pack es suficiente para la mayoría de deployers pymes. No necesita un engagement de consultoría. Necesita un inventario disciplinado y un árbol de decisión, propiedad de una persona que tenga treinta por ciento de su tiempo.

Semanas 1 a 2: inventario

Liste cada sistema de IA en uso activo. Incluya herramientas SaaS que sus equipos adoptaron sin un proceso formal de procurement (el problema de shadow AI). Para cada sistema, registre: proveedor, caso de uso, quién decide con él, si produce outputs que afecten a una persona específica. Este inventario es el artefacto individual más importante que producirá. Todo lo demás es downstream de él.

Semanas 3 a 4: clasificación

Para cada sistema en el inventario, asigne una categoría de riesgo. Alto, limitado o mínimo. Use el Annex III del Act como su referencia. Para los casos inciertos, consiga una consulta de una hora con un abogado de privacidad o IA; en 2026 esto cuesta de 300 a 600 euros para un especialista cualificado. Documente el rationale para cada clasificación, no solo la conclusión.

Semanas 5 a 8: cerrar las brechas en sistemas de alto riesgo

Para cada sistema de alto riesgo, trabaje a través de la lista de seis documentos en la sección 3 de esta guía. En la mayoría de casos, tres de los seis documentos son suministrados por el proveedor y usted conserva copias. Los otros tres (su gestión de riesgos, sus arreglos de supervisión, su documentación técnica del lado deployer) los escribe usted.

Semanas 9 a 12: transparencia y supervisión para riesgo limitado

Para cada sistema de riesgo limitado, agregue divulgación donde falte. Actualice scripts de chatbot, descripciones de productos, flujos de trabajo de generación de imágenes. Escriba una política interna de uso de IA de una página que cubra la IA de cara al empleado y la revisión humana esperada. Esto es barato y cierra el hallazgo de auditoría más común.

De qué es responsable su proveedor versus de qué es responsable usted

El Act traza una línea nítida entre providers (que ponen sistemas de IA en el mercado) y deployers (que los usan en sus operaciones). La mayoría de pymes son deployers casi todo el tiempo. Entender la línea le previene de pagar trabajo de compliance que no es su responsabilidad legal y le previene de asumir que el proveedor cubrió algo que no cubrió.

El provider posee la documentación técnica, la evaluación de conformidad, el marcado CE (donde aplique), el monitoreo post-mercado de cómo se desempeña su sistema en el mundo real, y el registro en la base de datos de la UE para sistemas de alto riesgo. Si está comprando una herramienta de proceso con IA a un proveedor, estas obligaciones son suyas, y la capacidad del proveedor para responder sus preguntas sobre compliance es en sí misma una señal de su seriedad.

El deployer posee el uso

El deployer posee el despliegue específico: el uso previsto en su contexto, el arreglo de supervisión humana, los datos que alimenta al sistema, las instrucciones que da a sus empleados, los avisos de transparencia a individuos afectados. Un proveedor no puede asumir estas obligaciones por usted. Viven dentro de su operación por definición.

  • Pida al proveedor: extracto de documentación técnica, descripción de gobernanza de datos, declaraciones de precisión y limitaciones, instrucciones de uso, declaración de compliance o declaración UE de conformidad para sistemas de alto riesgo.
  • Usted retiene y produce: evaluación de riesgos en su contexto, arreglo de supervisión humana, política interna de uso, avisos de transparencia a sus usuarios o clientes, logs de cómo el sistema realmente se ejecuta en su operación.
  • Cuando la responsabilidad se difumina: si hace fine-tuning a un modelo de propósito general sobre sus datos, puede convertirse en provider de un nuevo sistema de alto riesgo. Esta es la escalada no intencionada más común que vemos.

El rol de las agencias nacionales y los sandboxes regulatorios en 2026

A medida que nos acercamos a la fecha límite de agosto de 2026, los Estados miembros de la UE han establecido plenamente sus autoridades nacionales de supervisión de IA. En España, la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) lidera el camino, convirtiéndose en un referente de cómo se aplicarán las inspecciones y el soporte a las pymes.

La gran novedad para las pymes en 2026 es la apertura de los denominados sandboxes regulatorios (espacios de pruebas controlados). Según las directrices de la Comisión Europea 2026, estos entornos permiten a las pequeñas empresas probar sus sistemas de IA de alto riesgo bajo la supervisión directa del regulador, sin riesgo de sanciones inmediatas en caso de desajustes.

  • AESIA y otras agencias nacionales ofrecen guías de autoevaluación gratuitas diseñadas específicamente para pymes.
  • Los sandboxes regulatorios proporcionan un canal directo de comunicación con los inspectores para resolver dudas sobre la clasificación de sus herramientas.
  • Las pymes tienen prioridad de acceso a estos entornos de prueba frente a las grandes corporaciones.

Preguntas frecuentes

¿Aplica la EU AI Act a empresas de fuera de la UE?

Sí, si el output del sistema de IA se usa en la UE. Un proveedor de IA basado en EE. UU. que vende una herramienta de filtrado de CV a una empresa francesa está dentro del alcance. Una empresa SaaS canadiense que ofrece una herramienta a clientes alemanes está dentro del alcance. La prueba es dónde se usa el output, no dónde está la sede de la empresa. Esta es la misma lógica extraterritorial que GDPR.

¿Qué cuenta como «desplegar» un sistema de IA bajo el Act?

Usar un sistema de IA bajo su propia autoridad en el curso de una actividad profesional. Comprar una herramienta y dejar que su equipo la use le hace un deployer. Incrustar una API de tercero en su producto de cara al cliente probablemente le hace deployer del modelo subyacente y provider de su propio producto. El uso personal, no profesional, está excluido.

¿Es probable que la fecha límite del 2 de agosto de 2026 se retrase?

A abril de 2026, la Comisión ha señalado que el cronograma se sostiene. El lobbying de la industria por un retraso ha sido activo, particularmente alrededor de las reglas de modelos de IA de propósito general, pero la fecha límite de alto riesgo del Annex III es políticamente más difícil de mover. Planifique como si la fecha se sostuviera. Un retraso tardío no le da retroactivamente compliance.

¿Cómo saber si una herramienta específica de proceso con IA es de alto riesgo para un caso de uso específico?

Cruza dos cosas: la función de la herramienta (qué hace) y el contexto de uso (qué decisión influye). La clasificación sigue al uso, no a la herramienta. Si la herramienta influye en contratación, despido, crédito, evaluación educativa o acceso a un servicio, es probablemente de alto riesgo en ese despliegue. Si ayuda a un humano a resumir documentos o redactar emails, es casi con seguridad de riesgo limitado o mínimo.

¿Se necesita un Data Protection Officer para el compliance del AI Act?

No. El AI Act no requiere un DPO. El AI Act tiene su propio rol, la persona responsable de la supervisión humana de los sistemas de alto riesgo, pero esta no es una posición formal de oficial y puede sentarse con el líder de operaciones o el CTO. Un requisito de DPO puede venir del GDPR independientemente, dependiendo de su procesamiento.

¿Puede la documentación de GDPR existente cubrir las obligaciones del AI Act?

Parcialmente. La documentación de gobernanza de datos se solapa, y un registro de actividades de procesamiento puede formar la columna vertebral de un inventario de sistemas de IA. Pero el AI Act requiere artefactos que GDPR no: gestión de riesgos para riesgos específicos de IA, documentación técnica del sistema, arreglos de supervisión humana, logging de operación del sistema. Trátelos como regímenes que se solapan pero distintos.

Artículos relacionados

¿Qué es BPMN? Definición, símbolos y herramientas IA 2026Transformación IA de procesos: de flujos de trabajo manuales a agentes autónomos, sin el año de transición entremediasPor qué la transformación IA no es un proyecto BPMN, y por qué esa distinción decide si su programa llega a producción

¿Listo para co-construir su plan de transformación IA?

Suba cualquier documento de proceso y co-construya un plan de transformación IA con recomendaciones de herramientas reales y proyecciones de ROI, en minutos, no en semanas.

Probar LucidFlow gratis