Qué evidencias debe poder enseñar una empresa española el 2 de agosto de 2026 para demostrar cumplimiento del AI Act, punto por punto.
📌 En resumen
El AI Act (Reglamento UE 2024/1689) aplica plenamente el 2 de agosto de 2026 para la mayoría de sistemas. Este checklist resume las 8 evidencias mínimas que una empresa española debe tener preparadas antes de esa fecha: inventario, clasificación de riesgo, alfabetización documentada, supervisión humana escrita, documentación técnica del proveedor, procedimiento de incidencias, política interna de IA generativa y contratos actualizados. Ninguno requiere ser un despacho jurídico; todos requieren trazabilidad.
Cumplir el AI Act no es tener un expediente legal de 200 páginas. Es poder enseñar, en 30 minutos, que se ha hecho el trabajo básico de gobernanza sobre los sistemas de IA que la empresa usa. Esta guía es operativa: qué evidencias deben existir, en qué formato, actualizadas con qué frecuencia.
Lo primero es saber qué estás usando. Un inventario es una hoja (puede ser Excel, Notion o Airtable) con una fila por sistema de IA que la empresa utiliza o despliega. Campos mínimos:
Frecuencia de actualización: cada vez que se contrata un sistema nuevo o se deja de usar uno existente. Review formal anual.
Para cada sistema del inventario hay que asignar nivel de riesgo según el Reglamento:
Cada clasificación debe ir con justificación escrita (una o dos frases). Si el regulador pregunta, necesitas enseñar por qué has clasificado un copilot como riesgo mínimo y no como limitado o alto.
Artículo 4 del reglamento, aplicable desde el 2 de febrero de 2025. Obligación de que el personal que usa IA tenga formación adecuada. Mínimo anual:
Para cualquier sistema de alto riesgo es obligatoria supervisión humana (art. 14). Pero también es buena práctica en sistemas de riesgo limitado y mínimo si afectan decisiones. Qué debe quedar escrito:
Para sistemas de alto riesgo, el proveedor debe entregar la documentación del Anexo IV: descripción técnica, datos de entrenamiento, métricas de rendimiento, evaluación de conformidad, marcado CE. Si consumes un SaaS que entra en alto riesgo, esa documentación forma parte de tu archivo de cumplimiento. Sin ella, no puedes demostrar conformidad como deployer.
Un incidente grave (art. 3, punto 49 del reglamento) en un sistema de alto riesgo debe notificarse a la autoridad nacional en ≤15 días. Para poder hacerlo, hace falta un registro interno donde anotar:
Documento corto (2-4 páginas) firmado o aceptado digitalmente por todo el personal. Debe cubrir:
Un contrato de SaaS genérico firmado antes de 2024 probablemente no cubre los requisitos AI Act. Cláusulas a añadir o revisar:
| Mes | Acción |
|---|---|
| Abril-Mayo 2026 | Inventario + clasificación de riesgo de todos los sistemas (si aún no existe). |
| Mayo 2026 | Programa de alfabetización IA para el equipo (si no se hizo en 2025). |
| Junio 2026 | Política interna de uso de IA generativa aprobada y firmada. |
| Junio-Julio 2026 | Revisión y renegociación de contratos con proveedores de sistemas alto riesgo. |
| Julio 2026 | Procedimientos de supervisión humana y registro de incidencias operativos. |
| 2 agosto 2026 | Entrada en aplicación plena del Reglamento. |
Sí. De hecho está pensado para empresas con recursos limitados. No hace falta software especializado ni consultores externos obligatorios: se puede mantener en un espacio de Notion, SharePoint o Confluence. Lo que importa es que las evidencias existan, estén fechadas y se revisen anualmente.
Una pyme que parte de cero puede tenerlo operativo en 4-6 semanas de trabajo con un responsable interno part-time. El bloque más largo suele ser la renegociación de contratos con proveedores, porque depende de terceros.
Siguiente paso recomendado
Catálogo de datos, linaje automático y calidad del dato para cumplir con el AI Act sin parar los proyectos.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, acumuló experiencia en consultoría de datos y transformación digital trabajando con stacks variados — desde entornos Microsoft (SQL Server, Power BI, Azure) hasta ecosistemas open source (Python, dbt, BigQuery). Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes
La visión general del reglamento y qué impacta a una empresa española según su caso de uso.
Los tres tramos de multa del artículo 99 y cómo se calculan en pyme.
Acompañamiento para clasificar sistemas y montar la gobernanza mínima antes de agosto de 2026.
Seguir leyendo
7 min lectura
10 min lectura
18 min lectura
17 min lectura
18 min lectura
Última revisión: