ENS i RGPD en contractació pública: requisits per a eines digitals

1. Per què ENS i RGPD són inseparables en programari per a AAPP

ENS i RGPD són dos règims amb lògiques complementàries. L'ENS fixa els controls de seguretat que ha d'aplicar un sistema d'informació del sector públic: autenticació, xifratge, traçabilitat, continuïtat, auditoria. L'RGPD regula el tractament de dades personals des de l'òptica dels drets de l'interessat: licitud, minimització, finalitat, responsabilitat proactiva.

En un contracte de programari per a una administració pública, tots dos règims s'apliquen simultàniament: l'ENS perquè el sistema forma part de l'ecosistema digital de l'administració; l'RGPD perquè, a la pràctica, gairebé qualsevol programari administratiu acaba tractant dades personals (dades de licitadors, tècnics municipals, ciutadans). Tractar-los per separat és un dels errors habituals en la redacció de PPT.

2. ENS — RD 311/2022: nivells Baix, Mitjà, Alt i quan s'aplica cada un

L'ENS classifica els sistemes en tres nivells de seguretat (Baix, Mitjà, Alt) per a cada una de les cinc dimensions: confidencialitat, integritat, traçabilitat, autenticitat i disponibilitat. El nivell resultant determina els controls aplicables, recollits a l'annex II del RD 311/2022.

Nivell Baix: el perjudici per un incident seria limitat per a l'organisme o els interessats. Exemple típic: un portal informatiu sense dades personals significatives. Nivell Mitjà: el perjudici seria rellevant però no greu. Exemple: eines de tramitació administrativa amb dades de ciutadans. Nivell Alt: el perjudici seria greu o molt greu. Exemple: sistemes amb dades de categories especials (salut, antecedents), infraestructures crítiques o serveis públics essencials.

La categorització la fa el responsable del sistema mitjançant una anàlisi d'impacte formalitzada. Per a eines de contractació pública, el més habitual és una categorització Mitjana en gairebé totes les dimensions, amb alguna dimensió Alta quan es gestionin dades que permetin el perfilat de licitadors o quan el sistema sigui crític per al servei.

3. RGPD aplicat a la contractació pública

En un procediment de contractació es tracten dades personals de diverses categories: dades identificatives de licitadors i representants, dades professionals de tècnics signants, dades de solvència, a vegades dades de treballadors adscrits al servei. Cada una requereix la seva base jurídica d'acord amb l'article 6 RGPD i un termini de conservació proporcionat al compliment de la LCSP i a la documentació de l'expedient.

La LOPDGDD (Llei orgànica 3/2018) complementa l'RGPD i afegeix obligacions concretes per a les administracions públiques: delegat de protecció de dades obligatori (art. 34 LOPDGDD), registre d'activitats del tractament (art. 31 LOPDGDD) i coordinació amb l'AEPD en cas de bretxes. Qualsevol programari que es contracti s'ha d'integrar correctament en aquest marc.

4. L'encarregat del tractament: contracte de l'art. 28 RGPD

Quan una administració contracta un programari com a servei, el proveïdor es converteix en encarregat del tractament respecte de les dades personals que processi en nom de l'organisme. L'article 28 de l'RGPD exigeix un contracte específic que ha d'incloure: objecte, durada, naturalesa i finalitat del tractament, tipus de dades, categories d'interessats, obligacions de l'encarregat i drets del responsable.

En contractació pública, aquest contracte s'articula habitualment com una clàusula o un annex específic del PCAP o del contracte formalitzat després de l'adjudicació. Els elements mínims obligatoris són: instruccions documentades del responsable, deure de confidencialitat del personal del proveïdor, mesures tècniques i organitzatives alineades amb l'ENS, règim de subcontractació amb autorització prèvia, col·laboració en l'atenció de drets, notificació de bretxes en 72 hores i devolució o supressió de dades al final del contracte.

5. Transferències internacionals: quan el proveïdor SaaS les activa

Un proveïdor SaaS pot implicar transferències internacionals de dades si: allotja les dades fora de l'Espai Econòmic Europeu, utilitza subcontractistes (allotjament, suport, còpies de seguretat) ubicats fora de l'EEE, o fa servir models d'IA que processen dades en infraestructura extracomunitària. Qualsevol d'aquests supòsits activa el règim del capítol V de l'RGPD.

Les vies legals per habilitar aquestes transferències són tres: decisió d'adequació de la Comissió Europea, garanties adequades (clàusules contractuals tipus aprovades el 2021, normes corporatives vinculants) o excepcions taxades de l'article 49 RGPD. Després de la sentència Schrems II (C-311/18), el responsable del tractament ha de fer, a més, una avaluació d'impacte de transferència (TIA) per verificar que la legislació del país receptor no neutralitza les garanties contractuals.

Per a una administració pública espanyola, l'opció menys arriscada és exigir que totes les dades i el tractament complet es localitzin en infraestructura ubicada dins de l'EEE, idealment amb xifratge en repòs les claus del qual gestioni l'organisme mateix o un tercer europeu.

6. Com redactar requisits ENS/RGPD al PPT del programari

Els requisits ENS/RGPD al PPT han de ser concrets, verificables i proporcionats a l'objecte del contracte. Una clàusula genèrica com «el proveïdor complirà l'ENS i l'RGPD» no afegeix res i és recurrible per indeterminació. S'ha de traduir en exigències operatives.

Aquests requisits, ben ponderats en els criteris d'adjudicació, permeten diferenciar els proveïdors que compleixen formalment dels que compleixen operativament. Aquesta és una palanca clau en contractes de programari amb component d'IA.

7. Documentació que ha d'aportar el proveïdor (CCN-CERT, declaració d'aplicabilitat)

El proveïdor ha d'acreditar el compliment de l'ENS amb documentació formal. La via més sòlida és la certificació ENS emesa per una entitat acreditada per ENAC d'acord amb l'esquema CCN-STIC-809, que cobreix el nivell declarat (Baix, Mitjà o Alt). Com a alternativa, s'admet l'autodeclaració basada en la CCN-STIC-809 amb auditoria interna documentada.

Des de l'òptica de l'RGPD, el proveïdor ha d'aportar: registre d'activitats del tractament on aparegui el servei ofert, avaluació d'impacte (EIPD) quan el tractament impliqui un alt risc, política de privacitat aplicable al servei, identificació del delegat de protecció de dades i acreditació de mesures tècniques i organitzatives (xifratge, pseudonimització, control d'accessos, traçabilitat).

8. IA generativa i RGPD: què canvia amb LLM i RAG

Els models de llenguatge (LLM) i les arquitectures RAG (retrieval augmented generation) introdueixen qüestions noves. Primera: si el proveïdor utilitza un LLM entrenat amb dades de l'organisme, ha de quedar clar al contracte que aquestes dades no es reutilitzen per entrenar models de tercers. Segona: el dret a una decisió que no estigui basada únicament en el tractament automatitzat (art. 22 RGPD) limita l'ús de la IA en decisions amb efectes jurídics sobre persones; un tècnic ha de conservar la responsabilitat final.

Tercera: el Reglament d'IA de la UE (Reglament 2024/1689) introdueix obligacions addicionals per a sistemes d'alt risc, inclosos molts usos de la IA en l'administració pública. Tot i que el seu calendari d'aplicació és progressiu, els contractes de programari amb IA signats el 2026 l'han d'anticipar incloent-hi clàusules d'adaptació a la normativa aplicable.

En el sector específic de la redacció de plecs, la recomanació pràctica és treballar amb proveïdors que ofereixin arquitectura RAG sobre la documentació de l'organisme mateix, amb desplegament en infraestructura europea i garanties contractuals de no reutilització de dades. Pots llegir més sobre aquest enfocament a la nostra pàgina de com funciona LicitadIA.

9. Auditoria i manteniment: revisió bienal ENS

L'ENS no és un tràmit d'una sola vegada. L'article 31 del RD 311/2022 estableix que els sistemes de categoria Mitjana i Alta s'han de sotmetre a una auditoria formal cada dos anys, o sempre que hi hagi canvis substancials en el sistema. Els sistemes de categoria Baixa requereixen una autoavaluació amb el mateix cicle.

En contractes de llarga durada amb proveïdors SaaS, el PCAP ha de preveure les auditories periòdiques, l'actualització de la declaració d'aplicabilitat quan canviïn els controls aplicables i l'obligació del proveïdor de comunicar incidents i canvis d'infraestructura que puguin afectar el compliment.

10. Llista de comprovació pràctica per a un òrgan de contractació

Un resum d'accions que recomanem incorporar en qualsevol expedient de programari per a AAPP que tracti dades personals:

Per al cas concret d'eines d'IA aplicades a la redacció de plecs, LicitadIA ha estat dissenyada des del primer dia amb aquest marc en ment: desplegament europeu, contracte d'encarregat del tractament a punt, no reutilització de dades per a entrenament i compatibilitat amb els controls ENS del Nivell Mitjà.

Si vols revisar la documentació ENS i RGPD abans de plantejar un pilot, el més directe és contactar amb nosaltres indicant el teu organisme i el tipus de contractes que gestiones.

Preguntes freqüents