ENS e RXPD en contratación pública: requisitos para ferramentas dixitais

1. Por que ENS e RXPD son inseparables en software para AAPP

ENS e RXPD son dous réximes con lóxicas complementarias. O ENS fixa os controis de seguridade que debe aplicar un sistema de información do sector público: autenticación, cifrado, trazabilidade, continuidade, auditoría. O RXPD regula o tratamento de datos persoais desde a óptica dos dereitos do interesado: licitude, minimización, finalidade, responsabilidade proactiva.

Nun contrato de software para unha administración pública, ambos os réximes aplícanse simultaneamente: o ENS porque o sistema forma parte do ecosistema dixital da administración; o RXPD porque, na práctica, case calquera software administrativo acaba tratando datos persoais (datos de licitadores, técnicos municipais, cidadáns). Tratalos por separado é un dos erros habituais na redacción de PPT.

2. ENS — RD 311/2022: niveis Baixo, Medio, Alto e cando aplica cada un

O ENS clasifica os sistemas en tres niveis de seguridade (Baixo, Medio, Alto) por cada unha das cinco dimensións: confidencialidade, integridade, trazabilidade, autenticidade e dispoñibilidade. O nivel resultante determina os controis aplicables, recollidos no Anexo II do RD 311/2022.

Nivel Baixo: o prexuízo por un incidente sería limitado para o organismo ou os interesados. Exemplo típico: un portal informativo sen datos persoais significativos. Nivel Medio: o prexuízo sería relevante pero non grave. Exemplo: ferramentas de tramitación administrativa con datos de cidadáns. Nivel Alto: o prexuízo sería grave ou moi grave. Exemplo: sistemas con datos de categorías especiais (saúde, antecedentes), infraestruturas críticas ou servizos públicos esenciais.

A categorización realízaa o responsable do sistema mediante unha análise de impacto formalizada. Para ferramentas de contratación pública, o máis habitual é unha categorización Media en case todas as dimensións, con algunha dimensión Alta cando se manexen datos que permitan a elaboración de perfís de licitadores ou cando o sistema sexa crítico para o servizo.

3. RXPD aplicado á contratación pública

Nun procedemento de contratación trátanse datos persoais de varias categorías: datos identificativos de licitadores e representantes, datos profesionais de técnicos asinantes, datos de solvencia, ás veces datos de traballadores adscritos ao servizo. Cada un require a súa base xurídica conforme ao artigo 6 RXPD e un prazo de conservación proporcionado ao cumprimento da LCSP e á documentación do expediente.

A LOPDGDD (Lei orgánica 3/2018) complementa o RXPD e engade obrigacións concretas para administracións públicas: delegado de protección de datos obrigatorio (art. 34 LOPDGDD), rexistro de actividades do tratamento (art. 31 LOPDGDD) e coordinación coa AEPD en caso de quebras de seguridade. Calquera software que se contrate debe integrarse correctamente neste marco.

4. O encargado do tratamento: contrato do art. 28 RXPD

Cando unha administración contrata un software como servizo, o provedor convértese en encargado do tratamento respecto aos datos persoais que procese en nome do organismo. O artigo 28 do RXPD esixe un contrato específico que debe incluír: obxecto, duración, natureza e finalidade do tratamento, tipo de datos, categorías de interesados, obrigacións do encargado e dereitos do responsable.

En contratación pública, este contrato articúlase habitualmente como unha cláusula ou anexo específico do PCAP ou do contrato formalizado tras a adxudicación. Os elementos mínimos obrigatorios son: instrucións documentadas do responsable, deber de confidencialidade do persoal do provedor, medidas técnicas e organizativas aliñadas co ENS, réxime de subcontratación con autorización previa, colaboración na atención de dereitos, notificación de quebras de seguridade en 72 horas e devolución ou supresión de datos ao final do contrato.

5. Transferencias internacionais: cando o provedor SaaS as activa

Un provedor SaaS pode implicar transferencias internacionais de datos se: aloxa os datos fóra do Espazo Económico Europeo, utiliza subcontratistas (hosting, soporte, backups) situados fóra do EEE, ou emprega modelos de IA que procesan datos en infraestrutura extracomunitaria. Calquera destes supostos activa o réxime do Capítulo V do RXPD.

As vías legais para habilitar estas transferencias son tres: decisión de adecuación da Comisión Europea, garantías adecuadas (cláusulas contractuais tipo aprobadas en 2021, normas corporativas vinculantes) ou excepcións taxadas do artigo 49 RXPD. Tras a sentenza Schrems II (C-311/18), o responsable do tratamento debe ademais realizar unha avaliación de impacto de transferencia (TIA) para verificar que a lexislación do país receptor non neutraliza as garantías contractuais.

Para unha administración pública española, a opción menos arriscada é esixir que todos os datos e o tratamento completo se localicen en infraestrutura situada dentro do EEE, idealmente con cifrado en repouso cuxas chaves xestione o propio organismo ou un terceiro europeo.

6. Como redactar requisitos ENS/RXPD no PPT do software

Os requisitos ENS/RXPD no PPT deben ser concretos, verificables e proporcionados ao obxecto do contrato. Unha cláusula xenérica como «o provedor cumprirá o ENS e o RXPD» non engade nada e é recorrible por indeterminación. Debe traducirse en esixencias operativas.

Estes requisitos, ben ponderados nos criterios de adxudicación, permiten diferenciar os provedores que cumpren formalmente dos que cumpren operativamente. Esta é unha palanca clave en contratos de software con compoñente de IA.

7. Documentación que debe achegar o provedor (CCN-CERT, declaración de aplicabilidade)

O provedor debe acreditar o cumprimento ENS con documentación formal. A vía máis sólida é a certificación ENS emitida por unha entidade acreditada por ENAC conforme ao esquema CCN-STIC-809, que cobre o nivel declarado (Baixo, Medio ou Alto). Como alternativa, admítese a autodeclaración baseada na CCN-STIC-809 con auditoría interna documentada.

Desde a óptica RXPD, o provedor debe achegar: rexistro de actividades do tratamento onde apareza o servizo ofertado, avaliación de impacto (EIPD) cando o tratamento implique alto risco, política de privacidade aplicable ao servizo, identificación do delegado de protección de datos e acreditación de medidas técnicas e organizativas (cifrado, pseudonimización, control de accesos, trazabilidade).

8. IA xenerativa e RXPD: que cambia con LLM e RAG

Os modelos de linguaxe (LLM) e as arquitecturas RAG (retrieval augmented generation) introducen cuestións novas. Primeira: se o provedor utiliza un LLM adestrado sobre datos do organismo, debe quedar claro no contrato que eses datos non se reutilizan para adestrar modelos de terceiros. Segunda: o dereito a unha decisión que non estea baseada unicamente en tratamento automatizado (art. 22 RXPD) limita o uso de IA en decisións con efectos xurídicos sobre persoas; un técnico debe conservar a responsabilidade final.

Terceira: o Regulamento de IA da UE (Regulamento 2024/1689) introduce obrigacións adicionais para sistemas de alto risco, incluídos moitos usos de IA na administración pública. Aínda que o seu calendario de aplicación é progresivo, os contratos de software con IA asinados en 2026 deben anticipalo incluíndo cláusulas de adaptación á normativa aplicable.

No sector específico da redacción de pregos, a recomendación práctica é traballar con provedores que ofrezan arquitectura RAG sobre a documentación do propio organismo, con despregamento en infraestrutura europea e garantías contractuais de non reutilización de datos. Podes ler máis sobre este enfoque na nosa páxina de como funciona LicitadIA.

9. Auditoría e mantemento: revisión bienal ENS

O ENS non é un trámite dunha soa vez. O artigo 31 do RD 311/2022 establece que os sistemas de categoría Media e Alta deben someterse a unha auditoría formal cada dous anos, ou sempre que haxa cambios substanciais no sistema. Os sistemas de categoría Baixa requiren autoavaliación co mesmo ciclo.

En contratos de longa duración con provedores SaaS, o PCAP debe prever as auditorías periódicas, a actualización da declaración de aplicabilidade cando cambien os controis aplicables e a obrigación do provedor de comunicar incidentes e cambios de infraestrutura que poidan afectar o cumprimento.

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

Un resumo de accións que recomendamos incorporar en calquera expediente de software para AAPP que trate datos persoais:

Para o caso concreto de ferramentas de IA aplicadas á redacción de pregos, LicitadIA foi deseñada desde o primeiro día con este marco en mente: despregamento europeo, contrato de encargado do tratamento listo, non reutilización de datos para adestramento e compatibilidade cos controis ENS do Nivel Medio.

Se queres revisar a documentación ENS e RXPD antes de propoñer un piloto, o máis directo é contactar connosco indicando o teu organismo e o tipo de contratos que manexas.

Preguntas frecuentes