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

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, sabe en qué cubeta estás.

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ás leyendo esto porque diriges una firma de logística de 150 personas o una consulta legal de 40 personas, no estás construyendo nada de esto. Puedes saltarte 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.

La lista de disparadores de alto riesgo en el Annex III del Act es específica y limitada. No es un vibe. 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 tu caso de uso no está en la lista o no funciona como componente de seguridad de un producto regulado, no eres 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átalos como dos regímenes paralelos.

Si concluiste 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 construiste), o sobre qué datos opera (si lo despliegas). Verificaciones de calidad de datos. Resultados de pruebas de sesgo. Manejo de categorías especiales de datos. Si eres deployer de un sistema de tercero, esto es principalmente trabajo del proveedor, pero tú documentas lo que el proveedor te 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 eres deployer, el provider suministra la mayor parte de esto y tú conservas 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 escribas. Confirma que tu proveedor lo provee o constrúyelo internamente si despliegas in-house.

5. Transparencia e instrucciones de uso

Si eres provider, suministras instrucciones a los deployers. Si eres deployer, documentas cómo se usa realmente el sistema en tu contexto y te aseguras 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.

La mayoría de despliegues de IA en pymes aterrizan en riesgo limitado, y las obligaciones ahí son modestas pero reales. Ignóralas y creas exposición que es trivialmente 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 unas pocas cosas concretas. Si tu operación de atención al cliente usa un chatbot de IA, el chatbot dice que es una IA. Si usas IA para generar descripciones de productos y esas descripciones son de cara al consumidor en mercados donde importa, las etiquetas como generadas por IA. Si usas IA para editar imágenes de personas reales (usos adyacentes a deepfake), las etiquetas. Las obligaciones están sobre el deployer, que en la mayoría de casos eres tú, 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.

La estructura de penalizaciones del Act se ve aterradora 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 sobrevivible, no a nivel de quiebra.

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é te 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 te exime del compliance sustantivo. Reducen el coste y complejidad de llegar al compliance.

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 necesitas un engagement de consultoría. Necesitas 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

Lista cada sistema de IA en uso activo. Incluye herramientas SaaS que tus equipos adoptaron sin un proceso formal de procurement (el problema de shadow AI). Para cada sistema, registra: 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ás. Todo lo demás es downstream de él.

Semanas 3 a 4: clasificación

Para cada sistema en el inventario, asigna una categoría de riesgo. Alto, limitado o mínimo. Usa el Annex III del Act como tu referencia. Para los casos inciertos, consigue 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. Documenta 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, trabaja 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 tú conservas copias. Los otros tres (tu gestión de riesgos, tus arreglos de supervisión, tu documentación técnica del lado deployer) los escribes tú.

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

Para cada sistema de riesgo limitado, agrega divulgación donde falte. Actualiza scripts de chatbot, descripciones de productos, flujos de trabajo de generación de imágenes. Escribe 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.

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 te previene de pagar trabajo de compliance que no es tu responsabilidad legal y te 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ás comprando una herramienta de proceso con IA a un proveedor, estas obligaciones son suyas, y la capacidad del proveedor para responder tus 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 ti. Viven dentro de tu operación por definición.

• Pide 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.
• Retienes y produces: evaluación de riesgos en tu contexto, arreglo de supervisión humana, política interna de uso, avisos de transparencia a tus usuarios o clientes, logs de cómo el sistema realmente se ejecuta en tu operación.
• Cuando la responsabilidad se difumina: si haces fine-tuning a un modelo de propósito general sobre tus datos, puedes convertirte en provider de un nuevo sistema de alto riesgo. Esta es la escalada no intencionada más común que vemos.