ENS y RGPD en contratación pública: requisitos para herramientas digitales

1. Por qué ENS y RGPD son inseparables en software para AAPP

ENS y RGPD son dos regímenes con lógicas complementarias. El ENS fija los controles de seguridad que debe aplicar un sistema de información del sector público: autenticación, cifrado, trazabilidad, continuidad, auditoría. El RGPD regula el tratamiento de datos personales desde la óptica de derechos del interesado: licitud, minimización, finalidad, responsabilidad proactiva.

En un contrato de software para una administración pública, ambos regímenes se aplican simultáneamente: el ENS porque el sistema forma parte del ecosistema digital de la administración; el RGPD porque, en la práctica, casi cualquier software administrativo acaba tratando datos personales (datos de licitadores, técnicos municipales, ciudadanos). Tratarlos por separado es uno de los errores habituales en la redacción de PPT.

2. ENS — RD 311/2022: niveles Bajo, Medio, Alto y cuándo aplica cada uno

El ENS clasifica los sistemas en tres niveles de seguridad (Bajo, Medio, Alto) por cada una de las cinco dimensiones: confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad. El nivel resultante determina los controles aplicables, recogidos en el Anexo II del RD 311/2022.

Nivel Bajo: el perjuicio por un incidente sería limitado para el organismo o los interesados. Ejemplo típico: un portal informativo sin datos personales significativos. Nivel Medio: el perjuicio sería relevante pero no grave. Ejemplo: herramientas de tramitación administrativa con datos de ciudadanos. Nivel Alto: el perjuicio sería grave o muy grave. Ejemplo: sistemas con datos de categorías especiales (salud, antecedentes), infraestructuras críticas o servicios públicos esenciales.

La categorización la realiza el responsable del sistema mediante un análisis de impacto formalizado. Para herramientas de contratación pública, lo más habitual es una categorización Media en casi todas las dimensiones, con alguna dimensión Alta cuando se manejen datos que permitan perfilado de licitadores o cuando el sistema sea crítico para el servicio.

3. RGPD aplicado a contratación pública

En un procedimiento de contratación se tratan datos personales de varias categorías: datos identificativos de licitadores y representantes, datos profesionales de técnicos firmantes, datos de solvencia, a veces datos de trabajadores adscritos al servicio. Cada uno requiere su base jurídica conforme al artículo 6 RGPD y un plazo de conservación proporcionado al cumplimiento de la LCSP y a la documentación del expediente.

La LOPDGDD (Ley Orgánica 3/2018) complementa el RGPD y añade obligaciones concretas para administraciones públicas: delegado de protección de datos obligatorio (art. 34 LOPDGDD), registro de actividades del tratamiento (art. 31 LOPDGDD) y coordinación con la AEPD en caso de brechas. Cualquier software que se contrate debe integrarse correctamente en este marco.

4. El encargado del tratamiento: contrato del art. 28 RGPD

Cuando una administración contrata un software como servicio, el proveedor se convierte en encargado del tratamiento respecto a los datos personales que procese en nombre del organismo. El artículo 28 del RGPD exige un contrato específico que debe incluir: objeto, duración, naturaleza y finalidad del tratamiento, tipo de datos, categorías de interesados, obligaciones del encargado y derechos del responsable.

En contratación pública, este contrato se articula habitualmente como una cláusula o anexo específico del PCAP o del contrato formalizado tras la adjudicación. Los elementos mínimos obligatorios son: instrucciones documentadas del responsable, deber de confidencialidad del personal del proveedor, medidas técnicas y organizativas alineadas con el ENS, régimen de subcontratación previa autorización, colaboración en atención a derechos, notificación de brechas en 72 horas y devolución o supresión de datos al final del contrato.

5. Transferencias internacionales: cuándo el proveedor SaaS las activa

Un proveedor SaaS puede implicar transferencias internacionales de datos si: aloja los datos fuera del Espacio Económico Europeo, utiliza subcontratistas (hosting, soporte, backups) ubicados fuera del EEE, o emplea modelos de IA que procesan datos en infraestructura extracomunitaria. Cualquiera de estos supuestos activa el régimen del Capítulo V del RGPD.

Las vías legales para habilitar estas transferencias son tres: decisión de adecuación de la Comisión Europea, garantías adecuadas (cláusulas contractuales tipo aprobadas en 2021, normas corporativas vinculantes) o excepciones tasadas del artículo 49 RGPD. Tras la sentencia Schrems II (C-311/18), el responsable del tratamiento debe además realizar una evaluación de impacto de transferencia (TIA) para verificar que la legislación del país receptor no neutraliza las garantías contractuales.

Para una administración pública española, la opción menos arriesgada es exigir que todos los datos y el tratamiento completo se localicen en infraestructura ubicada dentro del EEE, idealmente con cifrado en reposo cuyas claves gestione el propio organismo o un tercero europeo.

6. Cómo redactar requisitos ENS/RGPD en el PPT del software

Los requisitos ENS/RGPD en el PPT deben ser concretos, verificables y proporcionados al objeto del contrato. Una cláusula genérica como "el proveedor cumplirá el ENS y el RGPD" no añade nada y es recurrible por indeterminación. Debe traducirse en exigencias operativas.

Estos requisitos, bien ponderados en los criterios de adjudicación, permiten diferenciar a los proveedores que cumplen formalmente de los que cumplen operativamente. Esta es una palanca clave en contratos de software con componente de IA.

7. Documentación que debe aportar el proveedor (CCN-CERT, declaración de aplicabilidad)

El proveedor debe acreditar el cumplimiento ENS con documentación formal. La vía más sólida es la certificación ENS emitida por una entidad acreditada por ENAC conforme al esquema CCN-STIC-809, que cubre el nivel declarado (Bajo, Medio o Alto). Como alternativa, admite la autodeclaración basada en la CCN-STIC-809 con auditoría interna documentada.

Desde la óptica RGPD, el proveedor debe aportar: registro de actividades del tratamiento donde aparezca el servicio ofertado, evaluación de impacto (EIPD) cuando el tratamiento implique alto riesgo, política de privacidad aplicable al servicio, identificación del delegado de protección de datos y acreditación de medidas técnicas y organizativas (cifrado, pseudonimización, control de accesos, trazabilidad).

8. IA generativa y RGPD: qué cambia con LLM y RAG

Los modelos de lenguaje (LLM) y las arquitecturas RAG (retrieval augmented generation) introducen cuestiones nuevas. Primera: si el proveedor utiliza un LLM entrenado sobre datos del organismo, debe quedar claro en el contrato que esos datos no se reutilizan para entrenar modelos de terceros. Segunda: el derecho a una decisión que no esté basada únicamente en tratamiento automatizado (art. 22 RGPD) limita el uso de IA en decisiones con efectos jurídicos sobre personas; un técnico debe conservar la responsabilidad final.

Tercera: el Reglamento de IA de la UE (Reglamento 2024/1689) introduce obligaciones adicionales para sistemas de alto riesgo, incluidos muchos usos de IA en administración pública. Aunque su calendario de aplicación es progresivo, los contratos de software con IA firmados en 2026 deben anticiparlo incluyendo cláusulas de adaptación a la normativa aplicable.

En el sector específico de redacción de pliegos, la recomendación práctica es trabajar con proveedores que ofrezcan arquitectura RAG sobre la documentación del propio organismo, con despliegue en infraestructura europea y garantías contractuales de no reutilización de datos. Puedes leer más sobre este enfoque en nuestra página de cómo funciona LicitadIA.

9. Auditoría y mantenimiento: revisión bienal ENS

El ENS no es un trámite de una sola vez. El artículo 31 del RD 311/2022 establece que los sistemas de categoría Media y Alta deben someterse a una auditoría formal cada dos años, o siempre que haya cambios sustanciales en el sistema. Los sistemas de categoría Baja requieren autoevaluación con el mismo ciclo.

En contratos de larga duración con proveedores SaaS, el PCAP debe prever las auditorías periódicas, la actualización de la declaración de aplicabilidad cuando cambien los controles aplicables y la obligación del proveedor de comunicar incidentes y cambios de infraestructura que puedan afectar al cumplimiento.

10. Checklist práctico para un órgano de contratación

Un resumen de acciones que recomendamos incorporar en cualquier expediente de software para AAPP que trate datos personales:

Para el caso concreto de herramientas de IA aplicadas a la redacción de pliegos, LicitadIA ha sido diseñada desde el primer día con este marco en mente: despliegue europeo, contrato de encargado del tratamiento listo, no reutilización de datos para entrenamiento y compatibilidad con los controles ENS del Nivel Medio.

Si quieres revisar la documentación ENS y RGPD antes de plantear un piloto, lo más directo es contactarnos indicando tu organismo y el tipo de contratos que manejas.

Preguntas frecuentes