AI Act y ENS para proveedores de la AAPP: el doble marco regulatorio que debes conocer
- Si desarrollas o vendes software de inteligencia artificial a la Administración Pública española, eres provider bajo el AI Act: las obligaciones más exigentes recaen sobre ti, no sobre tu cliente.
- El ENS (RD 311/2022) es obligatorio para cualquier proveedor privado que trate sistemas de información de una AAPP: necesitas Declaración de Conformidad (categoría básica) o Certificación externa (media o alta).
- La intersección de ambas normas crea un doble marco regulatorio que afecta a documentación técnica, gestión de riesgos, trazabilidad y supervisión humana: en muchos puntos se solapan y en otros divergen.
- Las obligaciones completas del Anexo III del AI Act para sistemas de alto riesgo están previstas para diciembre de 2027 (tras el acuerdo político sobre el Digital Omnibus de mayo de 2026).
- Los pliegos de licitación tech ya están incorporando requisitos de explicabilidad, trazabilidad y cumplimiento normativo IA. Quien llegue preparado gana ventaja competitiva real.
- El Kit Consulting (hasta 24.000 €) puede financiar el asesoramiento estratégico para preparar toda esta documentación.
En los últimos doce meses, he visto el mismo patrón repetirse en decenas de empresas tecnológicas españolas: llegan a la fase de pliegos de una licitación pública, descubren que el cliente exige cumplimiento del Esquema Nacional de Seguridad y, cuando preguntan por el AI Act, nadie sabe muy bien qué papel juegan. ¿Son proveedores? ¿Son usuarios? ¿Les aplica el Anexo III?
La respuesta corta es que probablemente les aplican ambas regulaciones, con obligaciones distintas pero complementarias, y que empezar a prepararlas ahora —antes de que llegue la próxima convocatoria— marca la diferencia entre ganar o perder el contrato.
En este artículo desgloso el doble marco regulatorio con la precisión que necesitas si eres una empresa tech que quiere o ya tiene contratos con la Administración Pública española.
¿Por qué los proveedores tecnológicos de la AAPP están en el radar del AI Act?
El Reglamento (UE) 2024/1689, conocido como AI Act, entró en vigor el 1 de agosto de 2024. Aunque su aplicación es escalonada, ya desde el 2 de febrero de 2025 están en vigor las prohibiciones de prácticas de IA inaceptables y la obligación de promover la alfabetización en IA para proveedores y usuarios.
La razón por la que los proveedores de la AAPP están especialmente expuestos tiene que ver con la lógica de cascada del AI Act: las Administraciones Públicas, cuando utilizan sistemas de IA para tomar decisiones que afectan a ciudadanos —gestión de prestaciones sociales, valoración de expedientes, sistemas de control de acceso—, son deployers (usuarios) según la norma. Y cuando alguien es deployer de un sistema de alto riesgo, sus obligaciones incluyen exigir a su proveedor que ese sistema cumpla todos los requisitos del AI Act.
Dicho de otra manera: la AAPP traslada el cumplimiento a su cadena de suministro tecnológica. Si vendes un sistema de IA a un ayuntamiento, una consejería o un organismo estatal, el contrato va a requerir —explícita o implícitamente— que ese sistema haya pasado la evaluación de conformidad, que tenga documentación técnica, que permita la supervisión humana y que esté registrado en la base de datos europea de la UE si cae dentro del Anexo III.
Además, la Ley Orgánica de gobernanza de la IA que España aprobó en el Consejo de Ministros de 2026 obliga al sector público estatal a mantener un inventario de los sistemas de IA utilizados en procedimientos administrativos y a trasladar este requisito a sus contratistas. Lo que antes era una buena práctica se convierte en una condición contractual.
Roles en el AI Act: ¿eres provider o deployer?
Antes de analizar obligaciones concretas, es imprescindible clarificar qué papel juegas en el ecosistema del AI Act. La norma distingue cuatro figuras principales:
| Rol | Definición | Ejemplos en el sector AAPP | Nivel de obligaciones |
|---|---|---|---|
| Provider (proveedor) | Quien desarrolla o pone en el mercado un sistema de IA bajo su nombre o marca, incluso si lo encarga a un tercero | Empresa tech que vende un sistema de valoración de expedientes de servicios sociales a una diputación | Máximo: documentación técnica, evaluación de conformidad, CE, registro UE |
| Deployer (usuario) | Quien utiliza un sistema de IA bajo su propia responsabilidad en su actividad profesional | Ayuntamiento que usa un sistema de reconocimiento biométrico para control de acceso | Alto: supervisión humana, registros, evaluación de impacto en derechos fundamentales |
| Distribuidor | Quien comercializa sin modificar el sistema de IA de un provider | Reseller que vende software de terceros a AAPP sin modificarlo | Medio: verificar conformidad del provider, no comercializar sistemas no conformes |
| Importador | Quien introduce en el mercado europeo un sistema de IA de un provider de fuera de la UE | Empresa española que importa y vende a la AAPP un sistema de IA americano | Alto: asume obligaciones de provider si este no está en la UE |
La regla práctica más importante: si desarrollas el sistema (o lo adaptas significativamente), eres provider con independencia de que tu cliente sea una AAPP o una empresa privada. Y ser provider de un sistema de alto riesgo implica las obligaciones más exigentes de toda la norma.
En la práctica, muchas empresas tecnológicas que trabajan con la Administración Pública son providers en unos contratos y deployers en otros (cuando usan herramientas de terceros en su propia operativa). Es fundamental clasificar cada sistema que gestionas.
Nota sobre las AAPP: Cuando una Administración Pública utiliza sistemas de IA de alto riesgo para tomar decisiones que afectan a ciudadanos, actúa como deployer. En virtud del Art. 26(8) del AI Act, las autoridades públicas tienen además la obligación específica de verificar que los sistemas que despliegan estén registrados en la base de datos de la UE antes de ponerlos en uso, y de abstenerse de usar sistemas no registrados.
Sistemas de IA de alto riesgo que se contratan habitualmente con la AAPP
El Anexo III del AI Act identifica ocho dominios de sistemas de IA de alto riesgo. Varios de ellos son especialmente relevantes para el sector público español, y muchos ya aparecen —o empezarán a aparecer— en licitaciones públicas:
1. Biometría
Sistemas de identificación biométrica remota, categorización biométrica basada en atributos sensibles y reconocimiento de emociones. En el contexto de la AAPP española, esto incluye sistemas de control de acceso en instalaciones públicas, reconocimiento facial en procesos de identificación digital ciudadana o sistemas de videovigilancia inteligente.
Obligaciones que genera para el provider: documentación técnica exhaustiva, evaluación de conformidad por organismo notificado, marcado CE, registro en la base de datos de la UE antes de cualquier comercialización. Los sistemas de identificación biométrica remota en tiempo real en espacios públicos están además sujetos a restricciones adicionales y requieren autorización judicial o administrativa previa.
2. Infraestructuras críticas
Sistemas destinados a ser componentes de seguridad en la gestión u operación de infraestructuras críticas digitales, tráfico rodado, suministro de agua, gas, calefacción o electricidad. En licitaciones públicas, esto abarca desde sistemas de gestión de redes eléctricas hasta plataformas de control de infraestructuras de transporte.
Intersección con el ENS: estos sistemas suelen clasificarse en categoría alta del ENS, lo que requiere certificación externa por entidad acreditada por ENAC. El cumplimiento del ENS y el AI Act se refuerzan mutuamente aquí.
3. Educación y formación profesional
Sistemas que determinan el acceso o la admisión a instituciones educativas, evalúan resultados de aprendizaje, asignan niveles educativos o monitorizan el comportamiento de los estudiantes. En España, cualquier sistema de IA que intervenga en procesos de admisión escolar, asignación de plazas universitarias o evaluación educativa automatizada cae aquí.
Tendencia en licitaciones: comunidades autónomas con competencias en educación están empezando a licitar plataformas de análisis de rendimiento académico. Los pliegos de estos contratos van a requerir evaluación de impacto en derechos fundamentales y mecanismos de recurso humano.
4. Empleo y gestión de recursos humanos
Sistemas de selección y evaluación de candidatos, decisiones sobre relaciones laborales (promoción, terminación, asignación de tareas basada en comportamiento), monitorización del rendimiento. En el contexto de la AAPP, aplica a herramientas de selección de funcionarios y personal laboral.
Atención: AESIA ha señalado que los sistemas de IA en selección de personal son uno de sus primeros focos de inspección proactiva. Si vendes herramientas de RRHH a administraciones, debes tener toda la documentación en orden antes de agosto de 2026.
5. Servicios esenciales privados y públicos
Este es el dominio más amplio para la AAPP española: sistemas que determinan la elegibilidad para asistencia pública y servicios sanitarios. Incluye cualquier herramienta de valoración de dependencia, servicios sociales, renta mínima vital o similares. También la priorización de llamadas de emergencia.
Obligación específica del deployer (AAPP): debe realizar una Evaluación de Impacto en Derechos Fundamentales (FRIA, según el Art. 27 del AI Act) antes de desplegar estos sistemas. El provider debe facilitar la documentación necesaria para esta evaluación.
6. Aplicación de la ley
Sistemas de evaluación de riesgo de victimización, fiabilidad de pruebas, riesgo de reincidencia, perfilado en investigaciones criminales. Aplica a fuerzas y cuerpos de seguridad del Estado y policías autonómicas y locales.
7. Migración, asilo y control de fronteras
Evaluación de riesgo de personas que entran en el territorio, valoración de solicitudes de asilo y visados, verificación de documentos de viaje. En España, principalmente competen al Ministerio del Interior y a delegaciones del Gobierno.
8. Administración de justicia y procesos democráticos
Asistencia a órganos judiciales en investigación de hechos y aplicación del Derecho. Los sistemas de apoyo a la decisión judicial son de alto riesgo, con limitaciones estrictas sobre el grado de automatización permitida.
En resumen: si tu producto toca cualquiera de estos ocho dominios en un contrato público, estás ante un sistema de alto riesgo del Anexo III con el máximo nivel de obligaciones como provider.
El ENS en 2026: requisitos para proveedores con componentes de IA
El Real Decreto 311/2022, que actualiza el Esquema Nacional de Seguridad, es de aplicación obligatoria para todas las Administraciones Públicas y, por extensión directa (Art. 2.3), para cualquier empresa privada que les preste servicios digitales.
Las tres categorías y lo que implican para el proveedor
El ENS clasifica los sistemas según las dimensiones de confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad de los datos gestionados. El resultado de esta valoración sitúa al sistema en una de tres categorías:
| Categoría ENS | ¿Quién audita? | Documento requerido | Vigencia | Sistemas de IA típicos |
|---|---|---|---|---|
| Básica | La propia organización (autoevaluación) | Declaración de Conformidad | 2 años | Chatbots de información general, motores de búsqueda semántica en intranets |
| Media | Entidad externa acreditada por ENAC | Certificación de Conformidad | 2 años | Sistemas de análisis documental, gestión de expedientes con componentes IA, herramientas de RRHH |
| Alta | Entidad externa acreditada por ENAC | Certificación de Conformidad | 2 años | Sistemas biométricos, IA en infraestructuras críticas, plataformas de servicios sociales con decisiones de alto impacto |
¿Cómo afecta la arquitectura de IA a la clasificación ENS?
Esta es una pregunta que muy pocos consultores abordan, y que tiene consecuencias prácticas importantes:
- Confidencialidad: si el sistema de IA procesa datos personales sensibles (salud, situación socioeconómica, datos biométricos) en un contrato con la AAPP, la dimensión de confidencialidad sube automáticamente, arrastrando la categoría hacia media o alta.
- Integridad: los modelos de IA que se actualizan con datos nuevos (fine-tuning, feedback loops) presentan vectores de manipulación (envenenamiento de datos, adversarial inputs) que el ENS requiere mitigar. Esto implica controles de integridad sobre los datos de entrenamiento y los modelos desplegados.
- Disponibilidad: si el sistema de IA es crítico para la prestación del servicio público (por ejemplo, un sistema de priorización de urgencias sanitarias), la dimensión de disponibilidad puede elevar la categoría a alta.
- Trazabilidad: los logs de las decisiones automatizadas de IA deben mantenerse con las garantías de integridad y retención que exige el ENS, lo que se solapa con la obligación de logging del AI Act (mínimo 6 meses, Art. 12).
Aquí está la clave práctica: cuando un sistema cae en el Anexo III del AI Act Y en categoría media o alta del ENS, la empresa debe certificarse por dos vías distintas con documentación parcialmente diferente. Gestionar esto de forma coordinada ahorra tiempo y coste.
La intersección: qué piden el ENS y el AI Act a la vez
La buena noticia es que ambas normas comparten una lógica de gestión de riesgos documentada. La mala es que el nivel de granularidad y los plazos difieren. Aquí el mapa de solapamientos y divergencias clave:
| Requisito | ENS (RD 311/2022) | AI Act (Reglamento UE 2024/1689) | ¿Se solapan? |
|---|---|---|---|
| Gestión de riesgos | Análisis de riesgos documentado, actualizado periódicamente | Sistema de gestión de riesgos durante todo el ciclo de vida (Art. 9) | Sí — una sola metodología puede alimentar ambos marcos |
| Documentación técnica | Política de seguridad, procedimientos, evidencias de controles | Documentación técnica exhaustiva (Art. 11 + Anexo IV): arquitectura, datos de entrenamiento, métricas de rendimiento | Parcial — el AI Act exige más detalle sobre el modelo en sí |
| Trazabilidad y logs | Registros de actividad y acceso según dimensión del sistema | Registro automático de eventos durante todo el ciclo de vida, retención mínima 6 meses (Art. 12) | Sí — un sistema de logging bien diseñado satisface ambos |
| Control de acceso | Gestión de privilegios, autenticación, control de acceso basado en roles | Supervisión humana efectiva con personas designadas y competentes (Art. 14) | Sí — la supervisión humana del AI Act se documenta en los procedimientos ENS |
| Gestión de incidentes | Notificación de incidentes de seguridad al CCN-CERT | Notificación de incidentes graves o mal funcionamiento al proveedor y autoridades (Art. 73) | Parcial — destinatarios distintos, pero el proceso puede unificarse |
| Calidad de datos | Integridad de la información como dimensión de categorización | Gobernanza de datos: calidad, representatividad, ausencia de sesgos en datos de entrenamiento (Art. 10) | No — el AI Act va mucho más allá en este punto |
| Certificación/conformidad | Declaración de Conformidad (básica) o Certificación ENAC (media/alta) | Autoevaluación (mayoría Anexo III) o evaluación por tercero notificado (casos específicos) + marcado CE | No — procesos y organismos completamente distintos |
| Transparencia al usuario | No aplicable directamente | Información clara a personas afectadas por decisiones de IA de alto riesgo (Art. 26(10)) | No — requisito exclusivo del AI Act |
La ventaja de abordarlos juntos: un sistema de gestión de riesgos bien diseñado, con documentación técnica modular y una arquitectura de logging unificada, puede satisfacer simultáneamente los requisitos del ENS y del AI Act, evitando duplicidades de documentación y reduciendo el coste de auditoría. Separar los proyectos de cumplimiento ENS y AI Act en dos equipos que no se coordinan es el error más común y el más caro.
Cómo están cambiando los pliegos de licitación: qué pedir ya
La normativa impacta en los pliegos de contratación pública de manera progresiva. Aunque la obligatoriedad plena del Anexo III llega en diciembre de 2027, los órganos de contratación más avanzados ya están incorporando requisitos de madurez en IA en sus pliegos de prescripciones técnicas y en los criterios de adjudicación.
Requisitos que ya están apareciendo en pliegos tech con componentes IA
- Explicabilidad: el sistema debe ser capaz de generar explicaciones comprensibles sobre sus decisiones o recomendaciones. Requisito que proviene directamente del Art. 13 del AI Act (transparencia hacia los usuarios) y que se está trasladando a los pliegos de servicios sociales y educación.
- Trazabilidad de decisiones: registro inmutable de todas las decisiones adoptadas por el sistema, con identificación del modelo, versión, datos de entrada y resultado. Compatible simultáneamente con el ENS (trazabilidad como dimensión) y el Art. 12 del AI Act.
- Auditoría independiente: algunos pliegos de mayor cuantía empiezan a exigir que el proveedor facilite auditorías técnicas periódicas del sistema por parte del órgano de contratación o de un tercero designado.
- No discriminación y análisis de sesgo: especialmente en servicios sociales, educación y empleo público. El pliego puede exigir que el proveedor realice un análisis de sesgos sobre los datos de entrenamiento y los resultados del modelo, y que lo actualice con periodicidad.
- Inventario de sistemas de IA: alineado con la obligación del sector público estatal de mantener un inventario de sistemas IA en procedimientos administrativos. El contratista puede tener que proporcionar una ficha técnica normalizada del sistema.
- Plan de transición y salida: cómo se garantiza la portabilidad de los datos y la continuidad del servicio al terminar el contrato, incluyendo los modelos entrenados con datos de la AAPP.
ISO 42001 como diferenciador en licitaciones
La norma ISO 42001, que establece un sistema de gestión de la inteligencia artificial, está empezando a aparecer en pliegos de licitación tech como criterio de solvencia técnica o como criterio de adjudicación. La Ley de Contratos del Sector Público permite a los órganos de contratación requerir certificaciones ISO cuando estén directa y justificadamente vinculadas al objeto del contrato.
Aunque la adopción de ISO 42001 en España todavía es incipiente, las empresas que combinen ENS + AI Act readiness + ISO 42001 tendrán una posición diferencial en los pliegos de los próximos dos años. No es solo una ventaja reputacional: es una demostración documentada de capacidad de gestión de IA que reduce el riesgo percibido por el órgano de contratación.
La AESIA y su papel como supervisora de los proveedores AAPP
La Agencia Española de Supervisión de la Inteligencia Artificial (AESIA), con sede en A Coruña y oficinas en Madrid, es la autoridad nacional competente para aplicar el AI Act en España. Fue creada en 2023, convirtiéndose en la primera agencia de este tipo de la Unión Europea.
Desde el 2 de febrero de 2025, AESIA tiene poderes de inspección activos sobre las prácticas prohibidas y la obligación de alfabetización en IA. Su capacidad sancionadora plena —incluyendo los sistemas de alto riesgo del Anexo III— se activa con la entrada en vigor de esas obligaciones, inicialmente prevista para agosto de 2026 y ahora apuntando a diciembre de 2027 tras el acuerdo político sobre el Digital Omnibus.
¿Qué puede hacer la AESIA con un proveedor de IA a la AAPP?
- Inspecciones proactivas sectoriales: AESIA puede iniciar revisiones temáticas de sectores concretos. Ha señalado públicamente que los sistemas de IA en selección de personal son uno de sus primeros objetivos. Los proveedores de herramientas de RRHH a administraciones públicas están en la lista.
- Investigaciones por reclamación: cualquier ciudadano afectado por una decisión adoptada con IA puede presentar una reclamación ante AESIA. Si el sistema es tuyo y lo ha comprado una AAPP, la investigación puede llegar hasta tu empresa.
- Notificaciones obligatorias: los proveedores de sistemas de alto riesgo deben notificar incidentes graves o mal funcionamientos. Incumplir esta obligación es una infracción independiente.
- Sanciones: hasta 35 millones de euros o el 7% de la facturación global anual para prácticas prohibidas; hasta 15 millones o el 3% por incumplimientos en sistemas de alto riesgo.
El sandbox regulatorio: una herramienta infrautilizada
AESIA gestiona un espacio de pruebas regulatorio (sandbox), establecido mediante el RD 817/2023, que permite a empresas desarrollar y probar sistemas de IA de alto riesgo bajo supervisión de la agencia, con flexibilidad temporal en el cumplimiento a cambio de transparencia y cooperación. Del sandbox ya han salido 16 guías prácticas de cumplimiento que AESIA ha publicado abiertamente en aesia.gob.es.
Para una pyme tech que quiere desarrollar un sistema de IA para la AAPP y no sabe si su producto es de alto riesgo, el sandbox es el mecanismo más seguro para testear sin riesgo sancionador inmediato.
Plan de preparación para proveedores: 6 meses antes de licitar
Si tu empresa quiere estar lista para las licitaciones tech con componentes IA que van a proliferar en los próximos dos años, aquí tienes las diez acciones ordenadas por prioridad y secuencia lógica:
- Inventario de sistemas de IA (semana 1-2): lista todos los sistemas que desarrollas, vendes o integras. Para cada uno, identifica si incorpora algún componente de toma de decisiones automatizada. Esta lista es el punto de partida de todo lo demás.
- Clasificación AI Act (semana 3-4): para cada sistema del inventario, determina su nivel de riesgo bajo el AI Act: inaceptable (prohibido), alto riesgo (Anexo III), riesgo limitado (obligaciones de transparencia) o riesgo mínimo. Las guías de AESIA son un recurso gratuito y fiable para hacer esta clasificación.
- Clasificación ENS (semana 3-4, en paralelo): para cada sistema que ya tienes o que estás desarrollando para contratos públicos, realiza el análisis de dimensiones ENS. Si ya tienes contratos vigentes con AAPP, el análisis ENS debería ya estar hecho; si no, es urgente.
- Gap analysis documentación técnica (mes 2): compara la documentación que tienes hoy con lo que exige el Anexo IV del AI Act para sistemas de alto riesgo. Los gaps más comunes son: ausencia de documentación de datos de entrenamiento, falta de métricas de rendimiento por subgrupos de población, y ausencia de procedimientos de supervisión humana documentados.
- Sistema de gestión de riesgos (mes 2-3): implementa un proceso de identificación, evaluación y mitigación de riesgos continuo para cada sistema de alto riesgo. Este proceso debe ser revisable por AESIA en caso de inspección.
- Arquitectura de logging unificada (mes 3): diseña o actualiza el sistema de registro de eventos para que cumpla simultáneamente con el ENS (trazabilidad) y el AI Act (Art. 12: registro automático durante todo el ciclo de vida, retención mínima 6 meses).
- Procedimientos de supervisión humana (mes 3-4): documenta quién, cómo y con qué frecuencia supervisa las decisiones del sistema. Define los umbrales de intervención manual. Forma al personal. Esto satisface tanto el Art. 14 del AI Act como las medidas de personal del ENS.
- Declaración de Conformidad ENS / Certificación (mes 4-5): según la categoría ENS de tus sistemas, prepara la autoevaluación (básica) o inicia el proceso de auditoría externa con una entidad acreditada por ENAC (media o alta). Sin este documento, no puedes presentarte a licitaciones.
- Evaluación de conformidad AI Act (mes 5-6): para sistemas de alto riesgo Anexo III, la mayoría permiten autoevaluación documentada. Prepara la documentación técnica según el Anexo IV y, si el sistema lo requiere, contacta con un organismo notificado para la evaluación externa.
- Registro en base de datos de la UE (mes 6): los sistemas de alto riesgo deben registrarse en la base de datos europea antes de ser comercializados. Este es un requisito previo al marcado CE y a poder presentarte a licitaciones con sistemas Anexo III.
Financiación con Kit Consulting
El programa Kit Consulting, gestionado por Red.es con fondos NextGenerationEU, puede financiar el asesoramiento estratégico para preparar toda esta documentación. Los importes disponibles son:
- Segmento A (10-49 empleados): hasta 12.000 €
- Segmento B (50-99 empleados): hasta 18.000 €
- Segmento C (100-249 empleados): hasta 24.000 €
El programa incluye específicamente servicios de asesoramiento en inteligencia artificial y en ciberseguridad (adaptación al ENS categoría media-alta). Combinados, pueden cubrir buena parte del trabajo de preparación del doble marco regulatorio.
Estado actual: La convocatoria del Kit Consulting está cerrada a nuevas solicitudes. Se espera una segunda convocatoria pendiente de apertura oficial. Si te interesa financiar tu proyecto con este programa, es recomendable que contactes con tu agente digitalizador para reservar plaza en cuanto se abra.
Si quieres explorar cómo articular un proyecto de cumplimiento ENS + AI Act financiado con Kit Consulting, escríbeme directamente y analizamos tu caso.
Preguntas frecuentes sobre AI Act y ENS para proveedores de la AAPP
¿El AI Act afecta a los proveedores de software para la Administración Pública?
Sí, directamente. Los proveedores de sistemas de IA que licitan con AAPP son providers bajo el AI Act y tienen las obligaciones más exigentes: documentación técnica según el Anexo IV, sistema de gestión de riesgos (Art. 9), evaluación de conformidad, registro en la base de datos de la UE y marcado CE para sistemas de alto riesgo. El hecho de que el cliente sea una Administración Pública no reduce las obligaciones del proveedor; en algunos casos las amplía, porque las AAPP están sujetas a requisitos adicionales de registro y supervisión que trasladan contractualmente a sus proveedores.
¿Qué obligaciones tiene una AAPP que usa sistemas de IA?
Las Administraciones Públicas son deployers bajo el AI Act cuando usan sistemas de IA para tomar decisiones que afectan a ciudadanos. Sus obligaciones principales, recogidas en el Art. 26, incluyen: usar el sistema conforme a las instrucciones del proveedor, asignar personal competente para la supervisión humana, mantener los registros automáticos generados por el sistema (mínimo 6 meses), informar a los trabajadores afectados antes del despliegue, notificar incidentes graves, realizar una Evaluación de Impacto en Derechos Fundamentales (FRIA, Art. 27) para determinados sistemas, e informar a los ciudadanos cuando una decisión que les afecta se haya adoptado con IA. El Art. 26(8) añade una obligación específica para autoridades públicas: verificar que los sistemas que despliegan estén registrados en la base de datos de la UE.
¿Debo cumplir el ENS Y el AI Act si vendo software de IA a la AAPP?
Sí, ambos marcos son obligatorios y se aplican en paralelo. El ENS (RD 311/2022) regula la seguridad de los sistemas de información que tratan datos de la AAPP: cualquier proveedor privado que gestione información pública debe cumplirlo y acreditarlo mediante Declaración de Conformidad (categoría básica) o Certificación de Conformidad externa (categorías media y alta). El AI Act regula los sistemas de IA con independencia de si son seguros o no en sentido convencional: se centra en gestión de riesgos específicos de la IA, calidad de datos, explicabilidad, supervisión humana y trazabilidad. Gestionar ambos marcos de forma integrada reduce duplicidades de documentación y coste de cumplimiento.
¿Qué sistemas de IA del Anexo III se contratan habitualmente con la AAPP?
Los más comunes en licitaciones públicas españolas incluyen: sistemas de reconocimiento biométrico para seguridad y control de acceso en instalaciones públicas, herramientas de valoración de dependencia y elegibilidad para servicios sociales, sistemas de admisión y evaluación en el ámbito educativo, plataformas de análisis de riesgo en el ámbito judicial o policial, sistemas de gestión de infraestructuras críticas con componentes de IA, y herramientas de selección y evaluación de personal para el empleo público. Todos ellos son sistemas de alto riesgo bajo el Anexo III y generan las obligaciones máximas para el provider.
¿Cuándo entran en vigor las obligaciones del Anexo III para proveedores de la AAPP?
Originalmente estaban previstas para el 2 de agosto de 2026. Tras el acuerdo político alcanzado en mayo de 2026 sobre el paquete Digital Omnibus, la fecha esperada se desplaza a diciembre de 2027 para los sistemas del Anexo III. Sin embargo, conviene actuar ya por tres razones: primero, el acuerdo político no es ley hasta su publicación en el DOUE; segundo, los pliegos de licitación ya están anticipando estos requisitos; tercero, los procesos de certificación ENS y documentación técnica AI Act llevan meses de trabajo. Empezar ahora significa llegar preparado en 2027, no corriendo en el último momento.
¿ISO 42001 ayuda a ganar licitaciones con la AAPP?
Cada vez más. La Ley de Contratos del Sector Público permite que los órganos de contratación utilicen certificaciones ISO como criterio de solvencia técnica o como criterio de adjudicación, siempre que estén directa y justificadamente vinculadas al objeto del contrato. ISO 42001 (sistema de gestión de la inteligencia artificial) está empezando a aparecer en pliegos de servicios tech con componentes IA, especialmente en licitaciones de mayor cuantía. Combinada con la certificación ENS y la documentación AI Act, demuestra una capacidad de gestión integral de la IA que reduce el riesgo percibido por el comprador público y puede marcar la diferencia en la puntuación técnica.
¿Qué es la AESIA y qué papel tiene con los proveedores de la AAPP?
La Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) es el organismo competente en España para aplicar el AI Act. Creada en 2023 con sede en A Coruña, fue la primera agencia de supervisión de IA de la UE. Supervisa tanto a providers como a deployers, incluyendo las AAPP. Sus herramientas son: inspecciones proactivas (iniciando por sistemas de selección de personal), investigaciones por reclamación de ciudadanos, notificaciones obligatorias de incidentes, y sanciones de hasta 35 M€ o el 7% de la facturación global. También ofrece el sandbox regulatorio para probar sistemas IA bajo supervisión con flexibilidad temporal de cumplimiento, y ha publicado 16 guías prácticas disponibles gratuitamente en aesia.gob.es.
¿Cómo financiar la adaptación al AI Act y al ENS para proveedores de la AAPP?
El programa Kit Consulting (gestionado por Red.es con fondos NextGenerationEU) puede cubrir el asesoramiento estratégico para preparar la documentación técnica del AI Act, el gap analysis respecto al ENS y el plan de cumplimiento integrado. Los importes van desde 12.000 € (10-49 empleados) hasta 24.000 € (100-249 empleados). El programa incluye específicamente servicios de asesoramiento en inteligencia artificial y en ciberseguridad/ENS. Es especialmente útil para pymes tech que quieren estar listas para las licitaciones de los próximos dos años sin asumir todo el coste internamente.
¿Quieres preparar tu empresa para las próximas licitaciones tech con IA?
Si desarrollas o vendes sistemas con componentes de IA a la Administración Pública española, puedo ayudarte a diseñar un plan de cumplimiento ENS + AI Act integrado, eficiente en coste y documentado para pasar la próxima auditoría o pliego de licitación.