Știu că a reînceput sezonul cursurilor de GDPR în care învățăm cum să fim compliant și cum să interpretăm cât mai bine o lege concepută a încurca mai mult decât a descurca. Dar, înainte de a ști dacă și cum trebuie să păstram dovada consimțământului userilor (ori nu am uitat de vreuna dintre aceste reguli de pe când existau bătrânele directive data privacy), cred că este necesar să aflăm dacă GDPR-ul ni se aplică sau nu. Nu de alta, dar, cu siguranță, vor exista în cursul activității noastre numeroase ocazii în care clientul/clienții vor încerca să ne convingă că suntem ori intermediari, ori operatori, ori și una și alta sau că, indiferent de situație trebuie să semnăm un contract ori o anexă GDPR pentru că ne obligă „mama corporație”.
Prima recomandare ar fi să nu va aruncați să semnați orice contract cu prevederi GDPR și când spun contract, mă refer inclusiv la orice înscris, fie acesta sub forma unei anexe sau declarații unilateriale. Dacă un contract necesită avizul unui avocat cu atât mai mult unul care conține o răspundere pe gdpr. Nu de alta, dar, chiar dacă pare echitabil, cu clauze aplicabile ambelor părți sau fără vreo răspundere programată a funcționa sub forma unei despăgubiri, șansele de a vă asuma mai mult decât puteți duce sunt destul de mari. Și asta, pentru că acest GDPR a adus cu sine un soi de luptă pentru supraviețuire în care sunt antrenate și multe companii tech precum deținători platforme online, dezvoltatori software, hosting provideri, etc. Între acestea și realii operatori de date cu caracter personal a început o adevărată fugă de răspundere, fiecare dorind să arunce maimuța în brațele cui poate să o ducă întrucât, știți și voi, companii cu resurse îndeajuns cât să implementeze cap coadă impunerile GDPR, sunt destul de puține.
Scriu acest articol pentru că m-am întâlnit recent cu o situație în care, chiar fără o implicare la nivelul datelor cu caracter personal, partenerul contractual propunea semnarea unui acord în conformitate cu dispozițiile gdpr. Este clar, adevărata și, poate, cea mai semnificativă schimbare (din punctul meu de vedere) pe care a adus-o acest GDPR constă în faptul că a atras după sine o răspundere în dauna industriei IT și în beneficiul realilor operatori de date, majoritatea firmelor tech fiind, în prezent, forțate să suporte calitatea de procesator de date cu caracter personal doar pentru că există un acces la date sau o minimă stocare, chiar dacă aceasta este tranzitorie, chiar dacă aceasta este accesorie, chiar dacă aceasta este operată pentru îndeplinirea unor obligații de securitate și culmea, chiar dacă aceasta, nereprezentând un serviciu distinct de cel furnizat, nu este remunerată.
Dincolo de aceste situații în care, cel mai probabil, nu putem face nimic, un minim acces la date însemnând prelucrare, există și altele, f importante, și de care trebuie să se țină cont, care implică dezvoltatorii software și care nu presupun aplicabilitatea gdpr.
Exemplul foarte bun ar fi acela al dezvoltării unor aplicații, desktop ori mobile, destinate a fi utilizate de către client (exclusiv sau de clienții/clientul clientului) și nu de dezvoltator. Indiferent de modalitatea în care aceste aplicații vor funcționa, chiar dacă prin utilizarea acestor aplicații se va ajunge la vreun acces la datele personale ale anumitor persoane fizice, dacă dezvoltatorul a creat doar aplicația (design și sau implementare) răspunderea acestuia nu trebuie să privească prelucrarea de date. Într-o asemenea situație, chiar dacă aplicația va fi folosită cu precădere pentru prelucrarea de date cu caracter personal, regulamentul GDPR nu trebuie să îi fie aplicabil dezvoltatorului software.
De cele mai multe ori aceste lucruri nu trebuie lăsate la voia întâmplării în sensul că simplul refuz al semnării unui acord gdpr nu ne poate absolvi de răspundere, fiind de preferat să existe o clauză clară în care să fie precizată răspunderea fiecărei părți, respectiv neasumarea acesteia cu privire la prelucrarea de date cu caracter personal ce urmează a se realiza prin utilizarea aplicației respective. Și asta pentru că multe aspecte pot fi interpretate diferit ulterior semnării unui contract, mai ales când interpretarea stă la mâna unei persoane care nu a cunoscut nici una dintre părți și care va trebui să înțeleagă de ce cel care a dezvoltat o aplicație programată pentru a înregistra nume și adrese de email, nu trebuie să răspundă pentru modalitatea în care aceste nume și adrese de email sunt înregistrate efectiv.
Trebuie să ținem cont și de faptul că, indiferent de semnarea sau nu a unui contract în acest sens, regulamentul gdpr poate fi în egală măsură aplicabil, cunoscut fiind faptul că obligațiile dintre părți urmează a fi interpretate inclusiv în funcție de ceea ce legea (adica inclusiv gdpr) și uzanțele prevăd.
Conexat cu asta, îmi aduc aminte de ceea ce un drag „profesor” încerca să își învețe elevii, atrăgând atenția asupra faptului că marele avantaj al unui contract consta nu în ceea ce este scris în acesta ci în ceea ce este exclus.
Revenind la GDPR, așa cum am explicat mai sus, chiar fără a fi menționat în expres ca aplicabilitate, el poate fi impus în cazul în care operațiunile vreunei părți vor fi interpretate a presupune vreo prelucrare de date cu caracter persoanal, și este de preferat să nu riscăm ca activitatea noastră să fie ulterior considerată a avea vreo legătură cu aceasta. Un scurt disclaimer nu ar strica în care părțile să recunoască neimplicarea dezvoltatorului la nivelul datelor cu caracter personal ce vor urma a fi prelucrate prin utilizarea aplicației de către client. În felul acesta dezvoltarea va fi clar înțeleasă a exclude orice formă de acces la date și nimeni nu va putea să susțină că am fi fost obligați să consiliem în vreun fel clientul în ceea ce privește maniera în care datele vor fi preluate de la useri și prelucrate efectiv.
Știu că sună absurd, dar printre acele multe obligații impuse unui intermediar ( a propos de asta, cât de neutru sună “traducerea” în română a calității de “processor”) este și aceea de a “consilia” operatorul cu privire la conformitatea cu GDPR, a se vedea art.28 (1) lit.e) și h) în care procesatorul (intermediarul) trebuie să ofere asistență tehnică și organizatorică pentru îndeplinirea anumitor sarcini puse în seama operatorului (echitabil, nu?). Ei bine, aceasta și alte asemenea absurdități ar fi bine să fie evitate, mai ales când aplicația reprezintă un software la comandă, realizat exclusiv la instrucțiunile clientului, pus în brațele acestuia pentru a și-l asuma complet.
Este posibil ca demarcația să fie fină între ceea ce reprezintă o minimă implicare la nivel de date și ceea ce nu va putea fi prelucrare mai ales în situația în care aplicație este dezvoltată tocmai pentru a prelucra date cu caracter personal.
Poate este mai ușor dacă am pleca de la un exemplu de aplicabilitate GDPR, cazul unui dezvoltator software care nu doar dezvoltă aplicația dar oferă și servicii mentenanță, activitate care poate prespune accesul la anumite date ce vor fi stocate, colectate, organizate de aplicație. Un alt exemplu de aplicabilitate GDPR ar mai fi și acela în care dezvoltarea în sine a aplicației a necesitat accesul la anumite baze de date puse la dispoziție de către client. În această ultimă situație, o limitare a răspunderii se poate totuși negocia întrucât prelucrarea a avut o perioadă de timp limitată și ocazionată doar de dezvoltare, la predarea proiectului dezvoltatorul fiind descărcat practic de astfel de atribuții. Dincolo de aceste exemple stă cazul proiectului conceput exclusiv pe marginea indicațiilor clientului, în care dezvoltatorul și-a asumat doar prestarea unor servicii de dezvoltare software la comandă, aplicația urmând să fie folosită ulterior de către client potrivit propriilor interese.
Pentru a fi și mai evidente lucrurile, întotdeauna când vi se pune la îndoială calitatea de simplu dezvoltator, să citiți cu atenție ceea ce însuși gdpr-ul definește a fi prelucrare de date cu caracter personal:
orice operaţiune sau set de operaţiuni efectuate asupra datelor cu caracter personal sau asupra seturilor de date cu caracter personal, cu sau fără utilizarea de mijloace automatizate, cum ar fi colectarea, înregistrarea, organizarea, structurarea, stocarea, adaptarea sau modificarea, extragerea, consultarea, utilizarea, divulgarea prin transmitere, diseminarea sau punerea la dispoziţie în orice alt mod, alinierea sau combinarea, restricţionarea, ştergerea sau distrugerea;
Câteva caracteristici merită a fi reținute: prelucrarea nu va putea fi acțiunea ocazională de reținere a unei adrese de email, prelucrarea se va efectua asupra unor date sau a unui set de date, trebuind așadar să existe mai multe astfel de date, o suită, un set, prelucrarea trebuie să implice un minim acces (orice tip într-adevăr, dar acces să fie) și nu orice date sunt date personale ci doar cele care corespund persoanelor fizice.
Așadar fără acces nu există prelucrare iar fără prelucrare nu există gdpr. J
