La lliçó anterior va tancar el mapa normatiu assenyalant l'única norma que arriba a Nimbus sempre, sense llindars de mida i sense dependre de cap client. I amb una particularitat que en multiplica l'exigència: l'historial de cites d'una clínica de fisioteràpia revela informació sobre la salut d'una persona, encara que a la base de dades només hi hagi un nom, un telèfon i una data. Aquesta lliçó baixa al detall pràctic: qui respon de què, quins principis obliguen, com s'atén un dret de debò —inclosa la pregunta incòmoda de com s'esborra algú que és dins d'una còpia de seguretat—, quins documents cal tenir escrits, i què passa exactament durant les 72 hores següents a descobrir una bretxa.

⚠️ Nota de validació — llegeix-la abans de continuar

Aquesta lliçó és material formatiu i no constitueix assessorament jurídic. Les plantilles, criteris i exemples que conté són didàctics i estan construïts sobre una empresa fictícia. L'aplicació real del RGPD depèn dels tractaments concrets, del sector, dels contractes i de la interpretació de l'autoritat de control, i les normes i les seves guies s'actualitzen. Abans de prendre qualsevol decisió: verifica la versió vigent del Reglament (UE) 2016/679, de la LO 3/2018 (LOPDGDD) i de les guies de l'AEPD, i valida-ho amb un professional —advocat especialitzat en protecció de dades, delegat de protecció de dades (DPD) o responsable de compliment—. Un error en aquest terreny no es corregeix amb un pedaç.

1. Per què aquesta lliçó importa especialment a Nimbus
2. Conceptes amb precisió: personal, pseudonimitzat, anònim
3. Responsable i encarregat: Nimbus és les dues coses
4. Els principis de l'article 5, aplicats
5. Bases jurídiques: article 6 i l'article 9 per a dades de salut
6. Drets de les persones i com s'atenen de debò
7. Obligacions documentals: el RAT i l'Avaluació d'Impacte
8. Privacitat des del disseny i per defecte
9. L'article 32 i per què el mòdul 5 n'és la resposta
10. Encarregats, subencarregats i el contracte de l'article 28
11. Transferències internacionals
12. Notificació de bretxes i l'incident de 02-06 sota el RGPD
13. El DPD, el règim sancionador i la relació amb les clíniques

A la base de dades A-01 no hi ha diagnòstics, ni informes mèdics, ni receptes. Hi ha noms, correus, telèfons i una taula de cites amb data, hora i centre. Un desenvolupador raonable diria que això són dades de contacte i una agenda. I tanmateix: si el centre és una clínica de fisioteràpia, saber que una persona concreta hi va tots els dimarts des de fa quatre mesos revela informació sobre la seva salut. No cal el diagnòstic. La dada relativa a la salut no és només la que descriu una patologia, sinó qualsevol que permeti deduir informació sobre l'estat de salut d'una persona identificada o identificable. I les dades de salut són una categoria especial de l'article 9, el tractament de les quals està prohibit amb caràcter general llevat que concorri una de les excepcions taxades de l'apartat 2.

Això té tres conseqüències que travessen tota la lliçó i expliquen per què Nimbus no pot tractar aquest assumpte com una pime qualsevol: la base jurídica és més exigent, perquè no n'hi ha prou amb l'article 6 i cal a més una excepció del 9.2; l'Avaluació d'Impacte és probablement obligatòria, perquè hi ha tractament a gran escala de categories especials (apartat 7); i el llindar de risc per notificar una bretxa als afectats baixa molt, perquè el risc per als drets i llibertats d'una fuita de dades de salut és alt gairebé per definició (apartat 12).

I un matís d'arquitectura que convé fixar des d'ara: el mateix camp té naturalesa diferent segons el client. Una cita en un gimnàs és una cita; la mateixa fila, amb tenant_id d'una clínica, revela salut. Aplicar dos nivells de protecció segons el tenant complica la vida enormement, així que la decisió correcta és tractar tot l'historial de cites amb el nivell de la categoria especial —cosa que ja es va decidir tècnicament a 03-07 amb el xifratge a nivell de camp de les notes clíniques—.

Aquestes quatre definicions decideixen si el RGPD aplica o no a un conjunt de dades, i es confonen constantment.

El punt que causa més errors, i que ja es va anticipar a 03-07: la pseudonimització no treu les dades del RGPD. És una mesura de seguretat excel·lent —l'article 32.1.a la cita expressament— i redueix l'impacte d'una bretxa, però mentre existeixi en algun lloc la clau que permeti revertir-la, continua havent-hi dada personal i continuen aplicant-se tots els drets i obligacions. Molts projectes es dissenyen sobre la creença contrària i descobreixen tard que la seva «base de dades anonimitzada d'analítica» és una base de dades personal sense base jurídica. L'anonimització real, en canvi, és difícil: cal eliminar no només els identificadors directes, sinó la possibilitat de reidentificació per combinació. Si Nimbus publica un panell amb «pacients per franja horària, centre i codi postal», una franja amb dues persones en un codi postal petit identifica algú; i les tècniques que ho eviten —agregació amb llindar mínim, generalització, soroll— destrueixen part de la utilitat de la dada. D'aquí la regla pràctica per a l'equip de l'Iván: davant el dubte, és dada personal. El cost de tractar com a personal una cosa que no ho era és documentació; el de l'error contrari és una infracció.

Aquesta distinció determina qui respon de què, i és l'error conceptual més freqüent en un SaaS. Responsable del tractament és qui decideix les finalitats i els mitjans —per a què es tracten les dades i com, en allò essencial—; encarregat és qui les tracta per compte del responsable, seguint les seves instruccions documentades.

Nimbus porta dos barrets alhora, i confondre'ls és car:

La conseqüència pràctica més important, i la que cal gravar-se: si Nimbus fes servir l'historial de cites de les clíniques per millorar el seu producte, entrenar un model predictiu o elaborar informes de mercat, deixaria de ser encarregat i passaria a ser responsable d'aquest tractament —sense base jurídica, sense informació als pacients i amb dades de categoria especial—. És una de les infraccions més greus que pot cometre un SaaS, i passa moltes vegades sense mala fe, simplement perquè a algú de producte li sembla una bona idea; per això convé que estigui escrit a POL-05 i a la formació de desenvolupament de 06-05. I una precisió que sol sorprendre: l'encarregat no està exempt de responsabilitat. L'article 82 permet que un interessat reclami directament a l'encarregat quan incompleix obligacions que el Reglament li imposa específicament o actua fora de les instruccions del responsable. Ser encarregat no és un escut.

Els sis principis més el setè que els governa, amb la seva traducció a decisions concretes de Nimbus:

Minimització: cal el DNI per reservar una sessió de fisioteràpia? L'exercici mental s'ha de fer camp per camp, i gairebé sempre sobren coses:

La conclusió de disseny és contraintuïtiva per a molta gent de producte: el camp més segur és el que no existeix. Un DNI que no es recull no es pot filtrar, no cal xifrar-lo, no apareix en una bretxa i no cal esborrar-lo. Cada camp eliminat del formulari redueix alhora el risc, la feina de compliment i l'impacte d'un incident.

Política de retenció de Nimbus (exemple didàctic; els terminis reals s'han de fixar amb assessoria i, en el cas de les dades de pacients, els decideix la clínica responsable, no Nimbus):

Dues disciplines separen una política de retenció real d'una de decorativa: els terminis s'executen sols —un cron o una política de cicle de vida, no un recordatori per a la Lucía— i cada termini té una justificació escrita. «Per si de cas» no ho és; conservar indefinidament incompleix l'article 5.1.e i és el que converteix una bretxa petita en una de gran.

Tota operació necessita almenys una base jurídica de l'article 6, i no es poden acumular a conveniència: se'n tria una, es documenta i es comunica.

Per què el consentiment no és la millor base gairebé mai, sent la que tothom anomena primer: és revocable en qualsevol moment i amb la mateixa facilitat amb què es va donar, cosa que deixa el responsable en una situació impossible si el tractament era imprescindible; ha de ser lliure, i si no es pot fer servir el servei sense consentir, generalment no ho és —condicionar la reserva al consentiment de màrqueting és el vici clàssic—; i cal poder demostrar que es va obtenir: qui, quan, amb quin text exacte i quina versió. Per al nucli del servei la base correcta sol ser l'execució del contracte (6.1.b) per a les cites i l'interès legítim (6.1.f) per als registres de seguretat, amb la ponderació escrita. El consentiment queda per al que realment és opcional: comunicacions comercials, cookies analítiques, funcionalitats accessòries.

L'article 9 i les dades de salut. El tractament de categories especials està prohibit, llevat d'excepció del 9.2. Les rellevants aquí: a) consentiment explícit —via freqüent en l'àmbit privat, i «explícit» exigeix manifestació clara i específica, no una casella genèrica—; h) medicina preventiva, diagnòstic o assistència sanitària, la via natural d'un centre sanitari i subjecta al secret professional del 9.3; f) reclamacions; i i) salut pública, pròpia d'autoritats.

Nota important: l'excepció de l'article 9 no substitueix la base de l'article 6, s'hi suma; calen totes dues. I qui les determina per a les dades de pacients és la clínica responsable, no Nimbus. El que sí que ha de fer Nimbus són dues coses: no imposar un disseny que obligui la clínica a una base inadequada —per exemple, un camp obligatori de motiu clínic— i documentar al contracte que no farà servir aquestes dades per a finalitats pròpies.

Nota de validació. L'elecció de base jurídica i d'excepció de l'article 9 és una decisió jurídica amb conseqüències sancionadores. Aquesta taula és orientativa: consulta-ho amb un DPD o advocat.

El termini és d'un mes des de la recepció, prorrogable dos mesos més per complexitat o nombre de sol·licituds, informant de la pròrroga i dels seus motius dins del primer mes; la resposta és gratuïta llevat de sol·licituds manifestament infundades o excessives. I aquests són els tres problemes operatius reals, on fallen les organitzacions:

(a) Verificar la identitat sense demanar de més. Si algú escriu demanant totes les dades d'una altra persona, atendre'l sense verificar és una bretxa; però demanar còpia del DNI per sistema és recollir una dada nova i excessiva. El criteri és fer servir mitjans que ja es tenen: si la persona escriu des del correu associat al seu compte i confirma amb un codi enviat a aquell correu o al telèfon registrat, la identitat està raonablement acreditada. Només davant de dubtes fonamentats es demana informació addicional, i proporcionada.

(b) A qui s'adreça la sol·licitud. Un pacient d'una clínica que escriu a Nimbus s'adreça a l'encarregat, no al responsable, i Nimbus no la pot resoldre pel seu compte: l'ha de redirigir a la clínica sense dilació i assistir-la (art. 28.3.e). Respondre directament seria actuar fora d'instruccions.

(c) La supressió quan hi ha còpies de seguretat, el problema tècnic que gairebé ningú no explica bé. Si un pacient demana la seva supressió i Nimbus té còpies diàries amb 35 dies de retenció i Object Lock en mode COMPLIANCE (05-07), la dada continuarà existint dins d'aquestes còpies i no se'n pot esborrar —aquesta immutabilitat és precisament el que protegeix davant del ransomware—. La solució acceptada per la pràctica, sempre que es documenti: (1) supressió efectiva i immediata en els sistemes actius —base de dades, buckets, índexs, memòries cau i tercers que hagin rebut la dada—; (2) les còpies es declaren «congelades»: no s'esborren, però no es fan servir per reintroduir la dada; (3) la sol·licitud es registra en una llista de supressions pendents que sobreviu a la restauració; (4) el procediment de restauració inclou reaplicar aquestes supressions abans de tornar el servei, escrit al runbook de 04-06 perquè el que no està escrit no es farà enmig d'una crisi; (5) les còpies expiren soles als 35 dies i allà la supressió és total; i (6) s'informa l'interessat d'aquest termini residual.

Plantilla de procediment d'atenció de drets:

És el document que l'AEPD demana primer en qualsevol actuació, i no tenir-lo és en si mateix una infracció. Encara que l'article 30.5 preveu una excepció per a organitzacions de menys de 250 empleats, decau quan el tractament no és ocasional o inclou categories especials —totes dues coses certes aquí—, així que Nimbus està obligat a portar-lo, en la seva doble condició de responsable (art. 30.1) i d'encarregat (art. 30.2).

Dues advertències: el RAT és un document viu —s'actualitza quan canvia un tractament, un subencarregat o un termini, i la seva data de revisió és el primer que es mira— i no és un exercici literari: si diu que les notes van xifrades a nivell de camp, un inspector pot demanar que es demostri.

És obligatòria quan el tractament comporti un alt risc per als drets i llibertats, i l'article 35.3 presumeix aquest risc en tres supòsits: avaluació sistemàtica basada en tractament automatitzat amb efectes significatius, tractament a gran escala de categories especials i observació sistemàtica a gran escala de zones d'accés públic. A ells s'hi suma la llista de tipus de tractament que requereixen AIPD publicada per l'AEPD —consulta-la en la seva versió vigent—.

Nimbus la necessita? Amb altíssima probabilitat sí, i qui l'ha de fer és cada clínica responsable, amb l'assistència de Nimbus que exigeix l'article 28.3.f. El raonament: hi ha tractament de dades que revelen salut, a escala rellevant (desenes de centres, milers de pacients), a distància i amb subencarregats, un d'ells fora de l'EEE. Reuneix diversos criteris alhora, i quan en concorren dos o més la resposta pràctica és fer-la. Nimbus té un interès propi molt clar a fer la seva pròpia AIPD del producte, encara que sigui encarregat: es converteix en un lliurable comercial que els seus clients reutilitzen, estalvia a cada clínica començar de zero i respon per avançat a mitja dotzena de qüestionaris. Contingut mínim (art. 35.7), traduït:

L'error més comú en una AIPD mereix subratllar-se: copiar l'anàlisi de riscos de seguretat. Són anàlisis diferents. A 04-01 l'impacte es mesurava en euros per a Nimbus; en una AIPD es mesura en dany a les persones —discriminació laboral si se sap que algú va a rehabilitació, dany reputacional, angoixa, pèrdua de control sobre dades íntimes—. El mateix incident té dos impactes diferents i s'han de valorar tots dos. I si després de les mesures el risc residual continua sent alt, escau la consulta prèvia a l'AEPD de l'article 36.

L'article 25 exigeix mesures des del disseny —en determinar els mitjans i durant el tractament— i per defecte —que només es tractin les dades necessàries per a cada finalitat, sense intervenció de l'usuari—. Traduït a decisions de producte de Nimbus:

L'última fila és la més important i la més barata: convertir «aquesta dada és necessària?» en un element de la plantilla de pull request de 06-01. És privacitat des del disseny implementada com a hàbit, i costa una línia de text.

L'article 32 exigeix «mesures tècniques i organitzatives apropiades per garantir un nivell de seguretat adequat al risc», i n'esmenta expressament quatre: pseudonimització i xifratge; confidencialitat, integritat, disponibilitat i resiliència permanents; capacitat de restaurar ràpidament després d'un incident; i un procés de verificació, avaluació i valoració regulars de l'eficàcia. No imposa tecnologies concretes: obliga a decidir en funció del risc i poder justificar la decisió, i tota la feina tècnica del curs és exactament aquesta justificació:

L'article 32.1.d mereix atenció especial perquè és el que gairebé ningú no compleix: no n'hi ha prou amb implantar, cal verificar regularment l'eficàcia. És la tesi de 06-01 —el control no provat està «planificat»— i l'objecte sencer de 06-04. Un responsable que davant l'AEPD diu «tenim còpies» i no pot ensenyar un informe de restauració datat no compleix el 32.1.c ni el 32.1.d, encara que les còpies existeixin.

L'article 28 exigeix que la relació amb un encarregat es regeixi per un contracte o un altre acte jurídic amb contingut mínim taxat: és el document que determina què pot fer Nimbus amb les dades de les clíniques, i el que aquestes exigiran en cada renovació. Contingut obligatori (art. 28.3), amb la seva redacció pràctica:

La cadena de subencarregats és on s'acumulen els problemes. Nimbus subcontracta tres proveïdors que toquen dades —cloud (A-05), correu transaccional (A-11) i consultora de sistemes (A-19)— i les regles dels articles 28.2 i 28.4 són tres. Primera: cal autorització del responsable, específica o general per escrit, i si és general s'ha d'informar de qualsevol incorporació o canvi i permetre oposar-s'hi —la pràctica sana és una llista pública de subencarregats amb avís de 30 dies—. Segona: al subencarregat se li imposen les mateixes obligacions que Nimbus va assumir davant la clínica; no es pot prometre al client més del que s'exigeix al proveïdor. I tercera, la que canvia la conversa de 04-04: Nimbus continua responent plenament davant la clínica del compliment del subencarregat. Externalitzar l'execució no externalitza la responsabilitat, i l'incident de 02-06 n'és l'exemple perfecte: Nimbus va respondre davant els seus clients d'una fallada que va passar a casa d'un altre.

Nota de validació. Els contractes de l'article 28, els seus annexos i les clàusules d'auditoria i responsabilitat tenen efectes jurídics i econòmics directes. No es redacten amb una plantilla d'Internet: es validen amb assessoria jurídica, i convé revisar les clàusules contractuals tipus que la Comissió Europea té publicades per a relacions responsable-encarregat.

El capítol V regula les transferències fora de l'Espai Econòmic Europeu, i l'important per a una pime és que passen constantment sense que ningú se n'adoni: n'hi ha prou que un proveïdor SaaS allotgi dades fora, o que el seu personal de suport hi accedeixi des d'un tercer país. L'accés remot des de fora de l'EEE és una transferència, encara que els servidors siguin a Frankfurt. Aquest matís s'oblida sempre.

Quan es fan servir CCT cal fer a més una avaluació d'impacte de la transferència (TIA): analitzar si la legislació del país de destinació permet accessos per autoritats que buidin de contingut les garanties, i afegir mesures suplementàries si cal —xifratge amb claus retingudes a l'EEE, pseudonimització, minimització del que es transfereix—. El cas concret de Nimbus. El proveïdor de correu transaccional (A-11) rep nom, adreça de correu i el text del recordatori, i tres mesures de minimització redueixen el problema fins a fer-lo manejable. No enviar mai el motiu de la cita: el text mínim de l'apartat 8 no és només bona pràctica, redueix la categoria de dades transferides i treu la salut de la transferència. No enviar el nom del centre quan revela especialitat sanitària: «Té una cita el dimarts a les 17:00» amb un enllaç autenticat transfereix molt menys que «Cita a Clínica de Rehabilitació Neurològica». I avaluar un proveïdor allotjat a la UE, on sovint el cost és similar i la transferència desapareix: la millor gestió d'una transferència internacional sol ser no fer-la.

Una violació de la seguretat de les dades personals és tota violació que ocasioni destrucció, pèrdua o alteració accidental o il·lícita, o comunicació o accés no autoritzats. Fixa-t'hi bé: no cal un atacant. Un correu amb la llista de pacients al destinatari equivocat és una bretxa; un portàtil sense xifrar perdut és una bretxa; una fallada d'aïllament entre tenants que deixa un client veure dades d'un altre és una bretxa.

Contingut mínim (art. 33.3): naturalesa de la violació, categories i nombre aproximat d'interessats i de registres; contacte del DPD; conseqüències probables; i mesures adoptades o proposades, incloses les de mitigació. Si no es disposa de tot, es pot facilitar de manera esglaonada —possibilitat clau, perquè el rellotge no s'atura mentre s'investiga—. I el registre intern de bretxes de l'article 33.5 és obligatori SEMPRE, es notifiqui o no: fins i tot la bretxa que es decideix no notificar es documenta amb fets, efectes, mesures correctives i el raonament de per què no escaïa notificar. És el primer que demana l'AEPD quan arriba per una altra via, i la seva absència agreuja qualsevol expedient.

Recordem: entrada per l'accés remot de la consultora (A-19), robatori d'un .env, exfiltració d'1,2 TB, esborrament de còpies, 20 dies de dwell time i descobriment el dia 20 a les 09:00.

Les cinc lliçons jurídiques del cas:

1. El rellotge arrenca amb el «coneixement», no amb la certesa. Nimbus en va tenir coneixement el dia 20 a les 09:00, quan va saber amb raonable certesa que hi havia hagut una violació. Esperar a saber-ho tot és l'error que multiplica les sancions. Es pot notificar de manera esglaonada; no es pot començar tard.
2. La notificació esglaonada existeix precisament per a això. El dia 22 l'abast continuava indeterminat. La resposta correcta no és callar: és notificar el que se sap, dir que la investigació continua i ampliar.
3. Nimbus, com a encarregat, no notifica a l'AEPD: notifica a cada clínica. Són elles, com a responsables, les que notifiquen. Amb una conseqüència operativa brutal: el retard de Nimbus consumeix el termini dels seus 40 clients. Per això el contracte ha de fixar un termini intern curt —24 hores sol ser el que es pacta— i per això Nimbus ha de lliurar informació utilitzable, no un correu vague.
4. El xifratge com a excepció de l'article 34 no salva aquí. L'excepció exigeix que les dades siguin inintel·ligibles per a l'atacant. Si l'atacant va robar un .env amb les credencials de l'aplicació i va exfiltrar a través de la mateixa aplicació, les dades li van arribar desxifrades. Xifrar en repòs protegeix davant del robatori del disc o del bucket, no davant d'un atacant que té les claus. Aquesta distinció decideix si cal comunicar-ho a milers de persones o no, i es decideix en el disseny, mesos abans.
5. Els 20 dies de dwell time agreugen la valoració. L'article 83.2 pondera, entre altres criteris, la naturalesa i gravetat, la intencionalitat o negligència, les mesures per mitigar el dany, el grau de responsabilitat atenent les mesures tècniques i organitzatives aplicades (arts. 25 i 32) i la cooperació. Vint dies sense detectar, amb set oportunitats perdudes, apunten directament a la insuficiència de les mesures de l'article 32.

Plantilla de comunicació als afectats (art. 34). Ha de fer servir llenguatge clar i senzill, no jurídic:

Quatre decisions de redacció que convé copiar: no es minimitza —«un incident sense conseqüències» destrueix la confiança quan se'n sap més—, es diu explícitament què NO està afectat, s'adverteix del risc real i concret —phishing dirigit fent servir el mateix historial de cites— i es donen accions concretes en lloc de recomanacions genèriques.

Necessita Nimbus un delegat de protecció de dades? L'article 37.1 el fa obligatori en tres supòsits —autoritats públiques; observació habitual i sistemàtica a gran escala com a activitat principal; i tractament a gran escala de categories especials com a activitat principal—, i la LOPDGDD (art. 34) hi afegeix una llista d'entitats obligades. A Nimbus l'anàlisi honesta és que l'activitat principal consisteix a tractar, per compte de tercers, dades de les quals es deriven dades de salut, a una escala rellevant. Encara que el seu paper sigui d'encarregat —i l'article 37 aplica «al responsable i a l'encarregat»—, la conclusió raonable és que probablement sí que hi està obligat, i en qualsevol cas designar-lo és defensable i barat: un DPD extern (2.000-5.000 €/any) aporta a més criteri jurídic independent. Requisits que no es poden oblidar: independència funcional, absència de conflicte d'interessos —la Marta no pot ser DPD, perquè decideix sobre els tractaments que hauria de supervisar— i publicació de les seves dades de contacte, comunicades a l'AEPD.

Règim sancionador (art. 83). Dos nivells:

Els percentatges es calculen sobre el volum de negoci del grup empresarial, no de la filial, i l'AEPD disposa a més d'altres mesures de vegades més greus que la multa: limitació o ordre de cessament del tractament, que per a un SaaS equival a apagar el producte. Què mira l'AEPD a la pràctica, amb criteri realista per a una pime: poques vegades arriba d'ofici a una empresa de 38 persones. Hi arriba per reclamació d'un interessat o per notificació de bretxa. I un cop dins, el primer que demana és un conjunt molt predictible de documents: RAT, política de privacitat i informació a l'interessat, contractes de l'article 28, registre de bretxes, AIPD si escau, i evidència de les mesures de l'article 32. La ponderació de l'article 83.2 valora expressament la cooperació i les mesures adoptades per mitigar, així que la diferència entre una sanció greu i un advertiment sol estar a poder demostrar diligència amb documents datats abans de l'incident. És exactament el que es construeix a 06-04.

La relació amb les clíniques: qui notifica a qui. És on hi ha més confusió, i el contracte ho ha de resoldre amb un quadre com aquest:

El termini de 24 hores del contracte no és negociable a la baixa: si Nimbus notifica a les 60 hores, deixa a cada clínica 12 per investigar, valorar i notificar a l'AEPD, cosa materialment impossible, i les 40 incomplirien per culpa del seu proveïdor. És l'argument amb què la Marta defensa internament el runbook: el rellotge de Nimbus no és el seu, és el dels seus clients.

• Creure que pseudonimitzar treu les dades del RGPD. No ho fa: és una mesura de seguretat excel·lent, no una via d'escapament.
• Confondre els dos barrets. Fer servir dades de pacients de les clíniques per a analítica de producte o per entrenar un model converteix Nimbus en responsable sense base jurídica i amb categories especials. És de les infraccions més greus possibles, i passa sense mala fe.
• Triar el consentiment per defecte. És revocable, ha de ser lliure i s'ha de demostrar. Per al nucli del servei: contracte, o interès legítim amb ponderació documentada.
• Demanar còpia del DNI per atendre un dret d'accés. És recollir una dada nova i excessiva: fes servir els mitjans que ja tens. I tingues resolt el problema de les còpies de seguretat en la supressió —llista de supressions pendents, reaplicació després de restaurar escrita al runbook, expiració—.
• Esperar a saber-ho tot per notificar. El rellotge corre des del coneixement. Existeix la notificació esglaonada precisament per això.
• Confiar que «les dades estaven xifrades» eximeix de comunicar-ho als afectats. Només si eren inintel·ligibles per a l'atacant. Si va robar les credencials de l'aplicació, no ho eren.
• Consell: comença pel RAT. És obligatori, és el primer que es demana, i escriure'l revela tractaments que ningú no havia pensat, terminis que ningú no havia fixat i subencarregats que ningú no havia autoritzat. I fes l'AIPD del producte encara que siguis encarregat. Es converteix en un lliurable comercial que els teus clients reutilitzen i respon per avançat a mitja dotzena de qüestionaris. I minimitza al formulari abans que a l'arquitectura: cada camp que elimines redueix alhora el risc, el compliment i l'impacte d'una bretxa. És la mesura més barata que existeix.

Exercici 1 — El nou mòdul de recordatoris intel·ligents

Producte proposa una funcionalitat: analitzar l'historial de cites de tots els tenants per predir quins pacients faltaran i enviar-los un recordatori addicional, millorant l'ocupació dels centres. L'Iván ja té el model entrenat amb dades de producció de les 40 clíniques. Analitza la proposta: rol de Nimbus, base jurídica, article 9, principis de l'article 5 compromesos, article 22 i què ha de fer la Marta. Indica si hi ha alguna forma legítima d'oferir-la i amb quines condicions.

Exercici 2 — Una bretxa petita

El Rubén, a suport, respon a la consulta d'una clínica adjuntant per error un llistat en Excel amb 312 pacients d'una altra clínica —nom, telèfon i dates de les seves cites—. Ho detecta ell mateix 40 minuts després i avisa. El destinatari és l'administrativa d'un centre client, que confirma per telèfon haver esborrat el correu sense obrir l'adjunt. Decideix, raonant cada pas: és una bretxa? qui és responsable i qui encarregat? cal notificar-ho a l'AEPD? i als 312 pacients? què es documenta en qualsevol cas? quina acció correctiva escau?

Exercici 3 — Dret de supressió amb complicacions

Arriba a [email protected] aquest missatge: «Sóc pacient de Clínica Fisio Valencia. Vull que esborrin totes les meves dades del seu sistema immediatament. També vull saber qui ha consultat el meu historial de cites l'últim any. I em nego que les meves dades siguin als Estats Units.» Redacta el pla d'actuació indicant quins drets s'exerceixen, qui atén cadascun, terminis, com es verifica la identitat, i com es resol tècnicament cada punt —inclòs el problema de les còpies de seguretat i el del proveïdor de correu—.

Exercici 1

El veredicte: tal com està plantejada, la funcionalitat és il·lícita, i a més ja s'ha comès una infracció en entrenar el model amb dades de producció. Rol i base jurídica. Nimbus decideix per si mateix la finalitat (millorar l'ocupació, millorar el seu producte) i els mitjans (el model), cosa que el converteix en responsable d'aquest tractament i no en encarregat —l'article 28.10 ho diu expressament—. I com a responsable no té cap base jurídica: no hi ha contracte amb els pacients, no hi ha consentiment, i l'interès legítim no pot prevaler sobre els drets de persones les dades de les quals revelen salut en un tractament que no esperen en absolut. Tractar les dades per a una finalitat pròpia és a més actuar fora de les instruccions documentades (art. 28.3.a) i incompliment contractual davant les 40 clíniques.

Articles 9, 5 i 22. Són dades que revelen salut i caldria una excepció del 9.2: cap no hi encaixa, perquè no hi ha consentiment explícit i l'excepció sanitària (9.2.h) cobreix l'assistència, no l'optimització comercial de l'agenda d'un proveïdor de programari. De l'article 5 es vulneren la limitació de la finalitat de manera flagrant —predir absències és incompatible amb gestionar reserves—, la licitud i transparència i la minimització. L'article 22 no s'activa si només s'envia un recordatori addicional, però sí que hi entraria de ple si el model derivés en penalitzacions, pagament anticipat o pèrdua de prioritat. I hi ha una infracció ja consumada: el model entrenat és fruit d'un tractament il·lícit i els models poden memoritzar dades d'entrenament, així que no n'hi ha prou amb no desplegar-lo: cal destruir-lo i documentar-ne la destrucció.

Què ha de fer la Marta, en aquest ordre: (1) aturar la iniciativa avui; (2) localitzar quines dades es van copiar a quin entorn i esborrar-les juntament amb el model; (3) valorar amb assessoria i el DPD si l'entrenament constitueix bretxa o incompliment notificable als clients —probablement sí com a incompliment contractual—; (4) documentar la decisió en acta; (5) afegir al procés de producte una comprovació obligatòria de privacitat des del disseny, perquè la fallada de fons no és de l'Iván: és que la proposta va arribar a implementar-se sense que ningú fes la pregunta.

Via legítima, que existeix i és viable: convertir-ho en una funcionalitat per tenant, on cada clínica és la responsable que decideix activar-la sobre les seves pròpies dades. Condicions: model entrenat i executat per tenant sense barrejar dades; la clínica actualitza la seva informació als pacients i determina la seva base jurídica; es documenta com a instrucció a l'annex de l'article 28; s'ofereix oposició senzilla; s'actualitzen RAT i AIPD. És estadísticament menys potent i és l'única forma defensable. La diferència entre una infracció greu i una funcionalitat vàlida no és a la tecnologia, és en qui decideix i sobre quines dades.

Exercici 2

És una bretxa? Sí, sense cap dubte. Hi ha comunicació no autoritzada de dades personals a un tercer: que sigui un error intern i no un atac és irrellevant, i que el destinatari sigui un client de confiança tampoc no l'elimina. És una bretxa de confidencialitat amb dades que revelen salut —312 persones identificades com a pacients d'un centre de fisioteràpia—. Rols: les dades són de pacients d'una clínica, així que la clínica afectada és la responsable i Nimbus és l'encarregat que ha causat la bretxa. Nimbus no notifica a l'AEPD: notifica a la clínica en el termini del contracte (24 h) i és ella qui decideix i notifica.

Notificar a l'AEPD? La decisió és de la clínica, però Nimbus li ha de donar els elements i una recomanació fonamentada. A favor de notificar: categoria especial, 312 afectats, identificació com a pacients d'un centre sanitari. A favor de considerar improbable el risc: destinatari únic i identificat, subjecte a confidencialitat contractual, confirmació d'esborrament sense obrir, exposició de 40 minuts i cap evidència de difusió. La recomanació prudent és notificar, perquè el llindar de l'article 33 no és «risc alt» sinó «llevat que sigui improbable que constitueixi un risc», que és un llistó baix; amb categories especials pel mig, sostenir la improbabilitat és arriscat, i no notificar i que se sàpiga després és un agreujant clar. Però és una decisió jurídica del responsable, que l'ha de prendre amb el seu DPD o assessoria: aquesta solució és material formatiu, no un dictamen. Sigui quina sigui la decisió, el raonament es documenta.

Als 312 pacients? L'article 34 exigeix risc alt. Amb destinatari únic identificat, confidencialitat contractual, esborrament confirmat sense obertura i 40 minuts d'exposició, és defensable que el risc alt no hi concorre i que no escau la comunicació individual —evitant a més una alarma desproporcionada per un incident contingut—. Convé reforçar-ho obtenint del destinatari confirmació escrita d'esborrament, no només telefònica. I en tot cas es documenta el registre de l'article 33.5: cronologia, causa arrel, categories i nombre d'afectats, destinatari i la seva confirmació, valoració del risc amb el seu raonament, decisió i qui la va prendre, i mesures correctives.

Accions correctives, on hi ha el valor real de l'exercici, perquè la causa arrel no és el Rubén. Tècnica i estructural: eliminar la possibilitat d'exportar a Excel i adjuntar a mà; els informes es generen des del sistema, filtrats per tenant, amb URL signada de 120 s al destinatari autenticat —si el fitxer no existeix fora del sistema, no es pot adjuntar al correu equivocat; és el patró de C-06—. Preventiva: avís al client de correu davant d'adjunts amb dades personals fora del domini, i retard de 60 segons que permeti cancel·lar (els 40 minuts haurien estat 0). Detectiva: revisar si el llindar de D-05 hauria disparat amb aquesta exportació i ajustar-lo. Formativa: cas anonimitzat a la píndola de 06-05. I molt important: el Rubén va detectar i reportar el seu propi error en 40 minuts, que és exactament el comportament desitjat, i se li agraeix explícitament. Sancionar-lo garantiria que el proper error es calli, i el proper podria ser de 40.000 registres. És la cultura justa de 06-05.

Exercici 3

S'estan exercint tres coses diferents, i separar-les és el primer encert: supressió (art. 17); accés (art. 15) en el seu vessant d'informació sobre destinataris i accessos —amb el matís que l'article 15 dona dret a conèixer destinataris o categories de destinataris, no automàticament el nom de cada empleat que va consultar, i cal ponderar les dades d'aquests empleats—; i una manifestació sobre transferències internacionals, que es tracta com a oposició o com a sol·licitud d'informació de l'article 15.2 sobre les garanties del capítol V.

Pas 0 — Determinació del rol, que ho condiciona tot. Diu ser pacient de Clínica Fisio Valencia, per tant Nimbus és encarregat i no pot atendre la sol·licitud. L'ha de registrar el mateix dia, redirigir-la a la clínica en 48 hores advertint que el termini d'un mes corre des de la recepció original, informar el sol·licitant de a qui s'ha remès, i oferir assistència tècnica (art. 28.3.e). Atendre-la directament seria actuar fora d'instruccions, i esborrar dades sense instrucció del responsable podria destruir informació que la clínica està obligada a conservar per normativa sanitària.

Passos 1 i 2 — Identitat i supressió. La clínica verifica amb els mitjans que ja té —codi al telèfon o correu de la seva fitxa—, sense demanar còpia del DNI. Després valora les excepcions de l'article 17.3, i aquí és molt probable que hi concorrin: obligació legal de conservació de documentació clínica i eventual defensa de reclamacions. Escenari realista: supressió parcial. Se suprimeix el que no està emparat (contacte, compte del portal, preferències, comunicacions comercials) i es bloqueja la resta —conservada, no tractada, accessible només a requeriment— durant el termini legal, explicant-ho amb claredat, perquè un «no podem esborrar-ho» sense motiu genera una reclamació segura. Tècnicament, sobre el que sí que se suprimeix, Nimbus executa sota instrucció: esborrament a la base de dades activa, a A-02, a índexs i memòries cau, i sol·licitud de supressió al proveïdor de correu; i aplica el procediment de còpies de l'apartat 6 —llista de supressions pendents, còpies no usades per reintroduir, reaplicació després de restaurar escrita al runbook, i expiració als 35 dies, termini del qual s'informa—.

Pas 3 — Qui ha consultat el seu historial. Aquí Nimbus aporta un valor que gairebé cap proveïdor no pot: la taula d'auditoria append-only de C-07, amb 12 mesos de retenció, permet generar un informe per pacient_ref amb data, hora, tipus d'accés i rol de l'usuari. La ponderació raonable és donar rol i organització —«personal administratiu del centre», «suport del proveïdor sota tiquet #4412»— en lloc de noms d'empleats; i si l'informe revelés accessos injustificats, això és un incident en si mateix i activa 04-05. Pas 4 — L'objecció als Estats Units. Es respon amb transparència i fets: allotjament i base de dades a la UE; l'única transferència és el proveïdor de correu transaccional, emparada en CCT amb avaluació TIA-2026-02, i el que es transfereix es limita a nom, correu i un recordatori sense motiu de la cita ni especialitat del centre. I s'ofereix una alternativa concreta: desactivar els recordatoris per correu i fer servir SMS o notificació a l'app, amb la qual cosa deixa d'haver-hi cap transferència respecte de les seves dades. És la resposta que resol el problema real de la persona en lloc de discutir el marc jurídic.

Pas 5 — Terminis i tancament: tot dins d'un mes des de la recepció original, no des que Nimbus el va reenviar. Si la valoració del 17.3 ho complica, pròrroga de dos mesos comunicada i motivada dins del primer mes. La resposta final, en llenguatge clar, inclou què s'ha suprimit, què es conserva bloquejat i per què, l'informe d'accessos, l'explicació de les transferències amb la seva alternativa, i sempre la menció del dret a reclamar davant l'AEPD.

Has recorregut el RGPD per on es viu de debò: en les decisions de producte, en el model de dades, a la bústia de suport i en les 72 hores següents a una mala notícia. Saps per què això afecta especialment Nimbus: l'historial de cites d'una clínica de fisioteràpia revela informació sobre la salut, encara que no hi hagi cap diagnòstic a la base de dades, i això el converteix en categoria especial de l'article 9 amb tres conseqüències —base jurídica més exigent, AIPD probablement obligatòria i llindar més baix per comunicar una bretxa als afectats—.

Manegues els conceptes amb precisió: dada personal, categoria especial, dada pseudonimitzada que continua sent dada personal —l'error que enfonsa molts projectes d'analítica— i dada anònima amb la seva tensió irreductible entre utilitat i reidentificació. I tens clara la distinció que ho ordena tot: Nimbus porta dos barrets, encarregat respecte dels pacients de les seves clíniques i responsable respecte dels seus empleats, els seus visitants web i els seus usuaris administradors; amb la frontera vermella que fer servir les dades dels clients per a una finalitat pròpia el converteix en responsable sense base jurídica, i amb el recordatori que ser encarregat no és un escut. Apliques els principis de l'article 5 amb l'anàlisi de minimització camp a camp —on el DNI resulta innecessari i la conclusió és que el camp més segur és el que no existeix— i amb una política de retenció real, executada automàticament i amb justificació escrita a cada línia. Saps triar base jurídica i per què el consentiment sol ser la pitjor opció per al nucli del servei, i que l'excepció de l'article 9 se suma a l'article 6, no el substitueix. Saps atendre els set drets amb el seu termini d'un mes prorrogable, amb els tres problemes operatius que ningú no explica: verificar identitat sense demanar el DNI, redirigir al responsable quan ets encarregat, i la solució completa al problema de suprimir algú que és dins d'una còpia immutable —esborrament actiu, llista de supressions, reaplicació després de restaurar escrita al runbook, i expiració als 35 dies—.

Tens les obligacions documentals resoltes: un RAT complet amb les seves dues seccions —responsable i encarregat— i entrades reals emplenades, i una AIPD amb el seu contingut de l'article 35.7 i l'error que l'arruïna, que és copiar l'anàlisi de riscos de seguretat en lloc de mesurar el dany a les persones. Saps traduir l'article 25 a decisions concretes de producte, inclosa la més barata de totes: preguntar «aquesta dada és necessària?» a la plantilla de pull request. I tens la taula que connecta cada exigència de l'article 32 amb la feina del mòdul 5, amb l'apartat que gairebé ningú no compleix —32.1.d, verificar regularment l'eficàcia— assenyalat com l'objecte de la propera lliçó. Domines el contracte de l'article 28 amb les seves clàusules obligatòries, la cadena de subencarregats amb la regla que externalitzar l'execució no externalitza la responsabilitat, i les transferències internacionals que passen sense que ningú se n'adoni —inclòs l'accés remot des de fora de l'EEE—, amb la solució més elegant per al cas de Nimbus: minimitzar el contingut del recordatori fins a treure la salut de la transferència. I has analitzat l'incident de 02-06 sota el RGPD amb el seu rellotge de 72 hores des del coneixement i no des de la certesa, la notificació esglaonada, el fet que el retard de Nimbus consumeix el termini dels seus 40 clients, per què el xifratge en repòs no va salvar de comunicar-ho als afectats quan l'atacant tenia les claus, i com els 20 dies de dwell time agreugen la valoració de l'article 83.2. Amb la plantilla de comunicació als afectats i les seves quatre decisions de redacció. Tanques amb el DPD —probablement obligatori, extern, independent i sense conflicte d'interessos—, els dos nivells sancionadors, el que l'AEPD demana de debò quan arriba, i el quadre de qui notifica a qui entre Nimbus i les clíniques.

I fixa't en el que ha aparegut una vegada i una altra en aquesta lliçó: RAT, contractes, registre de bretxes, informes de restauració, evidència de les mesures de l'article 32, documents datats abans de l'incident. El RGPD no premia estar segur: premia poder demostrar-ho, i en diu responsabilitat proactiva. El mateix demanava NIS2, el mateix demana un auditor d'ISO 27001 i el mateix demana el client amb el seu qüestionari de 90 preguntes. A Compliment i Auditoria (06-04) convertim aquesta exigència en un sistema: què fa vàlida una evidència, com s'automatitza la seva recollida perquè l'auditoria deixi de ser tres dies de pànic, com es completa la matriu de traçabilitat que arrosseguem des de 04-03, com es comporta un auditor de debò i què pregunta quan demana una mostra, i com es respon a una troballa sense discutir ni exagerar. Tota la feina tècnica del mòdul 5 va deixar un rastre; ara el recollirem.